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.
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!
If the compiler generates incorrect code here, this is just a bug, probably somewhere in the common subexpression elimination (or maybe reload) code. Now if the compiler has this bug, it might manifest itself also at different places -- which we *cannot* find by a code review, as the code itself is completely correct ...
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).
Bye, Ulrich