Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Gabriel Dos Reis]

Ian Lance Taylor <address@hidden> writes:

| Gabriel Dos Reis <address@hidden> 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