On Mon, 5 Nov 2012, Kenneth Zadeck wrote:
This switch to doing math within the precision causes many test cases to
behave differently. However, I want to know if differently means
"incorrectly" or "I have fixed problems that we have just decided to live
As far as I know, the TREE_OVERFLOW settings follow the most sensible
interpretation of the C standard requirements (that any overflowing
operation, with signed result type, whose operands are integer constant
expressions, results in the overall containing expression, wherein that
overflowing operation is evaluated in the abstract C semantics, not being
an integer constant expression).
Nothing in the testcases should care in the least about the "two HWI"
internal implementation - from the front-end perspective, arithmetic
according to the relevant precision is always right, and overflow should
always be determined according to that precision.
The question is why is having a case label of 256 on a unsigned char switch
"The integer promotions are performed on the controlling expression. The
constant expression in each case label is converted to the promoted type
of the controlling expression." (C11, 220.127.116.11 paragraph 5). That is, in
the semantics of C the switch is on an int value, not an unsigned char,
and 256 is converted to int (which leaves it unchanged). If the value
*is* modified by the conversion (say if it's 0x100000000ULL, converted to
int), that's still valid C, as long as you don't get duplicate case
I don't know if the *implementation* of this bit of C does anything funny
with constants outside the range of their types, but the specification is