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

["anz at obs-nice dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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
12345.123456
12345.123456
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
12345.123047
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
  http://gcc.gnu.org/ml/gcc/2002-10/msg00950.html
  http://gcc.gnu.org/ml/gcc/2001-05/msg01583.html
could fail in obscure ways.

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


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


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