From: "Nordlund Kim (Nokia-NET/Helsinki)" <[EMAIL PROTECTED]> Date: Wed, 27 Sep 2006 14:45:21 +0300 (EEST)
> But for signed types it falls under this: > > 6.5 Expressions > 5 If an exceptional condition occurs during the evaluation of an > expression (that is, if the > result is not mathematically defined or not in the range of > representable values for its > type), the behavior is undefined. > > Already the initial assignment of 0x80000000 to int falls under this: > > 6.3.1.3 Signed and unsigned integers > 1 When a value with integer type is converted to another integer type > other than _Bool, if > the value can be represented by the new type, it is unchanged. > 2 Otherwise, if the new type is unsigned, the value is converted by > repeatedly adding or > subtracting one more than the maximum value that can be represented > in the new type > until the value is in the range of the new type.49) > 3 Otherwise, the new type is signed and the value cannot be > represented in it; either the > result is implementation-defined or an implementation-defined signal > is raised. > > Of course it can be argued whether the gcc optimization is sane. But it > seems not to be wrong, and there is no justification for writing the code > to be unspecified. Correct, and actually this undefined behavior turns out to be critical for several types of loop optimizations which I feel totally justifies the interpretation gcc is using now. I'll apply Thomas's original patch, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
