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.


Roger Sayle writes:
 > 
 > Hi Andrew,
 > 
 > On Thu, 29 May 2003, Andrew Haley wrote:
 > > Roger Sayle writes:
 > >  > The following patch tweaks the gcj front-end to use GCC's built-ins
 > >  > for the mathematical functions atan, atan2, exp, log, pow and tan
 > >  > in 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.
 > >
 > > Perhaps we could enable this with a switch; perhaps it doesn't matter.
 > > Comments welcome...
 > 
 > I'll have to double check the wording in the JLS, but I believe that
 > its doesn't require anything beyond the appropriate IEEE standards,
 > with the exception that IEEE FP exceptions can/are/maybe thrown as
 > java exceptions.
 > 
 > The default behaviour of GCC's built-in mathematical functions is to
 > only apply an optimization if its guaranteed to produce identical
 > floating point results without risk of overflow, rounding or exception.
 > Such as calculating sqrt(2.0) or pow(2.0,3.0) at compile-time.  So
 > although many language standards permit up to 1 ulp error (or worse),
 > GCC's middle-end requires a perfect 0.5 ulp for IEEE double by default.

Yes, but are the math functions themselves required to be within 1 ulp
of the correctly rounded result?  Are they required to be monotonic?

Andrew.


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