This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: FWD: FLOATING-POINT CONSISTENCY, -FFLOAT-STORE, AND X86
On Thu, Dec 17, 1998 at 07:26:15PM +0000, Dave Love wrote:
> >>>>> "Marc" == Marc Lehmann <pcg@goof.com> writes:
>
> Marc> I should hjave a look at glibc's libm to see wether rounding
> Marc> would affect it negatively.
>
> Yes please! I've never been able to get a story on it but haven't
> seen problems in rather limited Fortran tests. (There's a comment
Just that I'm the wrong person to ask, as we have much better glibc experts
on this list ;)
> about libm requirements in fpu_control.h which seemed to be
> contradicted by something else in the header.)
You mean:
* The hardware default is 0x037f. I choose 0x1372.
(extended precision)
vs.
/* The fdlibm code requires strict IEEE double precision arithmetic,
?? The question is: what is "fdlibm"?
Back to the problem: I see a couple of functions in bits/mathinline.h
explicitly using long double, but I suspect this is to workaround the
"spilling vs. chop" problem when these are spilled to memory.
Looking through the functions I see more potential problems. Given
some function (say, hypot), which has to do some calculcations itself,
the result is probably correct to 64 bits when using extended precision.
When we set double precision in the fpu, all the internal calculations
in these functions are done with that precision, and we have rounding.
While the effects are small, isn't it possible that, out of a sudden, many
of our libm functions start to give us less then double precision (say,
54 or 55 bits)? Even if this is very minor, these functions have changed.
None of them set the fpu control word, btw.
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ --+
The choice of a GNU generation |
|