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