On Wed, 31 Oct 2012, Tobias Burnus wrote: > Jakub Jelinek: > > I think it would be nice if you also posted the changes you did to > > test-ldouble.c and libm-test.inc, so that next time we could more easily > > test it again. > > See attachment. (I didn't do it properly at first, thus, I had to propagate > the changes to the right files )
Is there also a change to gen-libm-test.pl (or elsewhere) to change "l" or "L" suffixes on constants (inputs and expected results) to "Q"? You define TEST_LDOUBLE, but don't seem to redefine LDBL_MANT_DIG - does this mean that the tests conditioned e.g. on LDBL_MANT_DIG >= 113 don't run? (Really I'd like the tests in glibc to be conditioned on the particular features they need, e.g. at least a certain number of mantissa bits, rather than hardcoding conditions such as "defined TEST_LDOUBLE && LDBL_MANT_DIG >= 113".) When the draft C floating-point TS is more advanced, it's expected to define standard names for standard IEEE 754 types, when the implementation supports them (such as _Float128), and standard function names (such as expf128) - at that point it might make sense to consider rearranging the glibc ldbl-128 code so that it can be used both to provide _Float128 functions and "long double" functions, and making glibc provide these functions as they will now have standard C bindings. (libquadmath will still make sense for non-glibc or older-glibc systems, but hopefully the implementations can be closer to the glibc versions then. And supporting the various parts of the floating-point TS in glibc would be a lot of work.) -- Joseph S. Myers jos...@codesourcery.com
