Ian Lance Taylor <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > I do hope your and Richard G's constructive search for middle ground | > will find echoes within the middle-end maintainers. | | This seems likely, since Richard and I are two of the three middle-end | maintainers, and I don't recall hearing from the other one in this | discussion.
I'm glad to hear that, and I do hope that will lay down ground for moving forward. | > I do appreciate your preliminary patch -- and I'm sure Paul find it | > useful too, as tool to advance in this discussion. I suspect that, | > what is not clear is whether "the other side" (I hate that expression) | > is amenable to agreeing on that course or whether the seemingly | > prevalent attitude "but it is undefined; but it is not C" is the | > opinion of the majority of middle-end maintainers. | | I don't personally see that as the question. This code is undefined, | and, therefore, is in some sense not C. This is probably an area where opinions diverge. Nobody is arguing what the ISO C standard says: signed integer arithmetic overflow is undefined behaviour. Where opinions diverge, I suspect, is how "undefined behaviour" should be interpreted. As I've produced evidence before, "undefined behaviour" is a black hole term that contains both erroneous programs whose diagnostic would require solving the halting problem, and a hook for the implementation to provide useful conformant extensions. Now, we are faced with taking advantage of that limbo and do some code transformations, or provide another useful extensions (e.g. LIA-1). Consequently, saying "it is not C" is not accurate and not helping making decisions that move forward in a useful way -- what the ISO C standard defines (and ISO C++ for that matter) is a family of languages called C. However, as I said earlier, I very much support your effort and do hope it finds echo with the middle-end maintainers. | If we take any other | attitude, then we will be definining and supporting a different | language. I think that relatively few people want the language "C | plus signed integers wrap", which is the language we support with the | -fwrapv option. | | What I think we need to do is introduce a warning option to optionally | warn about optimizations which are unusually risky for existing code. | And I think we need to provide more fine-grained control over which | optimizations we implement. Yes, I agree. I filled a PR to request -Wundedined. I did not raise it to "blocker" for GCC-4.3.0, but I would not mind if a middle-end maintainer does :-) -- Gaby