Re: GCC optimizes integer overflow: bug or feature?

[Joseph S. Myers]

On Thu, 21 Dec 2006, Paul Eggert wrote:

> But because bigtime_test wants an int, this causes the test
> program to compute the equivalent of (int) ((unsigned int)
> INT_MAX + 1), and C99 says that if you cannot assume
> wrapping semantics this expression has undefined behavior in
> the common case where INT_MAX < UINT_MAX.

Conversion of out-of-range integers to signed types is 
implementation-defined not undefined, and GCC duly documents the modulo 
semantics for that conversion.  I don't know if you have to deal with 
compilers applying different semantics there, but shared overflow checking 
functions in gnulib could deal with the differences between compilers.

(Conversion of out-of-range floating-point numbers to integer types *is* 
undefined, but Annex F changes this to returning an unspecified value so 
bounding the possible behavior, and I believe GCC follows Annex F for 
this: it's useful not to have to guarantee any particular result, since 
different machines have conversion instructions that may do different 
things for out-of-range values, and to be able to return different results 
for compile-time and run-time conversions, but floating-point conversions 
don't have the same scope as integer arithmetic for useful optimization 
based on undefined behavior.)

-- 
Joseph S. Myers
address@hidden