poage@sunny.ucdavis.edu (Tom Poage) (01/15/91)
FYI, op.dbm has an infinite while loop when patch
level 44 is compiled with gcc (1.37.1) on a Sun-3 (4.0.3).
Apparently, reading from an empty ndbm file returns nulls
(as opposed to undefs or EOF).
...
print (dbmopen(h,'Op.dbmx',0640) ? "ok 1\n" : "not ok 1\n");
...
while (($key,$value) = each(h)) {
$i++;
}
rint (!$i ? "ok 3\n" : "not ok 3\n");
Sorry, haven't looked into it yet. Anybody else? It may have always
been broken, since op.dbm was just added in this release (I think).
Also ... cc (Sun's) barfs if you try any kind of optimization.
Sometimes because the compile is too big (eval.c), sometimes because
/lib/iropt grows out of its allotted space. I guess more stack and/or
swap (though I've got 40MB) may be indicated.
I'll see what I can find.
--
Tom Poage, Clinical Engineering
Universiy of California, Davis, Medical Center, Sacramento, CA
poage@sunny.ucdavis.edu {...,ucbvax,uunet}!ucdavis!sunny!poagepoage@sunny.ucdavis.edu (Tom Poage) (01/16/91)
In article <585@sunny.ucdavis.edu> I write: >FYI, op.dbm has an infinite while loop when patch >level 44 is compiled with gcc (1.37.1) on a Sun-3 (4.0.3). >Apparently, reading from an empty ndbm file returns nulls >(as opposed to undefs or EOF). Drat. I somehow trashed the -fpcc-struct-return definition. Yes, it passes all tests (thanks, Larry). >Also ... cc (Sun's) barfs if you try any kind of optimization. >Sometimes because the compile is too big (eval.c), sometimes because >/lib/iropt grows out of its allotted space. I guess more stack and/or >swap (though I've got 40MB) may be indicated. I got the whole thing to compile with -O, but -O4 dies (it doesn't get past perl.c, and I didn't try any other -O? types) after eating up nearly all 40MB of swap space over about a 30 minute period (unloaded machine). If cc takes that much to build it, I'll pass [1/2 :-)]. Sorry for the almost false alarm. Tom. -- Tom Poage, Clinical Engineering Universiy of California, Davis, Medical Center, Sacramento, CA poage@sunny.ucdavis.edu {...,ucbvax,uunet}!ucdavis!sunny!poage
rob@array.UUCP (Rob Marchand) (01/16/91)
In article <586@sunny.ucdavis.edu> poage@sunny.ucdavis.edu (Tom Poage) writes: > >I got the whole thing to compile with -O, but -O4 dies (it >doesn't get past perl.c, and I didn't try any other -O? types) >after eating up nearly all 40MB of swap space over about a 30 >minute period (unloaded machine). If cc takes that much to build >it, I'll pass [1/2 :-)]. > >Sorry for the almost false alarm. Tom. >-- I've built several perl versions on a Sun 3/160 with 16MB of memory, and (I think) around 30-40MB of swap. I used -O3 on all routines except toke.c and eval.c (also ttoke.c and teval.c too, of course). As you note, the optimizer (for Sun cc) gets itself into a tizzy and chomps on memory until it runs out of VM (an error from getpage()). I dropped to -O2 for those two. Perl, patchlevels 18, 28(?) and 44 passed all tests, and has given no problems so far (although now that I've said it, things will probably start to fall apart :-) Takes a while to build at those optimization levels though, and I'm not sure that I gain anything by bumping it up that high. Oh well. By the way, perl is a great package; just have to get the book now! Cheers! Rob Marchand -- Rob Marchand UUCP : uunet!attcan!lsuc!array!rob Array Systems Computing ARPA : rob%array.UUCP@uunet.UU.NET 401 Magnetic Drive, Unit 24 Phone : +1(416)736-0900 Fax: (416)736-4715 Downsview, Ont CANADA M3J 3H9 Telex : 063666 (CNCP EOS TOR) .TO 21:ARY001
mitch@hq.af.mil (Mitch Wright) (01/17/91)
/* * On 14 Jan 91 21:35:02 GMT, * poage@sunny.ucdavis.edu (Tom Poage) said: * */ Tom> FYI, op.dbm has an infinite while loop when patch Tom> level 44 is compiled with gcc (1.37.1) on a Sun-3 (4.0.3). Tom> Apparently, reading from an empty ndbm file returns nulls Tom> (as opposed to undefs or EOF). I had the same problem, but subsequently canceled the article after receiving a blindingly fast reply from Larry. The problem is probably due to the fact the -fpcc-struct-return was not in your CFLAGS. That alone fixed the problem for me. Good Luck! ..mitch
aas@aase.nr.no (Gisle Aas) (01/18/91)
In article <MITCH.91Jan16133824@hq.af.mil> mitch@hq.af.mil (Mitch Wright) writes:
Tom> FYI, op.dbm has an infinite while loop when patch
Tom> level 44 is compiled with gcc (1.37.1) on a Sun-3 (4.0.3).
Tom> Apparently, reading from an empty ndbm file returns nulls
Tom> (as opposed to undefs or EOF).
I had the same problem, but subsequently canceled the article after
receiving a blindingly fast reply from Larry.
The problem is probably due to the fact the -fpcc-struct-return was
not in your CFLAGS. That alone fixed the problem for me.
I experience the same problem when compiling perl (3@44) using gcc on
Sun Sparcstation (SunOS 4.1). The -fpcc-struct-return flag is _NOT_
missing. No problem when using the SunOS cc compiler. Any ideas?
I have no problems using gcc on Sun-3 platforms.
--
Gisle Aas | snail: Boks 114 Blindern, N-0314 Oslo, Norway
Norsk Regnesentral | X.400: G=Gisle;S=Aas;O=nr;P=uninett;C=no
voice: +47-2-453561 | inet: Gisle.Aas@nr.nopcn@daimi.aau.dk (Peder Chr. N|rgaard) (01/19/91)
aas@aase.nr.no (Gisle Aas) writes: >I experience the same problem when compiling perl (3@44) using gcc on >Sun Sparcstation (SunOS 4.1). The -fpcc-struct-return flag is _NOT_ >missing. No problem when using the SunOS cc compiler. Any ideas? Yes, this is an error, or whatever you choose to call it, in gcc code generation for the Sparc architecture. The function call it generates is not compliant with the SPARC standards - something about not putting in the size of the result of a function call. Whatever the reason, a program compiled with gcc 1.37.1 cannot call a function from Sun's libc if that function returns more than four bytes. Which the dbm routines do. I had other problems with using gcc for compiling perl (some strange things happened with fork calls) and eventually gave it up as a bad job and stuck to Suns cc. -- Peder Chr. Norgaard **** pcnorgaard@daimi.aau.dk Computer Science Department, Aarhus University Ny Munkegade 116, DK-8000 Aarhus C, DENMARK phone: +45 86 12 71 88 / telefax: +45 86 13 57 25 / telex: 64767 aausci dk