------- Additional Comments From doko at cs dot tu-berlin dot de 2004-03-24
22:37 -------
Subject: description of -ffloat-store in gcc man page incorrect/inaccurate
On 2004-03-24 08:03:40 +0100, Matthias Klose wrote:
> Vincent Lefevre writes:
> > The second paragraph is incorrect. The IEEE754 standard has nothing
> > to do with that since it allows extended precision for intermediate
> > computations. This option just makes gcc more ISO C compliant, since
> > the ISO C forbids excess precision after an explicit conversion to
> > double (cast or affectation).
>
> gcc-3.4 reads:
>
> -ffloat-store
> Do not store floating point variables in registers, and inhibit
> other options that might change whether a floating point value is
> taken from a register or memory.
>
> This option prevents undesirable excess precision on machines such
> as the 68000 where the floating registers (of the 68881) keep more
> precision than a "double" is supposed to have. Similarly for the
> x86 architecture. For most programs, the excess precision does
> only good, but a few programs rely on the precise definition of
> IEEE floating point. Use -ffloat-store for such programs, after
> modifying them to store all pertinent intermediate computations
> into variables.
"This option prevents undesirable excess precision"
This isn't quite correct, since internal computations will still be
performed in extended precision if the processor is configured to do
so (unfortunately, this is the case by default under Linux, but not
under FreeBSD, NetBSD and AFAIK, MS Windows). Only the stored values
will be in double precision. But this is not equivalent to compute
in double precision directly due to the effect of "double rounding"
(a first rounding due to the computation in extended precision and a
second one due to the "extended -> double" conversion). See the test
at the end of this message.
"For most programs, the excess precision does only good"
This may be dangerous and not portable though. Users should not rely
on that when writing/testing programs. I think that it is better to
just say that it is harmless.
"but a few programs rely on the precise definition of IEEE floating
point"
As I said, this option has nothing to do with what IEEE requires.
Whether it is used or not, this will be conform to the IEEE-754
standard (which allows extended precision for intermediate
computations -- but doesn't say what intermediate computations are
exactly, this is left to the language specifications). This option
will just fix gcc's default behavior: without this option, gcc will
fail to convert extended precision values to double after a cast or
an assignment (unless this has been fixed in the latest versions).
The latest public draft of the C99 standard (WG14/N869) says:
In 5.1.2.3:
[#13] EXAMPLE 4 Implementations employing wide registers
have to take care to honor appropriate semantics. Values
are independent of whether they are represented in a
register or in memory. For example, an implicit spilling of
a register is not permitted to alter the value. Also, an
explicit store and load is required to round to the
precision of the storage type. In particular, casts and
assignments are required to perform their specified
conversion. For the fragment
double d1, d2;
float f;
d1 = f = expression;
d2 = (float) expressions;
the values assigned to d1 and d2 are required to have been
converted to float.
In 6.3.1.5:
[#2] When a double is demoted to float, a long double is |
demoted to double or float, or a value being represented in |
greater precision and range than required by its semantic |
type (see 6.3.1.8) is explicitly converted to its semantic |
type, if the value being converted is outside the range of
values that can be represented, the behavior is undefined.
If the value being converted is in the range of values that
can be represented but cannot be represented exactly, the |
result is either the nearest higher or nearest lower |
representable value, chosen in an implementation-defined
manner.
In 6.3.1.8:
[#2] The values of floating operands and of the results of
floating expressions may be represented in greater precision
and range than that required by the type; the types are not
changed thereby.45)
45)The cast and assignment operators are still required to
perform their specified conversions as described in
6.3.1.4 and 6.3.1.5.
------------------------------------------------------------------
You can see all these differences with
http://www.vinc17.org/software/tst-ieee754.c
(I've just updated it to add the assignment test, which is in fact
a test concerning the C language, not the IEEE-754 standard).
1) On Linux/x86 without -ffloat-store:
--------
__STDC_IEC_559__ defined:
The implementation shall conform to the IEEE-754 standard.
FLT_EVAL_METHOD is 2 (see ISO/IEC 9899, 5.2.4.2.2#7).
The IEEE-754 result is 9007199254740994 with double precision.
The IEEE-754 result is 9007199254740996 with extended precision.
The obtained result is 9007199254740996.
The implementation doesn't seem to convert values to the target type after
an assignment (see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).
--------
2) On Linux/x86 with -ffloat-store:
--------
__STDC_IEC_559__ defined:
The implementation shall conform to the IEEE-754 standard.
FLT_EVAL_METHOD is 2 (see ISO/IEC 9899, 5.2.4.2.2#7).
The IEEE-754 result is 9007199254740994 with double precision.
The IEEE-754 result is 9007199254740996 with extended precision.
The obtained result is 9007199254740996.
--------
3) On Linux/ppc:
--------
__STDC_IEC_559__ defined:
The implementation shall conform to the IEEE-754 standard.
FLT_EVAL_METHOD is 0 (see ISO/IEC 9899, 5.2.4.2.2#7).
The IEEE-754 result is 9007199254740994 with double precision.
The IEEE-754 result is 9007199254740996 with extended precision.
The obtained result is 9007199254740994.
--------
(1) shows the gcc bug concerning assignments/casts and (2) shows
that using -ffloat-store fixes it. But in both cases, the result
in the first test is 9007199254740996, i.e. internal computations
are performed in extended precision whether -ffloat-store is used
or not. (3) shows what one gets with double-precision internal
computations.
Note: tst-ieee754.c contains other tests; I haven't written the
results here as they are off-topic.
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
