[LLVMdev] Definition of C/C++ integral conversion(was Re: nsw/nuw for trunc)

[Tobias Grosser]

On 09/30/2011 04:46 PM, Duncan Sands wrote:
>>> 3) If the destination type is signed, the value is unchanged if it
>>> can be represented in the destination type (and bit-field
>>> width); otherwise, the value is implementation-defined.
>>> ----------------------------------------------------
>>>
>>> 4.7.3 suggest to me, that the standard does not define a result for
>>> '(signed char) 999'. I assume you know this section, but I could not
>>> find a reason why this section should not apply in this case. Any ideas?
>>
>> It does apply: the value is implementation-defined, and the definition
>> that any sane implementation uses is 2's complement truncation.
>
> Right, implementation defined is not the same as undefined.

Thanks for your help. I found that the undefined behavior on integer 
overflow, is specified in 5 (5):

"If during the evaluation of an expression, the result is not 
mathematically defined or not in the range of representable
values for its type, the behavior is undefined, unless such an 
expression is a constant expressionappears where an integral
constant expression is required (5.19)"

This seems to apply to mathematical expressions, but not to 
explicit/implicit type conversions.

Hence, code like

int index = a + 100;
A[index] = ...

may result on 64bit architectures in a sext(trunc(index)) expression, 
that can be optimized out easily. Very interesting.

Cheers and thanks again for your help
Tobi