~alpine/aports

This thread contains a patchset. You're looking at the original emails, but you may wish to use the patch review UI. Review patch
5 2

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

Breno Leitao <brenohl@br.ibm.com>
Details
Message ID
<1484670631-10385-1-git-send-email-brenohl@br.ibm.com>
Sender timestamp
1484670631
DKIM signature
missing
Download raw message
Patch: +6 -0
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:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Breno Leitao <brenohl@br.ibm.com>
Details
Message ID
<68f63acc-b6ad-5370-55a8-a55ea4e8b479@br.ibm.com>
In-Reply-To
<20170120143532.1aa59d71@vostro> (view parent)
Sender timestamp
1484919056
DKIM signature
missing
Download raw message
Hi Timo,

On 01/20/2017 10:35 AM, Timo Teras wrote:
> On Fri, 20 Jan 2017 14:25:10 +0200
> Timo Teras <timo.teras@iki.fi> wrote:
> 
>> On Tue, 17 Jan 2017 14:30:31 -0200
>> Breno Leitao <brenohl@br.ibm.com> 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:
>>>
>>> unsupported long double type musl
>>>
>>> This patch just turns "long double" into "double" for ppc64le.  
>>
>> 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.

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

> 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.)

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!



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Breno Leitao <brenohl@br.ibm.com>
Details
Message ID
<5864bbf3-3968-c1dd-e268-2078e9a29560@br.ibm.com>
In-Reply-To
<20170120154216.699bd22d@vostro> (view parent)
Sender timestamp
1484927643
DKIM signature
missing
Download raw message
Hi Timo,

On 01/20/2017 11:42 AM, Timo Teras wrote:
> On Fri, 20 Jan 2017 11:30:56 -0200
> Breno Leitao <brenohl@br.ibm.com> wrote:
> 
>> Hi Timo,
>>
>> On 01/20/2017 10:35 AM, Timo Teras wrote:
>>> On Fri, 20 Jan 2017 14:25:10 +0200
>>> Timo Teras <timo.teras@iki.fi> wrote:
>>>   
>>>> On Tue, 17 Jan 2017 14:30:31 -0200
>>>> Breno Leitao <brenohl@br.ibm.com> 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:
>>>>>
>>>>> unsupported long double type musl
>>>>>
>>>>> This patch just turns "long double" into "double" for ppc64le.    
>>>>
>>>> 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.
>>
>> POWER9 will add support for IEEE long double together with IBM
>> extended double.
> 
> 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.

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



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20170120142510.7dd61350@vostro>
In-Reply-To
<1484670631-10385-1-git-send-email-brenohl@br.ibm.com> (view parent)
Sender timestamp
1484915110
DKIM signature
missing
Download raw message
On Tue, 17 Jan 2017 14:30:31 -0200
Breno Leitao <brenohl@br.ibm.com> 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:
> 
> unsupported long double type musl
> 
> This patch just turns "long double" into "double" for ppc64le.

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?



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20170120143532.1aa59d71@vostro>
In-Reply-To
<20170120142510.7dd61350@vostro> (view parent)
Sender timestamp
1484915732
DKIM signature
missing
Download raw message
On Fri, 20 Jan 2017 14:25:10 +0200
Timo Teras <timo.teras@iki.fi> wrote:

> On Tue, 17 Jan 2017 14:30:31 -0200
> Breno Leitao <brenohl@br.ibm.com> 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:
> > 
> > unsupported long double type musl
> > 
> > This patch just turns "long double" into "double" for ppc64le.  
> 
> 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?

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


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20170120154216.699bd22d@vostro>
In-Reply-To
<68f63acc-b6ad-5370-55a8-a55ea4e8b479@br.ibm.com> (view parent)
Sender timestamp
1484919736
DKIM signature
missing
Download raw message
On Fri, 20 Jan 2017 11:30:56 -0200
Breno Leitao <brenohl@br.ibm.com> wrote:

> Hi Timo,
> 
> On 01/20/2017 10:35 AM, Timo Teras wrote:
> > On Fri, 20 Jan 2017 14:25:10 +0200
> > Timo Teras <timo.teras@iki.fi> wrote:
> >   
> >> On Tue, 17 Jan 2017 14:30:31 -0200
> >> Breno Leitao <brenohl@br.ibm.com> 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:
> >>>
> >>> unsupported long double type musl
> >>>
> >>> This patch just turns "long double" into "double" for ppc64le.    
> >>
> >> 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.
> 
> POWER9 will add support for IEEE long double together with IBM
> extended double.

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


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)