On 1/1/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> the seemingly prevalent attitude "but it is undefined; but it is not
> C" is the opinion of the majority of middle-end maintainers.
Does anybody DISAGREE with that "attitude"? It isn't valid C to assume that
signed overflow wraps. I've heard nobody argue that it is. The question
is how far we go in supporting existing code that's broken in this way.
I don't disagree with that attitude, I even strongly agree. We support broken
code by options like -fno-strict-aliasing and -fwrapv. I see this discussion as
a way to prioritize work we need to do anyway: annotate operations with
their overflow behavior (like creating new tree codes WRAPPING_PLUS_EXPR),
clean up existing code to make it more obvious where rely on what semantics,
add more testcases for corner-cases and document existing
(standard-conformant) behavior more explicitly.
Note that we had/have a similar discussion like this (what's a valid/useful
optimization in the users perspective) on the IEEE math front - see the
hunge thread about -ffast-math, -funsafe-math-optimizations and the
proposal to split it into -fassociative-math and -freciprocal-math. We also
have infrastructure work to do there, like laying grounds to implement
proper contraction support.
Richard.
