powerpc64le build fails with GCC7
Commit Message
Hi all,
With GCC7, the test for -mfloat128 fails with a message that this option
requires -mfloat128-type to be supplied as well. Cannot supply both
options unconditionally, though, as GCC6 would choke on unknown option.
Patch attached, please review. Build-tested only, with GCC 7.2.0 and 6.4.0.
Regards,
Alexey.
Comments
On Mon, 21 Aug 2017, Alexey Neyman wrote:
> Hi all,
>
> With GCC7, the test for -mfloat128 fails with a message that this option
> requires -mfloat128-type to be supplied as well. Cannot supply both options
> unconditionally, though, as GCC6 would choke on unknown option.
Could you explain further what the circumstances are under which this is
or is not needed, given that people have evidently been building without
this option, presumably with GCC configured differently?
You should not need to edit the toplevel configure.ac or config.make.in to
set an architecture-specific makefile variable. Rather, use
LIBC_CONFIG_VAR in the sysdeps configure.ac to set such a variable without
needing to change system-independent files.
On Mon, Aug 21, 2017 at 08:56:48AM -0700, Alexey Neyman wrote:
> Hi all,
>
> With GCC7, the test for -mfloat128 fails with a message that this
> option requires -mfloat128-type to be supplied as well. Cannot
> supply both options unconditionally, though, as GCC6 would choke on
> unknown option.
>
> Patch attached, please review. Build-tested only, with GCC 7.2.0 and 6.4.0.
>
> Regards,
> Alexey.
>
> From ea42205587b557c604f165ffdb745d94035fd18d Mon Sep 17 00:00:00 2001
> From: Alexey Neyman <stilor@att.net>
> Date: Mon, 21 Aug 2017 08:50:02 -0700
> Subject: [PATCH] Fix powerpc64le target with GCC7
>
> With GCC7, the test for -mfloat128 fails with a message that this
> option requires -mfloat128-type to be supplied as well. Cannot
> supply both options unconditionally, though, as GCC6 would choke
> on unknown option.
>
> * sysdeps/powerpc/powerpc64le/configure.ac:
> Detect if -mfloat128-type needs to be supplied in addition to
> -mfloat128
> * configure.ac (libc_cv_compiler_powerpc64le_float128_type):
> New variable.
> * config.make.in (config-cflags-mfloat128-type): New variable.
> * sysdeps/powerpc/powerpc64le/configure, configure: Regenerate.
This comes up because when you configure a cross compiler, the test for whether
long double defaults to 64 bits or 128 bits fails (i.e. glibc is at least 2.4
or newer), and the compiler defaults long double to 64 bits. If you add the
--with-long-double-128 switch when you build the compiler, it should avoid the
message.
Similarly, when my patch to make -mfloat128 goes in, I reworked the test so
that float128 no longer checks if long doubles are 64 bits or 128 bits.
However, if you are doing a cross compiler, you should make sure the long
double support matches your target system (presumably configure the cross
compiler to use an appropriate glibc or add the --with-long-double-128
configuration option).
On 08/21/2017 10:20 AM, Joseph Myers wrote:
> On Mon, 21 Aug 2017, Alexey Neyman wrote:
>
>> Hi all,
>>
>> With GCC7, the test for -mfloat128 fails with a message that this option
>> requires -mfloat128-type to be supplied as well. Cannot supply both options
>> unconditionally, though, as GCC6 would choke on unknown option.
> Could you explain further what the circumstances are under which this is
> or is not needed, given that people have evidently been building without
> this option, presumably with GCC configured differently?
This issue occurred during the bootstrap pass-1 of the
'powerpc64le-unknown-linux-gnu' sample in the crosstool-NG. Crosstool-NG
does three builds of GCC:
- "bootstrap pass-1" builds just the GCC itself with only C language -
it is then used to build the CRT and install headers from the selected libc
- "bootstrap pass-2" builds GCC with only C language, with headers/CRT
already in the sysroot (so it can build libgcc) - it is then used to
build the libc
- "final pass" builds GCC with all the enabled languages and libraries.
GCC was configured as follows:
/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/build/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=powerpc64le-unknown-linux-gnu
--prefix=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools
--with-local-prefix=/home/avn/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot
--with-sysroot=/home/avn/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot
--with-newlib --enable-threads=no --disable-shared
--with-pkgversion='crosstool-NG crosstool-ng-1.23.0-174-g9ee0e06f'
--enable-__cxa_atexit --disable-libgomp --disable-libmudflap
--disable-libmpx --disable-libssp --disable-libquadmath
--disable-libquadmath-support
--with-gmp=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools
--with-mpfr=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools
--with-mpc=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools
--with-isl=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools
--enable-lto --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-target-optspace
--disable-nls --disable-multilib --enable-languages=c
Now that you mentioned that it has been building successfully, I tried
the same option with the "pass-2" bootstrap compiler and this option
worked fine.
The difference between the pass-1 and pass-2 compilers is:
pass-1: --with-newlib --enable-threads=no --disable-shared
pass-2: --enable-shared
I then tried configuring pass-2 compiler in the same way as pass-1 and
-mfloat128 still worked even without -mfloat128-type. So, GCC's
configure selects different setting for TARGET_FLOAT128_TYPE depending
on whether the headers are already installed in sysroot.
In other words, it works when configuring GCC against a sysroot with a
previously built/installed GLIBC headers. But it doesn't work when
bootstrapping from the ground up.
At this point, I am not sure whether it is a GLIBC bug (i.e. it should
bootstrap regardless of the TARGET_FLOAT128_TYPE setting in GCC) or a
GCC bug (i.e. it should configure TARGET_FLOAT128_TYPE consistently
regardless of the headers being present in sysroot). Please advise.
Regards,
Alexey.
>
> You should not need to edit the toplevel configure.ac or config.make.in to
> set an architecture-specific makefile variable. Rather, use
> LIBC_CONFIG_VAR in the sysdeps configure.ac to set such a variable without
> needing to change system-independent files.
>
On 08/21/2017 12:40 PM, Michael Meissner wrote:
> On Mon, Aug 21, 2017 at 08:56:48AM -0700, Alexey Neyman wrote:
>> Hi all,
>>
>> With GCC7, the test for -mfloat128 fails with a message that this
>> option requires -mfloat128-type to be supplied as well. Cannot
>> supply both options unconditionally, though, as GCC6 would choke on
>> unknown option.
>>
>> Patch attached, please review. Build-tested only, with GCC 7.2.0 and 6.4.0.
>>
>> Regards,
>> Alexey.
>>
>> From ea42205587b557c604f165ffdb745d94035fd18d Mon Sep 17 00:00:00 2001
>> From: Alexey Neyman <stilor@att.net>
>> Date: Mon, 21 Aug 2017 08:50:02 -0700
>> Subject: [PATCH] Fix powerpc64le target with GCC7
>>
>> With GCC7, the test for -mfloat128 fails with a message that this
>> option requires -mfloat128-type to be supplied as well. Cannot
>> supply both options unconditionally, though, as GCC6 would choke
>> on unknown option.
>>
>> * sysdeps/powerpc/powerpc64le/configure.ac:
>> Detect if -mfloat128-type needs to be supplied in addition to
>> -mfloat128
>> * configure.ac (libc_cv_compiler_powerpc64le_float128_type):
>> New variable.
>> * config.make.in (config-cflags-mfloat128-type): New variable.
>> * sysdeps/powerpc/powerpc64le/configure, configure: Regenerate.
> This comes up because when you configure a cross compiler, the test for whether
> long double defaults to 64 bits or 128 bits fails (i.e. glibc is at least 2.4
> or newer), and the compiler defaults long double to 64 bits. If you add the
> --with-long-double-128 switch when you build the compiler, it should avoid the
> message.
Thanks, this explains it.
Shouldn't the GCC configuration fall back to 128-bit long double if the
test fails - given that GLIBC requires it?
Regards,
Alexey.
>
> Similarly, when my patch to make -mfloat128 goes in, I reworked the test so
> that float128 no longer checks if long doubles are 64 bits or 128 bits.
> However, if you are doing a cross compiler, you should make sure the long
> double support matches your target system (presumably configure the cross
> compiler to use an appropriate glibc or add the --with-long-double-128
> configuration option).
>
>
On 08/21/2017 02:08 PM, Alexey Neyman wrote:
> On 08/21/2017 12:40 PM, Michael Meissner wrote:
>> On Mon, Aug 21, 2017 at 08:56:48AM -0700, Alexey Neyman wrote:
>>> Hi all,
>>>
>>> With GCC7, the test for -mfloat128 fails with a message that this
>>> option requires -mfloat128-type to be supplied as well. Cannot
>>> supply both options unconditionally, though, as GCC6 would choke on
>>> unknown option.
>>>
>>> Patch attached, please review. Build-tested only, with GCC 7.2.0 and
>>> 6.4.0.
>>>
>>> Regards,
>>> Alexey.
>>>
>>> From ea42205587b557c604f165ffdb745d94035fd18d Mon Sep 17 00:00:00 2001
>>> From: Alexey Neyman <stilor@att.net>
>>> Date: Mon, 21 Aug 2017 08:50:02 -0700
>>> Subject: [PATCH] Fix powerpc64le target with GCC7
>>>
>>> With GCC7, the test for -mfloat128 fails with a message that this
>>> option requires -mfloat128-type to be supplied as well. Cannot
>>> supply both options unconditionally, though, as GCC6 would choke
>>> on unknown option.
>>>
>>> * sysdeps/powerpc/powerpc64le/configure.ac:
>>> Detect if -mfloat128-type needs to be supplied in addition to
>>> -mfloat128
>>> * configure.ac (libc_cv_compiler_powerpc64le_float128_type):
>>> New variable.
>>> * config.make.in (config-cflags-mfloat128-type): New variable.
>>> * sysdeps/powerpc/powerpc64le/configure, configure: Regenerate.
>> This comes up because when you configure a cross compiler, the test
>> for whether
>> long double defaults to 64 bits or 128 bits fails (i.e. glibc is at
>> least 2.4
>> or newer), and the compiler defaults long double to 64 bits. If you
>> add the
>> --with-long-double-128 switch when you build the compiler, it should
>> avoid the
>> message.
> Thanks, this explains it.
>
> Shouldn't the GCC configuration fall back to 128-bit long double if
> the test fails - given that GLIBC requires it?
This should've been:
Shouldn't the GCC configuration for powerpc64le-*-linux target fall back
to 128-bit long double if the test fails - given that GLIBC requires it?
Sorry, hit "send" too fast.
>
> Regards,
> Alexey.
>
>>
>> Similarly, when my patch to make -mfloat128 goes in, I reworked the
>> test so
>> that float128 no longer checks if long doubles are 64 bits or 128 bits.
>> However, if you are doing a cross compiler, you should make sure the
>> long
>> double support matches your target system (presumably configure the
>> cross
>> compiler to use an appropriate glibc or add the --with-long-double-128
>> configuration option).
>>
>>
>
On Mon, 21 Aug 2017, Alexey Neyman wrote:
> At this point, I am not sure whether it is a GLIBC bug (i.e. it should
> bootstrap regardless of the TARGET_FLOAT128_TYPE setting in GCC) or a GCC bug
> (i.e. it should configure TARGET_FLOAT128_TYPE consistently regardless of the
> headers being present in sysroot). Please advise.
I think you should investigate further why the difference in
TARGET_FLOAT128_TYPE. But, it's always a good idea to configure such a
bootstrap compiler with --with-glibc-version=<whatever>, which should
avoid any need to find headers in the sysroot. And on some platforms it's
necessary to do so if you want to do a bootstrap with only two rather than
three GCC builds (with the first bootstrap GCC being used to build a glibc
that's identical to what an alternating series of builds would converge
on) as otherwise GCC disagrees with glibc's expectations about
stack-smashing protection mechanisms.
On 08/21/2017 02:21 PM, Joseph Myers wrote:
> On Mon, 21 Aug 2017, Alexey Neyman wrote:
>
>> At this point, I am not sure whether it is a GLIBC bug (i.e. it should
>> bootstrap regardless of the TARGET_FLOAT128_TYPE setting in GCC) or a GCC bug
>> (i.e. it should configure TARGET_FLOAT128_TYPE consistently regardless of the
>> headers being present in sysroot). Please advise.
> I think you should investigate further why the difference in
> TARGET_FLOAT128_TYPE.
Michael Meissner has just identified the cause for that difference; it
is the failing test for "--with-long-double-128". So, the question
becomes - shouldn't GCC default to 128-bit long doubles on
powerpc64le-*-linux targets, given this is what GLIBC supports?
> But, it's always a good idea to configure such a
> bootstrap compiler with --with-glibc-version=<whatever>, which should
> avoid any need to find headers in the sysroot. And on some platforms it's
> necessary to do so if you want to do a bootstrap with only two rather than
> three GCC builds (with the first bootstrap GCC being used to build a glibc
> that's identical to what an alternating series of builds would converge
> on) as otherwise GCC disagrees with glibc's expectations about
> stack-smashing protection mechanisms.
It would not have helped in this case. I'll add this as a further
enhancement in crosstool-NG, thanks for the tip. Regarding two GCC
builds, though - does --with-glibc-version=... also obviate the need for
crt*.o files when building bootstrap GCC (i.e., libgcc)? Currently,
crt*.o are built using "bootstrap pass-1" compiler and then passed to
"bootstrap pass-2" so that it can build libgcc.so.
Regards,
Alexey.
>
On Mon, 21 Aug 2017, Alexey Neyman wrote:
> On 08/21/2017 02:21 PM, Joseph Myers wrote:
> > On Mon, 21 Aug 2017, Alexey Neyman wrote:
> >
> > > At this point, I am not sure whether it is a GLIBC bug (i.e. it should
> > > bootstrap regardless of the TARGET_FLOAT128_TYPE setting in GCC) or a GCC
> > > bug
> > > (i.e. it should configure TARGET_FLOAT128_TYPE consistently regardless of
> > > the
> > > headers being present in sysroot). Please advise.
> > I think you should investigate further why the difference in
> > TARGET_FLOAT128_TYPE.
> Michael Meissner has just identified the cause for that difference; it is the
> failing test for "--with-long-double-128". So, the question becomes -
> shouldn't GCC default to 128-bit long doubles on powerpc64le-*-linux targets,
> given this is what GLIBC supports?
I think the GCC default based on old glibc is ridiculous for powerpc64le,
which never supported such old glibc. It's dubious generically for all
targets where the change was in glibc 2.4; there's no obvious reason for
being able to configure GCC for 64-bit long double on any of those targets
other than by an explicit configure option. (Things may be different when
configured with a target triplet for C libraries other than glibc; my
comments are specifically for *-linux-gnu* targets.)
But, given the link to that configure option, and given that we check for
-mlong-double-128 in configure, checking for this other option seems
reasonable.
> > But, it's always a good idea to configure such a
> > bootstrap compiler with --with-glibc-version=<whatever>, which should
> > avoid any need to find headers in the sysroot. And on some platforms it's
> > necessary to do so if you want to do a bootstrap with only two rather than
> > three GCC builds (with the first bootstrap GCC being used to build a glibc
> > that's identical to what an alternating series of builds would converge
> > on) as otherwise GCC disagrees with glibc's expectations about
> > stack-smashing protection mechanisms.
> It would not have helped in this case. I'll add this as a further enhancement
> in crosstool-NG, thanks for the tip. Regarding two GCC builds, though - does
> --with-glibc-version=... also obviate the need for crt*.o files when building
> bootstrap GCC (i.e., libgcc)? Currently, crt*.o are built using "bootstrap
> pass-1" compiler and then passed to "bootstrap pass-2" so that it can build
> libgcc.so.
The first build of GCC builds only static libgcc, with inhibit-libc.
That first build suffices to build glibc. With that glibc you can then
build the final GCC, with shared libgcc and non-C-language support. The
(stripped) glibc binary should be identical to one resulting from a longer
sequence of alternating GCC and glibc builds (it was on the platforms I
tested this on, when implementing --with-glibc-version and the other glibc
and libgcc build changes required for this).
See build-many-glibcs.py for details of a working modern bootstrap process
that builds GCC only twice. Note that this process requires GCC 4.9 or
later (but so does building current glibc at all). Also note that you
need to rebuild glibc with the final compiler if you want to run the full
testsuite, because parts of that depend on being configured with a
compiler with C++ support and shared libgcc.
From ea42205587b557c604f165ffdb745d94035fd18d Mon Sep 17 00:00:00 2001
From: Alexey Neyman <stilor@att.net>
Date: Mon, 21 Aug 2017 08:50:02 -0700
Subject: [PATCH] Fix powerpc64le target with GCC7
With GCC7, the test for -mfloat128 fails with a message that this
option requires -mfloat128-type to be supplied as well. Cannot
supply both options unconditionally, though, as GCC6 would choke
on unknown option.
* sysdeps/powerpc/powerpc64le/configure.ac:
Detect if -mfloat128-type needs to be supplied in addition to
-mfloat128
* configure.ac (libc_cv_compiler_powerpc64le_float128_type):
New variable.
* config.make.in (config-cflags-mfloat128-type): New variable.
* sysdeps/powerpc/powerpc64le/configure, configure: Regenerate.
Signed-off-by: Alexey Neyman <stilor@att.net>
---
ChangeLog | 10 ++++++
config.make.in | 1 +
configure | 4 +++
configure.ac | 3 ++
sysdeps/powerpc/powerpc64le/Makefile | 58 +++++++++++++++++---------------
sysdeps/powerpc/powerpc64le/configure | 20 ++++++++++-
sysdeps/powerpc/powerpc64le/configure.ac | 8 ++++-
7 files changed, 74 insertions(+), 30 deletions(-)
@@ -1,3 +1,13 @@
+2017-08-21 Alexey Neyman <stilor@att.net>
+
+ * sysdeps/powerpc/powerpc64le/configure.ac:
+ Detect if -mfloat128-type needs to be supplied in addition to
+ -mfloat128
+ * configure.ac (libc_cv_compiler_powerpc64le_float128_type):
+ New variable.
+ * config.make.in (config-cflags-mfloat128-type): New variable.
+ * sysdeps/powerpc/powerpc64le/configure, configure: Regenerate.
+
2017-08-21 Florian Weimer <fweimer@redhat.com>
[BZ #21972]
@@ -40,6 +40,7 @@ asflags-cpu = @libc_cv_cc_submachine@
config-extra-cflags = @libc_extra_cflags@
config-extra-cppflags = @libc_extra_cppflags@
config-cflags-nofma = @libc_cv_cc_nofma@
+config-cflags-mfloat128-type = @libc_cv_compiler_powerpc64le_float128_type@
defines = @DEFINES@
sysheaders = @sysheaders@
@@ -618,6 +618,7 @@ have_libaudit
LIBGD
libc_cv_cc_loop_to_function
libc_cv_cc_submachine
+libc_cv_compiler_powerpc64le_float128_type
libc_cv_cc_nofma
libc_cv_mtls_dialect_gnu2
fno_unit_at_a_time
@@ -6331,6 +6332,9 @@ fi
$as_echo "$libc_cv_cc_nofma" >&6; }
+# Detected in powerpc64le fragment
+
+
if test -n "$submachine"; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for compiler option for CPU variant" >&5
$as_echo_n "checking for compiler option for CPU variant... " >&6; }
@@ -1677,6 +1677,9 @@ for opt in -ffp-contract=off -mno-fused-madd; do
done])
AC_SUBST(libc_cv_cc_nofma)
+# Detected in powerpc64le fragment
+AC_SUBST(libc_cv_compiler_powerpc64le_float128_type)
+
if test -n "$submachine"; then
AC_CACHE_CHECK([for compiler option for CPU variant],
libc_cv_cc_submachine, [dnl
@@ -6,35 +6,37 @@
# linked executables, forcing to link the loader after libgcc link.
f128-loader-link = $(as-needed) $(elf-objpfx)ld.so $(no-as-needed)
+f128-options = -mfloat128 $(config-cflags-mfloat128-type)
+
ifeq ($(subdir),math)
# sqrtf128 requires emulation before POWER9.
CPPFLAGS += -I../soft-fp
# float128 requires adding a handful of extra flags.
-$(foreach suf,$(all-object-suffixes),%f128$(suf)): CFLAGS += -mfloat128
-$(foreach suf,$(all-object-suffixes),%f128_r$(suf)): CFLAGS += -mfloat128
-$(foreach suf,$(all-object-suffixes),$(objpfx)test-float128%$(suf)): CFLAGS += -mfloat128
-$(foreach suf,$(all-object-suffixes),$(objpfx)test-ifloat128%$(suf)): CFLAGS += -mfloat128
-CFLAGS-libm-test-support-float128.c += -mfloat128
+$(foreach suf,$(all-object-suffixes),%f128$(suf)): CFLAGS += $(f128-options)
+$(foreach suf,$(all-object-suffixes),%f128_r$(suf)): CFLAGS += $(f128-options)
+$(foreach suf,$(all-object-suffixes),$(objpfx)test-float128%$(suf)): CFLAGS += $(f128-options)
+$(foreach suf,$(all-object-suffixes),$(objpfx)test-ifloat128%$(suf)): CFLAGS += $(f128-options)
+CFLAGS-libm-test-support-float128.c += $(f128-options)
$(objpfx)test-float128% $(objpfx)test-ifloat128%: \
gnulib-tests += $(f128-loader-link)
endif
# Append flags to string <-> _Float128 routines.
ifneq ($(filter $(subdir),wcsmbs stdlib),)
-$(foreach suf,$(all-object-suffixes),%f128$(suf)): CFLAGS += -mfloat128
-$(foreach suf,$(all-object-suffixes),%f128_l$(suf)): CFLAGS += -mfloat128
-$(foreach suf,$(all-object-suffixes),%f128_nan$(suf)): CFLAGS += -mfloat128
-$(foreach suf,$(all-object-suffixes),%float1282mpn$(suf)): CFLAGS += -mfloat128
-$(foreach suf,$(all-object-suffixes),%mpn2float128$(suf)): CFLAGS += -mfloat128
-CFLAGS-bug-strtod.c += -mfloat128
-CFLAGS-bug-strtod2.c += -mfloat128
-CFLAGS-tst-strtod-round.c += -mfloat128
-CFLAGS-tst-wcstod-round.c += -mfloat128
-CFLAGS-tst-strtod6.c += -mfloat128
-CFLAGS-tst-strfrom.c += -mfloat128
-CFLAGS-tst-strfrom-locale.c += -mfloat128
-CFLAGS-strfrom-skeleton.c += -mfloat128
+$(foreach suf,$(all-object-suffixes),%f128$(suf)): CFLAGS += $(f128-options)
+$(foreach suf,$(all-object-suffixes),%f128_l$(suf)): CFLAGS += $(f128-options)
+$(foreach suf,$(all-object-suffixes),%f128_nan$(suf)): CFLAGS += $(f128-options)
+$(foreach suf,$(all-object-suffixes),%float1282mpn$(suf)): CFLAGS += $(f128-options)
+$(foreach suf,$(all-object-suffixes),%mpn2float128$(suf)): CFLAGS += $(f128-options)
+CFLAGS-bug-strtod.c += $(f128-options)
+CFLAGS-bug-strtod2.c += $(f128-options)
+CFLAGS-tst-strtod-round.c += $(f128-options)
+CFLAGS-tst-wcstod-round.c += $(f128-options)
+CFLAGS-tst-strtod6.c += $(f128-options)
+CFLAGS-tst-strfrom.c += $(f128-options)
+CFLAGS-tst-strfrom-locale.c += $(f128-options)
+CFLAGS-strfrom-skeleton.c += $(f128-options)
$(foreach test,bug-strtod bug-strtod2 bug-strtod2 tst-strtod-round \
tst-wcstod-round tst-strtod6 tst-strrom tst-strfrom-locale \
strfrom-skeleton,$(objpfx)$(test)): gnulib-tests += $(f128-loader-link)
@@ -44,18 +46,18 @@ strfrom-skeleton,$(objpfx)$(test)): gnulib-tests += $(f128-loader-link)
# Makefiles (e.g.: wcsmbs/Makefile) override CFLAGS defined by the Makefiles in
# sysdeps. This is avoided with the use sysdep-CFLAGS instead of CFLAGS.
sysdep-CFLAGS += $(sysdep-CFLAGS-$(<F))
-sysdep-CFLAGS-fpioconst.c += -mfloat128
-sysdep-CFLAGS-strtod_l.c += -mfloat128
-sysdep-CFLAGS-strtof_l.c += -mfloat128
-sysdep-CFLAGS-strtold_l.c += -mfloat128
-sysdep-CFLAGS-wcstod_l.c += -mfloat128
-sysdep-CFLAGS-wcstof_l.c += -mfloat128
-sysdep-CFLAGS-wcstold_l.c += -mfloat128
+sysdep-CFLAGS-fpioconst.c += $(f128-options)
+sysdep-CFLAGS-strtod_l.c += $(f128-options)
+sysdep-CFLAGS-strtof_l.c += $(f128-options)
+sysdep-CFLAGS-strtold_l.c += $(f128-options)
+sysdep-CFLAGS-wcstod_l.c += $(f128-options)
+sysdep-CFLAGS-wcstof_l.c += $(f128-options)
+sysdep-CFLAGS-wcstold_l.c += $(f128-options)
endif
# Append flags to printf routines.
ifeq ($(subdir),stdio-common)
-CFLAGS-printf_fp.c = -mfloat128
-CFLAGS-printf_fphex.c = -mfloat128
-CFLAGS-printf_size.c = -mfloat128
+CFLAGS-printf_fp.c = $(f128-options)
+CFLAGS-printf_fphex.c = $(f128-options)
+CFLAGS-printf_size.c = $(f128-options)
endif
@@ -1,6 +1,24 @@
# This file is generated from configure.ac by Autoconf. DO NOT EDIT!
# Local configure fragment for sysdeps/powerpc/powerpc64le.
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether compiler supports -mfloat128-type" >&5
+$as_echo_n "checking whether compiler supports -mfloat128-type... " >&6; }
+if ${libc_cv_compiler_powerpc64le_float128_type+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ if { ac_try='${CC-cc} -mfloat128-type -xc /dev/null -S -o /dev/null'
+ { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; }; }; then :
+ libc_cv_compiler_powerpc64le_float128_type=-mfloat128-type
+fi
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_compiler_powerpc64le_float128_type" >&5
+$as_echo "$libc_cv_compiler_powerpc64le_float128_type" >&6; }
+
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if $CC supports binary128 floating point type" >&5
$as_echo_n "checking if $CC supports binary128 floating point type... " >&6; }
@@ -8,7 +26,7 @@ if ${libc_cv_compiler_powerpc64le_binary128_ok+:} false; then :
$as_echo_n "(cached) " >&6
else
save_CFLAGS="$CFLAGS"
-CFLAGS="$CFLAGS -Werror -mfloat128"
+CFLAGS="$CFLAGS -Werror -mfloat128 $libc_cv_compiler_powerpc64le_float128_type"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
@@ -1,12 +1,18 @@
GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
# Local configure fragment for sysdeps/powerpc/powerpc64le.
+AC_CACHE_CHECK([whether compiler supports -mfloat128-type],
+ libc_cv_compiler_powerpc64le_float128_type, [dnl
+LIBC_TRY_CC_OPTION([-mfloat128-type],
+ [libc_cv_compiler_powerpc64le_float128_type=-mfloat128-type])
+])
+
dnl Require binary128 floating point support on powerpc64le (available in
dnl GCC 6.2).
AC_CACHE_CHECK([if $CC supports binary128 floating point type],
libc_cv_compiler_powerpc64le_binary128_ok, [dnl
save_CFLAGS="$CFLAGS"
-CFLAGS="$CFLAGS -Werror -mfloat128"
+CFLAGS="$CFLAGS -Werror -mfloat128 $libc_cv_compiler_powerpc64le_float128_type"
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
__float128 a, b, c, d, e;
int i;
--
2.11.0