Paolo Bonzini <[EMAIL PROTECTED]> writes: >> However, prudence suggests that, if a maintainer >> expresses no preference, the Autoconf default should prefer >> safety to speed when we get into tricky areas like this. > > I disagree. One such bug (and one in loops, in particular) went > unnoticed for 11 years: see the loop.c hunk in > > http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02126.html
Sorry, I don't understand the point of this reference. Are you saying that -fwrapv sometimes speeds things up? Or that -O2 without -fwrapv is often harmless in practice? (The URL suggests both things.) If so, I agree. But the point here is that sometimes -O2 without -fwrapv does break applications, whereas in practice -O2 -fwrapv does not break them. Hence -O2 -fwrapv is a safer default choice than plain -O2. > if (~((time_t) 0) > 0) > { > /* time_t is unsigned. */ > time_t_max = ~(time_t) 0; > time_t_min = 0; > } > else > { > /* time_t is signed. */ > time_t_min = ((time_t)1) << (sizeof (time_t) * CHAR_BIT - 1); > time_t_max = ~time_t_min; > } First, this proposed replacement code isn't portable either. It assumes that there are no padding bits in signed integers. It also assumes that the compiler will not complain about the integer overflow in signed left shifts like 1<<31. Neither of these assumptions is safe in practice, which is why the gnulib code is written the way it is. So this change, while fixing one portability problem, introduces others. Second, this replacement doesn't fix the integer overflow issue that actually broke gnulib with beta gcc -O2. The actual problem was five or ten lines away, but you didn't see it. Please see <http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00084.html> for the fix that actually works. I hope this example helps to explain why this issue reaallly gives me the willies. It's easy for a compiler developer to say "Oh, your code is broken, go fix it!" But the code here is not broken -- it merely assumes C99 + wrapping LIA-1, which is a perfectly reasonable assumption -- and fixing the code to be portable to uncooperative C99 platforms is not at all as trivial as one might naively think. The problem causes a lot of bugs for unwary application developers, and rewriting the code to be portable would cause a lot of makework hassle for the wary. Obviously there will be some programs for which omitting -fwrapv is a real performance win, just as -ffast-math can be a real performance win. With the patch I'm thinking of for Autoconf, maintainers will be able to specify either of these possibilities. So all we're really arguing about here is what should be the default. For most GNU programs, I'd guess the performance changes for -fwrapv (whether positive or negative) are unmeasurable, or nearly so. But -fwrapv's reliability advantages are undeniably positive. So the default seems like a easy call.