public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate
@ 2004-03-24  6:29 debian-gcc at lists dot debian dot org
  2004-03-24  6:36 ` [Bug other/14708] " pinskia at gcc dot gnu dot org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: debian-gcc at lists dot debian dot org @ 2004-03-24  6:29 UTC (permalink / raw)
  To: gcc-bugs

[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).

-- 
           Summary: description of -ffloat-store in gcc man page
                    incorrect/inaccurate
           Product: gcc
           Version: 3.3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: debian-gcc at lists dot debian dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
  2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
@ 2004-03-24  6:36 ` pinskia at gcc dot gnu dot org
  2004-03-24 15:34 ` bangerth at dealii dot org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-03-24  6:36 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-24 06:36 -------
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?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
  2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
  2004-03-24  6:36 ` [Bug other/14708] " pinskia at gcc dot gnu dot org
@ 2004-03-24 15:34 ` bangerth at dealii dot org
  2004-03-24 22:38 ` doko at cs dot tu-berlin dot de
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: bangerth at dealii dot org @ 2004-03-24 15:34 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From bangerth at dealii dot org  2004-03-24 15:34 -------
This section might even benefit from some of the words we have on our 
web pages about the effects of excess precision. 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
  2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
  2004-03-24  6:36 ` [Bug other/14708] " pinskia at gcc dot gnu dot org
  2004-03-24 15:34 ` bangerth at dealii dot org
@ 2004-03-24 22:38 ` doko at cs dot tu-berlin dot de
  2004-03-25  1:17 ` pinskia at gcc dot gnu dot org
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: doko at cs dot tu-berlin dot de @ 2004-03-24 22:38 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7229 bytes --]


------- 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 <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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
  2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
                   ` (2 preceding siblings ...)
  2004-03-24 22:38 ` doko at cs dot tu-berlin dot de
@ 2004-03-25  1:17 ` pinskia at gcc dot gnu dot org
  2004-03-28 13:53 ` vincent at vinc17 dot org
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-03-25  1:17 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-25 01:17 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
  2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
                   ` (3 preceding siblings ...)
  2004-03-25  1:17 ` pinskia at gcc dot gnu dot org
@ 2004-03-28 13:53 ` vincent at vinc17 dot org
  2004-03-28 13:54 ` vincent at vinc17 dot org
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: vincent at vinc17 dot org @ 2004-03-28 13:53 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From vincent at vinc17 dot org  2004-03-28 13:53 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
  2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
                   ` (4 preceding siblings ...)
  2004-03-28 13:53 ` vincent at vinc17 dot org
@ 2004-03-28 13:54 ` vincent at vinc17 dot org
  2004-11-29 14:24 ` pinskia at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: vincent at vinc17 dot org @ 2004-03-28 13:54 UTC (permalink / raw)
  To: gcc-bugs



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent at vinc17 dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
  2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
                   ` (5 preceding siblings ...)
  2004-03-28 13:54 ` vincent at vinc17 dot org
@ 2004-11-29 14:24 ` pinskia at gcc dot gnu dot org
  2004-11-29 15:35 ` vincent at vinc17 dot org
  2004-12-08 15:13 ` vincent at vinc17 dot org
  8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-11-29 14:24 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-29 14:24 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-11-29 14:24:22
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
  2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
                   ` (6 preceding siblings ...)
  2004-11-29 14:24 ` pinskia at gcc dot gnu dot org
@ 2004-11-29 15:35 ` vincent at vinc17 dot org
  2004-12-08 15:13 ` vincent at vinc17 dot org
  8 siblings, 0 replies; 10+ messages in thread
From: vincent at vinc17 dot org @ 2004-11-29 15:35 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From vincent at vinc17 dot org  2004-11-29 15:35 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
  2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
                   ` (7 preceding siblings ...)
  2004-11-29 15:35 ` vincent at vinc17 dot org
@ 2004-12-08 15:13 ` vincent at vinc17 dot org
  8 siblings, 0 replies; 10+ messages in thread
From: vincent at vinc17 dot org @ 2004-12-08 15:13 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From vincent at vinc17 dot org  2004-12-08 15:13 -------
I'm wrong. gcc 3.4 (from Debian) still has this problem. So, -ffloat-store is
still needed for C compliance.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2004-12-08 15:13 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-24  6:29 [Bug other/14708] New: description of -ffloat-store in gcc man page incorrect/inaccurate debian-gcc at lists dot debian dot org
2004-03-24  6:36 ` [Bug other/14708] " pinskia at gcc dot gnu dot org
2004-03-24 15:34 ` bangerth at dealii dot org
2004-03-24 22:38 ` doko at cs dot tu-berlin dot de
2004-03-25  1:17 ` pinskia at gcc dot gnu dot org
2004-03-28 13:53 ` vincent at vinc17 dot org
2004-03-28 13:54 ` vincent at vinc17 dot org
2004-11-29 14:24 ` pinskia at gcc dot gnu dot org
2004-11-29 15:35 ` vincent at vinc17 dot org
2004-12-08 15:13 ` vincent at vinc17 dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).