[Rd] Build failure on powerpc64
Hi R folks, Went to build R 3.6.2 for Fedora/EPEL and got failures across the board. Disabling the test suite for all non-intel architectures resolves most of the failures, but powerpc64 dies in the compiler, specifically here: gcc -m64 -I../../src/extra/xdr -I. -I../../src/include -I../../src/include -I/usr/local/include -I../../src/nmath -DHAVE_CONFIG_H -fopenmp -fPIC -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -c arithmetic.c -o arithmetic.o arithmetic.c:180:26: error: initializer element is not constant 180 | static LDOUBLE q_1_eps = (1 / LDBL_EPSILON); | ^ make[3]: *** [../../Makeconf:124: arithmetic.o] Error 1 Took me a bit to figure out why, but this is happening because on powerpc64, gcc is compiled with -mlong-double-128, and the long double format used on PPC is IBM's 128bit long double which is two doubles added together. As a result, gcc can't safely do const assignments to long doubles on ppc64, so it dies there. The fix is easy enough, do not try to assign a value to a static long double on ppc64. --- ./src/main/arithmetic.c.orig2019-12-12 18:30:12.416334062 + +++ ./src/main/arithmetic.c 2019-12-12 18:30:44.966334062 + @@ -179,7 +179,10 @@ void attribute_hidden InitArithmetic() #endif } -#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) +/* PowerPC 64 (when gcc has -mlong-double-128) breaks here because + * of issues constant folding 128bit IBM long doubles. + */ +#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) && !__PPC64__ static LDOUBLE q_1_eps = 1 / LDBL_EPSILON; #else static double q_1_eps = 1 / DBL_EPSILON; Hope that helps someone else. Tom [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 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
wrote:
> >>>>> Tom Callaway
> >>>>> on Thu, 12 Dec 2019 14:21:10 -0500 writes:
>
> > Hi R folks,
>
> > Went to build R 3.6.2 for Fedora/EPEL and got failures across the
> board.
>
> > Disabling the test suite for all non-intel architectures resolves
> most of
> > the failures, but powerpc64 dies in the compiler, specifically here:
>
> > gcc -m64 -I../../src/extra/xdr -I. -I../../src/include
> -I../../src/include
> > -I/usr/local/include -I../../src/nmath -DHAVE_CONFIG_H -fopenmp
> -fPIC
> > -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8
> > -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection
> -c
> > arithmetic.c -o arithmetic.o
> > arithmetic.c:180:26: error: initializer element is not constant
> > 180 | static LDOUBLE q_1_eps = (1 / LDBL_EPSILON);
> > | ^
> > make[3]: *** [../../Makeconf:124: arithmetic.o] Error 1
>
> > Took me a bit to figure out why, but this is happening because on
> > powerpc64, gcc is compiled with -mlong-double-128, and the long
> double
> > format used on PPC is IBM's 128bit long double which is two doubles
> added
> > together. As a result, gcc can't safely do const assignments to long
> > doubles on ppc64, so it dies there.
>
> > The fix is easy enough, do not try to assign a value to a static long
> > double on ppc64.
> > --- ./src/main/arithmetic.c.orig2019-12-12
> 18:30:12.416334062 +
> > +++ ./src/main/arithmetic.c 2019-12-12 18:30:44.966334062 +
> > @@ -179,7 +179,10 @@ void attribute_hidden InitArithmetic()
> > #endif
> > }
>
> > -#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> > +/* PowerPC 64 (when gcc has -mlong-double-128) breaks here because
> > + * of issues constant folding 128bit IBM long doubles.
> > + */
> > +#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) &&
> !__PPC64__
> > static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> > #else
> > static double q_1_eps = 1 / DBL_EPSILON;
>
>
> > Hope that helps someone else.
> > Tom
>
> Thank you, Tom. That is "interesting" ...
>
> The piece in question had been added by me,
>
> r77193 | maechler | 2019-09-18 13:21:49 +0200 (Wed, 18 Sep 2019) | 1 line
>
> x %% +/- Inf now typically return non-NaN; fix the "FIXME" in C
> --
Re: [Rd] Build failure on powerpc64
No, that does not change the issue: arithmetic.c:180:26: error: initializer element is not constant 180 | static LDOUBLE q_1_eps = 1.L / LDBL_EPSILON; Tom On Fri, Dec 13, 2019 at 11:56 AM Serguei Sokol wrote: > Le 13/12/2019 à 17:06, Tom Callaway a écrit : > > arithmetic.c: > > static LDOUBLE q_1_eps = 1 / LDBL_EPSILON; > Just a thought: can it be that it's "1" which is at the origin of > compiler complaint? > In this case, would the syntax "1.L" be sufficient to keep it calm? > > Serguei. > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build failure on powerpc64
This change seems correct, but as we don't have any non-PPC64 systems or
build targets in the Fedora buildsystem, it won't affect Fedora if it
doesn't make it.
Tom
On Wed, Mar 25, 2020, 6:16 AM peter dalgaard wrote:
> Do note that 3.6-patched will only be live for a day or two as we branch
> for 4.0.0 on Friday. Anything committed there is unlikely to make it into
> an official release (in principle, the 3.6 branch can be revived but it
> would take a very strong incentive to do so.)
>
> If you want an R-3.6.3-for-ppc, I think a vendor patch is the way. AFAIR
> (it's been more than a decade since I looked at this stuff) the RPM spec
> files make it fairly easy to apply changes to the sources before building.
>
> -pd
>
> > On 25 Mar 2020, at 10:00 , Martin Maechler
> wrote:
> >
> >>>>>> Martin Maechler
> >>>>>>on Tue, 17 Dec 2019 11:25:31 +0100 writes:
> >
> >>>>>> 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
&
[Rd] R Segfault reported in Fedora 17
Full details, including all sorts of logs here: https://bugzilla.redhat.com/show_bug.cgi?id=857655 A very quick look doesn't show anything obvious, in fact, it might be a readline bug, but readline is remarkably stable and boring these days. ~tom == Fedora Project __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Segfault reported in Fedora 17
On 09/17/2012 01:55 PM, peter dalgaard wrote: > Very hard to find this sort of bug without reproducibility instructions. I agree, especially if the bug is in readline somewhere. > But the bug report says that it is a SIGABRT, not SIGSEGV. That's a different > kettle of fish isn't it? Yep. It sure is. Just wanted to put in on your radar in case it ends up being helpful. I don't have any real plans to try to dig deeper into it, since this is the first such report (and Fedora has automated mechanisms for reporting crashed apps). ~tom == Fedora Project __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
