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