Path: utzoo!utgpu!watmath!uunet!umbc3!alex From: alex@umbc3.UMD.EDU (Alex S. Crain) Newsgroups: unix-pc.general Subject: Re: Gcc 1.26 available for anonymous Internet FTP Message-ID: <1413@umbc3.UMD.EDU> Date: 6 Dec 88 00:40:18 GMT References: <444@manta.pha.pa.us> <11760@cup.portal.com> <1375@umbc3.UMD.EDU> <10628@stb.UUCP> Reply-To: alex@umbc3.UMD.EDU (Alex S. Crain) Distribution: unix-pc Organization: University of Maryland, Baltimore County Lines: 49 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