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