[Bug libquadmath/116007] New: libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[Bug libquadmath/116007] New: libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni@free-electrons.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

            Bug ID: 116007
           Summary: libquadmath fails to build with
                    libgcc/soft-fp/quad.h:69:1: error: unable to emulate
                    'TF'
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libquadmath
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thomas.petazzoni@free-electrons.com
  Target Milestone: ---

When GCC 14.1.0 is configured with:

./configure --prefix="/home/buildroot/autobuild/instance-3/output-1/host"
--sysconfdir="/home/buildroot/autobuild/instance-3/output-1/host/etc"
--enable-static  --target=powerpc64le-buildroot-linux-musl
--with-sysroot=/home/buildroot/autobuild/instance-3/output-1/host/powerpc64le-buildroot-linux-musl/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float --enable-plugins --enable-lto
--with-gmp=/home/buildroot/autobuild/instance-3/output-1/host
--with-mpc=/home/buildroot/autobuild/instance-3/output-1/host
--with-mpfr=/home/buildroot/autobuild/instance-3/output-1/host
--with-pkgversion="Buildroot 2024.05-761-gc624eee120"
--with-bugurl="https://gitlab.com/buildroot.org/buildroot/-/issues"
--without-zstd --disable-libmpx --enable-libquadmath
--enable-libquadmath-support --disable-libsanitizer --enable-tls
--enable-threads --without-isl --without-cloog --with-cpu=power8
--enable-languages=c,fortran
--with-build-time-tools=/home/buildroot/autobuild/instance-3/output-1/host/powerpc64le-buildroot-linux-musl/bin
--disable-shared --disable-libgomp 

it fails to build with:

In file included from ../../../libquadmath/math/sqrtq.c:13:
../../../libquadmath/math/../../libgcc/soft-fp/quad.h:69:1: error: unable to
emulate 'TF'
   69 | typedef float TFtype __attribute__ ((mode (TF)));
      | ^~~~~~~

Full build log available at
http://autobuild.buildroot.net/results/8f5/8f585b83166d94772fe581f2efb0691676b33dab/build-end.log

Issue can be reproduced by doing:

$ git clone https://gitlab.com/buildroot.org/buildroot.git
$ cd buildroot
$ git checkout c624eee1 
$ wget -O .config
http://autobuild.buildroot.net/results/8f5/8f585b83166d94772fe581f2efb0691676b33dab/config
$ make

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
             Target|                            |powerpc64le-buildroot-linux
                   |                            |-musl
          Component|libquadmath                 |target

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This might just be fixed on the trunk.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni@free-electrons.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #2 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> ---
(In reply to Andrew Pinski from comment #1)
> This might just be fixed on the trunk.

Thanks for the super fast feedback. Do you have a pointer to the commit fixing
this? I quickly looked at the recent changes in the master branch in the
libquadmath/ directory and couldn't spot anything that seemed related.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> --enable-libquadmath --enable-libquadmath-support

You should not need this since the libc should already have support for 128bit
FP (either double double or IEEE 128bit).

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
To build libquadmath on powerpc*, one needs --with-long-double-128 (and perhaps
--with-long-double-format=ieee if C library supports that), unless that is
detected automatically.
# Check if TFmode long double should be used by default or not.
# Some glibc targets used DFmode long double, but with glibc 2.4
# and later they can use TFmode.
case "$target" in
  powerpc*-*-linux* | \
  sparc*-*-linux* | \
  s390*-*-linux* | \
  alpha*-*-linux*)
    AC_ARG_WITH(long-double-128,
      [AS_HELP_STRING([--with-long-double-128],
                      [use 128-bit long double by default])],
      gcc_cv_target_ldbl128="$with_long_double_128", [
      case "$target" in
        s390*-*-linux-musl*)
          gcc_cv_target_ldbl128=yes
          ;;
        powerpc*-*-linux-musl*)
          gcc_cv_target_ldbl128=no
          ;;
        *)]
      [GCC_GLIBC_VERSION_GTE_IFELSE([2], [4], [gcc_cv_target_ldbl128=yes], [
      [gcc_cv_target_ldbl128=no
      grep '^[  ]*#[    ]*define[       ][      ]*__LONG_DOUBLE_MATH_OPTIONAL'
\
        $target_header_dir/bits/wordsize.h > /dev/null 2>&1 \
      && gcc_cv_target_ldbl128=yes
      ]])]
      [
          ;;                                                  
      esac
      ])
    ;;
esac                                                          

From thbis, it seems powerpc musl likely doesn't have neither double double nor
IEEE quad support and so in that case you can't use --enable-libquadmath
--enable-libquadmath-support.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
See r10-4792

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni@free-electrons.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #6 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> ---
Thanks for all the feedback! However, I'm still a bit confused. In one comment
you say:

> From thbis, it seems powerpc musl likely doesn't have neither double double
> nor IEEE quad support and so in that case you can't use --enable-libquadmath
> --enable-libquadmath-support.

But then in the followup comment you point to
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=8d7be8d614ba028074597c3ab1ee12d9495fde09
which seems to be a fix for the PowerPC/musl case.

What should I understand?

Also, if something is not supported, shouldn't it bail out during the configure
stage, rather than later on at build time?

I'm realizing that we have this snippet of code in Buildroot:

# PowerPC64 big endian by default uses the elfv1 ABI, and PowerPC 64
# little endian by default uses the elfv2 ABI. However, musl has
# decided to use the elfv2 ABI for both, so we force the elfv2 ABI for
# Power64 big endian when the selected C library is musl.
ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_powerpc64),yy)
HOST_GCC_COMMON_CONF_OPTS += \
        --with-abi=elfv2 \
        --without-long-double-128
endif

in Buildroot, but that only applies to PowerPC 64 Big Endian. Our comment says
that elfv2 ABI is already the default for PowerPC 64 Little Endian, but perhaps
we also need something for PowerPC 64 Little Endian anyway ?

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That commit made --without-long-double-128 the default on
powerpc*-*-linux-musl*.
ELFv2 is one thing, but whether long double is IEEE double, IBM double double
or IEEE quad is a separate thing.  You need to look at musl what it supports.
E.g. glibc in the last few years for powerpc64le-linux supports all 3, on
powerpc64-linux or powerpc-linux just IEEE double and IBM double double.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni@free-electrons.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #8 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> ---
(In reply to Jakub Jelinek from comment #7)
> That commit made --without-long-double-128 the default on
> powerpc*-*-linux-musl*.
> ELFv2 is one thing, but whether long double is IEEE double, IBM double
> double or IEEE quad is a separate thing.  You need to look at musl what it
> supports.
> E.g. glibc in the last few years for powerpc64le-linux supports all 3, on
> powerpc64-linux or powerpc-linux just IEEE double and IBM double double.

Thanks for your feedback. I wish I knew how to look into musl to understand
what it supports, but I honestly wouldn't know where to start. How do I find
out which one does musl support? I'm not even sure to understand the difference
between IEEE double, IEEE double double and IEEE quad.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[awilfox at adelielinux dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

A. Wilcox (awilfox) <awilfox at adelielinux dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |awilfox at adelielinux dot org

--- Comment #9 from A. Wilcox (awilfox) <awilfox at adelielinux dot org> ---
There is no musl that supports IBM double-double, and there is no plan to ever
support this upstream.

There is a patch set circulating around for musl that adds IEEE binary128
support (requiring ISA 3.0), but it is not yet upstream because they are
deciding what to name the ABI.  (the proposed name as powerpc64_f128 but it
wasn't accepted that way.)

I have just run into this trying to build trunk on ppc64-musl without
explicitly passing --enable-libquadmath:

 * /bin/sh
/var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/configure
--host=powerpc64-gentoo-linux-musl --build=powerpc64-gentoo-linux-musl
--prefix=/usr --bindir=/usr/powerpc64-gentoo-linux-musl/gcc-bin/15
--includedir=/usr/lib/gcc/powerpc64-gentoo-linux-musl/15/include
--datadir=/usr/share/gcc-data/powerpc64-gentoo-linux-musl/15
--mandir=/usr/share/gcc-data/powerpc64-gentoo-linux-musl/15/man
--infodir=/usr/share/gcc-data/powerpc64-gentoo-linux-musl/15/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc64-gentoo-linux-musl/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/powerpc64-gentoo-linux-musl/15/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=yes,extra
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo Hardened
15.0.9999 p, commit b1a31eaaeae90d7b7774bfb45f9954dc586f4dea
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --disable-multilib --disable-fixed-point --with-abi=elfv2
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-systemtap --disable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --without-isl --disable-libsanitizer
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --disable-fixincludes

[...]

/var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libquadmath/math/../../libgcc/soft-fp/quad.h:69:1:
error: unable to emulate 'TF'
   69 | typedef float TFtype __attribute__ ((mode (TF)));
      | ^~~~~~~
make[3]: *** [Makefile:984: math/sqrtq.lo] Error 1


Does --disable-libquadmath need to be explicitly passed on ppc64-musl systems
that are not using the musl "f128" patches?

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #10 from Rich Felker <bugdal at aerifal dot cx> ---
musl uses ld64 for all powerpc targets because the ABI was designed when
compiler support for IEEE quad was not widespread, with an intent of supporting
existing compilers rather than requiring recent ones.

Since presumably libquadmath builds fine on other targets where ld is not ieee
quad or IBM double-double, I'm assuming it must be target-specific code that's
failing. Could libquadmath just fallback to using generic arch-agnostic code on
targets (including musl) where ld is not one of the currently supported ones?

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[awilfox at adelielinux dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #11 from A. Wilcox (awilfox) <awilfox at adelielinux dot org> ---
I was unable to find any target-specific code in libquadmath at all.

I haven't bothered to actually bisect this, but the 13 branch is the last one
that builds libquadmath without the compiler supporting TF mode emulation.  And
it can't seem to do that any more without ldbl128 support.  Passing
--disable-libquadmath --disable-libquadmath-support enables GCC 14 and trunk to
build correctly on my system.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni@free-electrons.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #12 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> ---
Thanks for all the discussion, but I'm confused about what the conclusion
actually is. Could you help me understand what's the plan moving forward?

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-08-02
     Ever confirmed|0                           |1

--- Comment #13 from Peter Bergner <bergner at gcc dot gnu.org> ---
Just as an FYI, the following error on a powerpc64le-linux
--without-long-double-128 build:

In file included from ../../../libquadmath/math/sqrtq.c:13:
../../../libquadmath/math/../../libgcc/soft-fp/quad.h:69:1: error: unable to
emulate 'TF'
   69 | typedef float TFtype __attribute__ ((mode (TF)));
      | ^~~~~~~

...first shows up with the following commit:


commit 481ba4fb5fce8257f5dbeb994dac2748c0237fa2 (HEAD)
Author:     Jakub Jelinek <jakub@redhat.com>
AuthorDate: Tue Apr 9 08:17:25 2024 +0200
Commit:     Jakub Jelinek <jakub@redhat.com>
CommitDate: Tue Apr 9 08:17:25 2024 +0200

    libquadmath: Use soft-fp for sqrtq finite positive arguments [PR114623]

    sqrt should be 0.5ulp precise, but the current implementation is less
    precise than that.
    The following patch uses the soft-fp code (like e.g. glibc for x86) for it
    if possible.  I didn't want to replicate the libgcc infrastructure for
    choosing the right sfp-machine.h, so the patch just uses a single generic
    implementation.  As the code is used solely for the finite positive
arguments,
    it shouldn't generate NaNs (so the exact form of canonical QNaN/SNaN is
    irrelevant), and sqrt for these shouldn't produce underflows/overflows
either,
    for < 1.0 arguments it always returns larger values than the argument and
for
    > 1.0 smaller values than the argument.

    2024-04-09  Jakub Jelinek  <jakub@redhat.com>

            PR libquadmath/114623
            * sfp-machine.h: New file.
            * math/sqrtq.c: Include from libgcc/soft-fp also soft-fp.h and
quad.h
            if possible.
            (USE_SOFT_FP): Define in that case.
            (sqrtq): Use soft-fp based implementation for the finite positive
            arguments if possible.

...which is due to the above commit code includes quad.h, and quad.h (even
before the above commit) seems to require TFmode exists, which it doesn't on a
--without-long-double-128 build.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, can you explain how could libquadmath build at all in such configurations?
__float128 type is supported and not TFmode?
Is that because it is KFmode instead or what?
quadmath.h has
#if (!defined(_ARCH_PPC)) || defined(__LONG_DOUBLE_IEEE128__)
typedef _Complex float __attribute__((mode(TC))) __complex128;
#else
typedef _Complex float __attribute__((mode(KC))) __complex128;
#endif

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If so, then perhaps
--- libquadmath/math/sqrtq.c.jj 2024-04-09 08:16:54.128737859 +0200
+++ libquadmath/math/sqrtq.c    2024-08-02 23:28:00.862495012 +0200
@@ -9,6 +9,9 @@
     && defined(FE_TOWARDZERO) \
     && defined(FE_INEXACT)
 #define USE_SOFT_FP 1
+#if defined(_ARCH_PPC) && !defined(__LONG_DOUBLE_IEEE128__)
+#define TFtype __float128
+#endif
 #include "../../libgcc/soft-fp/soft-fp.h"
 #include "../../libgcc/soft-fp/quad.h"
 #endif
would fix that.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #16 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> So, can you explain how could libquadmath build at all in such
> configurations?
> __float128 type is supported and not TFmode?
> Is that because it is KFmode instead or what?

I don't know. :-).  Hopefully Mike can answer, since he knows the TF/IF/KFmode
support on Power better than anyone.

That said...

(In reply to Jakub Jelinek from comment #15)
> If so, then perhaps
> --- libquadmath/math/sqrtq.c.jj	2024-04-09 08:16:54.128737859 +0200
> +++ libquadmath/math/sqrtq.c	2024-08-02 23:28:00.862495012 +0200
> @@ -9,6 +9,9 @@
>      && defined(FE_TOWARDZERO) \
>      && defined(FE_INEXACT)
>  #define USE_SOFT_FP 1
> +#if defined(_ARCH_PPC) && !defined(__LONG_DOUBLE_IEEE128__)
> +#define TFtype __float128
> +#endif
>  #include "../../libgcc/soft-fp/soft-fp.h"
>  #include "../../libgcc/soft-fp/quad.h"
>  #endif
> would fix that.

I applied that patch and my powerpc64le-linux --without-lond-double-128 build
completed with no errors.  Whether what it produced is correct or not, I'll
leave to Mike to answer.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #17 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Does it also work if you spell the option name correctly?  All unknown
configure
options are always accepted silently.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #18 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #17)
> Does it also work if you spell the option name correctly?  All unknown
> configure
> options are always accepted silently.

Sorry, it was a typo here, not in my actual configure command, so yes, it works
with it spelled correctly.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #19 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:3ac02e67503ccffa3dfeeffc0a60fce6bdaca43b

commit r15-2708-g3ac02e67503ccffa3dfeeffc0a60fce6bdaca43b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Aug 3 20:37:54 2024 +0200

    libquadmath: Fix up libquadmath/math/sqrtq.c compilation in some powerpc*
configurations [PR116007]

    My PR114623 change started using soft-fp.h and quad.h for the sqrtq
implementation.
    Unfortunately, that seems to fail building in some powerpc* configurations,
where
    TFmode isn't available.
    quad.h has:
     #ifndef TFtype
     typedef float TFtype __attribute__ ((mode (TF)));
     #endif
    and uses TFtype.  quad.h has:
     /* Define the complex type corresponding to __float128
        ("_Complex __float128" is not allowed) */
     #if (!defined(_ARCH_PPC)) || defined(__LONG_DOUBLE_IEEE128__)
     typedef _Complex float __attribute__((mode(TC))) __complex128;
     #else
     typedef _Complex float __attribute__((mode(KC))) __complex128;
     #endif
    with the conditional and KCmode use added during porting of libquadmath
    to powerpc*, so I've just defined TFtype for powerpc when
__LONG_DOUBLE_IEEE128__
    isn't defined; I could define it to float __attribute__ ((mode (KF))) but
it
    seemed easier to just define it to __float128 which should do the same
thing.

    2024-08-03  Jakub Jelinek  <jakub@redhat.com>

            PR target/116007
            * math/sqrtq.c (TFtype): For PowerPC without
__LONG_DOUBLE_IEEE128__
            define to __float128 before including soft-fp.h and quad.h.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #20 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:3fe5720430a9ba61ed7562aac4d758cc77d49a28

commit r14-10566-g3fe5720430a9ba61ed7562aac4d758cc77d49a28
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Aug 3 20:37:54 2024 +0200

    libquadmath: Fix up libquadmath/math/sqrtq.c compilation in some powerpc*
configurations [PR116007]

    My PR114623 change started using soft-fp.h and quad.h for the sqrtq
implementation.
    Unfortunately, that seems to fail building in some powerpc* configurations,
where
    TFmode isn't available.
    quad.h has:
     #ifndef TFtype
     typedef float TFtype __attribute__ ((mode (TF)));
     #endif
    and uses TFtype.  quad.h has:
     /* Define the complex type corresponding to __float128
        ("_Complex __float128" is not allowed) */
     #if (!defined(_ARCH_PPC)) || defined(__LONG_DOUBLE_IEEE128__)
     typedef _Complex float __attribute__((mode(TC))) __complex128;
     #else
     typedef _Complex float __attribute__((mode(KC))) __complex128;
     #endif
    with the conditional and KCmode use added during porting of libquadmath
    to powerpc*, so I've just defined TFtype for powerpc when
__LONG_DOUBLE_IEEE128__
    isn't defined; I could define it to float __attribute__ ((mode (KF))) but
it
    seemed easier to just define it to __float128 which should do the same
thing.

    2024-08-03  Jakub Jelinek  <jakub@redhat.com>

            PR target/116007
            * math/sqrtq.c (TFtype): For PowerPC without
__LONG_DOUBLE_IEEE128__
            define to __float128 before including soft-fp.h and quad.h.

    (cherry picked from commit 3ac02e67503ccffa3dfeeffc0a60fce6bdaca43b)

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni@free-electrons.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007

--- Comment #22 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> ---
Thanks for the patch, I confirm it fixes the build issue I was seeing!