Bruce Korb <[EMAIL PROTECTED]> writes: > > 2) Add an option like -fstrict-signed-overflow which controls those > > cases which appear to be risky. Turn on that option at -O2. > > Not a good plan. -O2 should be constrained to disrupting very few > applications. (e.g. loop unrolling seems unlikely to cause problems) > Defer the "appear to be risky" stuff to several years after the warning > is out. Please.
Why should we handle signed overflow any differently from strict aliasing? We currently enable strict aliasing at -O2. Ian
