This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/323] optimized code gives strange floating point results
- From: "pepalogik at seznam dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 24 Jun 2008 20:12:20 -0000
- Subject: [Bug rtl-optimization/323] optimized code gives strange floating point results
- References: <bug-323-4315@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #117 from pepalogik at seznam dot cz 2008-06-24 20:12 -------
(In reply to comment #116)
> > Yes, but this requires quite a complicated workaround (solution (4) in my
> > comment #109).
>
> The problem is on the compiler side, which could store every result of a cast
> or an assignment to memory (this is inefficient, but that's what you get with
> the x87, and the ISO C language could be blamed too for *requiring* something
> like that instead of being more flexible).
>
> > So you could say that the IEEE754 double precision type is available even on
> > a processor without any FPU because this can be emulated using integers.
>
> Yes, but a conforming implementation would be the processor + a library, not
> just the processor with its instruction set.
>
> > Moreover, if we assess things pedantically, the workaround (4) still doesn't
> > fully obey the IEEE single/double precision type(s), because there remains the
> > problem of double rounding of denormals.
>
> As I said, in this particular case (underflow/overflow), double rounding is
> allowed by the IEEE standard. It may not be allowed by some languages (e.g.
> XPath, and Java in some mode) for good or bad reasons, but this is another
> problem.
OK, thanks for explanation. I think now it's clear.
> > I quote, too:
> > "Applies To
> > Microsoft® Visual C++®"
>
> Now I assume that it follows the MS-Windows API (though nothing is certain with
> Microsoft). And the other compilers under MS-Windows could (or should) do the
> same thing.
By a lucky hit, I have found this in the GCC documentation:
"
-mpc32
-mpc64
-mpc80
Set 80387 floating-point precision to 32, 64 or 80 bits. When '-mpc32' is
specified,
the significands of results of floating-point operations are rounded to 24
bits (single precision); '-mpc64' rounds the the significands of results of
floatingpoint
operations to 53 bits (double precision) and '-mpc80' rounds the significands
of results of floating-point operations to 64 bits (extended double precision),
which is the default. When this option is used, floating-point operations
in higher precisions are not available to the programmer without setting the
FPU control word explicitly.
[...]"
So GCC sets extended precision by default. And it's easy to change it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323