This is the mail archive of the
mailing list for the GCC project.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: iant at google dot com
- Cc: autoconf-patches at gnu dot org, bug-gnulib at gnu dot org, gcc at gcc dot gnu dot org
- Date: Sun, 31 Dec 2006 21:47:21 EST
- Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- References: <200612300047.kBU0lFwk014817@localhost.localdomain> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <45980B43.email@example.com> <firstname.lastname@example.org> <10612311945.AA05131@vlsi1.ultra.nyu.edu> <email@example.com> <10612312045.AA06726@vlsi1.ultra.nyu.edu> <firstname.lastname@example.org> <10701010202.AA09735@vlsi1.ultra.nyu.edu> <email@example.com>
> > But how would that happen here? If we constant-fold something that would
> > have overflowed by wrapping, we are ELIMINATING a signed overflow, not
> > INTRODUCING one. Or do I misunderstand what folding we're talking about
> > here?
> http://gcc.gnu.org/PR27116 is what led to the patch.
I think the patch is wrong. This is not a case where the source contains
"- INT_MIN". If it did, I think it would be perfectly safe to always fold
it in a wrapping way.
As I understand the issue here, the problem is that we're generating a
negation of a constant present in the source as part of ANOTHER
transformation. But I'd argue that such should not be generated if the
constant overflows REGARDLESS of the state of -fwrapv: it requires far too
much analysis of whether such a transformation is valid in such case to
bother doing it.
So I think it's correct for nearly all of the places that call negate_expr in
fold to protect that call with a call to negate_expr_p (I note a few seem
missing), but I'd argue that folding the expression "-CST" should
unconditionally do so and that negate_expr_p should return FALSE if an
overflow would occur independently of flag_wrapv and flag_trapv.