This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Illegal optimization in presence of setjmp
- To: Luc Bouge <bouge at ens-lyon dot fr>
- Subject: Re: Illegal optimization in presence of setjmp
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Mon, 08 Jan 2001 17:56:11 +0000
- Cc: gcc-bugs at gcc dot gnu dot org, Luc dot Bouge at ens-lyon dot fr
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> In my manual page, this is specified explicitely:
>
> -W Print extra warning messages for these events:
>
> o A nonvolatile automatic variable might be changed by a
> call to longjmp. These warnings are possible only in
> optimizing compilation.
Yes, but you used -Wall, not -W, which is different. Note, you only get
the warning if the optimizer is also turned on (Without that, gcc does not
do enough flow analysis to detect the problem). Certainly I get the
warning with egcs-1.1.2 and the current CVS code for your first example.
>
> Actually, it does in some cases, and I cannot find any easy rule
> to predict these cases. For instance, I considered using two variables
> instead of one as in the modified program below.
Subtle changes to your source can affect what ends up in a register and
what doesn't. It's not a reliable way of fixing the real problem in your
code (which is the missing volatile).
> My intuitive feeling is that the compiler **should** issue a warning as
> soon as it applies an optimization whose correctness is not guaranteed,
> as in case (1). As a programmer, I guess I expect the semantics of my
> program be invariant with respect to the level of optimization.
Yes, if your program conforms to the rules for the language, that is a
reasonable expectation -- if you step outside those bounds then all bets
are off. Fundamentally this is no different from expecting i++ + ++i to
return the value you want -- both have undefined behaviour and so the
optimizer may chose a different meaning.
Richard.