Richard Guenther wrote:
On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote:
specfp.
I would support the proposal to enable -fwrapv for -O[01], but not for -O2 as that is supposed to be "optimize for speed" and as -O3 is not widely used to optimize for speed (in fact it may make code slower). I'm undecided for -Os but care less about it.
I think it is a bad idea for the optimization levels to deal with anything other than optimization. -fwrapv is not about optimization, it is about changing the language semantics. So this proposal would be tantamount to implementing a different language at -O1 and -O2, and having -O2 change the formal semantic interpretation of the program. That seems a very bad idea to me. It is one thing to have different optimization levels do different amounts of optimization that in practice may have more or less effect on non-standard programs. It is quite another to guarantee at a formal semantic level wrapping at -O1 and not -O2. If we decide to avoid some optimizations at -O1 in this area, that's fine, but it should not be done by enabling -fwrapv as one of the (presumably documented) flags included in -O1. Instead I would just do this silently without the guarantee. And I continue to favor the compromise approach where loop optimization can use undefinedness of overflow in dealing with loop invariants, but we don't by default take advantage of undefinedess elsewhere. Then we have two switches: -fstandard which allows all optimizations (name can be changed, I don't care about the name) -fwrapv which changes the semantics to require wrapping in all cases (including loops)
