[Rd] Build failure on powerpc64

[Martin Maechler]

>>>>> Tom Callaway 
>>>>>     on Fri, 13 Dec 2019 11:06:25 -0500 writes:

    > 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

Thank you, Tom.
You were right... and only  A)  is needed.

In the mean time I've also been CC'ed in a corresponding debian
bug report on the exact same architecture.

In the end, after explanation and recommendation by Tomas
Kalibera, I've committed a slightly better change to R's
sources, both in the R-devel (trunk) and the "R-3.6.x patched"
branch:  Via a macro, it continues to use long double also for
the PPC 64 in this case:

$ svn diff -c77587
Index: src/main/arithmetic.c
===================================================================
--- src/main/arithmetic.c	(Revision 77586)
+++ src/main/arithmetic.c	(Revision 77587)
@@ -176,8 +176,14 @@
 #endif
 }
 
+
 #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
+# ifdef __PPC64__
+ // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding with LDOUBLE
+#  define q_1_eps (1 / LDBL_EPSILON)
+# else
 static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
+# endif
 #else
 static double  q_1_eps = 1 / DBL_EPSILON;
 #endif

------------- ------------- -------------

Thank you (and everybody else involved) once more,
Martin