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 <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 20 Oct 2004 21:31:15 -
> To: <[EMAIL PROTE
operation; but even then, the type of the object doesn't
change, although the its value's representation may if required.)
-paul-
> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 20 Oct 2004 19:54:55 -
> To: &l
--- 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
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 21:25
---
As I have said before, this has nothing to RTL, only the front-end. Read the code
which I copied from
the GCC, this is in the front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
lly occur on correspondingly wide cpu's, therefore
don't enable inappropriate operand promotion errors to be easily
observable.)
-paul-
> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 20 Oct 2004 19:29:13 -0000
&
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:54
---
When I am talking about promoting means that we add casts. aka sc%sc gets changed to
(signed char)
(((int)sc)%((int)sc)).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
t; From: Paul Schlie <[EMAIL PROTECTED]>
> Date: Wed, 20 Oct 2004 15:14:08 -0400
> To: <[EMAIL PROTECTED]>
> Subject: Re: [Bug c/18065] usual arithmetic conversion not applying correctly
>
> Please read rule 1:
>
> "If both operands have the same type, then no furth
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:29
---
And the reason why we don't shoten back to signed char % signed char:
/* Although it would be tempting to shorten always here, that loses
on some targets, since the modulo instruction
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:25
---
The promotion is coming from:
if (convert_p)
{
op0 = default_conversion (orig_op0);
op1 = default_conversion (orig_op1);
}
else
{
op0 = orig_op0;
op1 = orig_op1;
}
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:18
---
But the front-end is doing the promotions where the problem comes from, nowhere else
(I am using
4.0 to verify my claim that the front-end is actually doing the promotion).
--
http://gcc.gnu.org/bugzil
g <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 20 Oct 2004 18:50:01 -
> To: <[EMAIL PROTECTED]>
> Subject: [Bug c/18065] usual arithmetic conversion not applying correctly
>
>
> --- Additional Comments From pinskia at gcc dot gnu dot org
--- 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 followin
12 matches
Mail list logo
