[Bug tree-optimization/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 23:28 -------
Subject: Re:  usual arithmetic conversion not
 applying correctly

What size promotion is required for char sized integer operations?

 I see none?

What size promotion is required for short sized integer operations?

 I see none?

The standard's refers to (as below earlier already referenced by Andrew):

- "integer" promotion is performed on both operands, and then further size
and/or sign-type converted as required if the operands aren't already of the
same "integer" type.

"integer type" not "int"; char, short, int, long are "integer types" of
different rank, yes?

The only primitive storage classes in C which aren't intrinsically an
"integer type" are: bool, enum, and bit-fields to my knowledge, which
require implicit promotion to an "integer type" to be operated on.

Even if you said that char's aren't "integer types" it's easy enough to
define short as having the same size as char, thereby promote char->short
which is surely an "integer type", although char's already are.

Where am I missing it?

>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.


> From: jsm at polyomino dot org dot uk <gcc-bugzilla@gcc.gnu.org>
> Reply-To: <gcc-bugzilla@gcc.gnu.org>
> Date: 20 Oct 2004 22:41:59 -0000
> To: <schlie@comcast.net>
> Subject: [Bug tree-optimization/18065] usual arithmetic conversion not
> applying correctly
> 
> 
> ------- Additional Comments From jsm at polyomino dot org dot uk  2004-10-20
> 22:41 -------
> Subject: Re:  usual arithmetic conversion not applying correctly
> 
> On Wed, 20 Oct 2004, schlie at comcast dot net wrote:
> 
>>  It's a pretty major screw-up to presume
>>  all target machines are large, and then to encode that presumption into
>>  C's front end; not to mention it seems pretty stupid to do, and then
> 
> This is not a GCC presumption, it is a property of the C language that
> there are certain promotions that may not be optimally efficient for 8-bit
> targets.  If there is a "major screw-up", it is either in the choice to
> use a language designed for systems that are at least 16-bit on an 8-bit
> target, or in the language design if you think 8-bit targets should have
> been given greater importance when the language was being standardised in
> the 1980s; it is nothing to do with the front end.  The AVR target has a
> -mint8 option which puts the compiler in a nonconforming mode with 8-bit
> int, which might however give you better code than you can get with
> standard C on an 8-bit target.
> 
> 
> 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