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

[Richard Guenther]

On 12/31/06, Richard Kenner <address@hidden> wrote:
> > Are you volunteering to audit the present cases and argue whether they
> > fall in the "traditional" cases?
>
> I'm certainly willing to *help*, but I'm sure there will be some cases
> that will require discussion to get a consensus.
>
> > Note that -fwrapv also _enables_ some transformations on signed
> > integers that are disabled otherwise.  We for example constant fold
> > -CST for -fwrapv while we do not if signed overflow is undefined.
> > Would you change those?
>
> I don't understand the rationale for not wrapping constant folding when
> signed overflow is undefined: what's the harm in "defining" it as wrapping
> for that purpose?  If it's undefined, then why does it matter what we
> fold it to?  So we might as well fold it to what traditional code expects.

The reason is PR27116 (and others, see the difficulties in fixing PR27132).
We cannot do both, assume wrapping and undefined behavior during
foldings at the same time - this leads to wrong-code.  Citing from a
message from
myself:

"Other than that I'm a bit nervous if we both
introduce signed overflow because it is undefined and at the same time
pretend it doesn't happen because it is undefined.  Like given

  a - INT_MIN < a
-> a + INT_MIN < a
-> INT_MIN < 0

which is true, even for a == INT_MIN for which the original expression
didn't contain an overflow.  I.e. the following aborts

#include <limits.h>

extern void abort(void);

int foo(int a)
{
 return a - INT_MIN < a;
}

int main()
{
 if (foo(INT_MIN))
   abort ();
 return 0;
}

because we fold the comparison to 1."

This was while trying to implement a - -1 to a + 1 folding.  The problematic
folding that existed at that point was that negate_expr_p said it would
happily negate INT_MIN (to INT_MIN with overflow flag set), which is
wrong in this context.

Richard.