[Bug c/18065] usual arithmetic conversion not applying correctly

["schlie at comcast dot net" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From schlie at comcast dot net  2004-10-20 19:33 -------
Subject: Re:  usual arithmetic conversion not applying
 correctly

Maybe the confusion is that you're not recognizing that:

char, short, int, long, long long, are all integer types, with different
storage formats.

As opposed to enum or bit-field for example which should likely be converted
to an "integer type" with ideally the smallest and/or most efficient
representation specified for the machine, prior to an "integer" oriented
operation being performed.

???

-paul-

> From: Paul Schlie <schlie@comcast.net>
> Date: Wed, 20 Oct 2004 15:14:08 -0400
> To: <gcc-bugzilla@gcc.gnu.org>
> Subject: Re: [Bug c/18065] usual arithmetic conversion not applying correctly
> 
> Please read rule 1:
> 
>  "If both operands have the same type, then no further conversion is
>   needed." (no promotion to int is specified or implied as being required)
> 
> Seems plain enough to me, what makes you think that:
> 
>   char + char  => int + int ?
>  short + short => int + int ?
> 
> That would imply, QI mode (and HI mode typical of shorts on 32 bit machines)
> rtl instruction definitions are meaningless which isn't the case; as their
> definition defines the char and short operand rtl operator -> code
> transformation.
> 
> The front end has no business promoting all char and short arithmetic operands
> to ints, and in fact it doesn't; so am not sure what your thinking?
> 
> -paul-
> 
>> From: pinskia at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
>> Reply-To: <gcc-bugzilla@gcc.gnu.org>
>> Date: 20 Oct 2004 18:50:01 -0000
>> To: <schlie@comcast.net>
>> Subject: [Bug c/18065] usual arithmetic conversion not applying correctly
>> 
>> 
>> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20
>> 18:50 -------
>> From C99
>> (6.5.5/3): The usual arithmetic conversions are performed on the operands.
>> 
>> 6.3.1.8 Usual arithmetic conversions
>> Otherwise, the integer promotions are performed on both operands. Then the
>> following rules are
>> applied to the promoted operands: If both operands have the same type, then
>> no 
>> further conversion is
>> needed. Otherwise, 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. Otherwise, if the operand that has unsigned integer type has
>> rank greater or equal to the
>> rank of the type of the other operand, then the operand with signed integer
>> type is converted to the
>> type of the operand with unsigned integer type. Otherwise, if the type of the
>> operand with signed
>> integer type can represent all of the values of the type of the operand with
>> unsigned integer type, then
>> the operand with unsigned integer type is converted to the type of the
>> operand 
>> with signed integer
>> type. Otherwise, both operands are converted to the unsigned integer type
>> corresponding to the type of
>> the operand with signed integer type.
>> 
>> This is still not wrong code as signed char signed extended to int is still
>> the same number but this is
>> not a target problem but a front-end problem now.
>> 
>> To make sure that I read the statement correctly from the standard, it says
>> if 
>> the types are the same
>> there is no need to promote the value at all.
>> 
>> -- 
>>            What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>            Severity|minor                       |normal
>>           Component|target                      |c
>>             Summary|not using qi version of     |usual arithmetic conversion
>>                    |divmod                      |not applying correctly
>> 
>> 
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
>> 
>> ------- You are receiving this mail because: -------
>> You reported the bug, or are watching the reporter.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065