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

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

> I am.  I just now looked and found another example.
> gcc-4.3-20061223/gcc/fold-const.c's neg_double function
> contains this line:
> 
>       *hv = - h1;

OK, granted.  But it is followed by code testing for overflow.

That means that (1) we can find these by looking for cases where we are
setting an overflow indication and (2) that the heuristic of preserving
tests for overflow will be sufficient to deal with these kinds of cases.

> This may be the policy of the GCC developers for the code they
> maintain, but it's not a realistic policy for everybody, and GCC
> shouldn't insist on it, or even recommend it, for everybody.  I
> certainly can't assume it for the code I help maintain, as the
> minimal GCC standard is far too restrictive.

I continue to feel that it is reasonable for a compiler for a programming
language to require that its input be a valid program in that language.

> Sure, but right now the position of many GCC developers seems to be
> that code like this is "broken" and that its authors should find and
> rewrite it.  I don't think this is realistic.  Even GCC itself seems
> to have trouble implementing this policy well.

I can't speak for any other GCC developer, but I personally am quite
comfortable viewing any code that assumes wrapping semantics as broken
and needing fixing with the exception of these cases of checking for
overflow: there simply is no good way in C to do these checks in a portable
manner and, as I said, I think we should make sure they continue to work
and maybe even document that.

But also note that my position also is that we, as much as possible, should
allow these "broken" legacy codes to continue to work properly despite that
feeling, unless we have a specific case (such as the loop cases) where the
benefits of losing the optimization are quite high and the likelihood that
we'll break code is very low.