On Mon, Nov 5, 2012 at 10:13 PM, Kenneth Zadeck <zad...@naturalbridge.com> wrote: > 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.
Note this would be invalid GENERIC at most (INTEGER_CST is a generic tree). I think if the TREE_OVERFLOW bit is not set on the constant then it is not a valid INTEGER_CST in GENERIC (and thus GIMPLE). Note that there are present cases that violate this inside the frontends which is why we still have the path in the tree.c INTEGER_CST construction routines that do not "canonicalize" the constants (by properly sign-/zero-extending the input value according to the type - where there are still callers that use the fallback integer_type type as they feed the constructors with a NULL_TREE type). Before converting any of the above to wide_int's the above mess should be sorted out (mostly by making the frontends use a different thing than INTEGER_CSTs in the affected places - formerly I'd say double_ints, with wide-ints around I'm not so sure). Richard. > kenny
