This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [JAVA] Implement more java.lang.Math builtins.


Roger Sayle writes:
 > 
 > > > 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).

Sounds good.

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

I certainly do.  This would prevent significant regressions on
platforms that have system libraries of unknown provenance.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]