This is the mail archive of the
mailing list for the GCC project.
Re: [JAVA] Implement more java.lang.Math builtins.
- From: Roger Sayle <roger at eyesopen dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, <java-patches at gcc dot gnu dot org>
- Date: Thu, 29 May 2003 08:27:43 -0600 (MDT)
- Subject: Re: [JAVA] Implement more java.lang.Math builtins.
> > I'm a bit nervous about this. The JLS is quite specific about these
> > functions and how they are to be computed, whereas (as far as I am
> > aware) gcc's builtins are not quite so well-defined. The efficiency
> > argument is compelling, however.
> Yes, but are the math functions themselves required to be within 1 ulp
> of the correctly rounded result? Are they required to be monotonic?
I've also thought of another compromise. To support systems with
broken or old system libraries whose -lm functions aren't guaranteed
to be with 1ulp and/or monotonic, the builtins mechanism in the java
front-end could be rewritten so that GCC's built-in's don't fall
back to libm calls, but to their Java name-mangled equivalents. This
way the java runtime's implementations are always used, and constant
folding turns java.lang.Math.pow(x,0.5) into java.lang.Math.sqrt(x)
instead of _sqrt(x).
This would require a significant rework such that java/builtins.c uses
a similar mechanism to g77's com.c rather than using builtins.def. If
you think this is preferrable, I can submit a suitable follow-up