On Mon, Nov 02, 2020 at 07:00:15PM -0600, Segher Boessenkool wrote: > Hi! > > On Thu, Oct 22, 2020 at 06:07:14PM -0400, Michael Meissner wrote: > > This patch fixes 3 tests in the testsuite that fail if long double is set > > to IEEE 128-bit. > > > * c-c++-common/dfp/convert-bfp-11.c: If long double is IEEE > > 128-bit, skip the test. > > > --- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c > > +++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c > > @@ -5,6 +5,7 @@ > > Don't force 128-bit long doubles because runtime support depends > > on glibc. */ > > > > +#include <float.h> > > #include "convert.h" > > > > volatile _Decimal32 sd; > > @@ -39,6 +40,12 @@ main () > > if (sizeof (long double) != 16) > > return 0; > > > > + /* This test is written to test IBM extended double, which is a pair of > > + doubles. If long double can hold a larger value than a double can, > > such > > + as when long double is IEEE 128-bit, just exit immediately. */ > > A double-double can hold bigger values than a double can, as well > (if X is the biggest double, then X+Y is a valid double-double whenever > you take Y small enough). > > > + if (LDBL_MAX_10_EXP > DBL_MAX_10_EXP) > > + return 0;
Yes a double-double can hold more mantissa bits than a double, but the exponent size is the same (which is what I'm testing). > This is testing something different though: whether the base-10 > logarithm of the maximum finite double is different from that of the > maximum finite double-double. > > Is there no more direct test you can do? Just test __FLOAT128__ maybe? > The test is not even compiled if not powerpc*-linux, so you can test > such macros just fine. I will have to look at it. > > * gcc.dg/nextafter-2.c: On PowerPC, if long double is IEEE > > 128-bit, include math.h to get the built-in mapped correctly. > > > diff --git a/gcc/testsuite/gcc.dg/nextafter-2.c > > b/gcc/testsuite/gcc.dg/nextafter-2.c > > index e51ae94be0c..64e9e3c485f 100644 > > --- a/gcc/testsuite/gcc.dg/nextafter-2.c > > +++ b/gcc/testsuite/gcc.dg/nextafter-2.c > > @@ -13,4 +13,14 @@ > > # define NO_LONG_DOUBLE 1 > > # endif > > #endif > > + > > +#if defined(_ARCH_PPC) && defined(__LONG_DOUBLE_IEEE128__) > > +/* On PowerPC systems, long double uses either the IBM long double format, > > or > > + IEEE 128-bit format. The compiler switches the long double built-in > > + function names and glibc switches the names when math.h is included. > > + Because this test is run with -fno-builtin, include math.h so that the > > + appropriate nextafter functions are called. */ > > +#include <math.h> > > +#endif > > + > > #include "nextafter-1.c" > > Please explain *what* mappings are made? And why is it okay to do this > in the testsuite, when all "normal" code (that does not do this) will > just fail? I can put in a better comment. However, this test fails because it explicitly does not include math.h and it uses -fno-builtin. So the compiler can't effectively map the nextafter math function. > > * gcc.target/powerpc/pr70117.c: Add support for long double being > > IEEE 128-bit. > > That is not what the patch does -- it instead changes the code because > it does not work correctly with long double ieee128 (which it already > did claim to support!) > > So what are the actual changes doing, why are they correct, why was the > original not correct? > > (It is easy to make a test not fail anymore: just delete it! Something > here should be better than that :-) ) I will have to look into it. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
