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