[Bug c/18065] usual arithmetic conversion not applying correctly
schlie at comcast dot net
gcc-bugzilla@gcc.gnu.org
Wed Oct 20 19:33:00 GMT 2004
------- 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
More information about the Gcc-bugs
mailing list