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

[Paul Eggert]

address@hidden (Richard Kenner) writes:

>> I'm sure there are many other instances where the GCC source
>> code assumes wrapv semantics.  
>
> I'm not.

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;

This one is a bit less obvious because it doesn't have a
"Danger Will Robinson!" comment next to it, but h1 is a
signed integer and it's easy to arrange for h1 to have its
minimal value, so that "- h1" overflows.

So this GCC code is "broken" too.

And there is lots more where this came from.  Like it or
not, GCC internally assumes wrapv semantics in a lot of places.

> People who write code in GCC that makes such an assumption
> tend to document it, as you found out.

I'm skeptical of this claim.  The "*hv = - h1;" line is one
counterexample, as it doesn't document its wrapv assumption.
I expect most wrapv-assuming code in GCC is similar.  That's
the usual pattern, I'm afraid.

> For writing new code, it's easy: the C standard is all
> that should be assumed.  Old code should be modified, as
> time allows, to be consistent with that standard.

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.

> All the DOCUMENTATION would guarantee
> is that we compile only correct code correctly.

That's a tautology.  The documentation should say more than "true".

What we're arguing about here is whether the code is
"correct".  The "*hv = - h1" code is "correct" if one
assumes traditional C, or assumes C with LIA-1 wrapping
semantics.  The GCC documentation should address this
integer overflow issue; it should not duck it.

> the interesting cases are where things would break with any
> reasonable optimization that GCC would do and I don't see this as
> one of them.

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.