integral overflow and integral conversions

[Jason Merrill <jason at redhat dot com>]

Currently, the middle end seems to use the same rules for handling 
constant overflow of integer arithmetic and conversion between integer 
types: set TREE_OVERFLOW on the INTEGER_CST if the type is signed and 
the value doesn't fit in the target type.  But this doesn't seem to 
match the C/C++ standards.

C99 says,

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.

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.

Note the difference.  When converting an integer value to another 
integer type that it doesn't fit into, the behavior is either 
well-defined or implementation-defined.  When arithmetic produces a 
value that doesn't fit into the type in which the arithmetic is done, 
the behavior is undefined even if the type is unsigned.

So we're setting TREE_OVERFLOW inappropriately for conversion to signed 
integer types (though the front ends unset it again in cast context), 
and, more problematically, failing to set it for unsigned arithmetic 
overflow:

#include <limits.h>

enum E {
  A = (unsigned char)-1,	// OK
  B = (signed char)UCHAR_MAX,	// implementation-defined
  C = INT_MAX+1,		// undefined (C)/ill-formed (C++)
  D = UINT_MAX+1		// undefined (C)/ill-formed (C++)
};

Am I missing something?

This is more of a problem for C++, which says that arithmetic overflow 
in a context that requires a constant expression is ill-formed; in C 
it's merely undefined.

Jason