[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. If we do, future optimization passes may take advantage of the undefined signed overflow to break the code unjustifiably. The problem is that we don't have a way to annotate particular tree or RTL nodes as using wrapping arithmetic. (This is something we will have to change for LTO.) Ian
