This is the mail archive of the
mailing list for the GCC project.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Richard Kenner" <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: autoconf-patches at gnu dot org, bug-gnulib at gnu dot org, dewar at adacore dot com, eggert at cs dot ucla dot edu, gcc at gcc dot gnu dot org
- Date: Mon, 1 Jan 2007 12:04:29 +0100
- Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- References: <200612300047.kBU0lFwk014817@localhost.localdomain> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <45980B43.firstname.lastname@example.org> <email@example.com> <10612311945.AA05131@vlsi1.ultra.nyu.edu> <firstname.lastname@example.org> <10612312045.AA06726@vlsi1.ultra.nyu.edu>
On 12/31/06, Richard Kenner <email@example.com> 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
"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
extern void abort(void);
int foo(int a)
return a - INT_MIN < a;
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.