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.
You mean writing the hypothetical PLUS_WRAP_EXPR <a, b> (where a and b
are ints) as (int) ((unsigned)a + (unsigned)b)?
That might work actually. However, I don't know if the optimizers will
be able to see through the casts and perform all the subsequent
optimizations appropriately.
Paolo
