This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Illegal optimization in presence of setjmp


> 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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]