This is the mail archive of the
gcc@gcc.gnu.org
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> <45970416.80407@adacore.com> <8764bssikm.fsf@penguin.cs.ucla.edu> <571f6b510612310047r3b7ef9acl4a0ab082e88e17a3@mail.gmail.com> <87bqlkmm3r.fsf@penguin.cs.ucla.edu> <4aca3dc20612310641n78e8898euf1c003444e2303eb@mail.gmail.com> <87fyavhphc.fsf@penguin.cs.ucla.edu> <45980B43.7080301@adacore.com> <84fc9c000612311121x2ed1772fya44e59d373f0b57b@mail.gmail.com> <10612311945.AA05131@vlsi1.ultra.nyu.edu> <84fc9c000612311200p72f20f4g62beaa28cf2f920c@mail.gmail.com> <10612312045.AA06726@vlsi1.ultra.nyu.edu> <m38xgnttrj.fsf@localhost.localdomain> <10701010202.AA09735@vlsi1.ultra.nyu.edu> <m34prbts0p.fsf@localhost.localdomain>
> > 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.