This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> > 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]