Re: need help for arithmetic conversion about gcc

[Ian Lance Taylor <iant at google dot com>]

stephen <chency666@gmail.com> writes:

> But just as the "integer promotions" rules mentioned in C99 standard,
> which says "if both operands have signed integer types or both have
> unsigned integer types, the operand with the type of lesser integer
> conversion rank is converted to the type of the operand with greater
> rank." So when an operand with long type adding to the other operand
> with short type, the operand which is short type should convert to
> long type according to the rules above. But what i had found in GCC's
> rtl dumping files was that: these two operands were converted to the
> unsigned short types. Does GCC's implementations conflict with these
> rules?

I repeat:

    The assignment to ilval is going to truncate the result to "short
    int".  So gcc doesn't have to compute more than 16 bits of the
    result anyhow (assuming you are using a typical platform where short
    is 16 bits).  This is following the "as if" rule in the standard,
    which says that the compiler can generate any sequence of code which
    behaves as if the exact rules in the standard were followed.

Ian

> 2010/12/15 Ian Lance Taylor <iant@google.com>:
>> stephen <chency666@gmail.com> writes:
>>
>>> I am trying to figure out the rules of arithmetic conversion in gcc.
>>
>> gcc as such does not implement any particular rules. ÂYou seem to be
>> discussing the rules of arithmetic conversion in C. ÂThose rules are set
>> by the C standard, and gcc implements what the standard says when
>> compiling C code.
>>
>>
>>> In my previous understanding, suppose there are two operands with the
>>> different data type, the operand with less integer conversion rank
>>> would be converted to the type of the operand with greater rank. But I
>>> found it does not work like that in gcc. Take the following statements
>>> as an example,
>>>
>>> short ilval irval;
>>> long lval;
>>> ilval = lval + irval;
>>>
>>> In this case, both lval and ilval are converted to "short unsigned
>>> int", the result of "(short unsigned int) lval+(short unsigned int)
>>> irval" is then converted to "short int". I found the coversion notes
>>> from the RTL codes' file. The corresponding informations is given
>>> below:
>>>
>>> ;; D.1528 = (short unsigned int) lval
>>> ;; irval.0 = (short unsigned int) irval
>>> ;; D.1530 = D.1528 + irval.0
>>> ;; ilval = (short int) D.1530
>>>
>>> The part which confuses me is that the operand "lval" is converted
>>> from a type with greater rank (i.e., long ) to a type with less rank
>>> (i.e., short unsigned int ).
>>
>> Your test case has a syntax error and is incomplete. ÂHowever, the
>> answer to your implied question is that the assignment to ilval is going
>> to truncate the result to "short int". ÂSo gcc doesn't have to compute
>> more than 16 bits of the result anyhow (assuming you are using a typical
>> platform where short is 16 bits). ÂThis is following the "as if" rule in
>> the standard, which says that the compiler can generate any sequence of
>> code which behaves as if the exact rules in the standard were followed.
>>
>>
>>> However if it is multiply operation case, like this:
>>>
>>> short ilval irval;
>>> long lval;
>>> ilval = lval + irval;
>>>
>>> gcc handles it another way:
>>>
>>> ;; D.1528 = (long int) irval
>>> ;; D.1529 = D.1528 * lval
>>> ;; ilval = (short int) D.1529
>>>
>>> In this case (multiply operation), irval is converted from a type with
>>> less rank (int) to the type with greater rank (long).
>>
>> I note that your test case does not use multiplication, and has a syntax
>> error.
>>
>> The answer to your implied question is that simple truncation works with
>> addition but not multiplication, at least when considering the
>> possibility of overflow.
>>
>> Ian
>>