This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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.


On 29-May-2003, Roger Sayle <roger@eyesopen.com> wrote:
> 
> On Thu, 29 May 2003, Andrew Haley wrote:
> > Yes, but are the math functions themselves required to be within 1 ulp
> > of the correctly rounded result?  Are they required to be monotonic?
> 
> Yes and yes. 
> Without additional command-line options GCC's mathematical
> builtins are currently required to be monotonic and within 1 ulp of the
> correctly rounded result,
> which are also the requirements of the standard C library.

Required by what -- by GCC, or by some standard?
If the latter, which standard?

The C99 standard imposes almost no requirements about accuracy:

 |  The accuracy of ... the library functions in <math.h> and <complex.h>
 |  that  return  floating-point  results   is   implementation-
 |  defined.   The implementation may state that the accuracy is
 |  unknown.

The LIA-1 standard requires math functions to be accurate to within 1 ulp.
But do all the systems that GCC targets support this LIA-1 requirement?
And if GCC requires that they do, is this documented anywhere?

> Transformations or evaluations of mathematical built-ins
> within GCC at compile-time are required to be monotonic and within 0.5 ulp
> of the correctly rounded result.

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 non-monotonic?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


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