This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: gcj optimizations
Bryce McKinlay writes:
> Tom Tromey wrote:
>
> >Are we guaranteed that the system cos meets Java's requirements?
> >Andrew dealt with all the Math code in the very early days. I no
> >longer remember why we have our own cos instead of relying on the
> >system one. Perhaps the system we were using at that time simply
> >didn't have it.
> >
> Maybe our own cos was needed to meet the stricter Math requirements
> before the specification got relaxed?
Yes: the java.lang.Math.cos in our library meets the original Javal
requirements precisely.
> I don't think it is guaranteed that the system cos meets our
> requirements, since the glibc docs warn about systems which do not
> support NaN, etc. However, after conducting a small test it looks like
> inlined cos works just fine for x86.
Java says:
"for the Math class, a larger error bound of 1 or 2 ulps is allowed
for certain methods."
Intel says:
"On the Pentium processor, the wost case error on functions is less
than 1ulp when rounding to the nearest-even"
Very well.
> So, perhaps we need a flag to control whether the FP Math.* functions
> can be inlined (or replaced with system math lib calls which is what
> will actually happen in some cases), which we can then turn on/off in
> the libjava configure?
I don't get this. We need class StrictMath to do what class Math did
originally, and calls to class Math to call builtins where
appropriate, no?
Andrew.