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. -- Joseph S. Myers jos...@codesourcery.com
