Subject: [alpine-aports] [PATCH] Add support for ppc64le

From: Breno Leitao <[email-masked]>
Date: Tue, 17 Jan 2017 14:30:31 -0200

This is a patch that adds support for ppc64le platform.  Currently, musl fails
to build with long double as 128-bits, because POWER does not implement IEEE
long double but IBM long double which causes the following error:

unsupported long double type musl

This patch just turns "long double" into "double" for ppc64le.
---
 main/musl/APKBUILD | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/main/musl/APKBUILD b/main/musl/APKBUILD
index d2f3a82..2631ebb 100644
--- a/main/musl/APKBUILD
+++ b/main/musl/APKBUILD
@@ -39,6 +39,7 @@ install_sysroot_headers() {
 	case "$CARCH" in
 	aarch64*) ARCH="aarch64" ;;
 	arm*) ARCH="arm" ;;
+	ppc64*) ARCH="powerpc64" ;;
 	x86) ARCH="i386" ;;
 	x86_64) ARCH="x86_64" ;;
 	mips*) ARCH="mips" ;;
@@ -49,6 +50,11 @@ install_sysroot_headers() {
 build() {
 	cd "$builddir"
 
+	# Consider "long double" 64-bits wide on Power
+	if [ $CARCH == "ppc64le" ]; then
+		CFLAGS="$CFLAGS -mlong-double-64"
+	fi
+
 	# provide minimal libssp_nonshared.a so we don't need libssp from gcc
 	${CROSS_COMPILE}gcc $CPPFLAGS $CFLAGS -c "$srcdir"/__stack_chk_fail_local.c -o __stack_chk_fail_local.o || return 1
 	${CROSS_COMPILE}ar r libssp_nonshared.a __stack_chk_fail_local.o || return 1
-- 
2.7.4

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Timo Teras <[email-masked]>
Date: Fri, 20 Jan 2017 14:25:10 +0200

On Tue, 17 Jan 2017 14:30:31 -0200
Breno Leitao <[email-masked]> wrote:

> This is a patch that adds support for ppc64le platform.  Currently,
> musl fails to build with long double as 128-bits, because POWER does
> not implement IEEE long double but IBM long double which causes the
> following error:
> 

Should this be in gcc default flags instead? I suspect almost nothing
will work with 128-bit double if c-library does not support it. And
assume this affects ABI too?

---

---

From: Timo Teras <[email-masked]>
Date: Fri, 20 Jan 2017 14:35:32 +0200

On Fri, 20 Jan 2017 14:25:10 +0200

> assume this affects ABI too?

http://wiki.musl-libc.org/wiki/Supported_Platforms

powerpc (needs gcc built with --enable-secureplt --with-long-double-64,
and -Wl,--secure-plt to link dynamic binaries.)

Please add these as default options for gcc. Otherwise the toolchain is
more or less broken. This makes also the musl CFLAGS hack unnecessary.
Please submit the patch for recognizing the CARCH separately.

Thanks,
Timo

---

---

From: Breno Leitao <[email-masked]>
Date: Fri, 20 Jan 2017 11:30:56 -0200

Hi Timo,

>> assume this affects ABI too?

GCC on Powerpc has a native support for long double (128-bits float). The
support is not using the traditional IEEE 754R, but a very specific format
called "IBM extended double".

This is transparent to most of the open source software. The only problem I
see recently is related to musl that requires long double to be IEEE complaint.

If we set the --with-long-double-64 as a default gcc option, we will kill
*all* long double operations, i.e long double will be equal to double. I do
not think that killing all the quad float operation is worth just to become
IEEE 754R complaint.

That is why I proposed to do this change only where it is required, and the
only package to complain about it (long double not being IEEE) seems to be musl.

POWER9 will add support for IEEE long double together with IBM extended double.

> and -Wl,--secure-plt to link dynamic binaries.)

I am *not* using enable-secureplt, and I didn't saw any problem. it seems
that I need it, tho. Not sure with it didn't break. I will take a look depeer
at building musl with secure-plt.

Thank you!

---

---

From: Timo Teras <[email-masked]>
Date: Fri, 20 Jan 2017 15:42:16 +0200

On Fri, 20 Jan 2017 11:30:56 -0200
Breno Leitao <[email-masked]> wrote:

> >>> This is a patch that adds support for ppc64le platform.
> >>> Currently, musl fails to build with long double as 128-bits,
> >>> because POWER does not implement IEEE long double but IBM long
> >>> double which causes the following error:
> >>>
> >> Should this be in gcc default flags instead? I suspect almost
> >> nothing will work with 128-bit double if c-library does not
> >> support it. And assume this affects ABI too?  
> 
> GCC on Powerpc has a native support for long double (128-bits float).
> The support is not using the traditional IEEE 754R, but a very
> specific format called "IBM extended double".
> 
> This is transparent to most of the open source software. The only
> problem I see recently is related to musl that requires long double
> to be IEEE complaint.
> 
> If we set the --with-long-double-64 as a default gcc option, we will
> kill *all* long double operations, i.e long double will be equal to
> double. I do not think that killing all the quad float operation is
> worth just to become IEEE 754R complaint.
> 
> That is why I proposed to do this change only where it is required,
> and the only package to complain about it (long double not being
> IEEE) seems to be musl.
> 

But if you compile musl different from rest of system, then printf and
all C-library provided function operating on a double will not work for
the caller, due to assuming different double types. I'm pretty sure
you'd have a broken system in this case.

The only case where it makes sense is that the software using 'double'
is not calling any libc functions. But this is rare case. If there's
such software they probably setup CFLAGS anyway properly for this with
-ffreestanding etc.

I think ultimately the thing is that musl does not (yet?) support
128-bit double on powerpc. You might want to ask on #musl or musl
mailing list about this.

But for the time being we should just enable gcc's
--with-long-double-64 and live with this limitation.

/Timo

---

---

From: Breno Leitao <[email-masked]>
Date: Fri, 20 Jan 2017 13:54:03 -0200

Hi Timo,

> --with-long-double-64 and live with this limitation.

Yes, I agree with you. I just update the Pull Request with this new change
and linked to this discussion:

https://github.com/alpinelinux/aports/pull/765/commits/ae03bb344b4bd91fe3c9b91e49ab8270a27ac73c

Thank you,
Breno

---