Joe Buck <[EMAIL PROTECTED]> 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
