[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug c/14384] Invalid use of extra precision floating-point with -O0 opt

From: anz at obs-nice dot fr
Subject: [Bug c/14384] Invalid use of extra precision floating-point with -O0 optimization
Date: 10 Mar 2004 15:36:31 -0000

------- Additional Comments From anz at obs-nice dot fr  2004-03-10 15:36 
(In reply to comment #11)
The problem doesn't lie with the source gccbug.c, which I suppose is the one you
renamed to pr14384.c
It lies with the source code gccbug1c.c, in the fourth attachment.
This program, when run on my machine (see the 2nd attachment for the version of
gcc and system info), prints
showing that the result of the function has *not* been narrowed to float, even
though this *is* mandated by the C standard.  If the narrowing casts are obeyed,
as they should, at least the second result must be
on a machine running with 32-bit IEEE float,
and this is what is obtained if compiled with
-mfpmath=sse -msse
As Jim Wilson said, the C standard *allows* for float expressions to be computed
with higher accuracy, but if a (float) cast (or an assignment) is present, it
*must* be obeyed (see my 5th attachment), and this is not the case with gcc
(whatever the optimization level in that case).
*IF* you don't obey this rule, then programs that determine themselve the
machine accuracy in floating-point (like the famous paranoia program, see
could fail in obscure ways.

To summarize once more, even if
*may* be computed with higher accuracy than float if f1 and f2 are float
cannot, and the extra precision of the x87 processor *must* be discarded.

           What    |Removed                     |Added
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]