[Bug rtl-optimization/323] optimized code gives strange floating point results

["vincent at vinc17 dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #116 from vincent at vinc17 dot org  2008-06-22 21:14 -------
(In reply to comment #114)
> 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.

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


-- 


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