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. 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. > Naming suggestions welcome, at the moment I consider NEGATEV_EXPR > (thus appending V to the first part). As good a convention as any. Diego.
