This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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] long double IEEE double -> quad switch


Jakub Jelinek <jakub@redhat.com> wrote on 03/24/2004 10:04:27 AM:

> Hi!
> 
> The following patch allows sparc32 (and easily also alpha, s390{,x}) to
> switch from double == long double to IEEE quad long double without
> upgrading libc.so/libm.so SONAME.
> All functions which deal with long double (*printf*, *scanf*, *told*,
> q[efg]cvt*, strfmon{,_l}, *l in libm (and a few math routines in libc)
> had to be versioned and the installed headers 
> allow both -mlong-double-128 (which can now be made the default
> GCC option for sparc-*-linux and other arches) and through __REDIRECTs
> (or #defines for lame compilers) -mlong-double-64.
> Tested on sparc32 (only 2x6 make check failures (6 failures in
> test-ldouble and 6 in test-ildoubl; 4 of them is a GCC bug which 
optimizes
> out division by floating zero from const long double array (seems to be
> fixed in gcc 3.4), so division by zero exception is not raised,
> one is imprecise test in libm-test.inc (recently added atan2 has
> just enough digits for ldbl-96, not ldbl-128) and one is a 10 ulps 
failure
> which can be probably added to ulps)) and x86-64.

Have you made any more progress on this? We are all waiting for this to be 
resolved.

> 
> Alpha long double support should be doable on top of this patch quite
> easily, just a few 
linux/alpha/{Makefile,Implies,Versions,bits/wordsize.h}
> tweaks.
> 
> PowerPC{,64} will be far more difficult if ppc is going to use
> IBM long double format as opposed to IEEE quad long double
> (basically sysdeps/ieee754/ldbl-128ibm/ and 
sysdeps/ieee754/ldbl-64-128ibm/
> would need to be implemented, whereas the latter is trivial, the former
> is a lot of work).
> 

I have most of this code written but we are still debugging (a number of 
surprises in nextafter and fpclassify but we are making progress). So we 
are ready to start submitting code but would like to see more about your 
work first.

You mention ldbl-128ibm/ and ldbl-64-128ibm/ what do you see as the 
difference?

I also see an opportunity to improve the double implementations for 
64-bit. Should we add dbl-64-64(sp?) where the code assumes 64-bit 
registers for the (long) integer bit manipulation. This should be 
generally useful beyond powerpc64.

Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center


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