Date: Mon, 16 Mar 1998 13:28:38 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Anthony DOT Appleyard AT umist DOT ac DOT uk
cc: DJGPP AT delorie DOT com
Subject: Re: Clobbered
In-Reply-To: <57D90ADC@fs2.mt.umist.ac.uk>
Message-ID: <Pine.SUN.3.91.980316132819.13570C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Fri, 13 Mar 1998, Anthony.Appleyard wrote:

> What the rules for deciding whether longjmp may `clobber' a particular local
> variable or a `*this'? (I never use vfork().)

This is clearly explained in the GCC manual (type "info gcc invoking
warning" and search for ``longjmp''):

        * A nonvolatile automatic variable might be changed by a call to
          `longjmp'.  These warnings as well are possible only in
          optimizing compilation.

          The compiler sees only the calls to `setjmp'.  It cannot know
          where `longjmp' will be called; in fact, a signal handler
          could call it at any point in the code.  As a result, you may
          get a warning even when there is in fact no problem because
          `longjmp' cannot in fact be called at the place which would
          cause a problem.

The problem is that GCC assumes that any local variable not declared
`volatile' may be clobbered.  `longjmp' restores the stack state to
what `setjmp' has recorded, but depending on where was the local
variable stored (in a register, on the stack, or in memory) when
`longjmp' is called, you may or may not get it restored.

The easiest solution is to declare the variable `volatile' (and have
some sub-optimal optimization).  Or just live with the warning.