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

[Richard Kenner]

> But since you asked, I just now did a quick scan of
> gcc-4.3-20061223 (nothing fancy -- just 'grep -r') and the first
> example I found was this line of code in gcc/stor-layout.c's
> excess_unit_span function:
> 
>   /* Note that the calculation of OFFSET might overflow; we calculate it so
>      that we still get the right result as long as ALIGN is a power of two.  
> */
>   unsigned HOST_WIDE_INT offset = byte_offset * BITS_PER_UNIT + bit_offset;
> 
> Here, the programmer has helpfully written a "Danger, Will
> Robinson!" comment, which is how I found this example so quickly.
> Typically, though, we won't be so lucky.

That code's pretty strange, for a number of reasons, and has a number
of errors.  First of all, align is unsigned int, not the signed
HOST_WIDE_INT.  Secondly, precisely because of overflow, we're careful
everywhere else in that part of the compiler to do all arithmetic with trees,
so the precision is twice HOST_WIDE_INT, not HOST_WIDE_INT.  The code,
as written, only does the adjustment if OFFSET fits in signed HOST_WIDE_INT
and that's wrong too.

This is badly broken code, so if not wrapping breaks it, that would be a GOOD
thing!

> I'd guess there are dozens, maybe hundreds, of cases like this in
> the GCC sources.

I wouldn't.  As I said, that's really broken code.  For any code in a similar
form (and I agree there's some, but not much), I can demonstrate a failure
mode that DOESN'T involve wrapping semantics.  A lot of this code (luckily
not that piece!) is code that I wrote and I was EXTREMELY careful to avoid
doing computations of objects that might overflow as integers instead of
trees.  I'm not saying there are no bugs, just that if there ARE, I think
it's good that the issue of wrapping semantics would make them more visible
because they each represent poor quality code that needs to be fixed.

> Nor would I relish the prospect of keeping wrapv assumptions out of
> GCC as other developers make further contributions, as the wrapv
> assumption is so natural and pervasive.

It's neither natural not pervasive to me!  I would never write code that way
on the grounds that depending on overflow makes the code harder to read
because it's no longer as intuitive as code that doesn't depend on overflow
behavior.