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: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Cc: Andrew Haley <aph at redhat dot com>, <gcc-patches at gcc dot gnu dot org>, <java-patches at gcc dot gnu dot org>
- Date: Thu, 29 May 2003 10:01:26 -0600 (MDT)
- Subject: Re: [JAVA] Implement more java.lang.Math builtins.
On Fri, 30 May 2003, Fergus Henderson wrote:
> Is that enough to preserve monotonicity?
> Even if GCC's evaluations are monotonic, and the library's are also
> monotonic, mightn't combinations in which some calls are evaluated
> statically (by GCC) and some dynamically (by the library) be
Fergus raises an excellent point. Even when GCC's evaluations are
perfectly accurate (and therefore monotonic) and the system libraries
are accurate to 1ulp and monotonic, the monotonicity may not be
preserved by mixing static and dynamic function invocations.
For example, if the system library has a consistent +0.4ulp error in
calculation, it will be accurate enough for LIA and monotonic itself,
but not with respect to the correct results.
Fortunately, this should currently be a very rare issue, LIA requires
sqrt to be perfectly accurate 0.5ulp, and this is the only "rounded"
function we currently evaluate at compile-time. The other
non-rounded functions we evaluate at compile-time (without -ffast-math),
are only evaluated at common fixed points that most implementations
should pass through, such as 0.0 or 1.0.
However in the general case, this does appear to be an issue.
Fortunately, -ffree-standing provides a work-around for those who
have system libraries that comply with the letter if not the spirit
of the relevant standards.