Tanaka,

It's interesting that you should point this out, because I started this
debugging adventure by building a version of eval.c that would compile
without these warnings.  I ended up with many more volatile qualifiers and
useless initializations and the code still didn't work.

Later I found this text in the gcc manual:
"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."

There is a similar problem with uninitialized variable warnings.  The
compiler cannot predict the code's dynamic execution paths and so may emit
false positives.

So, it looks like the gcc project has yet to replace folks like us.
That's comforting in these troubled times. :-)

- brent


Tanaka Akira-3 wrote:
> 
> In article <49a9024b.0e0d6e0a.11f5.ffffee2f / mx.google.com>,
>   Nobuyoshi Nakada <nobu / ruby-lang.org> writes:
> 
>> I guess you misses a point here, gcc is aware of setjmp() and
>> emits code to save and restore registers into the stack before
>> and after it.  I suspect it doesn't work enough for some reason.
>> Anyway, your way would be correct for other compilers.
> 
> gcc -O -W warns it.
> 
> % gcc -O2 -g -W -Wall -Wno-parentheses  -DRUBY_EXPORT  -I. -I.    -c
> eval.c             
> ...
> -- 
> Tanaka Akira
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/MBARI8-patch-fixes-bugs-caused-by-incorrect-volatile-variable-declarations-tp22259357p22265962.html
Sent from the ruby-core mailing list archive at Nabble.com.