This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: rs6000: floating point cast oddities?
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: <dewar at gnat dot com>
- Cc: <rth at redhat dot com>, <dalej at apple dot com>, <gcc at gcc dot gnu dot org>
- Date: Mon, 17 Dec 2001 18:56:49 -0800 (PST)
- Subject: Re: rs6000: floating point cast oddities?
On Mon, 17 Dec 2001 dewar@gnat.com wrote:
>
> I must be confused, I thought that the C standard
> specified that all intermediate calculations were done in doulbe precision,
> is this a misunderstanding?
It is a misunderstanding, although partly correct in a historical context
(and in particular traditional function call argument and result
conversions etc).
But the reason we did _that_ particular expression in double precision is
that one of the sub-parts of the expression is a double, so from a
semantic standpoint the expression
float f;
f + 1.0;
is a double expression simply because "1.0" is double (ie "float +
double" gets promoted to "((double) float + double)").
Which was why somebody (obviously correctly) pointed out that you can get
the simple "float" semantics by just changing the expression into
f + 1.0f;
instead, because 1.0f is a float, and then the expression is all float,
and no conversion to double ever occurs.
> There is also a section in the latest C standard on mapping to IEEE, and
> that is actually what should be consulted here, rather than the IEEE standard itself.
No, the thing is, the _semantics_ of the expression is clearly:
(double)f + (double) 1.0
simply due to expression promotion. That's pretty clear and
straightforward.
However, the resultant double value is then cast back to just plain float
for the return, and my claim was that while the C semantic _mapping_ will
clearly be the expression
(float) ((double) f + (double) 1.0)
we can probably compute it more efficiently another way.
So my point was that the resulting unambiguous C expression above will,
assuming the hardware is IEEE compliant, have the same _value_ as just
doing the math in IEEE float precision. So we have the option to
potentially generate faster code that gives the same result.
So this time I really think that it is a IEEE _math_ question, not a "how
does this expression map _to_ IEEE math".
The thing is, I'm not sure I'm right that IEEE math does guarantee the
equality between the values of
float + float = (float)((double) float + (double) float)
I just have this recollection that it _is_ true.
Linus