public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc r13-6507] PR target/107299: Fix build issue when long double is IEEE 128-bit
@ 2023-03-06 22:42 Michael Meissner
  0 siblings, 0 replies; only message in thread
From: Michael Meissner @ 2023-03-06 22:42 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:306c7b1ac3e4413288e6930b00a3cab2133c4e57

commit r13-6507-g306c7b1ac3e4413288e6930b00a3cab2133c4e57
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Mon Mar 6 17:38:33 2023 -0500

    PR target/107299: Fix build issue when long double is IEEE 128-bit
    
    This patch updates the IEEE 128-bit types used in libgcc.
    
    At the moment, we cannot build GCC when the target uses IEEE 128-bit long
    doubles, such as building the compiler for a native Fedora 36 system.  The
    build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
    
    This patch changes libgcc to use long double for the IEEE 128-bit base type if
    long double is IEEE 128-bit, and it uses _Float128 otherwise.  The built-in
    functions are adjusted to be the correct version based on the IEEE 128-bit base
    type used.
    
    While it is desirable to ultimately have __float128 and _Float128 use the same
    internal type and mode within GCC, at present if you use the option
    -mabi=ieeelongdouble, the __float128 type will use the long double type and not
    the _Float128 type.  We get an internal compiler error if we combine the
    signbitf128 built-in with a long double type.
    
    I've gone through several iterations of trying to fix this within GCC, and
    there are various problems that have come up.  I developed this alternative
    patch that changes libgcc so that it does not tickle the issue.  I hope we can
    fix the compiler at some point, but right now, this is preventing people on
    Fedora 36 systems from building compilers where the default long double is IEEE
    128-bit.
    
    2023-03-06   Michael Meissner  <meissner@linux.ibm.com>
    
    libgcc/
    
            PR target/107299
            * config/rs6000/_divkc3.c (COPYSIGN): Use the correct built-in based on
            whether long double is IBM or IEEE.
            (INFINITY): Likewise.
            (FABS): Likewise.
            * config/rs6000/_mulkc3.c (COPYSIGN): Likewise.
            (INFINITY): Likewise.
            * config/rs6000/quad-float128.h (TF): Remove definition.
            (TFtype): Define to be long double or _Float128.
            (TCtype): Define to be _Complex long double or _Complex _Float128.
            * libgcc2.h (TFtype): Allow machine config files to override this.
            (TCtype): Likewise.
            * soft-fp/quad.h (TFtype): Likewise.

Diff:
---
 libgcc/config/rs6000/_divkc3.c       | 10 ++++++++++
 libgcc/config/rs6000/_mulkc3.c       |  9 +++++++++
 libgcc/config/rs6000/quad-float128.h | 38 +++++++++++++++++++++++++-----------
 libgcc/libgcc2.h                     |  4 ++++
 libgcc/soft-fp/quad.h                |  2 ++
 5 files changed, 52 insertions(+), 11 deletions(-)

diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c
index 9f52428cfa0..b5f9e59627d 100644
--- a/libgcc/config/rs6000/_divkc3.c
+++ b/libgcc/config/rs6000/_divkc3.c
@@ -26,9 +26,19 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #include "soft-fp.h"
 #include "quad-float128.h"
 
+/* Use the correct built-in function based on whether TFmode is _Float128 or
+   long double.  See quad-float128.h for more details.  */
+#ifndef __LONG_DOUBLE_IEEE128__
 #define COPYSIGN(x,y) __builtin_copysignf128 (x, y)
 #define INFINITY __builtin_inff128 ()
 #define FABS __builtin_fabsf128
+
+#else
+#define COPYSIGN(x,y) __builtin_copysignl (x, y)
+#define INFINITY __builtin_infl ()
+#define FABS __builtin_fabsl
+#endif
+
 #define isnan __builtin_isnan
 #define isinf __builtin_isinf
 #define isfinite __builtin_isfinite
diff --git a/libgcc/config/rs6000/_mulkc3.c b/libgcc/config/rs6000/_mulkc3.c
index 299d8d147b0..a01cb054054 100644
--- a/libgcc/config/rs6000/_mulkc3.c
+++ b/libgcc/config/rs6000/_mulkc3.c
@@ -26,8 +26,17 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #include "soft-fp.h"
 #include "quad-float128.h"
 
+/* Use the correct built-in function based on whether TFmode is _Float128 or
+   long double.  See quad-float128.h for more details.  */
+#ifndef __LONG_DOUBLE_IEEE128__
 #define COPYSIGN(x,y) __builtin_copysignf128 (x, y)
 #define INFINITY __builtin_inff128 ()
+
+#else
+#define COPYSIGN(x,y) __builtin_copysignl (x, y)
+#define INFINITY __builtin_infl ()
+#endif
+
 #define isnan __builtin_isnan
 #define isinf __builtin_isinf
 
diff --git a/libgcc/config/rs6000/quad-float128.h b/libgcc/config/rs6000/quad-float128.h
index 68bd9b97f23..974912326ba 100644
--- a/libgcc/config/rs6000/quad-float128.h
+++ b/libgcc/config/rs6000/quad-float128.h
@@ -27,21 +27,37 @@
    License along with the GNU C Library; if not, see
    <http://www.gnu.org/licenses/>.  */
 
-/* quad.h defines the TFtype type by:
-   typedef float TFtype __attribute__ ((mode (TF)));
+/* Override the types for IEEE 128-bit scalar and complex.  We need to use the
+   same IEEE 128-bit type (either long double or _Float128) for both the
+   128-bit scalar type and for the base type in _Complex.  Otherwise, if
+   different types are used, there may be problems in mixing _Complex values
+   with the scalar value.
 
-   This define forces it to use KFmode (aka, ieee 128-bit floating point).
-   However, when the compiler's default is changed so that long double is IEEE
-   128-bit floating point, we need to go back to using TFmode and TCmode.  */
-#ifndef __LONG_DOUBLE_IEEE128__
-#define TF KF
+   We can't use _Compelx _float128 since GCC doesn't allow it.  It only allows
+   _Complex for _Float128 or for long double.
 
-/* We also need TCtype to represent complex ieee 128-bit float for
-   __mulkc3 and __divkc3.  */
-typedef __complex float TCtype __attribute__ ((mode (KC)));
+   We use _Float128 when long double is IBM double-double or 64-bit, and long
+   double when long double uses the IEEE 128-bit type.  We need to do this
+   because the compiler has a built-in prototype for __mulkc3 and __divkc3
+   using those types.  Since we are declaring these functions here, we need to
+   use the same type that the compiler uses (i.e. we can't just always use
+   _Float128).
+
+   Even though the type _Float128 and long double (when long double uses IEEE
+   128-bits) both hold IEEE 128-bit values, the front ends treat these as two
+   separate types.
+
+   The extension keyword __float128 is currently problematical because it can
+   either be a synonym for _Float128 (when long double is IBM) or for long
+   double (when long double is IEEE).  */
+
+#ifdef __LONG_DOUBLE_IEEE128__
+#define TFtype long double
+#define TCtype _Complex long double
 
 #else
-typedef __complex float TCtype __attribute__ ((mode (TC)));
+#define TFtype _Float128
+#define TCtype _Complex _Float128
 #endif
 
 /* Force the use of the VSX instruction set.  */
diff --git a/libgcc/libgcc2.h b/libgcc/libgcc2.h
index 6f42db7f0be..3ec9bbd8164 100644
--- a/libgcc/libgcc2.h
+++ b/libgcc/libgcc2.h
@@ -156,9 +156,13 @@ typedef		float XFtype	__attribute__ ((mode (XF)));
 typedef _Complex float XCtype	__attribute__ ((mode (XC)));
 #endif
 #if LIBGCC2_HAS_TF_MODE
+#ifndef TFtype
 typedef		float TFtype	__attribute__ ((mode (TF)));
+#endif
+#ifndef TCtype
 typedef _Complex float TCtype	__attribute__ ((mode (TC)));
 #endif
+#endif
 
 typedef int cmp_return_type __attribute__((mode (__libgcc_cmp_return__)));
 typedef int shift_count_type __attribute__((mode (__libgcc_shift_count__)));
diff --git a/libgcc/soft-fp/quad.h b/libgcc/soft-fp/quad.h
index 3889bb44f1f..71f87d36ba9 100644
--- a/libgcc/soft-fp/quad.h
+++ b/libgcc/soft-fp/quad.h
@@ -65,7 +65,9 @@
 #define _FP_HIGHBIT_DW_Q	\
   ((_FP_W_TYPE) 1 << (_FP_WFRACBITS_DW_Q - 1) % _FP_W_TYPE_SIZE)
 
+#ifndef TFtype
 typedef float TFtype __attribute__ ((mode (TF)));
+#endif
 
 #if _FP_W_TYPE_SIZE < 64

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-03-06 22:42 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-06 22:42 [gcc r13-6507] PR target/107299: Fix build issue when long double is IEEE 128-bit Michael Meissner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).