On Fri, 27 Feb 2009, Diego Novillo wrote: > On Thu, Feb 26, 2009 at 06:05, Richard Guenther <rguent...@suse.de> wrote: > > > > There shall be no construct in the GIMPLE IL that invokes > > undefined behavior. > > Excellent! Thanks for starting this branch. > > > Thus, from now on integer overflow is defined and will wrap with > > the usual twos-complement semantics. Thus, for the middle-end > > -fwrapv is always in effect. This extends to pointer overflow. > > You mean that -fwrapv is always in effect for the *V_EXPR operations, > right? PLUS_EXPR will always be defined as not overflowing. It's up > to the front end to emit one or the other.
-fwrapv is always in effect for the regular variants (PLUS_EXPR). It is also in effect for the *NV_EXPR variants (yeah, the *V naming was confusing...), but we know that overflow doesn't happen for them so it doesn't matter what semantics overflow has - thus you can as well say -fno-wrapv is in effect for them - but! - the *NV_EXPR variants also exist for unsigned arithmetic just specifying the same restriction - no overflow. > How should we define merging two different TUs compiled with different > -fwrapv settings? This is something that may be common in the context > of LTO: > > $ gcc -flto -fwrapv f1.c > $ gcc -flto f2.c > $ gcc -o f -O2 f1.o f2.o > > We will be reading IL containing both overflow and non-overflow > operations. We should define the combination rules for them. There will be no use of flag_wrapv left after the frontends finished, everything is encoded in the IL. So combination of -fwrapv and -fno-wrapv CUs is just "combine them". > > Naming suggestions welcome, at the moment I consider NEGATEV_EXPR > > (thus appending V to the first part). > > As good a convention as any. As was noted, NEGATENV_EXPR is less confusing. Richard.
