IMHO, performing code review of the whole tree for missing volatile
keywords
would be a waste of time compared to do it on a case by case basis.
Simply
keep in mind that those bugs may happen - especially with "aggressive" compilers such as gcc 2.96. If a bug didn't happen with the previous compiler and does show up with the latest release, it might be a good candidate.
But the point is, this is *not* a Wine bug that was just exposed by a new compiler -- this is a compiler bug, plain and simple.
Did I write it was a WINE bug? No. It is very clear for me that it *is* a compiler issue.
I had three choices
a) find a workaround and have people comment on it; b) disable the optimize phase for gcc 2.96 and have the whole community on my back; c) fix gcc.
I went for the easy one.
Making these variables 'volatile' is not required at all -- 'volatile' tells the compiler that the variables might be changed behind the compiler's back, e.g. due to being asynchroneously modified by a signal handler or something like that. In this particular case, however, the variables are not only not changed behind the compiler's back, they are *never* changed at all!
100% agree. Again, it's a quick-yet-efficient workaround to the compiler problem that just happened to work. While volatile is for variables that are modified by external factors, it was a good way to prevent all the optimization - which was just what I wanted.
Instead of circumventing the compiler bug in this particular case, it might be preferable to find out which optimization phase contains the bug, and write a configure check that switches that phase off if it detects the bug (like we did with the 2.95.2 strength-reduce bug).
We'll do some research on the optimization phase. Once we found it, can anybody help us with that autoconf kungfu?
Ciao! Francois