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: [PATCH] (1/3) Add back libgcc-math


On Thu, 16 Nov 2006, Richard Guenther wrote:

> I can query AMD on this.  But those functions are supposed to be
> called with -funsafe-math-optimizations only as they violate certain
> aspects of IEEE/C, like they cannot consistently throw exceptions
> or raise FP status bits (they get vector input after all, and compute
> two or four results at the same time).  Also at least the exp variant
> truncates denormals to zero and the cosf variant reads "Denormals may 
> produce unexpected results".  Most of the routines state that they
> produce less than 1ulp of error, but I have not verified this myself
> but trust AMD here.

If they do produce < 1ulp that's better than many glibc implementations.  
(For some functions glibc does have implementations from IBM that claim to 
produce 0.5ulp correctly rounded to nearest values; but some platforms 
don't use them.)

> I don't know if it is possible to use the glibc tests in this
> circumstances without major hassle, but I agree having some correctness
> tests is useful.

The glibc tests should be useful as a source of (presumed correct) inputs 
and outputs (once you remove cases involving denormals and other special 
values).  Another possible source would be the tests Kaveh's been using to 
verify the builtins using MPFR.  If there are claimed 1ulp error bounds 
then that's something that can be checked and you don't need to deal with 
glibc's baselines of expected max ulps for each test on each platform.

-- 
Joseph S. Myers
joseph@codesourcery.com


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