[EMAIL PROTECTED] (Richard Kenner) writes: > > > > 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. > > > > If flag_wrapv is false, we can't do any optimization which may > > introduce signed overflow when it did not already exist. > > 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. Ian
