Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Paul Eggert]

Paolo Bonzini <address@hidden> 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.