> The burden of proof ought to be on the guys proposing -O2
> optimizations that break longstanding code, not on the skeptics.
There's also a burden of proof that proposed optimizations will actually
"break longstanding code". So far, all of the examples of code shown
that assumes wrapv semantics are such that it's nearly impossible to see
any useful optimization that would break it!
Let's look at the example from GCC's fold-const.c:neg_double:
*hv = - h1;
return (*hv & h1) < 0;
What could we do that could break that? We could conceivably argue after
seeing the first statement that either the sign bits of *hv and -h1 are
now different or an overflow occured, then argue that since an overflow
can't occur, they must be different. Hence the AND of the sign bits in
the second statement must always be zero and hence the RETURN always
returns zero.
I don't think GCC does that now, though it's certainly something it COULD
do. But that falls within what's been discussed earlier in this thread,
which is not using an assumption about overflow to deduce that a test is
always false or true because that might be testing for overflow.
In the atoi example, there's nothing to optimize, so that certainly wouldn't
be affected.
