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

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

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

Andrew,

It has nothing to do with "optimizing code", if the 3.X and 4.X front-ends
are promoting the size of anything other than bool, enum, or bit-field
operand values without explicit need, they're doing so in error, and in
contradiction to the standard's semantics.

(could you please check on this, as it should be clear that it's wrong,
 although may have gone unnoticed as most of GCC's targets are 32+ bit
 machines, and would have escaped detection, as on most larger machines
 most operations are converted by default to int as that's all they
 know about, it's only when the result is stored, does the operations
 required size express itself. 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
 worry about trying to optimize operand values into smaller sizes when
 subsequently realizing that their size promotion was not required, and
 calling it an optimization; the whole mess is more accurately a
 de-optimization, and perversion of C's semantics.)
 
Thanks, -paul-

> From: jsm at polyomino dot org dot uk <gcc-bugzilla@gcc.gnu.org>
> Reply-To: <gcc-bugzilla@gcc.gnu.org>
> Date: 20 Oct 2004 21:31:15 -0000
> To: <schlie@comcast.net>
> Subject: [Bug c/18065] usual arithmetic conversion not applying correctly
> 
> 
> ------- Additional Comments From jsm at polyomino dot org dot uk  2004-10-20
> 21:31 -------
> Subject: Re:  usual arithmetic conversion not applying correctly
> 
> On Wed, 20 Oct 2004, pinskia at gcc dot gnu dot org wrote:
> 
>> 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.
> 
> The integer promotions are where signed char is promoted to int.  Only
> after then are types compared.
> 
> It is not the job of the front end to optimise code.  The front end should
> generate datastructures corresponding exactly to the specified semantics
> of the language, including the promotions in this case.  Subsequent
> passes, preferably on GIMPLE but maybe including fold at present, can deal
> with eliminating conversions not needed for code generation.
> 
> -- 
> 
> 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