On Wed, 20 Dec 2006, Bruno Haible wrote: > > But the other way around? Without -fwrapv the compiler can assume more > > about the program being compiled (namely that signed integer overflows > > don't occur), and therefore has more freedom for optimizations. All > > optimizations that are possible with -fwrapv should also be performed > > without -fwrapv. Anything else is a missed optimization.
On Wed, Dec 20, 2006 at 03:50:23PM +0000, Joseph S. Myers wrote: > Indeed. Fixing this may require it to be possible to mark individual > operations with their overflow semantics (which will also be needed for > LTO to handling inlining between translation units compiled with different > options). The problem is that some optimizations involve transforming an > "overflow undefined" operation into an "overflow wraps" one, which is a > valid transformation, but can't be represented in trees at present - Doesn't it suffice just to change the type of the operation to unsigned? For signed integers, overflow is undefined, but for unsigned integers, overflow wraps.
