Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Tue, Jun 28, 2005 at 10:23:51AM +0300, Michael Veksler wrote:
| 
|  
|  On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
| > > >  So,
| > > > please, do refrain from reasoning like "since we did X for Y and Y was
| > > > undefined behaviour, we should do the same for Z."  "Undefined
| > > > behaviour" isn't a 0 or 1 thingy, even though it is about computers.
| > > > You need to evaluate them on case-by-case basis.
| 
| Andrew Pinski wrote on 28/06/2005 08:34:25:

I think there is a slight misattribution in your message.  The example
was given my Michael.

[...]

| Consider a processor whose integer addition instruction wraps.  Then
| the cheapest implementation for examples 1 and 2 above that cover the
| defined cases is to eliminate the loop in case 1, and produce a modulo
| result in case 2.  You worried about interaction between the two
| constructs.  Consider
| 
|     /* int a, b, c; */
|     if (b > 0) {
| 	a = b + c;
| 	int count;
| 	for (int i = c; i <= a; i++)
| 	    count++;
| 	some_func(count);
|     }
| 
| Since behavior on integer overflow is undefined, we can optimize assuming
| that overflow has not occurred.  Then a > c, so the for loop always
| executes b+1 times, and we end up with
| 
|     if (b > 0)
| 	some_func(b+1);
| 
| Any attempt to assign meaning to integer overflow would prevent this
| optimization.

We document that  
    
    a = (int) ((unsigned) b + c)

is well-defined and given by the wrapping semantics.  Does the current
optimizer takes that into account or will it assume b+1 execution times?

If the optimizer takes that into account, then the question becomes
when do we consider breaking the ABI to switch numeric_limits<signed
type>::is_modulo back to old behaviour.

-- Gaby