Skip to content
Prev 57829 / 63424 Next

Build failure on powerpc64

An excellent question. It is important to remember two key facts:

1. With gcc on ppc64, long doubles exist, they can be used, just not safely
as constants (and maybe they still can be used safely under specific
conditions?).
2. I am not an expert in either PowerPC64 or gcc. :)

Looking at connections.c, we have (in order):
  * handling long double as a valid case in a switch statement checking size
  * adding long double as a field in the u union define
  * handling long double as a valid case in a switch statement checking size
  * handling long double as a valid case in a switch statement checking size
  * memcpy from the address of a long double

In format.c, we have (in order):
  * conditionally creating private_nearbyintl for R_nearbyintl
  * defining a static const long double tbl[]
  * use exact scaling factor in long double precision

For most of these, it seems safe to leave them as is for ppc64. I would
have thought that the gcc compiler might have had issue with:

connections.c:
              static long double ld1;
                for (i = 0, j = 0; i < len; i++, j += size) {
                    ld1 = (long double) REAL(object)[i];

format.c:
   static const long double tbl[] =

... but it doesn't. Perhaps the original code at issue:

arithmetic.c:
   static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;

only makes gcc unhappy because of the very large value trying to be stored
in the static long double, which would make it span the "folded double" on
that architecture.

*****

It seems that the options are:

A) Patch the one place where the compiler determines it is not safe to use
a static long double on ppc64.
B) Treat PPC64 as a platform where it is never safe to use a static long
double

FWIW, I did run the test suite after applying my patch and all of the tests
pass on ppc64.

Tom


On Fri, Dec 13, 2019 at 5:44 AM Martin Maechler <maechler at stat.math.ethz.ch>
wrote: