Bernd Schmidt <[EMAIL PROTECTED]> writes: > Paul Eggert wrote: >> But so far, benchmark scores are the only scores given by the people >> who oppose having -O2 imply -fwrapv. > > And you expect real-world results will be different because...?
Because of the (admittedly limited) real-world measurements I've done with gzip and sha512sum, comparing -O2 to -O2 -fwrapv on x86. These were mentioned in <http://gcc.gnu.org/ml/gcc/2006-12/msg00870.html>, and showed that -fwrapv made little difference for those two cases. No other real-worldish measurements comparing -O2 to -O2 -fwrapv has been mentioned in this forum, as far as I know. > Has an example of code that actually breaks with a new gcc but not an > old one been posted in this thread yet? Sure, this whole thread started from one such example: http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00084.html (Note that the fix proposed there isn't sufficient in general, as the resulting code still assumes wrapv elsewhere.) And here is a bit more discussion: http://gcc.gnu.org/ml/gcc/2006-12/msg00607.html The code in question has already been fixed in CVS, so that's not really the issue; the issue is what other gotchas are lurking out there. > the burden of proof should be on the people who are surprised > that interesting things happen when they write in a language that > isn't C To repeat myself a bit, let's move beyond rhetoric like "a language that isn't C". There's nothing weird or unusual about assuming wrapv semantics in C programs. As we've seen it is common practice dating back to Unix source code in the 1970s, and (if you want to be pedantic) C99 Annex H with LIA-1 wrapping semantics gives a standard for it.