Bug 14708 - description of -ffloat-store in gcc man page incorrect/inaccurate
Summary: description of -ffloat-store in gcc man page incorrect/inaccurate
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 3.3.4
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: documentation
Depends on:
Blocks:
 
Reported: 2004-03-24 06:29 UTC by Debian GCC Maintainers
Modified: 2005-09-24 17:09 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-09-24 17:09:47


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Debian GCC Maintainers 2004-03-24 06:29:15 UTC
[forwarded from http://bugs.debian.org/233673]

The gcc man page says:

    -ffloat-store
        Do  not  store floating point variables in registers.  This pre-
        vents 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.

        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.

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).
Comment 1 Andrew Pinski 2004-03-24 06:36:31 UTC
Looks fixed on the mainline:
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. 


Is this enough or is there more?
Comment 2 Wolfgang Bangerth 2004-03-24 15:34:48 UTC
This section might even benefit from some of the words we have on our 
web pages about the effects of excess precision. 
W. 
Comment 3 Matthias Klose 2004-03-24 22:37:52 UTC
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 <vincent@vinc17.org> - 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 debian-gcc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Comment 4 Andrew Pinski 2004-03-25 01:17:37 UTC
First __STDC_IEC_559__ is comming from glibc and not GCC so glibc is wrong to define it in most cases 
on x86. Second the whole point of -ffloat-store is because x87 is such a backwards ass system with 
respect to FP.
Comment 5 Vincent Lefèvre 2004-03-28 13:53:19 UTC
I don't think that glibc is wrong by defining __STDC_IEC_559__ (computing in an
extended type is allowed by the IEEE-754 standard) as long as FLT_EVAL_METHOD is
correctly set. The real problem is that intermediate results in extended
precision are not converted back to double after a cast or an assignment; this
is required by the C standard, whether __STDC_IEC_559__ is defined or not.
Comment 6 Andrew Pinski 2004-11-29 14:24:22 UTC
Confirmed.
Comment 7 Vincent Lefèvre 2004-11-29 15:35:28 UTC
In Comment 5, I wrote:
> The real problem is that intermediate results in extended precision are not
converted back to double after a cast or an assignment; this is required by the
C standard, whether __STDC_IEC_559__ is defined or not.

This problem has been fixed in gcc 3.4. So, now I think that the -ffloat-store
option should no longer be used: if the user wants the result to be converted
into double precision, he could add a cast to double, which is more portable
than relying on --ffloat-store. Also, note that neither the cast nor the
-ffloat-store option solves the problem of "double rounding" as described here:

  http://www.vinc17.org/research/extended.en.html

IMHO the manual should discourage the use of -ffloat-store.
Comment 8 Vincent Lefèvre 2004-12-08 15:13:44 UTC
I'm wrong. gcc 3.4 (from Debian) still has this problem. So, -ffloat-store is
still needed for C compliance.