On 11/05/2012 03:37 PM, Joseph S. Myers wrote:
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
with".
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
legal?
"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, 6.8.4.2 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
labels.
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
clear enough.
What i see is that the front end builds an int_cst with the type
unsigned char and a value 0x100. I consider this invalid gimple and i
think the iant's email does too. It seems like the front end is wrong
to create this and should have promoted this value to an int before it
ever created gimple for it.
kenny
