public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH 0/3] Improvements to __ibm128 on PowerPC
@ 2022-08-18 21:28 Michael Meissner
  2022-08-18 21:39 ` [PATCH 1/3] Allow __ibm128 even if IEEE 128-bit floating point is not supported Michael Meissner
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Michael Meissner @ 2022-08-18 21:28 UTC (permalink / raw)
  To: gcc-patches, Michael Meissner, Segher Boessenkool, Kewen.Lin,
	David Edelsohn, Peter Bergner, Will Schmidt

The following 3 patches improve __ibm128 on the PowerPC GCC compiler:

The first patch allows the use of the __ibm128 keyword on non-VSX systems.
Originally, the __ibm128 keyword was only enabled when the IEEE 128-bit
floating point is enabled.  Sometime back in the GCC 12 development period,
Segher asked that the __ibm128 keyword be allowed in older systems that don't
support IEEE 128-bit.  This patch allows __ibm128 to be used if either IEEE
128-bit is enabled or long double used the IBM 128-bit format.

The second patch fixes PR target/105334.  This PR complains that the __ibm128
keyword is not defined on a system that uses IEEE 128-bit long double, but the
user used the -msoft-float option.  This patch removes the checks for hardware
floating point support in IBM 128-bit long double support, and also enables the
__ibm128 keyword.  The existing test gcc.target/powerpc/pr105334.c will now
pass on a system using IEEE 128-bit long double.

The third patch uses the 'w' suffix for __ibm128 constants.  It turns out we
had documented using the 'w' suffix for __ibm128, but we had never implemented
it.

I have tested these patches on the following systems:

    1)	LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
    2)	LE Power10 using --with-cpu=power9  --with-long-double-format=ibm
    3)	LE Power10 using --with-cpu=power8  --with-long-double-format=ibm
    4)	LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
    5)	LE Power9  using --with-cpu=power9  --with-long-double-format=ibm
    6)	BE Power8  using --with-cpu=power8  --with-long-double-format=ibm
    7)	BE Power8  using --with-cpu=power5  --with-long-double-format=ibm

There were no regressions in the build or in the tests.  On the power10 with
long double using the IEEE 128-bit format, pr105334.c now runs where it
previously failed.

Can I check these patches into the trunk?

Did we want to back port these changes to older GCC's?

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH 1/3] Allow __ibm128 even if IEEE 128-bit floating point is not supported.
  2022-08-18 21:28 [PATCH 0/3] Improvements to __ibm128 on PowerPC Michael Meissner
@ 2022-08-18 21:39 ` Michael Meissner
  2022-08-18 21:41 ` [PATCH 2/3] Allow __ibm128 with -msoft-float (PR target/105334) Michael Meissner
  2022-08-18 21:42 ` [PATCH 3/3] Add 'w' suffix for __ibm128 constants Michael Meissner
  2 siblings, 0 replies; 4+ messages in thread
From: Michael Meissner @ 2022-08-18 21:39 UTC (permalink / raw)
  To: Michael Meissner, gcc-patches, Segher Boessenkool, Kewen.Lin,
	David Edelsohn, Peter Bergner, Will Schmidt

Allow __ibm128 even if IEEE 128-bit floating point is not supported.

This patch allows the use of the __ibm128 keyword on non-VSX systems.
Originally, the __ibm128 keyword was only enabled when the IEEE 128-bit
floating point is enabled.  Sometime back in the GCC 12 development period,
Segher asked that the __ibm128 keyword be allowed in older systems that don't
support IEEE 128-bit.  But at the time, stage 1 had closed for GCC 12, so I
deferred doing this change until GCC 13.  This patch allows __ibm128 to be used
if either IEEE 128-bit is enabled or long double used the IBM 128-bit format.

I have tested these patches on the following systems:

    1)	LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
    2)	LE Power10 using --with-cpu=power9  --with-long-double-format=ibm
    3)	LE Power10 using --with-cpu=power8  --with-long-double-format=ibm
    4)	LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
    5)	LE Power9  using --with-cpu=power9  --with-long-double-format=ibm
    6)	BE Power8  using --with-cpu=power8  --with-long-double-format=ibm
    7)	BE Power8  using --with-cpu=power5  --with-long-double-format=ibm

There were no regressions in the build or in the tests.

Can I check this patch into the trunk?

Did we want to backport this to earlier GCC releases?

2022-08-17   Michael Meissner  <meissner@linux.ibm.com>

gcc/

	* config/rs6000/rs6000-builtins.cc (rs6000_init_builtins): Enable using
	the__ibm128 keyword on systems that either use the 128-bit IBM long
	double format for long double or support IEEE 128-bit.
	* config/rs6000/rs6000.cc (rs6000_init_libfuncs): Create IBM 128-bit
	floating point support functions on systems that support the __ibm128
	keyword.
	(rs6000_scalar_mode_supported_p): Likewise.
	* config/rs6000/rs6000.h (TARGET_IBM128): New macro.
	* config/rs6000/rs6000.md (@extenddf<mode>2_fprs): Allow IFmode to be
	converted even if long double is not 128-bits.
	(extenddf<mode>2_vsx): Likewise.
	(extendiftf2):Allow conversion on systems that support the __ibm128
	keyword.
	(extendtfif2): Likewise.
	(trunciftf2): Likewise.
	(trunctfif2): Likewise.
---
 gcc/config/rs6000/rs6000-builtin.cc |  2 +-
 gcc/config/rs6000/rs6000.cc         | 13 ++++++++-----
 gcc/config/rs6000/rs6000.h          |  6 ++++++
 gcc/config/rs6000/rs6000.md         | 13 ++++++-------
 4 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-builtin.cc b/gcc/config/rs6000/rs6000-builtin.cc
index 12afa86854c..70680890415 100644
--- a/gcc/config/rs6000/rs6000-builtin.cc
+++ b/gcc/config/rs6000/rs6000-builtin.cc
@@ -713,7 +713,7 @@ rs6000_init_builtins (void)
      For IEEE 128-bit floating point, always create the type __ieee128.  If the
      user used -mfloat128, rs6000-c.cc will create a define from __float128 to
      __ieee128.  */
-  if (TARGET_LONG_DOUBLE_128 && (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE))
+  if (TARGET_IBM128)
     {
       if (!TARGET_IEEEQUAD)
 	ibm128_float_type_node = long_double_type_node;
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index df491bee2ea..39527ce9bbc 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -11115,10 +11115,11 @@ rs6000_init_libfuncs (void)
 {
   /* __float128 support.  */
   if (TARGET_FLOAT128_TYPE)
-    {
-      init_float128_ibm (IFmode);
-      init_float128_ieee (KFmode);
-    }
+    init_float128_ieee (KFmode);
+
+  /* __ibm128 support.  */
+  if (TARGET_IBM128)
+    init_float128_ibm (IFmode);
 
   /* AIX/Darwin/64-bit Linux quad floating point routines.  */
   if (TARGET_LONG_DOUBLE_128)
@@ -23752,7 +23753,9 @@ rs6000_scalar_mode_supported_p (scalar_mode mode)
 
   if (DECIMAL_FLOAT_MODE_P (mode))
     return default_decimal_float_supported_p ();
-  else if (TARGET_FLOAT128_TYPE && (mode == KFmode || mode == IFmode))
+  else if (TARGET_FLOAT128_TYPE && mode == KFmode)
+    return true;
+  else if (TARGET_IBM128 && mode == IFmode)
     return true;
   else
     return default_scalar_mode_supported_p (mode);
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index ad9bf0f7358..813ec696c0d 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -564,6 +564,12 @@ extern int rs6000_vector_align[];
 					 && TARGET_P8_VECTOR		\
 					 && TARGET_POWERPC64)
 
+/* Whether the __ibm128 keyword is allowed.  Any system that supports _Float128
+   is assumed to be capable of supporting __ibm128.  Similarly if the long
+   double size is 128 bits, we assume __ibm128 is supported.  We don't want to
+   support it on a system without existing 128-bit long doubles.  */
+#define TARGET_IBM128	(TARGET_FLOAT128_TYPE || TARGET_LONG_DOUBLE_128)
+
 /* Inlining allows targets to define the meanings of bits in target_info
    field of ipa_fn_summary by itself, the used bits for rs6000 are listed
    below.  */
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 1367a2cb779..f942597c3b4 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -8586,8 +8586,7 @@ (define_insn_and_split "@extenddf<mode>2_fprs"
 	(float_extend:IBM128
 	 (match_operand:DF 1 "nonimmediate_operand" "d,m,d")))
    (use (match_operand:DF 2 "nonimmediate_operand" "m,m,d"))]
-  "!TARGET_VSX && TARGET_HARD_FLOAT
-   && TARGET_LONG_DOUBLE_128 && FLOAT128_IBM_P (<MODE>mode)"
+  "!TARGET_VSX && TARGET_HARD_FLOAT && FLOAT128_IBM_P (<MODE>mode)"
   "#"
   "&& reload_completed"
   [(set (match_dup 3) (match_dup 1))
@@ -8604,7 +8603,7 @@ (define_insn_and_split "@extenddf<mode>2_vsx"
   [(set (match_operand:IBM128 0 "gpc_reg_operand" "=d,d")
 	(float_extend:IBM128
 	 (match_operand:DF 1 "nonimmediate_operand" "wa,m")))]
-  "TARGET_LONG_DOUBLE_128 && TARGET_VSX && FLOAT128_IBM_P (<MODE>mode)"
+  "TARGET_VSX && FLOAT128_IBM_P (<MODE>mode)"
   "#"
   "&& reload_completed"
   [(set (match_dup 2) (match_dup 1))
@@ -9061,7 +9060,7 @@ (define_insn "*ieee_128bit_vsx_nabs<mode>2_internal"
 (define_expand "extendiftf2"
   [(set (match_operand:TF 0 "gpc_reg_operand")
 	(float_extend:TF (match_operand:IF 1 "gpc_reg_operand")))]
-  "TARGET_FLOAT128_TYPE"
+  "TARGET_IBM128"
 {
   rs6000_expand_float128_convert (operands[0], operands[1], false);
   DONE;
@@ -9088,7 +9087,7 @@ (define_expand "extendtfkf2"
 (define_expand "extendtfif2"
   [(set (match_operand:IF 0 "gpc_reg_operand")
 	(float_extend:IF (match_operand:TF 1 "gpc_reg_operand")))]
-  "TARGET_FLOAT128_TYPE"
+  "TARGET_IBM128"
 {
   rs6000_expand_float128_convert (operands[0], operands[1], false);
   DONE;
@@ -9097,7 +9096,7 @@ (define_expand "extendtfif2"
 (define_expand "trunciftf2"
   [(set (match_operand:TF 0 "gpc_reg_operand")
 	(float_truncate:TF (match_operand:IF 1 "gpc_reg_operand")))]
-  "TARGET_FLOAT128_TYPE"
+  "TARGET_IBM128"
 {
   rs6000_expand_float128_convert (operands[0], operands[1], false);
   DONE;
@@ -9124,7 +9123,7 @@ (define_expand "trunckftf2"
 (define_expand "trunctfif2"
   [(set (match_operand:IF 0 "gpc_reg_operand")
 	(float_truncate:IF (match_operand:TF 1 "gpc_reg_operand")))]
-  "TARGET_FLOAT128_TYPE"
+  "TARGET_IBM128"
 {
   rs6000_expand_float128_convert (operands[0], operands[1], false);
   DONE;
-- 
2.37.2


-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH 2/3] Allow __ibm128 with -msoft-float (PR target/105334)
  2022-08-18 21:28 [PATCH 0/3] Improvements to __ibm128 on PowerPC Michael Meissner
  2022-08-18 21:39 ` [PATCH 1/3] Allow __ibm128 even if IEEE 128-bit floating point is not supported Michael Meissner
@ 2022-08-18 21:41 ` Michael Meissner
  2022-08-18 21:42 ` [PATCH 3/3] Add 'w' suffix for __ibm128 constants Michael Meissner
  2 siblings, 0 replies; 4+ messages in thread
From: Michael Meissner @ 2022-08-18 21:41 UTC (permalink / raw)
  To: Michael Meissner, gcc-patches, Segher Boessenkool, Kewen.Lin,
	David Edelsohn, Peter Bergner, Will Schmidt

Allow __ibm128 with -msoft-float (PR target/105334)

This patch allows __ibm128 to be used on systems with software floating point
enabled.  Previously, we required hardware floating point to be enabled to use
__ibm128 keyword and the __ibm128 built-in functions.  This patch fixes PR
target/105334.

I have tested this patch on the following systems:

    1)	LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
    2)	LE Power10 using --with-cpu=power9  --with-long-double-format=ibm
    3)	LE Power10 using --with-cpu=power8  --with-long-double-format=ibm
    4)	LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
    5)	LE Power9  using --with-cpu=power9  --with-long-double-format=ibm
    6)	BE Power8  using --with-cpu=power8  --with-long-double-format=ibm
    7)	BE Power8  using --with-cpu=power5  --with-long-double-format=ibm

There were no regressions in the build or in the tests.  On the power10 with
long double using the IEEE 128-bit format, pr105334.c now runs where it
previously failed.

Can I check this patch into the trunk?

Did we want to backport this to earlier GCC releases?

2022-08-17   Michael Meissner  <meissner@linux.ibm.com>

gcc/

	PR target/105334
	* config/rs6000/rs6000.cc (init_float128_ibm): Do not require hardware
	floating point for the IBM 128-bit floating point comparison functions.
	* config/rs6000/rs6000.h (FLOAT128_IBM_P): Do not require hardware
	floating point to enable recognizing IBM 128-bit floating point modes.
---
 gcc/config/rs6000/rs6000.cc | 37 +++++++++++++++++--------------------
 gcc/config/rs6000/rs6000.h  |  2 +-
 2 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 39527ce9bbc..a6ec4c71ac0 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -10913,26 +10913,23 @@ init_float128_ibm (machine_mode mode)
       set_optab_libfunc (smul_optab, mode, "__gcc_qmul");
       set_optab_libfunc (sdiv_optab, mode, "__gcc_qdiv");
 
-      if (!TARGET_HARD_FLOAT)
-	{
-	  set_optab_libfunc (neg_optab, mode, "__gcc_qneg");
-	  set_optab_libfunc (eq_optab, mode, "__gcc_qeq");
-	  set_optab_libfunc (ne_optab, mode, "__gcc_qne");
-	  set_optab_libfunc (gt_optab, mode, "__gcc_qgt");
-	  set_optab_libfunc (ge_optab, mode, "__gcc_qge");
-	  set_optab_libfunc (lt_optab, mode, "__gcc_qlt");
-	  set_optab_libfunc (le_optab, mode, "__gcc_qle");
-	  set_optab_libfunc (unord_optab, mode, "__gcc_qunord");
-
-	  set_conv_libfunc (sext_optab, mode, SFmode, "__gcc_stoq");
-	  set_conv_libfunc (sext_optab, mode, DFmode, "__gcc_dtoq");
-	  set_conv_libfunc (trunc_optab, SFmode, mode, "__gcc_qtos");
-	  set_conv_libfunc (trunc_optab, DFmode, mode, "__gcc_qtod");
-	  set_conv_libfunc (sfix_optab, SImode, mode, "__gcc_qtoi");
-	  set_conv_libfunc (ufix_optab, SImode, mode, "__gcc_qtou");
-	  set_conv_libfunc (sfloat_optab, mode, SImode, "__gcc_itoq");
-	  set_conv_libfunc (ufloat_optab, mode, SImode, "__gcc_utoq");
-	}
+      set_optab_libfunc (neg_optab, mode, "__gcc_qneg");
+      set_optab_libfunc (eq_optab, mode, "__gcc_qeq");
+      set_optab_libfunc (ne_optab, mode, "__gcc_qne");
+      set_optab_libfunc (gt_optab, mode, "__gcc_qgt");
+      set_optab_libfunc (ge_optab, mode, "__gcc_qge");
+      set_optab_libfunc (lt_optab, mode, "__gcc_qlt");
+      set_optab_libfunc (le_optab, mode, "__gcc_qle");
+      set_optab_libfunc (unord_optab, mode, "__gcc_qunord");
+
+      set_conv_libfunc (sext_optab, mode, SFmode, "__gcc_stoq");
+      set_conv_libfunc (sext_optab, mode, DFmode, "__gcc_dtoq");
+      set_conv_libfunc (trunc_optab, SFmode, mode, "__gcc_qtos");
+      set_conv_libfunc (trunc_optab, DFmode, mode, "__gcc_qtod");
+      set_conv_libfunc (sfix_optab, SImode, mode, "__gcc_qtoi");
+      set_conv_libfunc (ufix_optab, SImode, mode, "__gcc_qtou");
+      set_conv_libfunc (sfloat_optab, mode, SImode, "__gcc_itoq");
+      set_conv_libfunc (ufloat_optab, mode, SImode, "__gcc_utoq");
     }
   else
     {
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 813ec696c0d..f58f5f3f355 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -337,7 +337,7 @@ extern const char *host_detect_local_cpu (int argc, const char **argv);
 #define FLOAT128_IBM_P(MODE)						\
   ((!TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128				\
     && ((MODE) == TFmode || (MODE) == TCmode))				\
-   || (TARGET_HARD_FLOAT && ((MODE) == IFmode || (MODE) == ICmode)))
+   || ((MODE) == IFmode || (MODE) == ICmode))
 
 /* Helper macros to say whether a 128-bit floating point type can go in a
    single vector register, or whether it needs paired scalar values.  */
-- 
2.37.2


-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH 3/3] Add 'w' suffix for __ibm128 constants
  2022-08-18 21:28 [PATCH 0/3] Improvements to __ibm128 on PowerPC Michael Meissner
  2022-08-18 21:39 ` [PATCH 1/3] Allow __ibm128 even if IEEE 128-bit floating point is not supported Michael Meissner
  2022-08-18 21:41 ` [PATCH 2/3] Allow __ibm128 with -msoft-float (PR target/105334) Michael Meissner
@ 2022-08-18 21:42 ` Michael Meissner
  2 siblings, 0 replies; 4+ messages in thread
From: Michael Meissner @ 2022-08-18 21:42 UTC (permalink / raw)
  To: Michael Meissner, gcc-patches, Segher Boessenkool, Kewen.Lin,
	David Edelsohn, Peter Bergner, Will Schmidt

Add 'w' suffix for __ibm128 constants.

In the documentation, we mention that 'w' or 'W' can be used as a suffix for
__ibm128 constants.  We never implemented this.  This patch fixes that.

In addition, the 'q' and 'Q' suffix were changed to use the mode used for the
__float128 type, instead of knowing whether to use KFmode or TFmode explicitly.
This will be used in a future patch where we change the mode used for __float128
on systems where long double is IEEE 128-bit.

I have tested this patch on the following systems:

    1)	LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
    2)	LE Power10 using --with-cpu=power9  --with-long-double-format=ibm
    3)	LE Power10 using --with-cpu=power8  --with-long-double-format=ibm
    4)	LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
    5)	LE Power9  using --with-cpu=power9  --with-long-double-format=ibm
    6)	BE Power8  using --with-cpu=power8  --with-long-double-format=ibm
    7)	BE Power8  using --with-cpu=power5  --with-long-double-format=ibm

There were no regressions in the build or in the tests.

Can I check this patch into the trunk?

Did we want to backport this to earlier GCC releases?

2022-08-17   Michael Meissner  <meissner@linux.ibm.com>

gcc/

	* config/rs6000/rs6000.cc (rs6000_c_mode_for_suffix): Allow 'w' or 'W'
	for __ibm128 constants.

gcc/testsuite/

	* gcc.target/powerpc/ibm128-suffix.c: New test.
---
 gcc/config/rs6000/rs6000.cc                   | 25 ++++++++++---------
 .../gcc.target/powerpc/ibm128-suffix.c        | 13 ++++++++++
 2 files changed, 26 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/ibm128-suffix.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index a6ec4c71ac0..046c538c748 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -23845,22 +23845,23 @@ rs6000_floatn_mode (int n, bool extended)
 
 }
 
-/* Target hook for c_mode_for_suffix.  */
+/* Target hook for c_mode_for_suffix.  We use TYPE_MODE to follow the mode used
+   for __float128 and __ibm128.
+
+   Only two suffixes are allowed, 'q' and 'w'.  The 'q' suffix is used for
+   float128 constants on both the x86 and PowerPC processors.  Its use predates
+   the use of 'f128' for _Float128 constants, and existing code still uses it.
+
+   The 'w' suffix was used on the x86 processors for their 80-bit long
+   double.  We use it for __ibm128 constants.  */
 static machine_mode
 rs6000_c_mode_for_suffix (char suffix)
 {
-  if (TARGET_FLOAT128_TYPE)
-    {
-      if (suffix == 'q' || suffix == 'Q')
-	return (FLOAT128_IEEE_P (TFmode)) ? TFmode : KFmode;
+  if (TARGET_FLOAT128_TYPE && (suffix == 'q' || suffix == 'Q'))
+    return TYPE_MODE (ieee128_float_type_node);
 
-      /* At the moment, we are not defining a suffix for IBM extended double.
-	 If/when the default for -mabi=ieeelongdouble is changed, and we want
-	 to support __ibm128 constants in legacy library code, we may need to
-	 re-evalaute this decision.  Currently, c-lex.cc only supports 'w' and
-	 'q' as machine dependent suffixes.  The x86_64 port uses 'w' for
-	 __float80 constants.  */
-    }
+  if (TARGET_IBM128 && (suffix == 'w' || suffix == 'W'))
+    return TYPE_MODE (ibm128_float_type_node);
 
   return VOIDmode;
 }
diff --git a/gcc/testsuite/gcc.target/powerpc/ibm128-suffix.c b/gcc/testsuite/gcc.target/powerpc/ibm128-suffix.c
new file mode 100644
index 00000000000..ff619860409
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/ibm128-suffix.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target longdouble128 } */
+/* { dg-options "-O2" } */
+
+/* See if the 'w' suffix is accepted for __ibm128.  */
+#ifndef NUMBER
+#define NUMBER  123456789012345678901234567890123456789E-10
+#endif
+
+#define GLUE2(X,Y)      X ## Y
+#define GLUE(X,Y)       GLUE2(X,Y)
+
+__ibm128 x = GLUE (NUMBER, w);
-- 
2.37.2


-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-08-18 21:42 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-18 21:28 [PATCH 0/3] Improvements to __ibm128 on PowerPC Michael Meissner
2022-08-18 21:39 ` [PATCH 1/3] Allow __ibm128 even if IEEE 128-bit floating point is not supported Michael Meissner
2022-08-18 21:41 ` [PATCH 2/3] Allow __ibm128 with -msoft-float (PR target/105334) Michael Meissner
2022-08-18 21:42 ` [PATCH 3/3] Add 'w' suffix for __ibm128 constants 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).