brant@manta.pha.pa.us (Brant Cheikes) (11/19/88)
With the help of Alex Crain, executables of Gnu CC version 1.26 (compiled for UNIXpc, version 3.51, with the shlib) are now available for anonymous Internet FTP from host linc.cis.upenn.edu in pub/unixpc/gcc.tar.Z. This file will be updated when a more current and stable Gcc becomes available (the current version is 1.30, but the optimizer doesn't work properly). NB: FTP service is not available to uucp-only sites. I may make a few other things similarly available in the future. If anyone has any suggestions, please let me know. -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science brant@manta.pha.pa.us, brant@linc.cis.upenn.edu, bpa!manta!brant
thad@cup.portal.com (Thad P Floryan) (11/25/88)
Brant Cheikes writes:
With the help of Alex Crain, executables of Gnu CC version 1.26
(compiled for UNIXpc, version 3.51, with the shlib) are now available
for anonymous Internet FTP from host linc.cis.upenn.edu in
pub/unixpc/gcc.tar.Z. This file will be updated when a more current
and stable Gcc becomes available (the current version is 1.30, but the
optimizer doesn't work properly).
WHAT problems exists with the optimizer in GCC 1.30? I just acquired most of
the GNU distribution from osu-cis, brought up GNU EMACS 18.52 without a hitch,
and was about to start on gcc, gas, etc.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]alex@umbc3.UMD.EDU (Alex S. Crain) (11/27/88)
In article <11760@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >WHAT problems exists with the optimizer in GCC 1.30? I just acquired most of >the GNU distribution from osu-cis, brought up GNU EMACS 18.52 without a hitch, >and was about to start on gcc, gas, etc. I've heard of gcc's optimiser bugs from various sources, but I've never actually *seen* any. gcc does exibit some behavour that is different from both the berkeley and SGS compilers, and will bring out various bugs in code that are not present under othe rcompilers, bucause of code restructuring, etc. gcc is particlarly obnoxious with regard to setjmp() / longjmp(), because of the way variables are placed in registers (which are *not* saved/restored by setjmp()/longjmp(). One mans bug is another mans feature, so make of it what you will. -- :alex. Systems Programmer nerwin!alex@umbc3.umd.edu UMBC alex@umbc3.umd.edu
michael@stb.UUCP (Michael) (12/05/88)
In article <1375@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: >restructuring, etc. gcc is particlarly obnoxious with regard to setjmp() / >longjmp(), because of the way variables are placed in registers (which >are *not* saved/restored by setjmp()/longjmp(). W h a t ? Setjmp/longjmp take a jmpbuf as an argument; in every 68000 system I've seen, this is an array big enough to store a movem d0-d7/a0-a6 (13 longs). So a setjmp/longjmp can (and do elsewhere) save registers and register variables. Or am I missing what you mean by saving register variables? Michael : --- : Michael Gersten uunet.uu.net!stb!michael : crash!gryphon!denwa!stb!michael : Coff Coff <=== Stop smoking.
alex@umbc3.UMD.EDU (Alex S. Crain) (12/06/88)
In article <10628@stb.UUCP> michael@stb.UUCP (Michael) writes: >W h a t ? Setjmp/longjmp take a jmpbuf as an argument; in every 68000 system >I've seen, this is an array big enough to store a movem d0-d7/a0-a6 (13 >longs). So a setjmp/longjmp can (and do elsewhere) save registers and >register variables. > >Or am I missing what you mean by saving register variables? Sorry, I wasn't very clear. From the GCC internals document.... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% When you use setjmp and longjmp, the only automatic variables guaranteed to remain valid are those declared volatile. This is a consequence of automatic register allocation. Consider this function: jmp_buf j; foo () { int a, b; a = fun1 (); if (setjmp (j)) return a; a = fun2 (); /* longjmp (j) may be occur in fun3.} */ return a + fun3 (); } Here a may or may not be restored to its first value when the longjmp occurs. If a is allocated in a register, then its first value is restored; otherwise, it keeps the last value stored in it. If you use the -W option with the -O option, you will get a warning when GNU CC thinks such a problem might be possible. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-- :alex. Systems Programmer nerwin!alex@umbc3.umd.edu UMBC alex@umbc3.umd.edu
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (12/06/88)
In article <10628@stb.UUCP> michael@stb.UUCP (Michael) writes: >In article <1375@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: >>restructuring, etc. gcc is particlarly obnoxious with regard to setjmp() / >>longjmp(), because of the way variables are placed in registers (which >>are *not* saved/restored by setjmp()/longjmp(). > >W h a t ? Setjmp/longjmp take a jmpbuf as an argument; in every 68000 system >I've seen, this is an array big enough to store a movem d0-d7/a0-a6 (13 >longs). You're correct. Despite his asterisk-emphasized "*not*", I think Alex knew what he was saying but just got the polarity of his sentence backward :-). setjmp/longjmp *do* save/restore registers, and that is, indirectly, what makes some programs break. Some code assumes that all variables which are *not* declared as "register" will *not* be saved/restored by setjmp/longjmp. This is true with simple-minded compilers, but it is not true of gcc, and ANSI C specifies that *no* assumptions may be made about this behavior. In fact, I think it says that values of any automatic variables are undefined after setjmp() returns via longjmp(). -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com