[PATCH] Honor --disable-decimal-float in building _Float128 support.

[Michael Meissner via Gcc-patches]

Honor --disable-decimal-float in building _Float128 support.

Joseph Myers reported that my previous patch to add conversions between
_Float128 and the Decimal types was still being built even if GCC was
configured with the --disable-decimal-float option.  This patch fixes that by
only building the conversion functions if both _Float128 and Decimal support
are built into GCC.

In addition, I removed the dependency on the target having a valid stdio.h file
to declare sprintf in building _sprintfkf.c.

Finally I noticed I had a mismatch in the _sprintfkf.h include file, and I
fixed that.

Joseph, does this patch fix your problem?

I have built cross compilers on the x86 with/without --disable-decimal-float
and the conversion functions are not built if --disable-decimal-float was used.
I have built stage1 compilers with all three long double formats on the native
little endian system, and I verified that they conversions are only built if
Decimal support is eabled.

As I post this, the bootstrap builds are going on.  Assuming the bootstrap
builds are successful, can I check this patch into the master branch?

libgcc/
2021-02-26  Michael Meissner  

* config.host (powerpc*-*-linux): Move the Decimal/_Float128
* conversions into t-float128-dec.
* config/rs6000/_sprintfkf.c: Do not include stdio.h.  Include
_sprintfkf.h.
* config/rs6000/_sprintfkf.h (__sprintfkf): Update calling
signature.
(sprintf): Add declaration.
* config/rs6000/t-float128 (fp128_dec_funcs): Move to
t-float128-dec.
(fp128_decstr_funcs): Move to t-float128-dec.
(ibm128_dec_funcs): Move to t-float128-dec.
(fp128_dec_objs): Move to t-float128-dec.
(fp128_decstr_objs): Move to t-float128-dec.
(ibm128_dec_objs): Move to t-float128-dec.
(FP128_CFLAGS_DECIMAL): Move to t-float128-dec.
(IBM128_CFLAGS_DECIMAL): Move to t-float128-dec.
* config/rs6000/t-float128-dec: New file.
* configure.ac (libgcc_cv_powerpc_float128_dec): New variable, set
to yes if both _Float128 and Decimal support are available.
* configure: Regenerate.

---
 libgcc/config.host  |  4 +++
 libgcc/config/rs6000/_sprintfkf.c   |  4 ++-
 libgcc/config/rs6000/_sprintfkf.h   |  2 +-
 libgcc/config/rs6000/t-float128 | 42 +
 libgcc/config/rs6000/t-float128-dec | 37 +
 libgcc/configure| 22 ++-
 libgcc/configure.ac |  8 ++
 7 files changed, 80 insertions(+), 39 deletions(-)
 create mode 100644 libgcc/config/rs6000/t-float128-dec

diff --git a/libgcc/config.host b/libgcc/config.host
index f808b61be70..b5b4b0b3ba0 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1220,6 +1220,10 @@ powerpc*-*-linux*)
tmake_file="${tmake_file} rs6000/t-float128"
fi
 
+   if test $libgcc_cv_powerpc_float128_dec = yes; then
+   tmake_file="${tmake_file} rs6000/t-float128-dec"
+   fi
+
if test $libgcc_cv_powerpc_float128_hw = yes; then
tmake_file="${tmake_file} rs6000/t-float128-hw"
fi
diff --git a/libgcc/config/rs6000/_sprintfkf.c 
b/libgcc/config/rs6000/_sprintfkf.c
index a7fdfb483c9..b367861fcc3 100644
--- a/libgcc/config/rs6000/_sprintfkf.c
+++ b/libgcc/config/rs6000/_sprintfkf.c
@@ -27,7 +27,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #include 
 #include 
 #include 
-#include 
+#include <_sprintfkf.h>
+
+extern int sprintf (char *restrict, const char *restrict, ...);
 
 /* This function must be built with IBM 128-bit as long double, so that we can
access the strfroml function if do not have an IEEE 128-bit version, and if
diff --git a/libgcc/config/rs6000/_sprintfkf.h 
b/libgcc/config/rs6000/_sprintfkf.h
index 637d104c882..22b245d2cbb 100644
--- a/libgcc/config/rs6000/_sprintfkf.h
+++ b/libgcc/config/rs6000/_sprintfkf.h
@@ -24,5 +24,5 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 /* Declaration of the conversion function to IEEE 128-bit floating point from
string using snprintf.  */
 
-extern int __sprintfkf (char *restrict, const char *restrict, ...);
+extern int __sprintfkf (char *restrict, const char *restrict, _Float128);
 
diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
index 6fb1a3d871b..bbc66465050 100644
--- a/libgcc/config/rs6000/t-float128
+++ b/libgcc/config/rs6000/t-float128
@@ -22,18 +22,6 @@ fp128_softfp_static_obj  = $(addsuffix 
-sw$(objext),$(fp128_softfp_funcs))
 fp128_softfp_shared_obj= $(addsuffix 
-sw_s$(objext),$(fp128_softfp_funcs))
 fp128_softfp_obj   = $(fp128_softfp_static_obj) $(fp128_softfp_shared_obj)
 
-# Decimal <-> _Float128 conversions
-fp128_dec_funcs= _kf_to_sd _kf_to_dd _kf_to_td \
- _sd_to_kf _dd_to_kf _td_to_kf
-
-# _Float128 to/from string 

Re: [PATCH, V2] Add conversions between _Float128 and Decimal.

[Michael Meissner via Gcc-patches]

On Wed, Feb 24, 2021 at 11:12:54PM +, Joseph Myers wrote:
> This change appears to have broken builds for powerpc in a configuration 
> that bootstraps a cross toolchain starting with a GCC build with no libc 
> available.
> 
> Specifically, such a bootstrap build uses --disable-decimal-float among 
> other options (in the first GCC build before libc has been built), to 
> disable GCC target library code that has any dependence on libc or libc 
> headers - dfp-bit.c uses libc headers, without an inhibit_libc 
> conditional, so cannot be used in such a bootstrap configuration.  Most of 
> the DFP code in libgcc is disabled by --disable-decimal-float, but it 
> seems the new conversions are not.  This results in errors of the form:
> 
> In file included from 
> /scratch/jmyers/glibc-bot/src/gcc/libgcc/config/rs6000/_kf_to_sd.c:37:
> /scratch/jmyers/glibc-bot/src/gcc/libgcc/dfp-bit.c:32:10: fatal error: 
> stdio.h: No such file or directory
>32 | #include 
>   |  ^
> compilation terminated.
> 
> The appropriate fix is not to build any of these new conversions in the 
> --disable-decimal-float case.  (That clearly makes sense anyway, even in 
> the absence of the bootstrap issue.)
> 
> https://sourceware.org/pipermail/libc-testresults/2021q1/007576.html

Thanks.  I agree if --disable-decimal-float is used we should not build the
conversions.  And we want to eliminate the stdio.h dependency.  I will look at
it unless somebody has already fixed it.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 3/3] Force IBM long double for conversion test on PowerPC.

[Michael Meissner via Gcc-patches]

[PATCH 3/3] Force IBM long double for conversion test on PowerPC.

The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use
the IBM 128-bit extended double format.  In particular, some of the tests
expect an infinity to be created if decimal values that are converted that are
too large for IBM extended double.  However, the numbers do fit in the range
for IEEE 128-bit format, since it has a larger exponent than the IBM 128-bit
format.  The test fails because an infinity is not generated.

This patch explicitly sets the long double type to IBM extended double.

I have run tests on a little endian power9 system with 3 compilers.  There
were no regressions with these patches, and the two tests in the following
patches now work if the default long double is not IBM 128-bit:

*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu
set.  There were no regressions.

Can I check this patch into the master branch?

gcc/testsuite/
2021-02-22  Michael Meissner  

* c-c++-common/dfp/convert-bfp-11.c: Force using IBM 128-bit long
double.  Remove check for 64-bit long double.
---
 .../c-c++-common/dfp/convert-bfp-11.c  | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c 
b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
index 95c433d2c24..35da07d1fa4 100644
--- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
+++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
@@ -1,9 +1,14 @@
-/* { dg-skip-if "" { ! "powerpc*-*-linux*" } } */
+/* { dg-require-effective-target dfp } */
+/* { dg-require-effective-target ppc_long_double_override_ibm128 } */
+/* { dg-add-options ppc_long_double_override_ibm128 } */
 
-/* Test decimal float conversions to and from IBM 128-bit long double. 
-   Checks are skipped at runtime if long double is not 128 bits.
-   Don't force 128-bit long doubles because runtime support depends
-   on glibc.  */
+/* We force the long double type to be IBM 128-bit because the CONVERT_TO_PINF
+   tests will fail if we use IEEE 128-bit floating point.  This is due to IEEE
+   128-bit having a larger exponent range than IBM 128-bit extended double.  So
+   tests that would generate an infinity with IBM 128-bit will generate a
+   normal number with IEEE 128-bit.  */
+
+/* Test decimal float conversions to and from IBM 128-bit long double.   */
 
 #include "convert.h"
 
@@ -36,9 +41,6 @@ CONVERT_TO_PINF (312, tf, sd, 1.6e+308L, d32)
 int
 main ()
 {
-  if (sizeof (long double) != 16)
-return 0;
-
   convert_101 ();
   convert_102 ();
 
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 2/3] Force long double to be IBM 128-bit on PowerPC test, PR target/70117

[Michael Meissner via Gcc-patches]

[PATCH 2/3] Force long double to be IBM 128-bit on PowerPC test, PR 
target/70117.

This patch fixes the pr70117 test to use IBM 128-bit long double.

I have run tests on a little endian power9 system with 3 compilers.  There
were no regressions with these patches, and the two tests in the following
patches now work if the default long double is not IBM 128-bit:

*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu
set.  There were no regressions.

Can I check this patch into the master branch?

gcc/testsuite/
2021-02-23  Michael Meissner  

PR target/70117
* gcc.target/powerpc/pr70117.c: Force the long double type to use
the IBM 128-bit format.
---
 gcc/testsuite/gcc.target/powerpc/pr70117.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
b/gcc/testsuite/gcc.target/powerpc/pr70117.c
index 3bbd2c595e0..8a5fad1dee0 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
@@ -1,5 +1,7 @@
-/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* powerpc*-*-aix* 
rs6000-*-* } } } */
-/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
+/* { dg-do run } */
+/* { dg-require-effective-target ppc_long_double_override_ibm128 } */
+/* { dg-options "-std=c99 -O2" } */
+/* { dg-add-options ppc_long_double_override_ibm128 } */
 
 #include 
 
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 1/3] Add long double target-supports on PowerPC.

[Michael Meissner via Gcc-patches]

[PATCH 1/3] Add long double target-supports on PowerPC.

This patch add several more selections to target-supports.exp:

*   3 selections for the current long double format;
*   3 selections if we can change the long double format to a particular
value.
*   3 functions to return the options needed to switch the long double
format for use with dg-add-options.

I have run tests on a little endian power9 system with 3 compilers.  There
were no regressions with these patches, and the two tests in the following
patches now work if the default long double is not IBM 128-bit:

*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu
set.  There were no regressions.

Can I check this patch into the master branch?

gcc/testsuite/
2021-02-23  Michael Meissner  

* lib/target-supports.exp
(check_effective_target_ppc_long_double_ibm128): New function.
(check_effective_target_ppc_long_double_ieee128): New function.
(check_effective_target_ppc_long_double_64bit): New function.
(add_options_for_ppc_long_double_override_ibm128): New function.
(check_effective_target_ppc_long_double_override_ibm128): New
function.
(add_options_for_ppc_long_double_override_ieee128): New function.
(check_effective_target_ppc_long_double_override_ieee128): New
function.
(add_options_for_ppc_long_double_override_64bit): New function.
(check_effective_target_ppc_long_double_override_64bit): New
function.
---
 gcc/testsuite/lib/target-supports.exp | 155 ++
 1 file changed, 155 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index af46c779214..50302973b62 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2354,6 +2354,161 @@ proc check_effective_target_ppc_ieee128_ok { } {
 }]
 }
 
+# See if the target is a powerpc with the long double format that uses the IBM
+# extended double format.
+
+proc check_effective_target_ppc_long_double_ibm128 { } {
+return [check_cached_effective_target ppc_long_double_ibm {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that uses the IEEE
+# 128-bit format.
+
+proc check_effective_target_ppc_long_double_ieee128 { } {
+return [check_cached_effective_target ppc_long_double_ieee {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IEEE128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that is 64-bit.
+
+proc check_effective_target_ppc_long_double_64bit { } {
+return [check_cached_effective_target ppc_long_double_64bit {
+   int main()
+   {
+ #ifndef _ARCH_PPC
+   return 1;
+ #else
+   return sizeof (long double) != 8;
+ #endif
+   }
+}]
+}
+
+# Like check_effective_target_ppc_long_double_ibm128, but check if we can
+# explicitly override the long double format to use the IBM 128-bit extended
+# double format, and GLIBC supports doing this override by switching the
+# sprintf to handle long double.
+
+proc add_options_for_ppc_long_double_override_ibm128 { flags } {
+if { [istarget powerpc*-*-*] } {
+   return "$flags -mlong-double-128 -Wno-psabi -mabi=ibmlongdouble"
+}
+return "$flags"
+}
+
+proc check_effective_target_ppc_long_double_override_ibm128 { } {
+return [check_runtime_nocache ppc_long_double_override_ibm128 {
+   #include 
+   #include 
+   volatile __ibm128 a = (__ibm128) 3.0;
+   volatile long double one = 1.0L;
+   volatile long double two = 2.0L;
+   volatile long double b;
+   char buffer[20];
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   b = one + two;
+   if (memcmp ((void *), (void *), sizeof (long double)) != 0)
+ return 1;
+   sprintf (buffer, "%lg", b);
+   return strcmp (buffer, "3") != 0;
+ #endif
+   }
+} [add_options_for_ppc_long_double_override_ibm128 ""]]
+}
+
+# Like check_effective_target_ppc_long_double_ieee, but check if we can
+# explicitly override the long double format to use the IEEE 128-bit format,
+# and GLIBC supports doing this override by switching the sprintf to handle
+# long double.
+
+proc 

Re: [PATCH 1/3] PowerPC: Add long double target-supports.

[Michael Meissner via Gcc-patches]

On Fri, Jan 15, 2021 at 06:16:43PM +, Joseph Myers wrote:
> On Thu, 14 Jan 2021, Michael Meissner via Gcc-patches wrote:
> 
> > +return [check_runtime_nocache ppc_long_double_ovveride_ibm128 {
> 
> > +return [check_runtime_nocache ppc_long_double_ovveride_ieee128 {
> 
> > +return [check_runtime_nocache ppc_long_double_ovveride_64bit {
> 
> All these places have the typo "ovveride".

Thanks.  I have fixed these in the next version of the patch.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH, 0 of 3], Fix PowerPC test suite for IEEE 128-bit long double

[Michael Meissner via Gcc-patches]

As I mentioned in the patch for adding _Float128 <-> Decimal conversions, there
are two test cases that fail if you configure the compiler to use IEEE 128-bit
long double or 64-bit long double.  That is because these tests are explicitly
testing that the long double is a pair of doubles (i.e. IBM 128-bit long
double).

In previous iterations of this patch, I set the target condition to run the
test only if long double uses the IBM 128-bit format.  Segher suggest that
instead I add target support tests and options to force the long double format
to IBM 128-bit long double.  I rewrote the patches to do this.

In the last time I posted this patch, Joseph Myers noticed that I misspelled
'override' in two of the functions.  I have fixed this in this patch.  Thanks.

There are 3 patches in this set:

1)  The patch to target-supports.exp to add 3 new functions that returns
true based on what the current long double format is.  And there are
three functions that return true if you can set the long double type at
compile time and the GLIBC supports this option.  The remaining 2
patches need this patch to be installed before they can be installed.

2)  The patch to gcc/testsuite/gcc.target/powerpc/pr70117.c that forces
this test to use IBM 128-bit long double.

3)  The patch to gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c that
forces this test to use IBM 128-bit long double.

I have done bootstrap builds on a power9 little endian system with the compiler
configured for the default IBM 128-bit long double and the IEEE 128-bit long
double.  The 2 tests now pass when I add these patches.  I also have built
bootstrap compilers on a power8 big endian system, and there were no
regressions.  Can I check these patches into the master branch?

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH, V2] Add conversions between _Float128 and Decimal.

[Michael Meissner via Gcc-patches]

On Sat, Feb 20, 2021 at 06:33:12PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Tue, Feb 09, 2021 at 02:35:05AM -0500, Michael Meissner wrote:
> > This patch implements conversions between _Float128 and the 3 Decimal 
> > floating
> > types.  It does this by extendending the dfp-bit conversions to add a new
> > binary floating point type (KF), and doing the conversions in the same 
> > manner
> > as the other binary/decimal conversions.
> 
> > For conversions from _Float128 to Decimal, this patch uses a function
> > (__sprintfkf) instead of the sprintf function to convert long double values 
> > to
> > strings.  The __sprintfkf function determines if GLIBC 2.32 or newer is used
> > and calls the IEEE 128-bit version of sprintf (__sprintfieee128).  If the 
> > GLIBC
> > is earlier than 2.32, the code will convert _Float128 to __ibm128 and then 
> > use
> > the normal sprintf to convert this value.
> 
> So if built with a glibc version before 2.32 (less than a year old) it
> will give the wrong answer.  This needs improving, or it will be another
> eight or so years until this is generally usable.

But until the long double format default is changed to be IEEE 128-bit floating
point,  only the people who explicitly convert between __float128/_Float128 and
the decimal types will see the issue.

In order to switch to the IEEE 128-bit floating point long double, you need at
least GLIBC 2.32, and you will get full accuracy.

> > The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
> > appropriate long double options.  There were a few differences in the test
> > suite runs that will be addressed in later patches, but over all it works
> > well.
> 
> What kind of differences?  I assume you checked all, and all differences
> are an improvement, or the differences are inconsequential and the test
> is not very good?

I have submitted patches for these before, and I will shortly ping or resubmit
them again.  But I felt this was more import to get in before worrying about
changes to the testsuite.  The changes are:

* C test   c-c++-common/dfp/convert-bfp-11.c fails
* C test   gcc.target/powerpc/pr70117.c  fails
* C test   gcc.dg/torture/float128-nan.c fails
* C test   gcc.target/powerpc/nan128-1.c fails
* C++ test c-c++-common/dfp/convert-bfp-11.c fails
* C++ testsall modules tests fails
* Fortran test gfortran.dg/default_format_2.f90  now passes
* Fortran test gfortran.dg/default_format_denormal_2.f90 now passes
* Fortran test gfortran.dg/ieee/large_2.f90  now passes

The following two tests test facets of the IBM 128-bit long double
implementation.  Since they are hard wired to use IBM 128-bit long double, I've
added options in the patches to run these tests with -mabi=ibmlongdouble if the
default is -mabi=ieeelongdouble.

* c-c++-common/dfp/convert-bfp-11.c
* gcc.target/powerpc/pr70117.c

The following two tests fail because they are testing the old libquadmath 'q'
built-ins, and there is a subtle difference between using the _Float128
built-in function for the nans function and the long double built-in function
for nans.  In particular, the signalling NaN is silently converted to a quiet
NaN.

* gcc.dg/torture/float128-nan.c
* gcc.target/powerpc/nan128-1.c

The modules failures are PR c++/98645, and are not a back end feature.

The 3 fortran tests now pass if long double uses the IEEE 128-bit
representation:

* gfortran.dg/default_format_2.f90
* gfortran.dg/default_format_denormal_2.f90
* gfortran.dg/ieee/large_2.f90

> 
> > --- /dev/null
> > +++ b/libgcc/config/rs6000/_sprintfkf.c
> > @@ -0,0 +1,57 @@
> > +   If we are linked against an earlier library, we will have fake it by
> > +   converting the value to long double, and using sprinf to do the 
> > conversion.
> 
> (typo, sprintf)

Fixed.

> > +   This isn't ideal, as IEEE 128-bit has more exponent range than IBM
> > +   128-bit.  */
> 
> And that results in some numbers being printed as Inf that are not.  But
> also, the significand has more bits, so there is a loss of precision as
> well.

Yes.

> > +int __sprintfkf (char *restrict string,
> > +const char *restrict format,
> > +_Float128 number)
> > +{
> > +  if (__sprintfieee128)
> > +return __sprintfieee128 (string, format, number);
> > +
> > +  return sprintf (string, format, (long double)number);
> 
> Space after cast.

Fixed.

> > +_Float128
> > +__strtokf (const char *string, char **endptr)
> > +{
> > +  long double num;
> > +
> > +  if (__strtoieee128)
> > +return __strtoieee128 (string, endptr);
> > +
> > +  num = strtold (string, endptr);
> > +  return (_Float128) num;
> 
> Do not cast return values please.  All casts you do should be *needed*,
> have a purpose.

Well it is changing type (num is long double, i.e. IBM 128-bit long double) and
the return is 

Re: [PATCH] PR 99133, Mark xxspltiw, xxspltidp, and xxsplti32x as being prefixed

[Michael Meissner via Gcc-patches]

On Wed, Feb 17, 2021 at 06:09:39PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Feb 17, 2021 at 12:17:30PM -0500, Michael Meissner wrote:
> > I noticed that the power10 xxspltiw, xxspltidp, and xxsplti32dx
> > instructions are not flagged as prefixed instructions, which means the
> > instruction length is not set to 12 bytes.  This patch sets these
> > instructions to be prefixed.  It also ensures that a leading 'p' is not
> > emitted before the instruction.
> > 
> > I checked this patch by doing a bootstrap build/check on a little endian 
> > power8
> > server system.  There were no regressions.
> 
> Why test a p10 patch on a p8?

Well it is just a code gen patch, so I can test it on any system, even an
x86_64 with a cross compiler.  Given that right now xxsplatiw is only created
via a built-in, The main consequence of not setting the prefixed attribute is
that the insn length is wrong.  Normal functions probably won't even notice,
but it is certainly possible that some function is large enough and it uses
xxsplatiw (and friends) and the assembler would complain that conditional jumps
are too far.

At the moment given it is only generated as a built-in function, I doubt people
would run into it.  As we add support in GCC 12 to use these instructions to
load up constants into the vector registers, it is more likely that people will
run into issues if the length is wrong.

> > In addition, I debugged cc1, and I
> > put a breakpoint on the get_attr_length function and I verified the insns 
> > now
> > have length 12.
> 
> You can just use -dp; the generated assembler output has lines like
>   pla 3,.LC0@pcrel # 6[c=4 l=12]  *pcrel_local_addr
> (c is cost, l is length).
> 
>   fprintf (asm_out_file, "[c=%d",
>insn_cost (debug_insn, optimize_insn_for_speed_p ()));
>   if (HAVE_ATTR_length)
> fprintf (asm_out_file, " l=%d",
>  get_attr_length (debug_insn));
>   fprintf (asm_out_file, "]  ");

Sure, but it is just as simple to verify it with a debugger.

> > +   Some prefixed instructions (xxspltiw, xxspltidp, xxsplti32dp, etc.) do 
> > not
> > +   have a leading 'p'.  Setting the prefix attribute to special does not 
> > the 'p'
> > +   prefix.  */
> 
> (grammar)
> 
> "special" is the *normal* case.  *Most* prefixed insns will be like
> this.  They aren't right now, but they will be.
> 
> It sounds like you should make a new attribute, "always_prefixed" or
> something, that then the code that sets "prefixed" can use.

Yes agreed.

> >  void
> >  rs6000_final_prescan_insn (rtx_insn *insn, rtx [], int)
> >  {
> > -  next_insn_prefixed_p = (get_attr_prefixed (insn) != PREFIXED_NO);
> > +  next_insn_prefixed_p = (get_attr_prefixed (insn) != PREFIXED_NO
> > + && get_attr_prefixed (insn) != PREFIXED_SPECIAL);
> >return;
> >  }
> 
> So you set next_insn_prefixed_p when exactly?  The original code was
> correct, as far as I can see?

rs6000_final_prescan_insn is called in the FINAL_PRESCAN_INSN target hook, and
it is the only place we can set the flag for ASM_OUTPUT_OPCODE to print the
initial 'p'.  As you know, during the development of prefixed support, I went
through various different methods of generating the prefixed instruction
(i.e. pld instead of ld).  The current method works for normal load, store and
add instructions that have a normal form and a prefixed form.  But it doesn't
work for other instructions that we need to start dealing with. 
> 
> There are four kinds of insns now:
> 
> 1) Never prefixed.
> 2) Always prefixed, like xxspltiw but many more in the future.
> 3) Sometimes prefixed, and they get a "p" mnemonic prefix then.  Those
> are the majority currently, since we mostly have load/store insns that
> are prefixed currently, and those usually have a non-prefixed form we
> handled already.
> 4) Sometimes prefixed, and they get a "pm" prefix then.  We don't handle
> those yet (those are the MMA GER insns).
> 
> The "prefixed" attribute should just mean if the instruction ended up as
> some prefixed form (8 bytes).
> 
> So, for insns like xxspltiw you should just set "prefixed" to "yes",
> because that makes sense, is not confusing.  The code that prefixes "p"
> to the mnemonic should change, instead.  It can look at some new
> attribute, but it could also just use
>   prefixed_load_p (insn) || prefixed_store_p (insn)
>   || prefixed_paddi_p (insn)
> or similar (perhaps make a helper function for that then?)

Yes.  Pat Haugen will be taking over the PR.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] PR 99133, Mark xxspltiw, xxspltidp, and xxsplti32x as being prefixed

[Michael Meissner via Gcc-patches]

PR 99133, Mark xxspltiw, xxspltidp, and xxsplti32x as being prefixed

I noticed that the power10 xxspltiw, xxspltidp, and xxsplti32dx
instructions are not flagged as prefixed instructions, which means the
instruction length is not set to 12 bytes.  This patch sets these
instructions to be prefixed.  It also ensures that a leading 'p' is not
emitted before the instruction.

I checked this patch by doing a bootstrap build/check on a little endian power8
server system.  There were no regressions.  In addition, I debugged cc1, and I
put a breakpoint on the get_attr_length function and I verified the insns now
have length 12.  Can I check this patch into the master branch?

GCC 10 does not have support for these instructions, so I will not need to do a
backport.

gcc/
2021-02-17  Michael Meissner  

PR target/99133
* config/rs6000/altivec.md (xxspltiw_v4si): Set prefixed
attribute.
(xxspltiw_v4sf): Set prefixed attribute.
(xxspltidp_v2df): Set prefixed attribute.
(xxsplti32dx_v4si): Set prefixed attribute.
(xxsplti32dx_v4si_inst): Set prefixed attribute.
(xxsplti32dx_v4sf): Set prefixed attribute.
* config/rs6000/rs6000.c (rs6000_insn_cost): Add support for
setting prefixed attribute to special.
(rs6000_final_prescan_insn): If prefixed attribute is special, do
not emit a leading 'p' before the instruction.
(rs6000_adjust_insn_length): Add support for setting prefixed
attribute to special.
* config/rs6000/rs6000.md (prefixed attribute): Add 'special' case
for prefixed instructions that do not use a leading 'p'.
---
 gcc/config/rs6000/altivec.md | 18 --
 gcc/config/rs6000/rs6000.c   | 13 +
 gcc/config/rs6000/rs6000.md  |  7 ++-
 3 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 27a269b9e72..d409acce3a9 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -826,7 +826,8 @@ (define_insn "xxspltiw_v4si"
 UNSPEC_XXSPLTIW))]
  "TARGET_POWER10"
  "xxspltiw %x0,%1"
- [(set_attr "type" "vecsimple")])
+ [(set_attr "type" "vecsimple")
+  (set_attr "prefixed" "special")])
 
 (define_expand "xxspltiw_v4sf"
   [(set (match_operand:V4SF 0 "register_operand" "=wa")
@@ -845,7 +846,8 @@ (define_insn "xxspltiw_v4sf_inst"
 UNSPEC_XXSPLTIW))]
  "TARGET_POWER10"
  "xxspltiw %x0,%1"
- [(set_attr "type" "vecsimple")])
+ [(set_attr "type" "vecsimple")
+  (set_attr "prefixed" "special")])
 
 (define_expand "xxspltidp_v2df"
   [(set (match_operand:V2DF 0 "register_operand" )
@@ -864,7 +866,8 @@ (define_insn "xxspltidp_v2df_inst"
 UNSPEC_XXSPLTID))]
   "TARGET_POWER10"
   "xxspltidp %x0,%1"
-  [(set_attr "type" "vecsimple")])
+  [(set_attr "type" "vecsimple")
+  (set_attr "prefixed" "special")])
 
 (define_expand "xxsplti32dx_v4si"
   [(set (match_operand:V4SI 0 "register_operand" "=wa")
@@ -883,7 +886,8 @@ (define_expand "xxsplti32dx_v4si"
 GEN_INT (index), operands[3]));
DONE;
 }
- [(set_attr "type" "vecsimple")])
+ [(set_attr "type" "vecsimple")
+  (set_attr "prefixed" "special")])
 
 (define_insn "xxsplti32dx_v4si_inst"
   [(set (match_operand:V4SI 0 "register_operand" "=wa")
@@ -893,7 +897,8 @@ (define_insn "xxsplti32dx_v4si_inst"
 UNSPEC_XXSPLTI32DX))]
   "TARGET_POWER10"
   "xxsplti32dx %x0,%2,%3"
-  [(set_attr "type" "vecsimple")])
+  [(set_attr "type" "vecsimple")
+  (set_attr "prefixed" "special")])
 
 (define_expand "xxsplti32dx_v4sf"
   [(set (match_operand:V4SF 0 "register_operand" "=wa")
@@ -921,7 +926,8 @@ (define_insn "xxsplti32dx_v4sf_inst"
 UNSPEC_XXSPLTI32DX))]
   "TARGET_POWER10"
   "xxsplti32dx %x0,%2,%3"
-  [(set_attr "type" "vecsimple")])
+  [(set_attr "type" "vecsimple")
+  (set_attr "prefixed" "special")])
 
 (define_insn "xxblend_"
   [(set (match_operand:VM3 0 "register_operand" "=wa")
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 798a715005c..f01fda35459 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -22031,7 +22031,7 @@ rs6000_insn_cost (rtx_insn *insn, bool speed)
   if (n == 0)
 {
   int length = get_attr_length (insn);
-  if (get_attr_prefixed (insn) == PREFIXED_YES)
+  if (get_attr_prefixed (insn) != PREFIXED_NO)
{
  int adjust = 0;
  ADJUST_INSN_LENGTH (insn, adjust);
@@ -26212,11 +26212,16 @@ static bool next_insn_prefixed_p;
insn is a prefixed insn where we need to emit a 'p' before the insn.
 
In addition, if the insn is part of a PC-relative reference to an external
-   label optimization, this is recorded also.  */
+   label optimization, this is recorded also.
+
+   Some prefixed instructions (xxspltiw, xxspltidp, xxsplti32dp, etc.) do not
+   have a leading 'p'.  Setting the prefix attribute 

[Ping #3, Patch V2] Add conversions between _Float128 and Decimal.

[Michael Meissner via Gcc-patches]

Ping patch

| Subject: [PATCH, V2] Add conversions between _Float128 and Decimal.
| Message-ID: <20210209073505.ga11...@ibm-toto.the-meissners.org>
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565009.html

I was asked to resubmit the patch with the copyright dates fixed, and Will's
comments addressed.  I have done this (Will's comments other than the copyright
dates were all about the check-in message, and not the patch itself).  I have
attempted to make the check-in message clearer.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PING, PATCH V2] Add conversions between _Float128 and Decimal.

[Michael Meissner via Gcc-patches]

Ping patch

| Subject: [PATCH, V2] Add conversions between _Float128 and Decimal.
| Message-ID: <20210209073505.ga11...@ibm-toto.the-meissners.org>
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565009.html

I was asked to resubmit the patch with the copyright dates fixed, and Will's
comments addressed.  I have done this (Will's comments other than the copyright
dates were all about the check-in message, and not the patch itself).  I have
attempted to make the check-in message clearer.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH, V2] Add conversions between _Float128 and Decimal.

[Michael Meissner via Gcc-patches]

[PATCH V2] Add conversions between _Float128 and Decimal.

This patch implements conversions between _Float128 and the 3 Decimal floating
types.  It does this by extendending the dfp-bit conversions to add a new
binary floating point type (KF), and doing the conversions in the same manner
as the other binary/decimal conversions.

For conversions from _Float128 to Decimal, this patch uses a function
(__sprintfkf) instead of the sprintf function to convert long double values to
strings.  The __sprintfkf function determines if GLIBC 2.32 or newer is used
and calls the IEEE 128-bit version of sprintf (__sprintfieee128).  If the GLIBC
is earlier than 2.32, the code will convert _Float128 to __ibm128 and then use
the normal sprintf to convert this value.

For conversions from Decimal to _Float128, this patch uses a function
(__strtokf) instead of strtold to convert the strings from the Decimal
conversion to long double.  The __strtokf function determines if GLIBC 2.32 or
newer is used, and if it is, calls the IEEE 128-bit version (__strtoieee128).
If the GLIBC is earlier than 2.32, the code will call strtold and convert the
__ibm128 value to _Float128.

These functions will primarily be used if/when the default PowerPC long double
type is changed to IEEE 128-bit, but they could also be used if the user
explicitly converts _Float128 to/from a Decimal type.

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works
well.  This patch is required to be able to build a toolchain where the default
long double is IEEE 128-bit.  Can I check this patch into the master branch for
GCC 11?

One test case relating to Decimal fails if I build a compiler where the default
is IEEE 128-bit:

*   c-c++-common/dfp/convert-bfp-11.c

I have patches for this test, and they have been submitted separately.

I have also built compilers with this patch on a big endian power8 system that
has both 32-bit and 64-bit support.  There were no regressions in running these
tests on the system.

Compared to the previous version of the patch, this version uses 2021 copyright
dates without mentioning other years.  I also rewrote some of the commentary
that Will mentioned to be clearer.

libgcc/
2021-02-09  Michael Meissner  

* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
* config/rs6000/_kf_to_sd.c: New file.
* config/rs6000/_kf_to_td.c: New file.
* config/rs6000/_sd_to_kf.c: New file.
* config/rs6000/_sprintfkf.c: New file.
* config/rs6000/_sprintfkf.h: New file.
* config/rs6000/_strtokf.h: New file.
* config/rs6000/_strtokf.c: New file.
* config/rs6000/_td_to_kf.c: New file.
* config/rs6000/quad-float128.h: Add new declarations.
* config/rs6000/t-float128 (fp128_dec_funcs): New macro.
(fp128_decstr_funcs): New macro.
(ibm128_dec_funcs): New macro.
(fp128_ppc_funcs): Add the new conversions.
(fp128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(fp128_decstr_objs): Force __float128 <-> string conversions to be
compiled with -mabi=ibmlongdouble.
(ibm128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(FP128_CFLAGS_DECIMAL): New macro.
(IBM128_CFLAGS_DECIMAL): New macro.
* dfp-bit.c (DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
* dfp-bit.h (BFP_KIND): Add new binary floating point kind for
IEEE 128-bit floating point.
(DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
(BFP_SPRINTF): New macro.
---
 libgcc/config/rs6000/_dd_to_kf.c | 37 ++
 libgcc/config/rs6000/_kf_to_dd.c | 37 ++
 libgcc/config/rs6000/_kf_to_sd.c | 37 ++
 libgcc/config/rs6000/_kf_to_td.c | 37 ++
 libgcc/config/rs6000/_sd_to_kf.c | 37 ++
 libgcc/config/rs6000/_sprintfkf.c| 57 
 libgcc/config/rs6000/_sprintfkf.h| 28 ++
 libgcc/config/rs6000/_strtokf.c  | 56 +++
 libgcc/config/rs6000/_strtokf.h  | 27 +
 libgcc/config/rs6000/_td_to_kf.c | 37 ++
 libgcc/config/rs6000/quad-float128.h |  8 
 libgcc/config/rs6000/t-float128  | 37 +-
 

[PING] Add conversions between _Float128 and Decimal.

[Michael Meissner via Gcc-patches]

Ping patch.  This really needs to go in to allow switching the long double type
to IEEE 128-bit.

https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564486.html
| Subject: [PATCH] Add conversions between _Float128 and Decimal.
| Message-ID: <20210129024208.ga25...@ibm-toto.the-meissners.org>

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] Make asm not contain prefixed addresses.

[Michael Meissner via Gcc-patches]

>From 4ceff15935a16da9ec5833279807855a8afc47cd Mon Sep 17 00:00:00 2001
From: Michael Meissner 
Date: Mon, 1 Feb 2021 22:19:57 -0500
Subject: [PATCH] Make asm not contain prefixed addresses.

In PR target/98519, the assembler does not like asm memory references that are
prefixed.  We can't automatically change the instruction to prefixed form with
a 'p' like we do for normal RTL insns, since this is assembly code.  Instead,
the patch prevents prefixed memory addresses from being passed by default.

This patch uses the TARGET_MD_ASM_ADJUST target hook to change the 'm' and 'o'
constraints to be 'em' and 'eo'.  The 'em' and 'eo' constraints do not allow
prefixed instructions.  In addition, a new constraint 'ep' is added to
explicitly require a prefixed instruction.

I have tested this on a little endian power9 system in doing a bootstrap build
and make check.  There were no regressions.  Can I check this into the master
branch?

I would like to also backport this change to the GCC 10 branch, since the bug
can happen in that release as well.

[gcc]
2021-02-01  Michael Meissner  

PR target/98519
* config/rs6000/constraints.md (em): New constraint.
(eo): New constraint.
(ep): New constraint.
* config/rs6000/rs6000.md (rs6000_md_asm_adjust): If prefixed
addresses are allowed, change the 'm' and 'o' constraints to 'em'
and 'eo' that do not allow prefixed instructions.
* doc/md.texi (PowerPC and IBM RS6000 constraints): Document 'em',
'eo', and 'ep' constraints.

[gcc/testsuite]
2021-02-01  Michael Meissner  

PR target/98519
* gcc.target/powerpc/pr98519.c: New test.
---
 gcc/config/rs6000/constraints.md   | 19 
 gcc/config/rs6000/rs6000.c | 56 +-
 gcc/doc/md.texi|  9 
 gcc/testsuite/gcc.target/powerpc/pr98519.c | 17 +++
 4 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr98519.c

diff --git a/gcc/config/rs6000/constraints.md b/gcc/config/rs6000/constraints.md
index 561ce9797af..56a7eda4c85 100644
--- a/gcc/config/rs6000/constraints.md
+++ b/gcc/config/rs6000/constraints.md
@@ -245,6 +245,25 @@ (define_memory_constraint "es"
   (and (match_code "mem")
(match_test "GET_RTX_CLASS (GET_CODE (XEXP (op, 0))) != RTX_AUTOINC")))
 
+;; Non-prefixed memory
+(define_memory_constraint "em"
+  "@internal Memory operand that is not prefixed."
+  (and (match_code "mem")
+   (not (match_operand 0 "prefixed_memory"
+
+;; Non-prefixed memory that is also offsettable
+(define_memory_constraint "eo"
+  "@internal Memory operand that is not prefixed but is offsettable."
+  (and (match_code "mem")
+   (not (match_operand 0 "prefixed_memory"))
+   (match_operand 0 "offsettable_mem_operand")))
+
+;; prefixed memory
+(define_memory_constraint "ep"
+  "@internal Memory operand that is prefixed."
+  (and (match_code "mem")
+   (match_operand 0 "prefixed_memory")))
+
 (define_memory_constraint "Q"
   "A memory operand addressed by just a base register."
   (and (match_code "mem")
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ec068c58aa5..726928a4d32 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -3414,9 +3414,63 @@ rs6000_builtin_mask_calculate (void)
 
 static rtx_insn *
 rs6000_md_asm_adjust (vec &/*outputs*/, vec &/*inputs*/,
- vec &/*constraints*/,
+ vec ,
  vec , HARD_REG_SET _regs)
 {
+  /* If prefixed addresses are allowed, change the "m" constraint to "em" and
+ the "o" constraint to "eo".  The "em" and "eo" constraints do not allow
+ prefixed memory.  */
+  if (TARGET_PREFIXED)
+{
+  size_t max_len = 0;
+  for (unsigned i = 0; i < constraints.length (); ++i)
+   {
+ size_t len = strlen (constraints[i]);
+ if (len > max_len)
+   max_len = len;
+   }
+
+  char *buffer = (char *) alloca (2 * max_len + 1);
+  for (unsigned i = 0; i < constraints.length (); ++i)
+   {
+ const char *constraint = constraints[i];
+ char *new_constraint = buffer;
+ char ch;
+ bool found_m_or_o = false;
+
+ while ((ch = *constraint++) != '\0')
+   switch (ch)
+ {
+ default:
+   *new_constraint++ = ch;
+   break;
+
+   /* If we found 'm' or 'o', convert it to 'em' or 'eo' so that
+  prefixed memory is not allowed.  */
+ case 'm':
+ case 'o':
+   found_m_or_o = true;
+   *new_constraint++ = 'e';
+   *new_constraint++ = ch;
+   break;
+
+   /* 'e' and 'w' begin two letter constraints.  */
+ case 'e':
+ case 'w':
+   *new_constraint++ = ch;
+   *new_constraint++ = 

Re: [PATCH] Add conversions between _Float128 and Decimal.

[Michael Meissner via Gcc-patches]

On Fri, Jan 29, 2021 at 03:45:49PM -0600, will schmidt wrote:
> On Thu, 2021-01-28 at 21:42 -0500, Michael Meissner via Gcc-patches wrote:
> > [PATCH] Add conversions between _Float128 and Decimal.
> > 
> 
> Hi, 
> Just a couple cosmetic nits in the description.  The changelog seems to
> match that patch contents OK.  
> 
> 
> > This patch implements conversions between _Float128 and the 3 Decimal
> > floating types.  It does by extendending the dfp-bit conversions to add a
> 
> nit: 'does so' or 'does this' 
> 
> > new binary floating point type (KF), and doing the conversions in the same
> > mannor as the other binary/decimal conversions.
> 
> manner.
> 
> > 
> > In particular for conversions from _Float128 to Decimal, it uses a sprintf
> > variant to convert _Float128 to strings, and a type specific function that
> > converts the string output to the appropriate Decimal type
> > 
> > For conversions from one of the Decimal types to _Float128, it uses a 
> > decimal
> > function to convert to string (i.e. __decimalToString), and then uses a
> > variant of strtold to convert to _Float128.
> 
> 
> Are the sprintf and strtold functions called actually variants? 

Normally sprintf and strtold are used for converting between binary and decimal
floating point types.

With these patches, when you are converting _Float128 to Decimal, __sprintfkf
is used instead of sprintf.  When you are converting Decimal to _Float128,
__strtokf is used instead of strtold.  These two functions handle checking
whether GLIBC 2.32 or newer was used and if so, it calls __sprintfieee128 or
__strtoieee128 respectively.  If GLIBC 2.31 or earlier was used, then it does
the conversion between __ibm128 and _Float128 to do the conversion.

> Other source files in libgcc/config appear to have the copyright range
> starting at a later date, presumably when the file was created.
> So.. I think this should be Copyright (C) 2021 FSF

Well they were initially cloned from other files, so I kept the long copyright
date.  But I could use just 2021.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] PR target/98870: Fix IEEE 128-bit fortran test

[Michael Meissner via Gcc-patches]

PR target/98870: Fix IEEE 128-bit fortran test

This test started failing when I changed the mapping of IEEE 128-bit long
double built-in functions on 2021-01-28.  This patch fixes the test so it
uses the correct name.

I have tested this patch and the test now passes.  Can I check it into the
master branch?

gcc/testsuite/
2021-01-29  Michael Meissner  

PR testsuite/98870
* gcc.target/powerpc/ppc-fortran/ieee128-math.f90: Fix mapping of
the built-in function.
---
 gcc/testsuite/gcc.target/powerpc/ppc-fortran/ieee128-math.f90 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ieee128-math.f90 
b/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ieee128-math.f90
index d74c8d723f1..06685499b54 100644
--- a/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ieee128-math.f90
+++ b/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ieee128-math.f90
@@ -17,4 +17,4 @@ program test_qp
 end
 
 ! { dg-final { scan-assembler-not {\mbl logl\M}} }
-! { dg-final { scan-assembler {\mbl logf128\M} } }
+! { dg-final { scan-assembler {\mbl __logieee128\M} } }
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [Ping] PowerPC: Add float128/Decimal conversions.

[Michael Meissner via Gcc-patches]

I rebusmitted the patch after verifying it still builds and works with the
current branch as:

https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564486.html

| Subject: [PATCH] Add conversions between _Float128 and Decimal.
| Message-ID: <20210129024208.ga25...@ibm-toto.the-meissners.org>

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] Add conversions between _Float128 and Decimal.

[Michael Meissner via Gcc-patches]

[PATCH] Add conversions between _Float128 and Decimal.

This patch implements conversions between _Float128 and the 3 Decimal
floating types.  It does by extendending the dfp-bit conversions to add a
new binary floating point type (KF), and doing the conversions in the same
mannor as the other binary/decimal conversions.

In particular for conversions from _Float128 to Decimal, it uses a sprintf
variant to convert _Float128 to strings, and a type specific function that
converts the string output to the appropriate Decimal type

For conversions from one of the Decimal types to _Float128, it uses a decimal
function to convert to string (i.e. __decimalToString), and then uses a
variant of strtold to convert to _Float128.

If the user is linked against GLIBC 2.32 or newer, then the sprintf and strtold
variant functions can use the features directly in GLIBC 2.32 to do this
conversion.

If you have an older GLIBC and want to convert _Float128 to one of the Decimal
types, it will convert the _Float128 to __ibm128 and then convert that to
Decimal.

Similarly if you have one of the Decimal types, and want to convert to
_Float128, it will first convert the Decimal type to __ibm128, and then convert
__ibm128 to _Float128.

These functions will primarily be used if/when the default PowerPC long double
type is changed to IEEE 128-bit, but they could also be used if the user
explicitly converts _Float128 to/from a Decimal type.

One test case relating to Decimal fails if I build a compiler where the default
is IEEE 128-bit:

*   c-c++-common/dfp/convert-bfp-11.c

I have patches for this test, and they have been submitted separately.

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works
well.  This patch is required to be able to build a toolchain where the default
long double is IEEE 128-bit.  Can I check this patch into the master branch for
GCC 11?

I have also built compilers with this patch on a big endian power8 system that
has both 32-bit and 64-bit support.  There were no regressions in running these
tests on the system.

Can I check this patch into the master branch?

libgcc/
2021-01-28  Michael Meissner  

* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
* config/rs6000/_kf_to_sd.c: New file.
* config/rs6000/_kf_to_td.c: New file.
* config/rs6000/_sd_to_kf.c: New file.
* config/rs6000/_sprintfkf.c: New file.
* config/rs6000/_sprintfkf.h: New file.
* config/rs6000/_strtokf.h: New file.
* config/rs6000/_strtokf.c: New file.
* config/rs6000/_td_to_kf.c: New file.
* config/rs6000/quad-float128.h: Add new declarations.
* config/rs6000/t-float128 (fp128_dec_funcs): New macro.
(fp128_decstr_funcs): New macro.
(ibm128_dec_funcs): New macro.
(fp128_ppc_funcs): Add the new conversions.
(fp128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(fp128_decstr_objs): Force __float128 <-> string conversions to be
compiled with -mabi=ibmlongdouble.
(ibm128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(FP128_CFLAGS_DECIMAL): New macro.
(IBM128_CFLAGS_DECIMAL): New macro.
* dfp-bit.c (DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
* dfp-bit.h (BFP_KIND): Add new binary floating point kind for
IEEE 128-bit floating point.
(DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
(BFP_SPRINTF): New macro.
---
 libgcc/config/rs6000/_dd_to_kf.c | 37 ++
 libgcc/config/rs6000/_kf_to_dd.c | 37 ++
 libgcc/config/rs6000/_kf_to_sd.c | 37 ++
 libgcc/config/rs6000/_kf_to_td.c | 37 ++
 libgcc/config/rs6000/_sd_to_kf.c | 37 ++
 libgcc/config/rs6000/_sprintfkf.c| 57 
 libgcc/config/rs6000/_sprintfkf.h| 28 ++
 libgcc/config/rs6000/_strtokf.c  | 56 +++
 libgcc/config/rs6000/_strtokf.h  | 27 +
 libgcc/config/rs6000/_td_to_kf.c | 37 ++
 libgcc/config/rs6000/quad-float128.h |  8 
 libgcc/config/rs6000/t-float128  | 37 +-
 libgcc/dfp-bit.c | 12 +-
 libgcc/dfp-bit.h | 

Re: [Ping] PowerPC: Add float128/Decimal conversions.

[Michael Meissner via Gcc-patches]

On Thu, Jan 28, 2021 at 12:59:18PM -0600, Segher Boessenkool wrote:
> On Thu, Jan 28, 2021 at 01:10:39PM -0500, Michael Meissner wrote:
> > > The whole thread is at 
> > > https://patchwork.ozlabs.org/project/gcc/patch/2020112524.ga...@ibm-toto.the-meissners.org/
> > >  .
> > > 
> > > I approved *that* version of the patch.
> > 
> > Yes you approved the built-in renaming patch and I checked in the patch that
> > you approved (rather than the modifications that I submitted).
> > 
> > However, this is about the second patch (that provides conversions between
> > _Float128 and Decimal), which as far as I can tell was not approved.  That 
> > is
> > what this particular question is about.
> 
> I see no second patch?
> 
> > So, I rewrote the whole patch so that it will work with older GLIBC's.
> 
> Did you check in what I approved or not?  It is a very simple question,
> it's just about facts, with a simple yes/no answer.

Yes I checked in that patch earlier this morning (the original patch that you
approved).

The second patch I want you to review is:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564407.html

| Date: Wed, 27 Jan 2021 16:19:52 -0500
| Subject: [PATCH, revised, #2] PowerPC: Add float128/Decimal conversions.
| Message-ID: <20210127211952.ga28...@ibm-toto.the-meissners.org>

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [Ping] PowerPC: Add float128/Decimal conversions.

[Michael Meissner via Gcc-patches]

On Wed, Jan 27, 2021 at 09:11:49PM -0600, Segher Boessenkool wrote:
> On Tue, Jan 26, 2021 at 06:43:06PM -0500, Michael Meissner wrote:
> > I posted this patch on January 14th, 2021:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563498.html
> > 
> > | Date: Thu, 14 Jan 2021 12:09:36 -0500
> > | Subject: [PATCH] PowerPC: Add float128/Decimal conversions.
> > | Message-ID: <20210114170936.ga3...@ibm-toto.the-meissners.org>
> > 
> > You had a question about what changed, and I replied:
> > 
> > | In your last message, you said that it was unacceptable that the 
> > conversion
> > | fails if the user uses an old GLIBC.  So I rewrote the code using weak
> > | references.  If the user has at least GLIBC 2.32, it will use the IEEE 
> > 128-bit
> > | string support in the library.
> > |
> > | If an older GLIBC is used, I then use the IBM 128-bit format as an 
> > intermediate
> > | value.  Obviously there are cases where IEEE 128-bit can hold values that 
> > IBM
> > | 128-bit can't (mostly due to the increased exponent range in IEEE 
> > 128-bit), but
> > | it at least does the conversion for the numbers in the common range.
> > |
> > | In doing this transformation, I needed to do minor edits to the main 
> > decimal
> > | to/from binary conversion functions to allow the KF functions to be 
> > declared.
> > | Previously, I used preprocessor magic to rename the functions.
> > 
> > This is the second most important patch in the IEEE 128-bit work.  What do I
> > need to do to be able to commit the patch?
> 
> The whole thread is at 
> https://patchwork.ozlabs.org/project/gcc/patch/2020112524.ga...@ibm-toto.the-meissners.org/
>  .
> 
> I approved *that* version of the patch.

Yes you approved the built-in renaming patch and I checked in the patch that
you approved (rather than the modifications that I submitted).

However, this is about the second patch (that provides conversions between
_Float128 and Decimal), which as far as I can tell was not approved.  That is
what this particular question is about.

You did not like the previous _Float128 <-> Decimal conversion patch because it
was tied into having a minimum GLIBC version.

So, I rewrote the whole patch so that it will work with older GLIBC's.

If you have a newer GLIBC (detected at runtime via a weak reference), it uses
the support functions in the new GLIBC to do the conversion.  I had a cut+paste
error in the original patch that I resubmitted, and I resubmitted with the
changed line.

If you have an older GLIBC and want to convert _Float128 to one of the Decimal
types, it will convert the _Float128 to __ibm128 and then convert that to
Decimal.

Similarly if you have one of the Decimal types, and want to convert to
_Float128, it will first convert the Decimal type to __ibm128, and then convert
__ibm128 to _Float128.

So what do I do?  Can I check in this patch or do I need to do further
modifications.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[COMMITTED] PowerPC: Map IEEE 128-bit long double built-ins.

[Michael Meissner via Gcc-patches]

After testing the patch I submitted on November 17th that was approved to make
sure it still works, I commited the patch to the master branch.  Sorry about
the intermediate rewrites.

[PATCH] Map long double built-ins correctly with IEEE 128-bit long double.

The PowerPC has two different 128-bit long double types, one that uses a pair
of doubles to get more mantissa range, and the other using the IEEE 128-bit
754R binary floating point format.  The pair of doubles has been used as the
traditional format, and we are in the process of moving to allow an
implementation to switch to using IEEE 128-bit floating point.  The GLIBC and
LIBSTDC++ libraries have been modified to have functions using the two
different formats in their libraries with different names.

This patch goes through all of the built-in functions that either take long
double arguments or return long double, and changes the name from the
traditional name to the IEEE 128-bit name.  The minimum GLIBC version to
support IEEE 128-bit floating point is 2.32.

The names changed are:

*   l is usually mapped to __ieee128;
*   printf is mapped to __printfieee128; (and)
*   scanf is mapped to __isoc99_scanfieee128.

A few functions have different mappings:

*   dreml   => __remainderieee128;
*   gammal  => __lgammaieee128;
*   gammal_r=> __lgammaieee128_r;
*   lgammal_r   => __lgammaieee128_r;
*   nexttoward  => __nexttoward_to_ieee128;
*   nexttowardf => __nexttowardf_to_ieee128;
*   nexttowardl => __nexttowardl_to_ieee128;
*   pow10l  => __exp10ieee128;
*   scalbl  => __scalbieee128;
*   significandl=> __significandieee128; (and)
*   sincosl => __sincosieee128.

gcc/
2021-01-28  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_mangle_decl_assembler_name): Add
support for mapping built-in function names for long double
built-in functions if long double is IEEE 128-bit.

gcc/testsuite/
2021-01-28  Michael Meissner  

* gcc.target/powerpc/float128-longdouble-math.c: New test.
* gcc.target/powerpc/float128-longdouble-stdio.c: New test.
* gcc.target/powerpc/float128-math.c: Adjust test for new name
being generated.  Add support for running test on power10.  Add
support for running if long double defaults to 64-bits.
---
 gcc/config/rs6000/rs6000.c| 135 --
 .../powerpc/float128-longdouble-math.c| 442 ++
 .../powerpc/float128-longdouble-stdio.c   |  36 ++
 .../gcc.target/powerpc/float128-math.c|  16 +-
 4 files changed, 589 insertions(+), 40 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-math.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-stdio.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ccfbe7ba9f1..fbaff289a40 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -27338,57 +27338,128 @@ rs6000_globalize_decl_name (FILE * stream, tree decl)
library before you can switch the real*16 type at compile time.
 
We use the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change this name.  We
-   only do this if the default is that long double is IBM extended double, and
-   the user asked for IEEE 128-bit.  */
+   only do this transformation if the __float128 type is enabled.  This
+   prevents us from doing the transformation on older 32-bit ports that might
+   have enabled using IEEE 128-bit floating point as the default long double
+   type.  */
 
 static tree
 rs6000_mangle_decl_assembler_name (tree decl, tree id)
 {
-  if (!TARGET_IEEEQUAD_DEFAULT && TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128
+  if (TARGET_FLOAT128_TYPE && TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128
   && TREE_CODE (decl) == FUNCTION_DECL
-  && DECL_IS_UNDECLARED_BUILTIN (decl))
+  && DECL_IS_UNDECLARED_BUILTIN (decl)
+  && DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
 {
   size_t len = IDENTIFIER_LENGTH (id);
   const char *name = IDENTIFIER_POINTER (id);
+  char *newname = NULL;
 
-  if (name[len - 1] == 'l')
+  /* See if it is one of the built-in functions with an unusual name.  */
+  switch (DECL_FUNCTION_CODE (decl))
{
- bool uses_ieee128_p = false;
- tree type = TREE_TYPE (decl);
- machine_mode ret_mode = TYPE_MODE (type);
+   case BUILT_IN_DREML:
+ newname = xstrdup ("__remainderieee128");
+ break;
 
- /* See if the function returns a IEEE 128-bit floating point type or
-complex type.  */
- if (ret_mode == TFmode || ret_mode == TCmode)
-   uses_ieee128_p = true;
- else
-   {
- function_args_iterator args_iter;
- tree arg;
+   case BUILT_IN_GAMMAL:
+ newname = xstrdup ("__lgammaieee128");
+ break;
+
+   case 

Re: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

[Michael Meissner via Gcc-patches]

Whoops, I thought I was replying to the second patch about Decimal and IEEE
128-bit conversion, not about built-in support.

On Wed, Jan 27, 2021 at 10:01:38PM -0500, Michael Meissner wrote:
> On Wed, Jan 27, 2021 at 07:43:56PM -0600, Segher Boessenkool wrote:
> > On Wed, Jan 27, 2021 at 01:06:46PM -0600, will schmidt wrote:
> > > On Thu, 2021-01-14 at 11:59 -0500, Michael Meissner via Gcc-patches wrote:
> > > > November 19th, 2020:
> > > > Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>
> > > 
> > > Subject and date should be sufficient
> > 
> > Only if people pick good subjects, and do not send ten patches with a
> > similar subject line on the same day.  I asked for the message id,
> > that works pretty much everywhere.
> > 
> > > _if_ having the old versions
> > > of the patchs are necessary to review the latest version of the
> > > patch.  Which ideally is not the case.
> > 
> > Stronger that that: I need to know what changed!  So please just explain
> > what changed, in just a short sentence or two, or more if that is needed
> > (but not if it is not needed).
> 
> In the past you complained that the patch would abort if the user did not link
> against GLIBC 2.32 (because there is an #ifdef in the code to do the abort if
> gcc was configured against an older GLIBC).
> 
> In addition, it used some pre-processor magic so that I didn't have to modify
> the dfp-bit.{c,h} functions to add new functions.  In particular, the new
> functions pretended they where the TF functions, and used #define to change 
> the
> names.
> 
> The new code modifies dfp-bit.{c,h} to have support for the KF functions as
> separate #ifdef's.  It eliminates the preprocessor trickery, since I did 
> modify
> the dfp-bit.{c,h} support.
> 
> In order to deal with older GLIBC's, I used a different function for the KF
> library (__sprintfkf instead of sprintf, and __strtokf instead of strold).
> This function uses weak references to see if we had the GLIBC symbols
> (__sprintfieee128 and __strtoieee128 that are in GLIBC 2.32).  If those
> functions exist, we call those functions directly.
> 
> If those functions do not exist, I converted the _Float128 type to or from
> __ibm128, and I did the normal long double conversions.  Given that IEEE
> 128-bit has a much larger exponent range than IBM 128-bit, it means there are
> some numbers that can't be converted.  But at least the majority of the values
> are converted.
> 
> Note all of the other binary/decimal conversions use the GLIBC functions
> (either sprintf or strto).  The GLIBC people have the expertise to do the
> conversion, wheras I do not.  But until GLIBC 2.32, there was not enough of 
> the
> support in GLIBC to handle IEEE 128-bit conversions.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

[Michael Meissner via Gcc-patches]

On Wed, Jan 27, 2021 at 07:43:56PM -0600, Segher Boessenkool wrote:
> On Wed, Jan 27, 2021 at 01:06:46PM -0600, will schmidt wrote:
> > On Thu, 2021-01-14 at 11:59 -0500, Michael Meissner via Gcc-patches wrote:
> > > November 19th, 2020:
> > > Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>
> > 
> > Subject and date should be sufficient
> 
> Only if people pick good subjects, and do not send ten patches with a
> similar subject line on the same day.  I asked for the message id,
> that works pretty much everywhere.
> 
> > _if_ having the old versions
> > of the patchs are necessary to review the latest version of the
> > patch.  Which ideally is not the case.
> 
> Stronger that that: I need to know what changed!  So please just explain
> what changed, in just a short sentence or two, or more if that is needed
> (but not if it is not needed).

In the past you complained that the patch would abort if the user did not link
against GLIBC 2.32 (because there is an #ifdef in the code to do the abort if
gcc was configured against an older GLIBC).

In addition, it used some pre-processor magic so that I didn't have to modify
the dfp-bit.{c,h} functions to add new functions.  In particular, the new
functions pretended they where the TF functions, and used #define to change the
names.

The new code modifies dfp-bit.{c,h} to have support for the KF functions as
separate #ifdef's.  It eliminates the preprocessor trickery, since I did modify
the dfp-bit.{c,h} support.

In order to deal with older GLIBC's, I used a different function for the KF
library (__sprintfkf instead of sprintf, and __strtokf instead of strold).
This function uses weak references to see if we had the GLIBC symbols
(__sprintfieee128 and __strtoieee128 that are in GLIBC 2.32).  If those
functions exist, we call those functions directly.

If those functions do not exist, I converted the _Float128 type to or from
__ibm128, and I did the normal long double conversions.  Given that IEEE
128-bit has a much larger exponent range than IBM 128-bit, it means there are
some numbers that can't be converted.  But at least the majority of the values
are converted.

Note all of the other binary/decimal conversions use the GLIBC functions
(either sprintf or strto).  The GLIBC people have the expertise to do the
conversion, wheras I do not.  But until GLIBC 2.32, there was not enough of the
support in GLIBC to handle IEEE 128-bit conversions.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH, revised, #2] PowerPC: Add float128/Decimal conversions.

[Michael Meissner via Gcc-patches]

>From 02b04aed77130f2ec9156d2f7ff89d4cc6b5a78b Mon Sep 17 00:00:00 2001
From: Michael Meissner 
Date: Thu, 21 Jan 2021 12:58:56 -0500
Subject: [PATCH, revised] PowerPC: Add float128/Decimal conversions.

[PATCH, revised] PowerPC: Add float128/Decimal conversions.

Unfortunately, the revision I just posted had the old patch, and not the new
patch.  This patch actually has the BFP_FMT set to "%.36Le" which gives enough
accuracy to allow c-c++-common/dfp/convert-bfp-6.c test to pass.

This patch replaces the following three patches:

September 24th, 2020:
Message-ID: <20200924203545.gd31...@ibm-toto.the-meissners.org>

October 22nd, 2020:
Message-ID: <2020100603.ga11...@ibm-toto.the-meissners.org>

January 14th, 2021:
Message-ID: <20210114170936.ga3...@ibm-toto.the-meissners.org>
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563498.html

This patch rewrites those patches.  In order to run with older GLIBC's, this
patch uses weak references to the IEEE 128-bit conversions to/from string that
are found in GLIBC 2.32.

If the user uses GLIBC 2.32 or later, the Decimal <-> Float128 conversions will
call the functions in that library.  This isn't ideal, as IEEE 128-bit has more
exponent range than IBM 128-bit.

If an older library is used, these patches will convert IEEE 128-bit to IBM
128-bit and do the conversion with IBM 128-bit.  I have tested this with a
compiler configured to use an older library, and it worked for the conversion
if the number could be represented in the IBM 128-bit format.

While most of the Decimal <-> Long double tests now pass when long doubles are
IEEE 128-bit, there is one test that fails:

*   c-c++-common/dfp/convert-bfp-11.c

I have patches for the bfp-11 test (which requires that long double be IBM
128-bit).

Compared to the patch on January 14th, this patch fixes the format string
for converting IEEE 128-bit floating point to string.  This in turn allows
the c-c++-common/dfp/convert-bfp-6.c to pass.

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

I have also built and tested this patch on a big endian Power8 system with
both 64 and 32-bit targets.  There were no regressions.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works
well.  This patch is required to be able to build a toolchain where the default
long double is IEEE 128-bit.  Can I check this patch into the master branch for
GCC 11?

libgcc/
2021-01-27  Michael Meissner  

* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
* config/rs6000/_kf_to_sd.c: New file.
* config/rs6000/_kf_to_td.c: New file.
* config/rs6000/_sd_to_kf.c: New file.
* config/rs6000/_sprintfkf.c: New file.
* config/rs6000/_sprintfkf.h: New file.
* config/rs6000/_strtokf.h: New file.
* config/rs6000/_strtokf.c: New file.
* config/rs6000/_td_to_kf.c: New file.
* config/rs6000/quad-float128.h: Add new declarations.
* config/rs6000/t-float128 (fp128_dec_funcs): New macro.
(fp128_decstr_funcs): New macro.
(ibm128_dec_funcs): New macro.
(fp128_ppc_funcs): Add the new conversions.
(fp128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(fp128_decstr_objs): Force __float128 <-> string conversions to be
compiled with -mabi=ibmlongdouble.
(ibm128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(FP128_CFLAGS_DECIMAL): New macro.
(IBM128_CFLAGS_DECIMAL): New macro.
* dfp-bit.c (DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
* dfp-bit.h (BFP_KIND): Add new binary floating point kind for
IEEE 128-bit floating point.
(DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
(BFP_SPRINTF): New macro.
---
 libgcc/config/rs6000/_dd_to_kf.c | 37 ++
 libgcc/config/rs6000/_kf_to_dd.c | 37 ++
 libgcc/config/rs6000/_kf_to_sd.c | 37 ++
 libgcc/config/rs6000/_kf_to_td.c | 37 ++
 libgcc/config/rs6000/_sd_to_kf.c | 37 ++
 libgcc/config/rs6000/_sprintfkf.c| 57 
 libgcc/config/rs6000/_sprintfkf.h| 28 ++
 libgcc/config/rs6000/_strtokf.c  | 56 +++
 libgcc/config/rs6000/_strtokf.h  | 27 +
 libgcc/config/rs6000/_td_to_kf.c  

Re: [PATCH, revised] PowerPC: Add float128/Decimal conversions.

[Michael Meissner via Gcc-patches]

[PATCH, revised] PowerPC: Add float128/Decimal conversions.

This patch revises the patch on January 14th.  The only change in this patch
compared to the previous patch is to change the format string for converting
IEEE 128-bit to string.  This allows the c-c++-common/dfp/convert-bfp-6.c test
now passes.

This patch replaces the following three patches:

September 24th, 2020:
Message-ID: <20200924203545.gd31...@ibm-toto.the-meissners.org>

October 22nd, 2020:
Message-ID: <2020100603.ga11...@ibm-toto.the-meissners.org>

January 14th, 2021:
Message-ID: <20210114170936.ga3...@ibm-toto.the-meissners.org>
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563498.html

This patch rewrites those patches.  In order to run with older GLIBC's, this
patch uses weak references to the IEEE 128-bit conversions to/from string that
are found in GLIBC 2.32.

If the user uses GLIBC 2.32 or later, the Decimal <-> Float128 conversions will
call the functions in that library.  This isn't ideal, as IEEE 128-bit has more
exponent range than IBM 128-bit.

If an older library is used, these patches will convert IEEE 128-bit to IBM
128-bit and do the conversion with IBM 128-bit.  I have tested this with a
compiler configured to use an older library, and it worked for the conversion
if the number could be represented in the IBM 128-bit format.

While most of the Decimal <-> Long double tests now pass when long doubles are
IEEE 128-bit, there is one test that fails:

*   c-c++-common/dfp/convert-bfp-11.c

I have patches for the bfp-11 test (which requires that long double be IBM
128-bit).

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

I have also built and tested this patch on a big endian Power8 system with
both 64 and 32-bit targets.  There were no regressions.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works
well.  This patch is required to be able to build a toolchain where the default
long double is IEEE 128-bit.  Can I check this patch into the master branch for
GCC 11?

libgcc/
2021-01-27  Michael Meissner  

* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
* config/rs6000/_kf_to_sd.c: New file.
* config/rs6000/_kf_to_td.c: New file.
* config/rs6000/_sd_to_kf.c: New file.
* config/rs6000/_sprintfkf.c: New file.
* config/rs6000/_sprintfkf.h: New file.
* config/rs6000/_strtokf.h: New file.
* config/rs6000/_strtokf.c: New file.
* config/rs6000/_td_to_kf.c: New file.
* config/rs6000/quad-float128.h: Add new declarations.
* config/rs6000/t-float128 (fp128_dec_funcs): New macro.
(fp128_decstr_funcs): New macro.
(ibm128_dec_funcs): New macro.
(fp128_ppc_funcs): Add the new conversions.
(fp128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(fp128_decstr_objs): Force __float128 <-> string conversions to be
compiled with -mabi=ibmlongdouble.
(ibm128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(FP128_CFLAGS_DECIMAL): New macro.
(IBM128_CFLAGS_DECIMAL): New macro.
* dfp-bit.c (DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
* dfp-bit.h (BFP_KIND): Add new binary floating point kind for
IEEE 128-bit floating point.
(DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
(BFP_SPRINTF): New macro.
---
 libgcc/config/rs6000/_dd_to_kf.c | 37 ++
 libgcc/config/rs6000/_kf_to_dd.c | 37 ++
 libgcc/config/rs6000/_kf_to_sd.c | 37 ++
 libgcc/config/rs6000/_kf_to_td.c | 37 ++
 libgcc/config/rs6000/_sd_to_kf.c | 37 ++
 libgcc/config/rs6000/_sprintfkf.c| 57 
 libgcc/config/rs6000/_sprintfkf.h| 28 ++
 libgcc/config/rs6000/_strtokf.c  | 56 +++
 libgcc/config/rs6000/_strtokf.h  | 27 +
 libgcc/config/rs6000/_td_to_kf.c | 37 ++
 libgcc/config/rs6000/quad-float128.h |  8 
 libgcc/config/rs6000/t-float128  | 37 +-
 libgcc/dfp-bit.c | 12 +-
 libgcc/dfp-bit.h | 26 +
 14 files changed, 470 insertions(+), 3 deletions(-)
 create mode 100644 libgcc/config/rs6000/_dd_to_kf.c
 create mode 100644 

Re: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

[Michael Meissner via Gcc-patches]

On Wed, Jan 27, 2021 at 01:06:46PM -0600, will schmidt wrote:
> On Thu, 2021-01-14 at 11:59 -0500, Michael Meissner via Gcc-patches wrote:
> > From 78435dee177447080434cdc08fc76b1029c7f576 Mon Sep 17 00:00:00 2001
> > From: Michael Meissner 
> > Date: Wed, 13 Jan 2021 21:47:03 -0500
> > Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.
> > 
> > This patch replaces patches previously submitted:
> > 
> > September 24th, 2020:
> > Message-ID: <20200924203159.ga31...@ibm-toto.the-meissners.org>
> > 
> > October 9th, 2020:
> > Message-ID: <20201009043543.ga11...@ibm-toto.the-meissners.org>
> > 
> > October 24th, 2020:
> > Message-ID: <2020100346.ga8...@ibm-toto.the-meissners.org>
> > 
> > November 19th, 2020:
> > Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>
> 
> 
> Subject and date should be sufficient _if_ having the old versions
> of the patchs are necessary to review the latest version of the
> patch.  Which ideally is not the case.
> 
> 
> > 
> > This patch maps the built-in functions that take or return long double
> > arguments on systems where long double is IEEE 128-bit.
> > 
> > If long double is IEEE 128-bit, this patch goes through the built-in 
> > functions
> > and changes the name of the math, scanf, and printf built-in functions to 
> > use
> > the functions that GLIBC provides when long double uses the IEEE 128-bit
> > representation.
> 
> ok.
> 
> > 
> > In addition, changing the name in GCC allows the Fortran compiler to
> > automatically use the correct name.
> 
> Does the fortran compiler currently use the wrong name? (pr?)

Yes.  If the compiler is configured for IBM 128-bit long double, the Fortran
compiler calls 'sinl' for real*16.  If the compiler is configured for IEEE
128-bit long double, the compiler needs to call __sinieee128 instead of sinl.

Similarly if a C or C++ user calls __builtin_sinl directly without including
math.h, the wrong name would be used.

Hence what this code does is change the names of all of the built-in functions
that can use long double to be the names appropriate for IEEE 128-bit.

> > 
> > To map the math functions, typically this patch changes l to
> > __ieee128.  However there are some exceptions that are handled with 
> > this
> > patch.
> 
> This appears to be  the rs6000_mangle_decl_assembler_name() function, which
> also maps l_r to ieee128_r, and looks like some additional special
> handling for printf and scanf.  

Yes, the rs6000_mangle_decl_assembler_name was not complete in the mapping.  In
particular, it did not handle *printf, *scanf, or *l_r calls.  There are also a
few names that need to have a different mapping.

> 
> > To map the printf functions,  is mapped to __ieee128.
> > 
> > To map the scanf functions,  is mapped to __isoc99_ieee128.
> 
> 
> > 
> > I have tested this patch by doing builds, bootstraps, and make check with 3
> > builds on a power9 little endian server:
> > 
> > *   Build one used the default long double being IBM 128-bit;
> > *   Build two set the long double default to IEEE 128-bit; (and)
> > *   Build three set the long double default to 64-bit.
> > 
> 
> ok
> 
> > The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
> > appropriate long double options.
> 
> Presumably the build is otherwise broken... 
> Does that mean more than invoking download_preqrequisites as part of the
> build?   If there are specific options required during configure/build of
> those packages, they should be called out.
> 
> > There were a few differences in the test
> > suite runs that will be addressed in later patches, but over all it works
> > well.
> 
> Presumably minimal. :-)

It depends on what you mean by minimal.

* There are 5 C tests that fail (2 Decimal/IEEE, 3 NaN related)
* 2 C tests that need some changes to be able to run
* There are 2 C++ tests that fail (Decimal/IEEE, same as the C tests)
* There are 31 C++ modules tests that fail (PR 98645)
* There are 3 Fortran tests that used to fail that now pass

I have patches for the Decimal/IEEE tests

> 
> >   This patch is required to be able to build a toolchain where the 
> > default
> > long double is IEEE 128-bit. 
> 
> Ok.   Could lead the patch description with this,.  I imagine this is
> just one of several patches that are still required towrards that goal.

In terms of 'need', this patch and the Decimal patch next are the two patches
that absolutely need to be installed.  The others fix some things and tests,
but are not required.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[Ping] PowerPC: Add float128/Decimal conversions.

[Michael Meissner via Gcc-patches]

I posted this patch on January 14th, 2021:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563498.html

| Date: Thu, 14 Jan 2021 12:09:36 -0500
| Subject: [PATCH] PowerPC: Add float128/Decimal conversions.
| Message-ID: <20210114170936.ga3...@ibm-toto.the-meissners.org>

You had a question about what changed, and I replied:

| In your last message, you said that it was unacceptable that the conversion
| fails if the user uses an old GLIBC.  So I rewrote the code using weak
| references.  If the user has at least GLIBC 2.32, it will use the IEEE 128-bit
| string support in the library.
|
| If an older GLIBC is used, I then use the IBM 128-bit format as an 
intermediate
| value.  Obviously there are cases where IEEE 128-bit can hold values that IBM
| 128-bit can't (mostly due to the increased exponent range in IEEE 128-bit), 
but
| it at least does the conversion for the numbers in the common range.
|
| In doing this transformation, I needed to do minor edits to the main decimal
| to/from binary conversion functions to allow the KF functions to be declared.
| Previously, I used preprocessor magic to rename the functions.

This is the second most important patch in the IEEE 128-bit work.  What do I
need to do to be able to commit the patch?


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[Ping] PowerPC: Map IEEE 128-bit long double built-ins.

[Michael Meissner via Gcc-patches]

Ping https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563496.html

| Date: Thu, 14 Jan 2021 11:59:19 -0500
| Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.
| Message-ID: <20210114165919.ga1...@ibm-toto.the-meissners.org>

As I've said in the past, this is the most important patch of the IEEE 128-bit
patches.  What do I need to do to be able to commit this patch ASAP?  Or what
changes do I need to make?

I posted the patch on January 14th.  You asked what had changed in the patch,
and I replied on the 19th:

| You grumbled about the way I converted the names from the current name to the
| IEEE 128-bit name as being unclear.
|
| 1) I moved the table of known mappings from within a function to a separate
| function, and I populated the switch statement with all of the current names.
|
| 2) I moved the code that looks at a built-in function's arguments and returns
| whether it uses long double to a separate function rather than being buried
| within a larger function.
|
| 3) I changed the code for case we we didn't provide a name (i.e. new 
built-ins)
| to hopefully be clearer on the conversion.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [BACKPORT] Apply fix for PR libgcc/97643 to gcc 10 branch

[Michael Meissner via Gcc-patches]

On Wed, Jan 20, 2021 at 06:46:14PM -0600, Segher Boessenkool wrote:
> On Wed, Jan 20, 2021 at 06:38:37PM -0500, Michael Meissner wrote:
> > This patch takes the fix that was applied to the trunk on December 3rd, and 
> > it
> > applies it to the GCC 10 branch.
> 
> > PR libgcc/97543, PR libgcc/97643
> > Backport from trunk.
> > 
> > 2020-12-03  Michael Meissner  
> > 
> > * config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable.
> > (IBM128_SHARED_OBJS): New make variable.
> > (IBM128_OBJS): New make variable.  Set all objects to use the
> > explicit IBM format, and disable gnu attributes.
> > (IBM128_CFLAGS): New make variable.
> > (gcc_s_compile): Add -mno-gnu-attribute to all shared library
> > modules.
> 
> Okay for 10.  Thanks!
> 
> Is there a reason we do not have that testcase in the testsuite, btw?

In order to test it you need to build a compiler + toolchain where the default
long double is 64-bits.  So it is kind of hard to put in a test for it, since
it was a bug in how libgcc was built with a compiler that defaults to 64-bit
long double.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[BACKPORT] Apply fix for PR libgcc/97643 to gcc 10 branch

[Michael Meissner via Gcc-patches]

PowerPC: Backport fix for libgcc long double support.

This patch takes the fix that was applied to the trunk on December 3rd, and it
applies it to the GCC 10 branch.

I have verified it by building compilers configured for both normal 128-bit IBM
long double and 64-bit long double with/without the patch.  I did make check
and the results were the expected results comparing 128-bit long double to
64-bit long double.

With the patch installed, the test case provided will build and run cleanly
with compilers configured for either 128-bit IBM long double or 64-bit long
double without error.

Without the patch installed, the linker complains about mixing long double
types.

Here is the test case.

#include 
#include 
int
main()
{
  long double a = 2.0;
  __int128 b = 8;
  printf("sizeof(long double) = %ld\n", sizeof(long double));
  printf("a * b = %Lf\n", a * (long double) b);
  return 0;
}

Can I apply this patch to the gcc-10-branch and close out PR 97543?

libgcc/
2021-01-20  Michael Meissner  

PR libgcc/97543, PR libgcc/97643
Backport from trunk.

2020-12-03  Michael Meissner  

* config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable.
(IBM128_SHARED_OBJS): New make variable.
(IBM128_OBJS): New make variable.  Set all objects to use the
explicit IBM format, and disable gnu attributes.
(IBM128_CFLAGS): New make variable.
(gcc_s_compile): Add -mno-gnu-attribute to all shared library
modules.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] PowerPC: Add float128/Decimal conversions.

[Michael Meissner via Gcc-patches]

On Fri, Jan 15, 2021 at 03:52:44PM -0600, Segher Boessenkool wrote:
> On Thu, Jan 14, 2021 at 12:09:36PM -0500, Michael Meissner wrote:
> > [PATCH] PowerPC: Add float128/Decimal conversions.
> 
> Same question here.

In your last message, you said that it was unacceptable that the conversion
fails if the user uses an old GLIBC.  So I rewrote the code using weak
references.  If the user has at least GLIBC 2.32, it will use the IEEE 128-bit
string support in the library.

If an older GLIBC is used, I then use the IBM 128-bit format as an intermediate
value.  Obviously there are cases where IEEE 128-bit can hold values that IBM
128-bit can't (mostly due to the increased exponent range in IEEE 128-bit), but
it at least does the conversion for the numbers in the common range.

In doing this transformation, I needed to do minor edits to the main decimal
to/from binary conversion functions to allow the KF functions to be declared.
Previously, I used preprocessor magic to rename the functions.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

[Michael Meissner via Gcc-patches]

On Fri, Jan 15, 2021 at 03:43:13PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Jan 14, 2021 at 11:59:19AM -0500, Michael Meissner wrote:
> > >From 78435dee177447080434cdc08fc76b1029c7f576 Mon Sep 17 00:00:00 2001
> > From: Michael Meissner 
> > Date: Wed, 13 Jan 2021 21:47:03 -0500
> > Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.
> > 
> > This patch replaces patches previously submitted:
> 
> What did you change after I approved it?

You grumbled about the way I converted the names from the current name to the
IEEE 128-bit name as being unclear.

1) I moved the table of known mappings from within a function to a separate
function, and I populated the switch statement with all of the current names.

2) I moved the code that looks at a built-in function's arguments and returns
whether it uses long double to a separate function rather than being buried
within a larger function.

3) I changed the code for case we we didn't provide a name (i.e. new built-ins)
to hopefully be clearer on the conversion.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move.

[Michael Meissner via Gcc-patches]

[PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move.

This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max.  Unlike the previous patch, I
decided to keep two separate patterns for fpmask before splitting (one pattern
for normal compares, and the other pattern for inverted compares).  I can go
back to a single pattern with a new predicate that allows either comparison.

Compared to the original code, these patterns do simplify the fpmask insns to
having one alternative instead of two.  In the original code, the first
alternative tried to use the result as a temporary register.  But that doesn't
work if you are doing a conditional move with SF/DF types, but the comparison
is KF/TF.  That is because the SF/DF types can use the traditional FPR
registers, but IEEE 128-bit floating point can only do arithmetic in the
traditional Altivec registers.

This code also has to insert a XXPERMDI if you are moving KF/TF values, but
the comparison is done with SF/DF values.  In this case, the set and compare
mask for SF/DF clears the bottom 64-bits of the register, and the XXPERMDI is
needed to fill it.

I have tested this on little endian power9 servers, and there were no
regressions.  I have also done unit tests on power10 hardware and the code
generates the min/max instructions.  Can I check this into the master branch?

gcc/
2021-01-14 Michael Meissner  

* config/rs6000/rs6000.c (have_compare_and_set_mask): Add IEEE
128-bit floating point types.
* config/rs6000/rs6000.md (FPMASK): New iterator.
(FPMASK2): New iterator.
(Fv mode attribute): Add KFmode and TFmode.
(movcc_fpmask): Replace
movcc_p9.  Add IEEE 128-bit fp support.
(movcc_invert_fpmask): Replace
movcc_invert_p9.  Add IEEE 128-bit fp
support.
(fpmask): Add IEEE 128-bit fp support.  Enable generator to
build te RTL.
(xxsel): Add IEEE 128-bit fp support.  Enable generator to
build te RTL.

gcc/testsuite/
2021-01-14  Michael Meissner  

* gcc.target/powerpc/float128-cmove.c: New test.
* gcc.target/powerpc/float128-minmax-3.c: New test.
---
 gcc/config/rs6000/rs6000.c|   8 +-
 gcc/config/rs6000/rs6000.md   | 188 --
 .../gcc.target/powerpc/float128-cmove.c   |  93 +
 .../gcc.target/powerpc/float128-minmax-3.c|  15 ++
 4 files changed, 237 insertions(+), 67 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-cmove.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-minmax-3.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 08b407030a3..47a56912e27 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15337,8 +15337,8 @@ rs6000_emit_vector_cond_expr (rtx dest, rtx op_true, 
rtx op_false,
   return 1;
 }
 
-/* Possibly emit the xsmaxcdp and xsmincdp instructions to emit a maximum or
-   minimum with "C" semantics.
+/* Possibly emit the xsmaxc{dp,qp} and xsminc{dp,qp} instructions to emit a
+   maximum or minimum with "C" semantics.
 
Unless you use -ffast-math, you can't use these instructions to replace
conditions that implicitly reverse the condition because the comparison
@@ -15474,6 +15474,10 @@ have_compare_and_set_mask (machine_mode mode)
 case E_DFmode:
   return TARGET_P9_MINMAX;
 
+case E_KFmode:
+case E_TFmode:
+  return FLOAT128_MIN_MAX_FPMASK_P (mode);
+
 default:
   break;
 }
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 45be9c381bc..d658b45ee3a 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -564,6 +564,19 @@ (define_mode_iterator SFDF [SF DF])
 ; And again, for when we need two FP modes in a pattern.
 (define_mode_iterator SFDF2 [SF DF])
 
+; Floating scalars that supports the set compare mask instruction.
+(define_mode_iterator FPMASK [SF
+ DF
+ (KF "FLOAT128_MIN_MAX_FPMASK_P (KFmode)")
+ (TF "FLOAT128_MIN_MAX_FPMASK_P (TFmode)")])
+
+; And again, for patterns that need two (potentially) different floating point
+; scalars that support the set compare mask instruction.
+(define_mode_iterator FPMASK2 [SF
+  DF
+  (KF "FLOAT128_MIN_MAX_FPMASK_P (KFmode)")
+  (TF "FLOAT128_MIN_MAX_FPMASK_P (TFmode)")])
+
 ; A generic s/d attribute, for sp/dp for example.
 (define_mode_attr sd [(SF   "s") (DF   "d")
  (V4SF "s") (V2DF "d")])
@@ -597,8 +610,13 @@ (define_mode_attr Ff   [(SF "f") (DF "d") (DI 
"d")])
 ; SF/DF constraint for arithmetic on VSX registers using instructions added in
 ; ISA 2.06 (power7).  This includes instructions that normally target DF mode,
 ; but are used on SFmode, since internally 

[PATCH 1/2] Power10: Add IEEE 128-bit min/max support.

[Michael Meissner via Gcc-patches]

[PATCH 1/2] Power10: Add IEEE 128-bit min/max support.

This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions.  The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.

Rather than trying to overload the current SF/DF min/max support, it was
simpler to just provide the new instructions as a separate insn.

I have tested this on little endian power9 servers, and there were no
regressions.  I have also done unit tests on power10 hardware and the code
generates the min/max instructions.  Can I check this into the master branch?

gcc/
2021-01-14  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_emit_minmax): Add support for ISA
3.1 IEEE 128-bit floating point xsmaxcqp and xsmincqp instructions.
* config/rs6000/rs6.h (FLOAT128_MIN_MAX_FPMASK_P): New macro.
* config/rs6000/rs6000.md (s3): Add support for the
ISA 3.1 IEEE 128-bit minimum and maximum instructions.

gcc/testsuite/
2021-01-14  Michael Meissner  

* gcc.target/powerpc/float128-minmax-2.c: New test.
---
 gcc/config/rs6000/rs6000.c|  3 ++-
 gcc/config/rs6000/rs6000.h|  5 +
 gcc/config/rs6000/rs6000.md   | 11 +++
 .../gcc.target/powerpc/float128-minmax-2.c| 15 +++
 4 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index b9e90ae0468..08b407030a3 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15742,7 +15742,8 @@ rs6000_emit_minmax (rtx dest, enum rtx_code code, rtx 
op0, rtx op1)
   /* VSX/altivec have direct min/max insns.  */
   if ((code == SMAX || code == SMIN)
   && (VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)
- || (mode == SFmode && VECTOR_UNIT_VSX_P (DFmode
+ || (mode == SFmode && VECTOR_UNIT_VSX_P (DFmode))
+ || FLOAT128_MIN_MAX_FPMASK_P (mode)))
 {
   emit_insn (gen_rtx_SET (dest, gen_rtx_fmt_ee (code, mode, op0, op1)));
   return;
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index b05dd827b13..1ff07345a93 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -345,6 +345,11 @@ extern const char *host_detect_local_cpu (int argc, const 
char **argv);
|| ((MODE) == TDmode)   \
|| (!TARGET_FLOAT128_TYPE && FLOAT128_IEEE_P (MODE)))
 
+/* Macro whether the float128 minimum, maximum, and set compare mask
+   instructions are enabled.  */
+#define FLOAT128_MIN_MAX_FPMASK_P(MODE)
\
+  (TARGET_POWER10 && TARGET_FLOAT128_HW && FLOAT128_IEEE_P (MODE))
+
 /* Return true for floating point that does not use a vector register.  */
 #define SCALAR_FLOAT_MODE_NOT_VECTOR_P(MODE)   \
   (SCALAR_FLOAT_MODE_P (MODE) && !FLOAT128_VECTOR_P (MODE))
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index bb9fb42f82a..45be9c381bc 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -5163,6 +5163,17 @@ (define_insn "*s3_vsx"
 }
   [(set_attr "type" "fp")])
 
+;; Min/max for ISA 3.1 IEEE 128-bit floating point
+(define_insn "s3"
+  [(set (match_operand:IEEE128 0 "altivec_register_operand" "=v")
+   (fp_minmax:IEEE128
+(match_operand:IEEE128 1 "altivec_register_operand" "v")
+(match_operand:IEEE128 2 "altivec_register_operand" "v")))]
+  "TARGET_POWER10"
+  "xscqp %0,%1,%2"
+  [(set_attr "type" "vecfloat")
+   (set_attr "size" "128")])
+
 ;; The conditional move instructions allow us to perform max and min operations
 ;; even when we don't have the appropriate max/min instruction using the FSEL
 ;; instruction.
diff --git a/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c 
b/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c
new file mode 100644
index 000..c71ba08c9f8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c
@@ -0,0 +1,15 @@
+/* { dg-require-effective-target ppc_float128_hw } */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-mdejagnu-cpu=power10 -O2 -ffast-math" } */
+
+#ifndef TYPE
+#define TYPE _Float128
+#endif
+
+/* Test that the fminf128/fmaxf128 functions generate if/then/else and not a
+   call.  */
+TYPE f128_min (TYPE a, TYPE b) { return __builtin_fminf128 (a, b); }
+TYPE f128_max (TYPE a, TYPE b) { return __builtin_fmaxf128 (a, b); }
+
+/* { dg-final { scan-assembler {\mxsmaxcqp\M} } } */
+/* { dg-final { scan-assembler {\mxsmincqp\M} } } */
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 0/2] PowerPC: Add power10 IEEE 128-bit min/max/cmove

[Michael Meissner via Gcc-patches]

These patches have been kicking around for awhile, and I really would like to
get them in.  They aren't as important as the other float128 patches I've
submitted today, since many of those patches are designed to allow switching
the long double format to IEEE 128-bit, which we need in GCC 11.

I have rewritten these patches based on the last review.  Hopefully I have made
them simpler.

The first patch adds the basic min/max insns.  Originally I tried to overload
min/max insns, but it was rather clunky because of the different rules for
DF/SF min/max insns vs. KF/TF insns.  Now, I just create separate min/max
patterns for IEEE 128-bit.

The second patch enables conditional move.  Because the conditional move is
based on using XXSEL, you can have one of the 4 floating point types being
compared and do a conditional move with another floating point type.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 3/3] PowerPC: Force IBM long double for conversion test.

[Michael Meissner via Gcc-patches]

[PATCH 3/3] PowerPC: Force IBM long double for conversion test.

The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use
the IBM 128-bit extended double format.  In particular, some of the tests
expect an infinity to be created if decimal values that are converted that are
too large for IBM extended double.  However, the numbers do fit in the range
for IEEE 128-bit format, since it has a larger exponent than the IBM 128-bit
format.  The test fails because an infinity is not generated.

This patch explicitly sets the long double type to IBM extended double.

I have run tests on a little endian power9 system with 3 compilers:
*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu set.

Can I check this patch into the master branch?

gcc/testsuite/
2021-01-14  Michael Meissner  

* c-c++-common/dfp/convert-bfp-11.c: Force using IBM 128-bit long
double.  Remove check for 64-bit long double.
---
 .../c-c++-common/dfp/convert-bfp-11.c  | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c 
b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
index 95c433d2c24..35da07d1fa4 100644
--- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
+++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
@@ -1,9 +1,14 @@
-/* { dg-skip-if "" { ! "powerpc*-*-linux*" } } */
+/* { dg-require-effective-target dfp } */
+/* { dg-require-effective-target ppc_long_double_override_ibm128 } */
+/* { dg-add-options ppc_long_double_override_ibm128 } */
 
-/* Test decimal float conversions to and from IBM 128-bit long double. 
-   Checks are skipped at runtime if long double is not 128 bits.
-   Don't force 128-bit long doubles because runtime support depends
-   on glibc.  */
+/* We force the long double type to be IBM 128-bit because the CONVERT_TO_PINF
+   tests will fail if we use IEEE 128-bit floating point.  This is due to IEEE
+   128-bit having a larger exponent range than IBM 128-bit extended double.  So
+   tests that would generate an infinity with IBM 128-bit will generate a
+   normal number with IEEE 128-bit.  */
+
+/* Test decimal float conversions to and from IBM 128-bit long double.   */
 
 #include "convert.h"
 
@@ -36,9 +41,6 @@ CONVERT_TO_PINF (312, tf, sd, 1.6e+308L, d32)
 int
 main ()
 {
-  if (sizeof (long double) != 16)
-return 0;
-
   convert_101 ();
   convert_102 ();
 
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 2/3] PowerPC: PR target/70117, Force long double to be IBM 128-bit.

[Michael Meissner via Gcc-patches]

[PATCH 2/3] PowerPC: PR target/70117, Force long double to be IBM 128-bit.

This patch fixes the pr70117 test to use IBM 128-bit long double.

I have run tests on a little endian power9 system with 3 compilers:
*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu set.

Can I check this patch into the master branch?

gcc/testsuite/
2021-01-14  Michael Meissner  

PR target/70117
* gcc.target/powerpc/pr70117.c: Force the long double type to use
the IBM 128-bit format.
---
 gcc/testsuite/gcc.target/powerpc/pr70117.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
b/gcc/testsuite/gcc.target/powerpc/pr70117.c
index 3bbd2c595e0..8a5fad1dee0 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
@@ -1,5 +1,7 @@
-/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* powerpc*-*-aix* 
rs6000-*-* } } } */
-/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
+/* { dg-do run } */
+/* { dg-require-effective-target ppc_long_double_override_ibm128 } */
+/* { dg-options "-std=c99 -O2" } */
+/* { dg-add-options ppc_long_double_override_ibm128 } */
 
 #include 
 
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 1/3] PowerPC: Add long double target-supports.

[Michael Meissner via Gcc-patches]

[PATCH 1/3] PowerPC: Add long double target-supports.

This patch add several more selections to target-supports.exp:

*   3 selections for the current long double format;
*   3 selections if we can change the long double format to a particular
value.
*   3 functions to return the options needed to switch the long double
format for use with dg-add-options.

I have run tests on a little endian power9 system with 3 compilers:
*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu set.

Can I check this patch into the master branch?

gcc/testsuite/
2021-01-14  Michael Meissner  

* lib/target-supports.exp
(check_effective_target_ppc_long_double_ibm128): New function.
(check_effective_target_ppc_long_double_ieee128): New function.
(check_effective_target_ppc_long_double_64bit): New function.
(add_options_for_ppc_long_double_override_ibm128): New function.
(check_effective_target_ppc_long_double_override_ibm128): New
function.
(add_options_for_ppc_long_double_override_ieee128): New function.
(check_effective_target_ppc_long_double_override_ieee128): New
function.
(add_options_for_ppc_long_double_override_64bit): New function.
(check_effective_target_ppc_long_double_override_64bit): New
function.
---
 gcc/testsuite/lib/target-supports.exp | 155 ++
 1 file changed, 155 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 47d4c45e9eb..2badb495adc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2354,6 +2354,161 @@ proc check_effective_target_ppc_ieee128_ok { } {
 }]
 }
 
+# See if the target is a powerpc with the long double format that uses the IBM
+# extended double format.
+
+proc check_effective_target_ppc_long_double_ibm128 { } {
+return [check_cached_effective_target ppc_long_double_ibm {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that uses the IEEE
+# 128-bit format.
+
+proc check_effective_target_ppc_long_double_ieee128 { } {
+return [check_cached_effective_target ppc_long_double_ieee {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IEEE128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that is 64-bit.
+
+proc check_effective_target_ppc_long_double_64bit { } {
+return [check_cached_effective_target ppc_long_double_64bit {
+   int main()
+   {
+ #ifndef _ARCH_PPC
+   return 1;
+ #else
+   return sizeof (long double) != 8;
+ #endif
+   }
+}]
+}
+
+# Like check_effective_target_ppc_long_double_ibm128, but check if we can
+# explicitly override the long double format to use the IBM 128-bit extended
+# double format, and GLIBC supports doing this override by switching the
+# sprintf to handle long double.
+
+proc add_options_for_ppc_long_double_override_ibm128 { flags } {
+if { [istarget powerpc*-*-*] } {
+   return "$flags -mlong-double-128 -Wno-psabi -mabi=ibmlongdouble"
+}
+return "$flags"
+}
+
+proc check_effective_target_ppc_long_double_override_ibm128 { } {
+return [check_runtime_nocache ppc_long_double_ovveride_ibm128 {
+   #include 
+   #include 
+   volatile __ibm128 a = (__ibm128) 3.0;
+   volatile long double one = 1.0L;
+   volatile long double two = 2.0L;
+   volatile long double b;
+   char buffer[20];
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   b = one + two;
+   if (memcmp ((void *), (void *), sizeof (long double)) != 0)
+ return 1;
+   sprintf (buffer, "%lg", b);
+   return strcmp (buffer, "3") != 0;
+ #endif
+   }
+} [add_options_for_ppc_long_double_override_ibm128 ""]]
+}
+
+# Like check_effective_target_ppc_long_double_ieee, but check if we can
+# explicitly override the long double format to use the IEEE 128-bit format,
+# and GLIBC supports doing this override by switching the sprintf to handle
+# long double.
+
+proc add_options_for_ppc_long_double_override_ieee128 { flags } {
+if { [istarget powerpc*-*-*] } {
+   return "$flags -mlong-double-128 -Wno-psabi -mabi=ieeelongdouble"
+}
+return "$flags"
+}
+
+proc 

[PATCH 0/3] PowerPC: Fix up tests for IEEE 128-bit long double

[Michael Meissner via Gcc-patches]

In November, I submitted a patch to fix up some of the tests for when IEEE
128-bit is used as the long double format.  Segher had some suggestions.  These
patches are based on those suggestions:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559836.html

These patches add several more selections to target-supports.exp:

*   3 selections for the current long double format;
*   3 selections if we can change the long double format to a particular
value.
*   3 functions to return the options needed to switch the long double
format for use with dg-add-options.

And there are the 2 tests (pr70117, convert-bfp-11.c) that need to be
configured run with IBM 128-bit long double because the test itself was written
knowing about the format of IBM 128-bit floating point.

I have run tests on a little endian power9 system with 3 compilers:
*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu set.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 2/2] PowerPC: Use __builtin_pack_ibm128 instead of __builtin_pack_longdouble.

[Michael Meissner via Gcc-patches]

[PATCH 2/2] PowerPC: Use __builtin_pack_ibm128 instead of 
__builtin_pack_longdouble.

In the patch submitted on October 22nd, 2020:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556869.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557529.html

Segher suggested that rather than add #ifdef code in libgcc's ibm-ldouble.c to
use __builtin_pack_ibm128 instead of __builtin_pack_longdouble, that I should
instead make __ibm128 available in targets that have 128-bit IBM long double,
but don't support __float128/_Float128.

This patch fixes the libgcc library to use __builtin_pack_ibm128 all of
the time.


I have tested these patches on a little endian power9 server system and there
were no regressions.  I have also tested the paches on a big endian power8
server system and there were no regressions.  On the big endian system, I have
built both compilers with power8 being the default cpu and power5 being the
default cpu.  I have verified that ibm-ldouble does use the ibm128 pack
built-in function.  Can i check this patch into the master branch once the
previous patch has been commited?

libgcc/
2021-01-13  Michael Meissner  

* config/rs6000/ibm-ldouble.c (pack_ldouble): Use
__builtin_pack_ibm128 instead of __builtin_pack_longdouble.
---
 libgcc/config/rs6000/ibm-ldouble.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libgcc/config/rs6000/ibm-ldouble.c 
b/libgcc/config/rs6000/ibm-ldouble.c
index 4c13453f975..92b4b4c583d 100644
--- a/libgcc/config/rs6000/ibm-ldouble.c
+++ b/libgcc/config/rs6000/ibm-ldouble.c
@@ -102,9 +102,9 @@ __asm__ (".symver __gcc_qadd,_xlqadd@GCC_3.4\n\t"
 static inline IBM128_TYPE
 pack_ldouble (double dh, double dl)
 {
-#if defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IBM128__)  \
+#if defined (__LONG_DOUBLE_128__)  \
 && !(defined (_SOFT_FLOAT) || defined (__NO_FPRS__))
-  return __builtin_pack_longdouble (dh, dl);
+  return __builtin_pack_ibm128 (dh, dl);
 #else
   union
   {
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 1/2] PowerPC: Allow __ibm128 on older systems.

[Michael Meissner via Gcc-patches]

[PATCH 1/2] PowerPC: Allow __ibm128 on older systems.

In the patch submitted on October 22nd, 2020:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556869.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557529.html

Segher suggested that rather than add #ifdef code in libgcc's ibm-ldouble.c to
use __builtin_pack_ibm128 instead of __builtin_pack_longdouble, that I should
instead make __ibm128 available in targets that have 128-bit IBM long double,
but don't support __float128/_Float128.

This patch fixes the compiler to allow __ibm128 on older systems, and it
adjusts the two ibm128 built-in functions to accomidate this change.  The next
patch will be to change libgcc/ibm-ldouble.c to always use the
__builtin_pack_ibm128 function.


I have tested these patches on a little endian power9 server system and there
were no regressions.  I have also tested the paches on a big endian power8
server system and there were no regressions.  On the big endian system, I have
built both compilers with power8 being the default cpu and power5 being the
default cpu.  Can I check this patch into the master branch?

gcc/
2021-01-13  Michael Meissner  

* config/rs6000/rs6000-builtin.def (BU_IBM128_2): Rename
RS6000_BTM_IBM128 from RS6000_BTM_FLOAT128.
* config/rs6000/rs6000-call.c (rs6000_invalid_builtin): Update
error message for __ibm128 built-in functions.
(rs6000_init_builtins): Create the __ibm128 keyword on older
systems where long double uses the IBM extended double format,
even if they don't support IEEE 128-bit floating point.
* config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Rename
RS6000_BTM_IBM128 from RS6000_BTM_FLOAT128.
(rs6000_builtin_mask_names): Rename RS6000_BTM_IBM128 from
RS6000_BTM_FLOAT128.
* config/rs6000/rs6000.h (TARGET_IBM128): New macro.
(RS6000_BTM_IBM128): Rename from RS6000_BTM_FLOAT128.
(RS6000_BTM_COMMON): Rename RS6000_BTM_IBM128 from
RS6000_BTM_FLOAT128.
---
 gcc/config/rs6000/rs6000-builtin.def |  5 ++---
 gcc/config/rs6000/rs6000-call.c  | 14 ++
 gcc/config/rs6000/rs6000.c   |  4 ++--
 gcc/config/rs6000/rs6000.h   | 12 +---
 4 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 8aa31ad0a06..1bf76eedadf 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -728,13 +728,12 @@
 | RS6000_BTC_BINARY),  \
CODE_FOR_ ## ICODE) /* ICODE */
 
-/* 128-bit __ibm128 floating point builtins (use -mfloat128 to indicate that
-   __ibm128 is available).  */
+/* 128-bit __ibm128 floating point builtins.  */
 #define BU_IBM128_2(ENUM, NAME, ATTR, ICODE)   \
   RS6000_BUILTIN_2 (MISC_BUILTIN_ ## ENUM, /* ENUM */  \
"__builtin_" NAME,  /* NAME */  \
(RS6000_BTM_HARD_FLOAT  /* MASK */  \
-| RS6000_BTM_FLOAT128),\
+| RS6000_BTM_IBM128),  \
(RS6000_BTC_ ## ATTR/* ATTR */  \
 | RS6000_BTC_BINARY),  \
CODE_FOR_ ## ICODE) /* ICODE */
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 519313bc0d6..5e58bea7e7a 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -11485,8 +11485,8 @@ rs6000_invalid_builtin (enum rs6000_builtins fncode)
 error ("%qs requires the %qs option", name, "-mhard-float");
   else if ((fnmask & RS6000_BTM_FLOAT128_HW) != 0)
 error ("%qs requires ISA 3.0 IEEE 128-bit floating point", name);
-  else if ((fnmask & RS6000_BTM_FLOAT128) != 0)
-error ("%qs requires the %qs option", name, "%<-mfloat128%>");
+  else if ((fnmask & RS6000_BTM_IBM128) != 0)
+error ("%qs requires the IBM 128-bit floating point", name);
   else if ((fnmask & (RS6000_BTM_POPCNTD | RS6000_BTM_POWERPC64))
   == (RS6000_BTM_POPCNTD | RS6000_BTM_POWERPC64))
 error ("%qs requires the %qs (or newer), and %qs or %qs options",
@@ -13181,7 +13181,7 @@ rs6000_init_builtins (void)
  For IEEE 128-bit floating point, always create the type __ieee128.  If the
  user used -mfloat128, rs6000-c.c will create a define from __float128 to
  __ieee128.  */
-  if (TARGET_FLOAT128_TYPE)
+  if (TARGET_IBM128)
 {
   if (!TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128)
ibm128_float_type_node = long_double_type_node;
@@ -13195,7 +13195,13 @@ rs6000_init_builtins (void)
 
   lang_hooks.types.register_builtin_type (ibm128_float_type_node,
  "__ibm128");
+}
+
+ 

[PATCH 0/2] PowerPC: Add __ibm128 to PowerPC targets without float128 support

[Michael Meissner via Gcc-patches]

In the patch submitted on October 22nd, 2020:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556869.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557529.html

Segher suggested that rather than add #ifdef code in libgcc's ibm-ldouble.c to
use __builtin_pack_ibm128 instead of __builtin_pack_longdouble, that I should
instead make __ibm128 available in targets that have 128-bit IBM long double,
but don't support __float128/_Float128.

These two patches add this support.  The first patch adds __ibm128 to those
systems that don't support __float128/_Float128 and have 128-bit IBM long
double.  The second patch changes the libgcc ibm-ldouble.c function to use
__builtin_pack_ibm128 insted of __builtin_pack_longdouble.

I have tested these patches on a little endian power9 server system and there
were no regressions.  I have also tested the paches on a big endian power8
server system and there were no regressions.  On the big endian system, I have
built both compilers with power8 being the default cpu and power5 being the
default cpu.  I have verified that ibm-ldouble does use the ibm128 pack
built-in function.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 2/2] PowerPC: PR 97791: Do not set gnu attributes on moves

[Michael Meissner via Gcc-patches]

>From 84ae44abc7a79b9c2e6d9f18a30516d3e8f65b1f Mon Sep 17 00:00:00 2001
From: Michael Meissner 
Date: Wed, 13 Jan 2021 21:45:20 -0500
Subject: [PATCH 2/2] PowerPC: PR 97791: Do not set gnu attributes on moves

This patch eliminates the code in rs6000_emit_move to set the long double
attribute.  This eliminates the false positives that occur when a type uses a
mode that is the same mode as the long double type.  However, to catch the
cases where long double is used without being passed or returned, we would need
to implement a GIMPLE pass that looked for explicit long double usage.

This patch also changes the the 3 tests that tested this move support to be
'XFAIL' until we flag long double usage correctly.

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works well.
This patch is highly desirable to be able to build a toolchain where the
default long double is IEEE 128-bit.  Can I check this patch into the master
branch for GCC 11?

gcc/
2021-01-14  Michael Meissner  

PR gcc/97791
* config/rs6000/rs6000.c (rs6000_emit_move): Delete code that sets
whether long double was passed based on the modes used in moves.

gcc/testsuite/
2021-01-14  Michael Meissner  

PR target/97791
* gcc.target/powerpc/gnuattr1.c: Mark as XFAIL.
* gcc.target/powerpc/gnuattr2.c: Mark as XFAIL.
* gcc.target/powerpc/gnuattr3.c: Mark as XFAIL.
---
 gcc/config/rs6000/rs6000.c  | 17 -
 gcc/testsuite/gcc.target/powerpc/gnuattr1.c |  9 +++--
 gcc/testsuite/gcc.target/powerpc/gnuattr2.c |  9 +++--
 gcc/testsuite/gcc.target/powerpc/gnuattr3.c |  9 +++--
 4 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 47a56912e27..6f48dd6566d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -10077,23 +10077,6 @@ rs6000_emit_move (rtx dest, rtx source, machine_mode 
mode)
   && GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT)
 gcc_unreachable ();
 
-#ifdef HAVE_AS_GNU_ATTRIBUTE
-  /* If we use a long double type, set the flags in .gnu_attribute that say
- what the long double type is.  This is to allow the linker's warning
- message for the wrong long double to be useful, even if the function does
- not do a call (for example, doing a 128-bit add on power9 if the long
- double type is IEEE 128-bit.  Do not set this if __ibm128 or __floa128 are
- used if they aren't the default long dobule type.  */
-  if (rs6000_gnu_attr && (HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT))
-{
-  if (TARGET_LONG_DOUBLE_128 && (mode == TFmode || mode == TCmode))
-   rs6000_passes_float = rs6000_passes_long_double = true;
-
-  else if (!TARGET_LONG_DOUBLE_128 && (mode == DFmode || mode == DCmode))
-   rs6000_passes_float = rs6000_passes_long_double = true;
-}
-#endif
-
   /* See if we need to special case SImode/SFmode SUBREG moves.  */
   if ((mode == SImode || mode == SFmode) && SUBREG_P (source)
   && rs6000_emit_move_si_sf_subreg (dest, source, mode))
diff --git a/gcc/testsuite/gcc.target/powerpc/gnuattr1.c 
b/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
index cf46777849a..9c7680aabae 100644
--- a/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
+++ b/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
@@ -1,11 +1,16 @@
 /* { dg-do compile { target { powerpc*-linux-* } } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-O2 -mvsx -mlong-double-64" } */
-/* { dg-final { scan-assembler "gnu_attribute 4, 9" } } */
+/* { dg-final { scan-assembler "gnu_attribute 4, 9" {xfail *-*-*} } } */
 
 /* Check that if we can do the long double operation without doing an emulator
call, such as with 64-bit long double support, that we still set the
-   appropriate .gnu_attribute.  */
+   appropriate .gnu_attribute.
+
+   However, the code that did this in rs6000_emit_move has been removed because
+   it could not differentiate between long double and another type that uses
+   the same mode.  This test is marked as xfail until a gimple pass is added to
+   track the use of long double types.  */
 
 long double a;
 
diff --git a/gcc/testsuite/gcc.target/powerpc/gnuattr2.c 
b/gcc/testsuite/gcc.target/powerpc/gnuattr2.c
index 32a4ba255a8..4ca60d63261 100644
--- a/gcc/testsuite/gcc.target/powerpc/gnuattr2.c
+++ b/gcc/testsuite/gcc.target/powerpc/gnuattr2.c
@@ -1,13 +1,18 @@
 /* { dg-do compile { target { powerpc*-linux-* && lp64 } } } */
 /* 

[PATCH 1/2] PowerPC: PR 97791: Fix an issue with gnu attributes.

[Michael Meissner via Gcc-patches]

[PATCH 1/2] PowerPC: PR 97791: Fix an issue with gnu attributes.

This patch patch fixes the problem that we set the GNU attribute for long
double if a type were passed or returned that uses the same representation as
the long double type (i.e. passing explicit __float128/_Float128 when long
double is IEEE 128-bit or passing __ibm128 when long double is IBM 128-bit).

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works well.
This patch is highly desirable to be able to build a toolchain where the
default long double is IEEE 128-bit.  Can I check this patch into the master
branch for GCC 11?

gcc/
2021-01-14  Michael Meissner  
Alan Modra  

PR gcc/97791
* config/rs6000/rs6000-call.c (init_cumulative_args): Only set
that long double was returned if the type is actually long
double.
(rs6000_function_arg_advance_1): Only set that long double was
passed if the type is actually long double.
---
 gcc/config/rs6000/rs6000-call.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 2308cc8b4a2..519313bc0d6 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -6554,12 +6554,14 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, tree fntype,
  if (SCALAR_FLOAT_MODE_P (return_mode))
{
  rs6000_passes_float = true;
+
+ /* If GNU attributes are enabled, mark if the function returns
+long double.  We do not mark if the function returns a type
+such as __ibm128 that uses the same modes as the current long
+double type, only if an actual long double type was used.  */
  if ((HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT)
- && (FLOAT128_IBM_P (return_mode)
- || FLOAT128_IEEE_P (return_mode)
- || (return_type != NULL
- && (TYPE_MAIN_VARIANT (return_type)
- == long_double_type_node
+ && return_type != NULL
+ && TYPE_MAIN_VARIANT (return_type) == long_double_type_node)
rs6000_passes_long_double = true;
 
  /* Note if we passed or return a IEEE 128-bit type.  We changed
@@ -6994,11 +6996,14 @@ rs6000_function_arg_advance_1 (CUMULATIVE_ARGS *cum, 
machine_mode mode,
   if (SCALAR_FLOAT_MODE_P (mode))
{
  rs6000_passes_float = true;
+
+ /* If GNU attributes are enabled, mark if the function passes long
+double.  We do not mark if the function returns a type such as
+__ibm128 that uses the same modes as the current long double type,
+only if an actual long double type was used.  */
  if ((HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT)
- && (FLOAT128_IBM_P (mode)
- || FLOAT128_IEEE_P (mode)
- || (type != NULL
- && TYPE_MAIN_VARIANT (type) == long_double_type_node)))
+ && type != NULL
+ && TYPE_MAIN_VARIANT (type) == long_double_type_node)
rs6000_passes_long_double = true;
 
  /* Note if we passed or return a IEEE 128-bit type.  We changed the
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 0/2] PowerPC: PR 97791: Fix attribute problems

[Michael Meissner via Gcc-patches]

There are many issues with the current implementation of GNU attributes to mark
functions that use long double.  The idea of .gnu_attributes was to mark
objects with ABI requirements.

The two patches in this thread fixes a small subset of the GNU attributes
problems.  It does not fix all of the problems.

The first patch fixes the problem that we set the GNU attribute for long double
if a type were passed or returned that uses the same representation as the long
double type (i.e. passing explicit __float128/_Float128 when long double is
IEEE 128-bit or passing __ibm128 when long double is IBM 128-bit).

The second patch eliminates the code in rs6000_emit_move to set the long double
attribute.  This eliminates the false positives that occur when a type uses a
mode that is the same mode as the long double type.  However, to catch the
cases where long double is used without being passed or returned, we would need
to implement a GIMPLE pass that looked for explicit long double usage.

This patch also changes the the 3 tests that tested this move support to be
'XFAIL' until we flag long double usage correctly.

The current problems with GNU attributes are:

1) Probably the most annoying bug is that they apply at an object level.
   So for example libgcc_s.so.1 is marked as using IBM long double causing
   warnings when linking against code that uses 64-bit long doubles even
   though such code won't use any of the libgcc 128-bit long double
   functions.

   a) Versions of ld prior to 2.35 did not check shared library
  .gnu_attributes, a bug that might allow a user to link a
  soft-float shared library with hard-float code.

2) The original implementation Alan Modra wrote in 2016 to mark relocatable
   object files with attributes had, and still has, bugs.

   a) It is possible for an object to be marked as using IBM long
  double when a function has a long double parameter that is not
  used.

   b) It is possible for an object to not be marked as using IBM long
  double when it does.  For example, a function with a pointer to
  long double parameter is not recognized as using long double.
  This is conceptually difficult to fix.  Does merely passing a
  pointer to another function constitute a use?  What about a
  pointer to a union containing a long double?

   c) An object that defines a global long double variables is not
  marked.

   d) Variable argument functions that process a long double in an
  argument corresponding to the ellipsis are not marked.

3) One of the problems with GNU attributes is that it would signal a long
   double was used when in reality an alternate type was returned or passed,
   such as passing __ibm128 or __float128 that just happens to use the same
   representation as the current long double type.  This is the bug being fixed
   in this patch.

4) In an attempt to fix some of these problems, Mike Meissner applied a patch
   to rs6000_emit_move that set the long double attribute whenever a move to or
   from a register involved a long double mode, but that has bugs too.

   a) With -mlong-double-64 an object that moves doubles to or from a
  register would by marked as using 64-bit long double.

   b) Functions that only use long double internally would wrongly
  cause their object to be marked with the long double attribute.

   c) 2c is not fixed by this patch, unless code in the object uses
  the global variable.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] PowerPC: Add float128/Decimal conversions.

[Michael Meissner via Gcc-patches]

[PATCH] PowerPC: Add float128/Decimal conversions.

This patch replaces the following two patches:

September 24th, 2020:
Message-ID: <20200924203545.gd31...@ibm-toto.the-meissners.org>

October 22nd, 2020:
Message-ID: <2020100603.ga11...@ibm-toto.the-meissners.org>

This patch rewrites those patches.  In order to run with older GLIBC's, this
patch uses weak references to the IEEE 128-bit conversions to/from string that
are found in GLIBC 2.32.

If the user uses GLIBC 2.32 or later, the Decimal <-> Float128 conversions will
call the functions in that library.  This isn't ideal, as IEEE 128-bit has more
exponent range than IBM 128-bit.

If an older library is used, these patches will convert IEEE 128-bit to IBM
128-bit and do the conversion with IBM 128-bit.  I have tested this with a
compiler configured to use an older library, and it worked for the conversion
if the number could be represented in the IBM 128-bit format.

While most of the Decimal <-> Long double tests now pass when long doubles are
IEEE 128-bit, there are two tests that fails:

*   c-c++-common/dfp/convert-bfp-6.c
*   c-c++-common/dfp/convert-bfp-11.c

I have patches for the bfp-11 test (which requires that long double be IBM
128-bit).  I have not looked at the bfp-6 test but I will shortly.

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works
well.  This patch is required to be able to build a toolchain where the default
long double is IEEE 128-bit.  Can I check this patch into the master branch for
GCC 11?

libgcc/
2021-01-14  Michael Meissner  

* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
* config/rs6000/_kf_to_sd.c: New file.
* config/rs6000/_kf_to_td.c: New file.
* config/rs6000/_sd_to_kf.c: New file.
* config/rs6000/_sprintfkf.c: New file.
* config/rs6000/_sprintfkf.h: New file.
* config/rs6000/_strtokf.h: New file.
* config/rs6000/_strtokf.c: New file.
* config/rs6000/_td_to_kf.c: New file.
* config/rs6000/quad-float128.h: Add new declarations.
* config/rs6000/t-float128 (fp128_dec_funcs): New macro.
(fp128_decstr_funcs): New macro.
(ibm128_dec_funcs): New macro.
(fp128_ppc_funcs): Add the new conversions.
(fp128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(fp128_decstr_objs): Force __float128 <-> string conversions to be
compiled with -mabi=ibmlongdouble.
(ibm128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(FP128_CFLAGS_DECIMAL): New macro.
(IBM128_CFLAGS_DECIMAL): New macro.
* dfp-bit.c (DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
* dfp-bit.h (BFP_KIND): Add new binary floating point kind for
IEEE 128-bit floating point.
(DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
(BFP_SPRINTF): New macro.
---
 libgcc/config/rs6000/_dd_to_kf.c | 37 ++
 libgcc/config/rs6000/_kf_to_dd.c | 37 ++
 libgcc/config/rs6000/_kf_to_sd.c | 37 ++
 libgcc/config/rs6000/_kf_to_td.c | 37 ++
 libgcc/config/rs6000/_sd_to_kf.c | 37 ++
 libgcc/config/rs6000/_sprintfkf.c| 57 
 libgcc/config/rs6000/_sprintfkf.h| 28 ++
 libgcc/config/rs6000/_strtokf.c  | 56 +++
 libgcc/config/rs6000/_strtokf.h  | 27 +
 libgcc/config/rs6000/_td_to_kf.c | 37 ++
 libgcc/config/rs6000/quad-float128.h |  8 
 libgcc/config/rs6000/t-float128  | 37 +-
 libgcc/dfp-bit.c | 12 +-
 libgcc/dfp-bit.h | 26 +
 14 files changed, 470 insertions(+), 3 deletions(-)
 create mode 100644 libgcc/config/rs6000/_dd_to_kf.c
 create mode 100644 libgcc/config/rs6000/_kf_to_dd.c
 create mode 100644 libgcc/config/rs6000/_kf_to_sd.c
 create mode 100644 libgcc/config/rs6000/_kf_to_td.c
 create mode 100644 libgcc/config/rs6000/_sd_to_kf.c
 create mode 100644 libgcc/config/rs6000/_sprintfkf.c
 create mode 100644 libgcc/config/rs6000/_sprintfkf.h
 create mode 100644 libgcc/config/rs6000/_strtokf.c
 create mode 100644 libgcc/config/rs6000/_strtokf.h
 create mode 100644 

[PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

[Michael Meissner via Gcc-patches]

>From 78435dee177447080434cdc08fc76b1029c7f576 Mon Sep 17 00:00:00 2001
From: Michael Meissner 
Date: Wed, 13 Jan 2021 21:47:03 -0500
Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

This patch replaces patches previously submitted:

September 24th, 2020:
Message-ID: <20200924203159.ga31...@ibm-toto.the-meissners.org>

October 9th, 2020:
Message-ID: <20201009043543.ga11...@ibm-toto.the-meissners.org>

October 24th, 2020:
Message-ID: <2020100346.ga8...@ibm-toto.the-meissners.org>

November 19th, 2020:
Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>

This patch maps the built-in functions that take or return long double
arguments on systems where long double is IEEE 128-bit.

If long double is IEEE 128-bit, this patch goes through the built-in functions
and changes the name of the math, scanf, and printf built-in functions to use
the functions that GLIBC provides when long double uses the IEEE 128-bit
representation.

In addition, changing the name in GCC allows the Fortran compiler to
automatically use the correct name.

To map the math functions, typically this patch changes l to
__ieee128.  However there are some exceptions that are handled with this
patch.

To map the printf functions,  is mapped to __ieee128.

To map the scanf functions,  is mapped to __isoc99_ieee128.

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works
well.  This patch is required to be able to build a toolchain where the default
long double is IEEE 128-bit.  Can I check this patch into the master branch for
GCC 11?

gcc/
2021-01-14  Michael Meissner  

* config/rs6000/rs6000.c (ieee128_builtin_name): New function.
(built_in_uses_long_double): New function.
(identifier_ends_in_suffix): New function.
(rs6000_mangle_decl_assembler_name): Update support for mapping built-in
function names for long double built-in functions if long double is
IEEE 128-bit to catch all of the built-in functions that take or
return long double arguments.

gcc/testsuite/
2021-01-14  Michael Meissner  

* gcc.target/powerpc/float128-longdouble-math.c: New test.
* gcc.target/powerpc/float128-longdouble-stdio.c: New test.
* gcc.target/powerpc/float128-math.c: Adjust test for new name
being generated.  Add support for running test on power10.  Add
support for running if long double defaults to 64-bits.
---
 gcc/config/rs6000/rs6000.c| 239 --
 .../powerpc/float128-longdouble-math.c| 442 ++
 .../powerpc/float128-longdouble-stdio.c   |  36 ++
 .../gcc.target/powerpc/float128-math.c|  16 +-
 4 files changed, 694 insertions(+), 39 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-math.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-stdio.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 6f48dd6566d..282703b9715 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -27100,6 +27100,172 @@ rs6000_globalize_decl_name (FILE * stream, tree decl)
 #endif
 
 
+/* If long double uses the IEEE 128-bit representation, return the name used
+   within GLIBC for the IEEE 128-bit long double built-in, instead of the
+   default IBM 128-bit long double built-in.  Or return NULL if the built-in
+   function does not use long double.  */
+
+static const char *
+ieee128_builtin_name (built_in_function fn)
+{
+  switch (fn)
+{
+default:   return NULL;
+case BUILT_IN_ACOSHL:  return "__acoshieee128";
+case BUILT_IN_ACOSL:   return "__acosieee128";
+case BUILT_IN_ASINHL:  return "__asinhieee128";
+case BUILT_IN_ASINL:   return "__asinieee128";
+case BUILT_IN_ATAN2L:  return "__atan2ieee128";
+case BUILT_IN_ATANHL:  return "__atanhieee128";
+case BUILT_IN_ATANL:   return "__atanieee128";
+case BUILT_IN_CABSL:   return "__cabsieee128";
+case BUILT_IN_CACOSHL: return "__cacoshieee128";
+case BUILT_IN_CACOSL:  return "__cacosieee128";
+case BUILT_IN_CARGL:   return "__cargieee128";
+case BUILT_IN_CASINHL: return "__casinhieee128";
+case BUILT_IN_CASINL:  return "__casinieee128";
+case BUILT_IN_CATANHL: return "__catanhieee128";
+case BUILT_IN_CATANL:  return "__catanieee128";
+case BUILT_IN_CBRTL:   return "__cbrtieee128";
+case BUILT_IN_CCOSHL:  return 

Re: [PATCH 2/3] PowerPC: require IBM long double for pr70117.

[Michael Meissner via Gcc-patches]

On Mon, Dec 14, 2020 at 05:26:03PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Dec 03, 2020 at 10:57:56PM -0500, Michael Meissner wrote:
> > --- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > @@ -1,5 +1,6 @@
> > -/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* 
> > powerpc*-*-aix* rs6000-*-* } } } */
> > -/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
> > +/* { dg-do run } */
> > +/* { dg-require-effective-target ppc_long_double_override_ibm } */
> > +/* { dg-options "-std=c99 -O2 -mlong-double-128 -mabi=ibmlongdouble 
> > -Wno-psabi" } */
> 
> 
> So we probably really want some add_options_for_ thing, and use that
> everywhere else?
> 
> 
> Before this patch you did not test for anything printf (or glibc at
> all); why is that suddenly necessary?

It works fine on systems where long double is IBM extended double (hence the
exclusions for darwin, aix, which do not have 128-bit long double).  It does
not work on systems where long double is either 64-bit or uses the IEEE 128-bit
representation.

For example, if I build a compiler where long double is 64-bit (i.e. PR 97543),
this test will fail.

In a previous version of the patch you said that it was a problem in that the
test was not run on systems where we have flipped the long double default.  So
I added the options to try and force it to run with IBM 128-bit long double.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] PowerPC: Add float128/Decimal conversions

[Michael Meissner via Gcc-patches]

On Fri, Dec 11, 2020 at 01:51:44PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Nov 19, 2020 at 07:05:24PM -0500, Michael Meissner wrote:
> > If the glibc is not 2.32 or later, this code just compiles to using abort.
> 
> That is the compile-time target glibc.  That is often *not* the glibc
> your program runs with, as I said before.  And this is a huge problem
> still.
> 
> > That way the user won't get unknown reference errors due to the calls to the
> > glibc 2.32 functions that aren't in previous glibcs.
> 
> See above.
> 
> Also, tight version dependencies like this are problematic: glibc has
> version dependencies on GCC already!
> 
> You should do the conversion *inside of libgcc*.  As said many times
> before.

Note, NONE of the other Decimal conversion functions are done within LIBGCC.
All use sprintf/scanf.  It is just that until GLIBC 2.32, we did not have the
necessary support in GLIBC.

I just don't think LIBGCC is the place to do this conversion, given the nature
of decimal arithmetic.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] PowerPC: Map IEEE 128-bit long double built-in functions

[Michael Meissner via Gcc-patches]

On Thu, Dec 10, 2020 at 03:20:01PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Nov 19, 2020 at 06:58:14PM -0500, Michael Meissner wrote:
> > * config/rs6000/rs6000.c (rs6000_mangle_decl_assembler_name): Add
> > support for mapping built-in function names for long double
> > built-in functions if long double is IEEE 128-bit.
> 
> Please write what it does, not "add support".  Say what names it maps
> to, importantly.  You don't need to list all, but what you wrote is
> 100% contentless.

Ok.

> > diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> > index a5188553593..35e9c844e17 100644
> > --- a/gcc/config/rs6000/rs6000.c
> > +++ b/gcc/config/rs6000/rs6000.c
> > @@ -27065,57 +27065,128 @@ rs6000_globalize_decl_name (FILE * stream, tree 
> > decl)
> > library before you can switch the real*16 type at compile time.
> >  
> > We use the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change this name.  
> > We
> > -   only do this if the default is that long double is IBM extended double, 
> > and
> > -   the user asked for IEEE 128-bit.  */
> > +   only do this transformation if the __float128 type is enabled.  This
> > +   prevents us from doing the transformation on older 32-bit ports that 
> > might
> > +   have enabled using IEEE 128-bit floating point as the default long 
> > double
> > +   type.  */
> 
> I still don't understand why you want to support some hypothetical and
> untested configuration.

I'm not sure what you mean by hypothetical and untested configuration.  If you
build a default configuration on a big endian system (i.e. do not use
--with-cpu specifying at least power7), the __float128 type is not enabled by
default, because you need access to the VSX vector registers.

> > +  /* { dg-final { scan-assembler {\mbl __ynieee128} } }  */
> 
> This kind of thing does not portably work (the function names can have
> various prefixes added).

Why would it have prefixes?  Can you suggest a better way of doing the test?
There are lots of different long names that need to get mapped if long doubles
are IEEE 128-bit.  This test just tries to test every function to make sure it
got mapped appropriately.

We can't do a link test without requiring that GLIBC is 2.32 or newer, since
the older GLIBCs don't have all of the symbols.  And the link test would only
work on little endian ELFV2 systems, since big endian GLIBC 2.32 does not
export any of the float128 stuff.

> I cannot understand this code, and it does seem far from obviously
> correct.  But, okay for trunk if you handle all fallout (and I mean all,
> not just "all you consider important").

Note, the code is only invokved for systems where IEEE 128-bit floating point
is supported.  So it will never get called for a lot of the random embedded
systems or the big endian systems.

There is another way I could do the code that is simpler, but over time it will
need maintainence as new built-in functions are added.

Right now, in going over the system built-ins, it tries to do the mapping based
on the names:

1)  If the function has a long double argument or returns long double, and
it ends in 'l', the name is mapped to "__" followed by 
and then "ieee128".  I.e. "sinl" becomes "__sinieee128".

2)  However, some names do not follow that formula and I have a switch
statement for the outliers.

3)  If the function name ends in "printf", the name is transformed to "__"
followed by  followed by "ieee128".  I.e. "sprintf" becomes
"__sprintfieee128".

4)  If the function names ends in "scanf", the name is transformed to
"__isoc99_" followed by  followed by "ieee128".  I.e. "vscanf"
becomes "__isoc99_vscanfieee128".

I could change it to just having a switch statement of all known built-in
functions.  I would need to add some code that if checking was enabled, it
would look for built-in functions that use long double that are not mapped, and
issue a warning to update the table of maps.  This might be cleaner to look at,
but every so often, we would need to add a new symbol.

Would you prefer me to do that second implementation?

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping x2: [PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move

[Michael Meissner via Gcc-patches]

This needs the first patch in the series to be applied first.  This patch is
not critical for enabling IEEE 128-bit long double, but it does improve
float128 code generation on power10.

I haven't received a reply for this patch:

| Date: Sun, 15 Nov 2020 23:53:20 -0500
| Subject: [PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move
| Message-ID: <20201116045320.gb3...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559167.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping x2: [PATCH 1/2] Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.

[Michael Meissner via Gcc-patches]

This patch has been around for quite some time.  It isn't critical for enabling
IEEE 128-bit long double, but it improves code generation for float128 on
power10.

I haven't received a reply for this patch:

| Date: Sun, 15 Nov 2020 23:50:51 -0500
| Subject: [PATCH 1/2] Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.
| Message-ID: <20201116045051.ga3...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559166.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping x2: [PATCH] PowerPC: Set long double size for IBM/IEEE.

[Michael Meissner via Gcc-patches]

This patch isn't critical for IEEE 128-bit long double, but it is a feature
Jonathan Wakely asked for, to have a single switch to enable IEEE/IBM 128-bit
long double, without having to set the long double size.

I haven't received a replay for this patch:

| Date: Thu, 19 Nov 2020 19:00:11 -0500
| Subject: [PATCH] PowerPC: Set long double size for IBM/IEEE.
| Message-ID: <2020112011.ga...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559660.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping x2: [PATCH] PowerPC: Add float128/Decimal conversions

[Michael Meissner via Gcc-patches]

This is one of the critical patches for enabling IEEE 128-bit long double.

I haven't received a reply for this patch:

| Date: Thu, 19 Nov 2020 19:05:24 -0500
| Subject: [PATCH] PowerPC: Add float128/Decimal conversions
| Message-ID: <2020112524.ga...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559661.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping x2: [PATCH] PowerPC: Map IEEE 128-bit long double built-in functions

[Michael Meissner via Gcc-patches]

This patch is one of the critical patches to enable building GCC with the long
double type set to IEEE 128-bit.

I haven't received a response for this patch:

| Date: Thu, 19 Nov 2020 18:58:14 -0500
| Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-in functions
| Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559659.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping: [PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move

[Michael Meissner via Gcc-patches]

I haven't received a reply for this patch:

| Date: Sun, 15 Nov 2020 23:53:20 -0500
| Subject: [PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move
| Message-ID: <20201116045320.gb3...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559167.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping: [PATCH 1/2] Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.

[Michael Meissner via Gcc-patches]

I haven't received a reply for this patch:

| Date: Sun, 15 Nov 2020 23:50:51 -0500
| Subject: [PATCH 1/2] Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.
| Message-ID: <20201116045051.ga3...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559166.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping: [PATCH] PowerPC: Add float128/Decimal conversions

[Michael Meissner via Gcc-patches]

I haven't received a reply for this patch:

| Date: Thu, 19 Nov 2020 19:05:24 -0500
| Subject: [PATCH] PowerPC: Add float128/Decimal conversions
| Message-ID: <2020112524.ga...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559661.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping [PATCH] PowerPC: Map IEEE 128-bit long double built-in functions

[Michael Meissner via Gcc-patches]

I haven't received a response for this patch:

| Date: Thu, 19 Nov 2020 18:58:14 -0500
| Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-in functions
| Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559659.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Ping: [PATCH] PowerPC: Set long double size for IBM/IEEE.

[Michael Meissner via Gcc-patches]

I haven't received a replay for this patch:

| Date: Thu, 19 Nov 2020 19:00:11 -0500
| Subject: [PATCH] PowerPC: Set long double size for IBM/IEEE.
| Message-ID: <2020112011.ga...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559660.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH, Committed] PowerPC PR libgcc/o7543 and libgcc/97643, Fix long double issues

[Michael Meissner via Gcc-patches]

I committed the following patch today.  After a burn-in period, I plan to
commit the patch to older GCC releases, and close out the two PRs.

PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issues

If you use a compiler with long double defaulting to 64-bit instead of 128-bit
with IBM extended double, you get linker warnings about mis-matches in the gnu
attributes for long double (PR libgcc/97543).  Even if the compiler is
configured to have long double be 64 bit as the default with the configuration
option '--without-long-double-128' you get the warnings.

You also get the same issues if you use a compiler with long double defaulting
to IEEE 128-bit instead of IBM extended double (PR libgcc/97643).

The issue is the way libgcc.a/libgcc.so is built.  Right now when building
libgcc under Linux, the long double size is set to 128-bits when building
libgcc.  However, the gnu attributes are set, leading to the warnings.

One feature of the current GNU attribute implementation is if you have a shared
library (such as libgcc_s.so), the GNU attributes for the shared library is an
inclusive OR of all of the objects within the library.  This means if any
object file that uses the -mlong-double-128 option and uses long double, the GNU
attributes for the library will indicate that it uses 128-bit IBM long
doubles.  If you have a static library, you will get the warning only if you
actually reference an object file  with the attribute set.

This patch does two things:

1)  All of the object files that support IBM 128-bit long doubles
explicitly set the ABI to IBM extended double.

2)  I turned off GNU attributes for building the shared library or for
building the IBM 128-bit long double support.

libgcc/
2020-12-03  Michael Meissner  

PR libgcc/97543
PR libgcc/97643
* config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable.
(IBM128_SHARED_OBJS): New make variable.
(IBM128_OBJS): New make variable.  Set all objects to use the
explicit IBM format, and disable gnu attributes.
(IBM128_CFLAGS): New make variable.
(gcc_s_compile): Add -mno-gnu-attribute to all shared library
modules.
---
 libgcc/config/rs6000/t-linux | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/libgcc/config/rs6000/t-linux b/libgcc/config/rs6000/t-linux
index ed821947b66..72e9c2770a6 100644
--- a/libgcc/config/rs6000/t-linux
+++ b/libgcc/config/rs6000/t-linux
@@ -6,3 +6,25 @@ HOST_LIBGCC2_CFLAGS += -mlong-double-128
 # smaller and faster libgcc code.  Directly specifying -mcmodel=small
 # would need to take into account targets for which -mcmodel is invalid.
 HOST_LIBGCC2_CFLAGS += -mno-minimal-toc
+
+# On the modules that deal with IBM 128-bit values, make sure that TFmode uses
+# the IBM extended double format.  Also turn off gnu attributes on the static
+# modules.
+IBM128_STATIC_OBJS = ibm-ldouble$(objext) _powitf2$(objext) \
+ ppc64-fp$(objext) _divtc3$(object) _multc3$(object) \
+ _fixtfdi$(object) _fixunstfdi$(object) \
+ _floatditf$(objext) _floatunsditf$(objext)
+IBM128_SHARED_OBJS = $(IBM128_STATIC_OBJS:$(objext):_s$(objext))
+IBM128_OBJS= $(IBM128_STATIC_OBJS) $(IBM128_SHARED_OBJS)
+
+IBM128_CFLAGS  = -Wno-psabi -mabi=ibmlongdouble -mno-gnu-attribute
+
+$(IBM128_OBJS) : INTERNAL_CFLAGS += $(IBM128_CFLAGS)
+
+# Turn off gnu attributes for long double size on all of the shared library
+# modules, but leave it on for the static modules, except for the functions
+# that explicitly process IBM 128-bit floating point.  Shared libraries only
+# have one gnu attribute for the whole library, and it can lead to warnings if
+# somebody changes the long double format.  We leave it on for the static
+# modules to catch mis-compilation errors.
+gcc_s_compile += -mno-gnu-attribute
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 1/3] PowerPC: Add long double target-supports.

[Michael Meissner via Gcc-patches]

PowerPC: Add long double target-supports.

I messed up posting this patch, using the wrong subject line.  This patch is
what I meant to post.

This patch replaces the patch submitted on November 21st:
| Date: Sat, 21 Nov 2020 00:33:52 -0500
| Subject: [PATCH 1/3] PowerPC: Add long double target-supports.
| Message-ID: <20201121053352.gc17...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559839.html

I expanded the target supports to include more options to select targets with
an appropriate long double format.  There are four options to check whether the
current long double is:

1)  128-bit using the IBM extended double format;
2)  128-bit using the IEEE format;
3)  Long double is 128-bits (i.e. either IBM or IEEE); (and)
4)  Long double is 64-bits.

I also added two new target supports:

1)  If you can switch the long double to IBM extended double via compiler
options and the GLIBC supports this change.  If you are using an
existing GLIBC with IBM long double, this should work since you aren't
switching the long double format.

2)  And likewise if you can switch the long double to IEEE 128-bit.

This patch and the following 2 other patches were tested together on a power9
little endian server system.  I built 4 compilers:

1)  Compiler without modifications;
2)  Compiler using my other patches configured for IBM long double;
3)  Compiler using my other patches configured for IEEE long double; (and)
4)  Compiler using my other patches configure for 64-bit double.

While I used the other patches to test the 64-bit and IEEE long double, these 3
patches should work for the default builds with IBM 128-bit, and they will
continue to work once all of the long double support patches are in.  The two
tests that are patched in the next two patches, now work in all environments.
Can I apply these patches to the master branch?

gcc/testsuite/
2020-12-03  Michael Meissner  

* lib/target-supports.exp
(check_effective_target_ppc_long_double_ibm): New function.
(check_effective_target_ppc_long_double_ieee): New function.
(check_effective_target_ppc_long_double_override_ibm): New function.
(check_effective_target_ppc_long_double_override_ieee): New function.
(check_effective_target_ppc_long_double_128bit): New function.
(check_effective_target_ppc_long_double_64bit): New function.
---
 gcc/testsuite/lib/target-supports.exp | 122 ++
 1 file changed, 122 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ff6bc5f4b92..01b82843bf5 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2348,6 +2348,128 @@ proc check_effective_target_ppc_ieee128_ok { } {
 }]
 }
 
+# See if the target is a powerpc with the long double format that uses the IBM
+# extended double format.
+
+proc check_effective_target_ppc_long_double_ibm { } {
+return [check_cached_effective_target ppc_long_double_ibm {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that uses the IEEE
+# 128-bit format.
+
+proc check_effective_target_ppc_long_double_ieee { } {
+return [check_cached_effective_target ppc_long_double_ieee {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IEEE128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# Like check_effective_target_ppc_long_double_ibm, but check if we can
+# explicitly override the long double format to use the IBM 128-bit extended
+# double format, and GLIBC supports doing this override by switching the
+# sprintf to handle long double.
+
+proc check_effective_target_ppc_long_double_override_ibm { } {
+set options "-mlong-double-128 -mabi=ibmlongdouble -Wno-psabi"
+check_runtime_nocache ppc_long_double_ovveride_ibm {
+   #include 
+   #include 
+   volatile __ibm128 a = (__ibm128) 3.0;
+   volatile long double one = 1.0L;
+   volatile long double two = 2.0L;
+   volatile long double b;
+   char buffer[20];
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   b = one + two;
+   if (memcmp ((void *), (void *), sizeof (long double)) != 0)
+ return 1;
+   sprintf (buffer, "%lg", b);
+   return strcmp (buffer, "3") != 0;
+ #endif
+   }
+} $options
+}
+
+# Like check_effective_target_ppc_long_double_ieee, but check if we can
+# explicitly override the long double format to use the IEEE 128-bit format,
+# and GLIBC supports doing this override by 

[PATCH 3/3] PowerPC: Force IBM long double for conversion test.

[Michael Meissner via Gcc-patches]

PowerPC: Force IBM long double for conversion test.

This patch replaces the following patch:
| Date: Sat, 21 Nov 2020 00:39:53 -0500
| Subject: [PATCH 3/3] PowerPC: Require IBM long double for conversion test.
| Message-ID: <20201121053953.ge17...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559841.html

The test c-c++-common/dfp/convert-bfp-11.c explicitly expects long double to
use the IBM 128-bit extended double format.  In particular, some of the tests
expect an infinity to be created if decimal values that are converted that are
too large for IBM extended double.  However, the numbers do fit in the range
for IEEE 128-bit format, since it has a larger exponent than the IBM 128-bit
format.  The test fails because an infinity is not generated.

This patch uses the target support option that says we can change the long
double type.  If the long double type uses the IBM format, you can use older
GLIBCs.  If you are using IEEE long doubles, this test will only run if GLIBC
is 2.32 or newer that supports switching the long double format.

I have checked this patch with 3 compilers built on a little endian power9
system, 1 compiler with IBM default long double, 1 compiler with IEEE default
long double, and 1 compiler with 64-bit long double.  This test passes with all
3 compilers.

Can I check this patch into the master branch?

gcc/testsuite/
2020-12-03  Michael Meissner  

* c-c++-common/dfp/convert-bfp-11.c: Force using IBM 128-bit long
double.  Remove check for 64-bit long double.
---
 .../c-c++-common/dfp/convert-bfp-11.c  | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c 
b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
index 95c433d2c24..d19d6aa9220 100644
--- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
+++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
@@ -1,9 +1,14 @@
-/* { dg-skip-if "" { ! "powerpc*-*-linux*" } } */
+/* { dg-require-effective-target dfp } */
+/* { dg-require-effective-target ppc_long_double_override_ibm } */
+/* { dg-options "-O2 -mlong-double-128 -mabi=ibmlongdouble -Wno-psabi" } */
 
-/* Test decimal float conversions to and from IBM 128-bit long double. 
-   Checks are skipped at runtime if long double is not 128 bits.
-   Don't force 128-bit long doubles because runtime support depends
-   on glibc.  */
+/* We force the long double type to be IBM 128-bit because the CONVERT_TO_PINF
+   tests will fail if we use IEEE 128-bit floating point.  This is due to IEEE
+   128-bit having a larger exponent range than IBM 128-bit extended double.  So
+   tests that would generate an infinity with IBM 128-bit will generate a
+   normal number with IEEE 128-bit.  */
+
+/* Test decimal float conversions to and from IBM 128-bit long double.   */
 
 #include "convert.h"
 
@@ -36,9 +41,6 @@ CONVERT_TO_PINF (312, tf, sd, 1.6e+308L, d32)
 int
 main ()
 {
-  if (sizeof (long double) != 16)
-return 0;
-
   convert_101 ();
   convert_102 ();
 
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 2/3] PowerPC: require IBM long double for pr70117.

[Michael Meissner via Gcc-patches]

PowerPC: PR target/70117, Force long double to be IBM 128-bit.

This patch replaces the following patch:
| Date: Sat, 21 Nov 2020 00:37:10 -0500
| Subject: [PATCH 2/3] PowerPC: require IBM long double for pr70117.
| Message-ID: <20201121053710.gd17...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559840.html

This patch uses the ppc_long_double_override_ibm target supports option that
was in the previous patch to make sure pr70117.c uses IBM extended double that
this test was designed for.

I have run this test on a power9 little endian server system with 3 compilers,
one configured for IBM long double, 1 configured for IEEE long double, and 1
configured for 64-bit long double.  All of the compilers used GLIBC 2.32, which
is needed to support switching the long double type, but this patch should work
with older GLIBCs as long as the compiler long double format matches GLIBC's
long double.

Can I check this change into the master branch once the previous patch is
applied?

gcc/testsuite/
2020-12-03  Michael Meissner  

PR target/70117
* gcc.target/powerpc/pr70117.c: Force the long double type to use
the IBM 128-bit format.
---
 gcc/testsuite/gcc.target/powerpc/pr70117.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
b/gcc/testsuite/gcc.target/powerpc/pr70117.c
index 3bbd2c595e0..6efece1c7c8 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
@@ -1,5 +1,6 @@
-/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* powerpc*-*-aix* 
rs6000-*-* } } } */
-/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
+/* { dg-do run } */
+/* { dg-require-effective-target ppc_long_double_override_ibm } */
+/* { dg-options "-std=c99 -O2 -mlong-double-128 -mabi=ibmlongdouble 
-Wno-psabi" } */
 
 #include 
 
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Date: Sat, 21 Nov 2020 00:33:52 -0500

[Michael Meissner via Gcc-patches]

PowerPC: Add long double target-supports.

This patch replaces the patch submitted on November 21st:
| Date: Sat, 21 Nov 2020 00:33:52 -0500
| Subject: [PATCH 1/3] PowerPC: Add long double target-supports.
| Message-ID: <20201121053352.gc17...@ibm-toto.the-meissners.org>
| https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559839.html

I expanded the target supports to include more options to select targets with
an appropriate long double format.  There are four options to check whether the
current long double is:

1)  128-bit using the IBM extended double format;
2)  128-bit using the IEEE format;
3)  Long double is 128-bits (i.e. either IBM or IEEE); (and)
4)  Long double is 64-bits.

I also added two new target supports:

1)  If you can switch the long double to IBM extended double via compiler
options and the GLIBC supports this change.  If you are using an
existing GLIBC with IBM long double, this should work since you aren't
switching the long double format.

2)  And likewise if you can switch the long double to IEEE 128-bit.

This patch and the following 2 other patches were tested together on a power9
little endian server system.  I built 4 compilers:

1)  Compiler without modifications;
2)  Compiler using my other patches configured for IBM long double;
3)  Compiler using my other patches configured for IEEE long double; (and)
4)  Compiler using my other patches configure for 64-bit double.

While I used the other patches to test the 64-bit and IEEE long double, these 3
patches should work for the default builds with IBM 128-bit, and they will
continue to work once all of the long double support patches are in.  The two
tests that are patched in the next two patches, now work in all environments.
Can I apply these patches to the master branch?

gcc/testsuite/
2020-12-03  Michael Meissner  

* lib/target-supports.exp
(check_effective_target_ppc_long_double_ibm): New function.
(check_effective_target_ppc_long_double_ieee): New function.
(check_effective_target_ppc_long_double_override_ibm): New function.
(check_effective_target_ppc_long_double_override_ieee): New function.
(check_effective_target_ppc_long_double_128bit): New function.
(check_effective_target_ppc_long_double_64bit): New function.
---
 gcc/testsuite/lib/target-supports.exp | 122 ++
 1 file changed, 122 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ff6bc5f4b92..01b82843bf5 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2348,6 +2348,128 @@ proc check_effective_target_ppc_ieee128_ok { } {
 }]
 }
 
+# See if the target is a powerpc with the long double format that uses the IBM
+# extended double format.
+
+proc check_effective_target_ppc_long_double_ibm { } {
+return [check_cached_effective_target ppc_long_double_ibm {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that uses the IEEE
+# 128-bit format.
+
+proc check_effective_target_ppc_long_double_ieee { } {
+return [check_cached_effective_target ppc_long_double_ieee {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IEEE128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# Like check_effective_target_ppc_long_double_ibm, but check if we can
+# explicitly override the long double format to use the IBM 128-bit extended
+# double format, and GLIBC supports doing this override by switching the
+# sprintf to handle long double.
+
+proc check_effective_target_ppc_long_double_override_ibm { } {
+set options "-mlong-double-128 -mabi=ibmlongdouble -Wno-psabi"
+check_runtime_nocache ppc_long_double_ovveride_ibm {
+   #include 
+   #include 
+   volatile __ibm128 a = (__ibm128) 3.0;
+   volatile long double one = 1.0L;
+   volatile long double two = 2.0L;
+   volatile long double b;
+   char buffer[20];
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   b = one + two;
+   if (memcmp ((void *), (void *), sizeof (long double)) != 0)
+ return 1;
+   sprintf (buffer, "%lg", b);
+   return strcmp (buffer, "3") != 0;
+ #endif
+   }
+} $options
+}
+
+# Like check_effective_target_ppc_long_double_ieee, but check if we can
+# explicitly override the long double format to use the IEEE 128-bit format,
+# and GLIBC supports doing this override by switching the sprintf to handle
+# long double.
+
+proc 

[PATCH 0/3] Updates for float128 tests

[Michael Meissner via Gcc-patches]

These patches update the test suite patches I posted on November 21.

There are 3 patches in this series.

1)  The first patch adds new target-support options;
2)  The second patch updates pr70117.c; (and)
3)  The third patch updates convert-bfp-11.c.

In the target supports patches, I expanded the target supports to include more
options to select targets with an appropriate long double format.  There are
four options to check whether the current long double is:

1)  128-bit using the IBM extended double format;
2)  128-bit using the IEEE format;
3)  Long double is 128-bits (i.e. either IBM or IEEE); (and)
4)  Long double is 64-bits.

I also added two new target supports:

1)  If you can switch the long double to IBM extended double via compiler
options and the GLIBC supports this change.  If you are using an
existing GLIBC with IBM long double, this should work since you aren't
switching the long double format.

2)  And likewise if you can switch the long double to IEEE 128-bit.

I modified the two tests to use the new target supports where we select IBM
128-bit at compile time.  This will allow these two tests to be tested with the
current compilers, and also continue to running these two tests when the
default long double has been changed.  I have built compilers with each of the
three long double formats being default, and all 3 compilers run these tests
(providing I use GLIBC 2.32 or later).

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

On Tue, Dec 01, 2020 at 10:36:10PM +, Jonathan Wakely wrote:
> I've attached a complete patch including those generated files, and
> I've also pushed the branch to refs/users/redi/heads/ieee128-squash in
> the gcc.gnu.org Git repo. That branch includes your patch for PR
> libgcc/97543 which is required for some of the libstdc++ changes to
> work properly.

This patch along with my posted patches allows me to build the Spec 2017
parest_r benchmark with a PowerPC compiler configured for IEEE 128-bit long
doubles (that previously failed).  Thanks for the hard work!

In addition, I built a compiler where long double defaulted to 64-bit, and I
could build all of the Spec 2017 rate benchmarks.

I ran the two benchmarks that generate IEEE 128-bit instructions when long
double is IEEE 128-bit (perlbench_r and parest_r) on a little endian power9
running Linux with all different long double formats.  There was no difference
in runtime between the benchmark compiled for the different long double
formats.  I have to imagine that while the code is built using long double, the
actual benchmark does not use those functions in a significant way.

I did bootstrap builds for three different compilers configured to use each of
the long double formats.  There were no differences in the C++ tests between
the three compilers.

In the C tests, the two tests that test the nanq and nansq built-in functions
fail with IEEE 128-bit long double because I did not incorprate the patch for
that in this run.  There are 9 tests that fail with long double configured for
64-bits that I will look at adjusting in the future.

In the Fortran tests, there were three benchmarks that fail with IBM 128-bit
long double that now pass with IEEE 128-bit long double.  There is one test
that fails when long double is 64-bits.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

Note this is just to keep the gcc-patches archive up to date.  I originally
posted this reply but the attached config.log file was too big.  It was also
sent directly to Jonathan, and he replied.  So I canceled the gcc-patches post,
and I'm sending out this one with a bzip2's config.log:

On Tue, Dec 01, 2020 at 09:10:30PM +, Jonathan Wakely wrote:
> On Tue, 1 Dec 2020 at 19:13, Michael Meissner via Libstdc++
>  wrote:
> >
> > On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> > > On 01/12/20 15:10 +, Jonathan Wakely wrote:
> > > >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> > > >>Jonathan, could you send a fresh set of patches (or at least 
> > > >>replacements)?  I
> > > >>tried installing the patches on a master branch I checked out this 
> > > >>morning, and
> > > >>I got two rejects:
> > > >
> > > >I don't understand why those chunks failed, but I'll rebase and send a
> > > >new patch ASAP.
> > >
> > > Here's the rebased patch, with regenerated autoconf files and a fix
> > > for the  header. I'd changed it since sending
> > > the previous patch, and broke the "there's more than one long double"
> > > case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).
> >
> > Unfortunately this patch DOES NOT work at all.
> >
> > If I build a compiler with the configure option:
> > --with-long-double-format=ieee
> >
> > And I compile this simple program:
> >
> > #include 
> >
> > int main(int argc, char *argv[], char *envp[])
> > {
> >   std::cout << "Hello World!\n";
> >   return 0;
> > }
> >
> > I get all of these errors:
> 
> It works fine for me (see below). I think your symptoms are due to
> using a glibc that doesn't support the new long double, and so
> libstdc++ support for it is also disabled. You need at least glibc
> 2.32 for the libstdc++ changes to be enabled.

I am using the Advance Toolchain which includes GLIBC 2.32, which has the
necessary support.  I will include the config.log as an attachment.

Note, I am also using the patches I submitted around November 19th.

In particular, there is the patch that maps long double built-in names if long
double is IEEE 128-bit:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559659.html

I used the patch that tries to fix some problems with gnu attributes:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559657.html

I used the patch that fixes up the gnu attributes use in libgcc:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559660.html

I used the patch that adds float128 <-> Decimal conversions:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559661.html

I used the patch that allows -mabi={ieee,ibm}longdouble to override the default
configuration for long double == 64 bits, without having to use the
-mlong-double-64 option as well:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559660.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797


libstdc++-v3-config.log.bz2
Description: BZip2 compressed data

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

On Tue, Dec 01, 2020 at 10:36:10PM +, Jonathan Wakely wrote:
> You need to run autoconf-2.69's autoreconf in the libstdc++-v3 source
> tree to regenerate configure, Makefile.in etc. Without doing that
> you're just running the same configure script as is on current trunk,
> and that doesn't even try looking for IEEE128 support in glibc, and so
> the new code in libstdc++ doesn't get enabled.
> 
> I've attached a complete patch including those generated files, and
> I've also pushed the branch to refs/users/redi/heads/ieee128-squash in
> the gcc.gnu.org Git repo. That branch includes your patch for PR
> libgcc/97543 which is required for some of the libstdc++ changes to
> work properly.

Sorry, I should have realized about needing to do autoconf.  Any way the new
patch builds the iostream version of hello world.  And it is going through the
rest of the build:

   1) Build 3 compilers with different long double formats;
   2) Build non-bootstrap compilers with the compilers in step 1;
   3) Build bootstrap compilers with the compilers in step 2;
   4) Build spec for the 2 128-bit long double types.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> On 01/12/20 15:10 +, Jonathan Wakely wrote:
> >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> >>Jonathan, could you send a fresh set of patches (or at least replacements)? 
> >> I
> >>tried installing the patches on a master branch I checked out this morning, 
> >>and
> >>I got two rejects:
> >
> >I don't understand why those chunks failed, but I'll rebase and send a
> >new patch ASAP.
> 
> Here's the rebased patch, with regenerated autoconf files and a fix
> for the  header. I'd changed it since sending
> the previous patch, and broke the "there's more than one long double"
> case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).

Unfortunately this patch DOES NOT work at all.

If I build a compiler with the configure option:
--with-long-double-format=ieee

And I compile this simple program:

#include 

int main(int argc, char *argv[], char *envp[])
{
  std::cout << "Hello World!\n";
  return 0;
}

I get all of these errors:

/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > 
std::num_put > 
>::_M_insert_int(std::ostreambuf_iterator >, 
std::ios_base&, char, long) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::money_get > 
>::_M_extract(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, std::string&) 
const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > 
std::money_put > 
>::_M_insert(std::ostreambuf_iterator >, 
std::ios_base&, char, std::string const&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned long 
long&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, long long&) 
const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::money_get > 
>::_M_extract(std::istreambuf_iterator 
>, std::istreambuf_iterator >, 
std::ios_base&, std::_Ios_Iostate&, std::string&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned int&) 
const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned 
long&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > 
std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator 
>, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > 
std::money_get > 
>::_M_extract(std::istreambuf_iterator >, 
std::istreambuf_iterator >, std::ios_base&, 
std::_Ios_Iostate&, std::string&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > std::num_put > 
>::_M_insert_float(std::ostreambuf_iterator >, std::ios_base&, wchar_t, char, long double) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > 
std::num_put > 
>::_M_insert_int(std::ostreambuf_iterator >, std::ios_base&, char, unsigned long) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

Jonathan, could you send a fresh set of patches (or at least replacements)?  I
tried installing the patches on a master branch I checked out this morning, and
I got two rejects:

--- libstdc++-v3/testsuite/util/testsuite_abi.cc
+++ libstdc++-v3/testsuite/util/testsuite_abi.cc
@@ -207,6 +207,7 @@
   known_versions.push_back("GLIBCXX_3.4.24");
   known_versions.push_back("GLIBCXX_3.4.25");
   known_versions.push_back("GLIBCXX_3.4.26");
+  known_versions.push_back("GLIBCXX_IEEE128_3.4.26");
   known_versions.push_back("CXXABI_1.3");
   known_versions.push_back("CXXABI_LDBL_1.3");
   known_versions.push_back("CXXABI_1.3.1");
@@ -220,6 +221,8 @@
   known_versions.push_back("CXXABI_1.3.9");
   known_versions.push_back("CXXABI_1.3.10");
   known_versions.push_back("CXXABI_1.3.11");
+  known_versions.push_back("CXXABI_1.3.12");
+  known_versions.push_back("CXXABI_IEEE128_1.3.12");
   known_versions.push_back("CXXABI_TM_1");
   known_versions.push_back("CXXABI_FLOAT128");
 }
@@ -238,7 +241,7 @@
 
   // Check that added symbols are added in the latest pre-release version.
   bool latestp = (test.version_name == "GLIBCXX_3.4.26"
-|| test.version_name == "CXXABI_1.3.11"
+|| test.version_name == "CXXABI_1.3.12"
 || test.version_name == "CXXABI_FLOAT128"
 || test.version_name == "CXXABI_TM_1");
   if (added && !latestp)
--- libstdc++-v3/include/bits/locale_facets.h
+++ libstdc++-v3/include/bits/locale_facets.h
@@ -51,16 +51,19 @@
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-  // NB: Don't instantiate required wchar_t facets if no wchar_t support.
-#ifdef _GLIBCXX_USE_WCHAR_T
-# define  _GLIBCXX_NUM_FACETS 28
-# define  _GLIBCXX_NUM_CXX11_FACETS 16
-#else
-# define  _GLIBCXX_NUM_FACETS 14
-# define  _GLIBCXX_NUM_CXX11_FACETS 8
-#endif
+// Number of standard facets (for narrow characters only)
+#define  _GLIBCXX_NUM_FACETS 14
+
+// Number of duplicated facets for cxx11 ABI
+#define  _GLIBCXX_NUM_CXX11_FACETS (_GLIBCXX_USE_DUAL_ABI ? 8 : 0)
+
+// codecvt and codecvt
 #define _GLIBCXX_NUM_UNICODE_FACETS 2
 
+// Facets duplicated for alt128 long double format
+// num_get, num_put, money_get, money_put (+ cxx11 money_get, money_put)
+#define _GLIBCXX_NUM_LBDL_ALT128_FACETS (4 + (_GLIBCXX_USE_DUAL_ABI ? 2 : 0))
+
   // Convert string to numeric value of type _Tp and store results.
   // NB: This is specialized for all required types, there is no
   // generic definition.


I tried to fix it with the following patches, but I get the error when I build
libstdc++:

.../bin/ld: duplicate version tag `CXXABI_1.3.12'

diff --git a/libstdc++-v3/testsuite/util/testsuite_abi.cc 
b/libstdc++-v3/testsuite/util/testsuite_abi.cc
index 33b9ec15935..bbe397ae8a4 100644
--- a/libstdc++-v3/testsuite/util/testsuite_abi.cc
+++ b/libstdc++-v3/testsuite/util/testsuite_abi.cc
@@ -207,6 +207,7 @@ check_version(symbol& test, bool added)
   known_versions.push_back("GLIBCXX_3.4.24");
   known_versions.push_back("GLIBCXX_3.4.25");
   known_versions.push_back("GLIBCXX_3.4.26");
+  known_versions.push_back("GLIBCXX_IEEE128_3.4.26");
   known_versions.push_back("GLIBCXX_3.4.27");
   known_versions.push_back("GLIBCXX_3.4.28");
   known_versions.push_back("GLIBCXX_3.4.29");
@@ -225,6 +226,7 @@ check_version(symbol& test, bool added)
   known_versions.push_back("CXXABI_1.3.10");
   known_versions.push_back("CXXABI_1.3.11");
   known_versions.push_back("CXXABI_1.3.12");
+  known_versions.push_back("CXXABI_IEEE128_1.3.12");
   known_versions.push_back("CXXABI_1.3.13");
   known_versions.push_back("CXXABI_TM_1");
   known_versions.push_back("CXXABI_FLOAT128");
@@ -260,7 +262,17 @@ check_version(symbol& test, bool added)
  && test.demangled_name.find("std::__cxx11::") != 0)
{
  if (test.version_name.find("_LDBL_") == std::string::npos
- && test.version_name.find("_FLOAT128") == std::string::npos)
+ && test.version_name.find("_FLOAT128") == std::string::npos
+ && test.version_name.find("_IEEE128") == std::string::npos)
+   test.version_status = symbol::incompatible;
+   }
+
+  // Check that IEEE128 long double compatibility symbols demangled as
+  // __ieee128 are put into some _LDBL_IEEE version name.
+  // XXX is this right? might not want *everything* for __ieee128 in here.
+  if (added && test.demangled_name.find("__ieee128") != std::string::npos)
+   {
+ if (test.version_name.find("_IEEE128") == std::string::npos)
test.version_status = symbol::incompatible;
}
diff --git a/libstdc++-v3/include/bits/locale_facets.h 
b/libstdc++-v3/include/bits/locale_facets.h
index 3e0ae8776c9..9b262c2d228 100644
--- a/libstdc++-v3/include/bits/locale_facets.h
+++ b/libstdc++-v3/include/bits/locale_facets.h
@@ -65,6 +65,10 @@ 

Re: [PATCH 1/3] PowerPC: Add long double target-supports.

[Michael Meissner via Gcc-patches]

On Mon, Nov 23, 2020 at 02:28:57PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Sat, Nov 21, 2020 at 12:33:52AM -0500, Michael Meissner wrote:
> > +# See if the target is a powerpc with the long double format that uses the 
> > IBM
> > +# extended double format.
> 
> "Return 1 if the target is PowerPC, and long double is IBM extended double."
> 
> > @@ -7939,6 +7992,9 @@ proc is-effective-target { arg } {
> >   "power10_hw" { set selected [check_power10_hw_available] }
> >   "ppc_float128_sw" { set selected [check_ppc_float128_sw_available] }
> >   "ppc_float128_hw" { set selected [check_ppc_float128_hw_available] }
> > + "ppc_long_double_ibm" { set selected [check_ppc_long_double_ibm] }
> > + "ppc_long_double_ieee" { set selected [check_ppc_long_double_ieee] }
> > + "ppc_long_double_64bit" { set selected [check_ppc_long_double_64bit] }
> >   "ppc_recip_hw"   { set selected [check_ppc_recip_hw_available] }
> >   "ppc_cpu_supports_hw" { set selected 
> > [check_ppc_cpu_supports_hw_available] }
> >   "ppc_mma_hw" { set selected [check_ppc_mma_hw_available] }
> 
> Why this?  It just defines aliases to the exact same name?

If you remove those lines you get the failure from the default case:

  default  { error "unknown effective target keyword `$arg'" }

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH 2/3] PowerPC: require IBM long double for pr70117.

[Michael Meissner via Gcc-patches]

On Sat, Nov 21, 2020 at 10:46:45AM -0500, David Edelsohn wrote:
> On Sat, Nov 21, 2020 at 12:37 AM Michael Meissner
>  wrote:
> >
> > PowerPC: require IBM long double for pr70117.
> >
> > Since the test is explicitly checking for IBM extended double, do not try to
> > run it when long double is IEEE 128-bit.
> >
> > I have tested this patch and the first patch in the series on a little 
> > endian
> > power9 system with 3 compilers that have the 3 different long double types
> > configured.  I verified that this test is listed as unsupported if long 
> > double
> > is not IBM 128-bit, and it passes if long double is IBM 128-bit.
> >
> > Can I check this patch into the master branch?  After an appropriate soak-in
> > time, can I back port this patch to the previous open GCC trees?
> >
> > gcc/testsuite/
> > 2020-11-21  Michael Meissner  
> >
> > PR target/70117
> > * gcc.target/powerpc/pr70117.c: Only run the test if long double
> > uses the IBM extended double format.
> > ---
> >  gcc/testsuite/gcc.target/powerpc/pr70117.c | 22 --
> >  1 file changed, 4 insertions(+), 18 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
> > b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > index 3bbd2c595e0..2077d15afd4 100644
> > --- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > @@ -1,26 +1,12 @@
> > -/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* 
> > powerpc*-*-aix* rs6000-*-* } } } */
> > -/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
> > +/* { dg-require-effective-target ppc_long_double_ibm } */
> > +/* { dg-options "-std=c99 -O2" } */
> 
> Mike,
> 
> You still need a
> 
> /* { dg-do run } */
> 
> line.  But without any target specified.
> 
> Segher may have other comments.
> 
> Thanks, David

Thanks.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 3/3] PowerPC: Require IBM long double for conversion test.

[Michael Meissner via Gcc-patches]

PowerPC: Require IBM long double for conversion test.

The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use
the IBM 128-bit extended double format.  In particular, some of the tests
expect an infinity to be created if decimal values that are converted that are
too large for IBM extended double.  However, the numbers do fit in the range
for IEEE 128-bit format, since it has a larger exponent than the IBM 128-bit
format.  The test fails because an infinity is not generated.

I have tested this patch, and the first patch in the series on a little endian
power9 computer running Linux, and I verified that if long double is not IBM
128-bit, the test is listed as UNSUPPORTED, and if long double is IBM 128-bit,
the test passes.

Can I check this into the master branch?  After an appropriate soak in period,
I would like to back port this to the open GCC branches.

gcc/testsuite/
2020-11-21  Michael Meissner  

* c-c++-common/dfp/convert-bfp-11.c: Require IBM 128-bit long
double.
---
 gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c 
b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
index 95c433d2c24..8c970bb76db 100644
--- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
+++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
@@ -1,4 +1,5 @@
-/* { dg-skip-if "" { ! "powerpc*-*-linux*" } } */
+/* { dg-require-effective-target dfp } */
+/* { dg-require-effective-target ppc_long_double_ibm } */
 
 /* Test decimal float conversions to and from IBM 128-bit long double. 
Checks are skipped at runtime if long double is not 128 bits.
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 2/3] PowerPC: require IBM long double for pr70117.

[Michael Meissner via Gcc-patches]

PowerPC: require IBM long double for pr70117.

Since the test is explicitly checking for IBM extended double, do not try to
run it when long double is IEEE 128-bit.

I have tested this patch and the first patch in the series on a little endian
power9 system with 3 compilers that have the 3 different long double types
configured.  I verified that this test is listed as unsupported if long double
is not IBM 128-bit, and it passes if long double is IBM 128-bit.

Can I check this patch into the master branch?  After an appropriate soak-in
time, can I back port this patch to the previous open GCC trees?

gcc/testsuite/
2020-11-21  Michael Meissner  

PR target/70117
* gcc.target/powerpc/pr70117.c: Only run the test if long double
uses the IBM extended double format.
---
 gcc/testsuite/gcc.target/powerpc/pr70117.c | 22 --
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
b/gcc/testsuite/gcc.target/powerpc/pr70117.c
index 3bbd2c595e0..2077d15afd4 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
@@ -1,26 +1,12 @@
-/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* powerpc*-*-aix* 
rs6000-*-* } } } */
-/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
+/* { dg-require-effective-target ppc_long_double_ibm } */
+/* { dg-options "-std=c99 -O2" } */
 
 #include 
 
-#if defined(__LONG_DOUBLE_IEEE128__)
-/* If long double is IEEE 128-bit, we need to use the __ibm128 type instead of
-   long double.  We can't use __ibm128 on systems that don't support IEEE
-   128-bit floating point, because the type is not enabled on those
-   systems.  */
-#define LDOUBLE __ibm128
-
-#elif defined(__LONG_DOUBLE_IBM128__)
-#define LDOUBLE long double
-
-#else
-#error "long double must be either IBM 128-bit or IEEE 128-bit"
-#endif
-
 union gl_long_double_union
 {
   struct { double hi; double lo; } dd;
-  LDOUBLE ld;
+  long double ld;
 };
 
 /* This is gnulib's LDBL_MAX which, being 107 bits in precision, is
@@ -36,7 +22,7 @@ volatile double dnan = 0.0/0.0;
 int
 main (void)
 {
-  LDOUBLE ld;
+  long double ld;
 
   ld = gl_LDBL_MAX.ld;
   if (__builtin_isinf (ld))
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 1/3] PowerPC: Add long double target-supports.

[Michael Meissner via Gcc-patches]

PowerPC: Add long double target-supports.

This patch adds 3 target supports to test what type of PowerPC long double is
used by the test:

   1)   Long double uses the IBM 128-bit extended double format;
   2)   Long double uses the IEEE 128-bit format; (and)
   3)   Long double uses the 64-bit format.

I have tested this patch and the following two patches in this series with
compilers with the 3 different long double types.  I verified that the two
tests being modified both are labeled as UNSUPPORTED if long double is not IBM
128-bit, and if long double is IBM 128-bit, the tests pass.

Can I check this into the master branch?  I think this patch should also be
back ported to the earlier branches.

gcc/testsuite/
2020-11-21  Michael Meissner  

* lib/target-supports.exp (check_ppc_long_double_ibm): New
function.
(check_ppc_long_double_ieee): New function.
(check_ppc_long_double_64bit): New function.
(is-effective-target): Add ppc_long_double_ibm,
ppc_long_double_ieee, and ppc_long_double_64bit.
---
 gcc/testsuite/lib/target-supports.exp | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 22acda2a74f..adcb789d136 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2336,6 +2336,59 @@ proc check_effective_target_ppc_ieee128_ok { } {
 }]
 }
 
+# See if the target is a powerpc with the long double format that uses the IBM
+# extended double format.
+
+proc check_ppc_long_double_ibm { } {
+return [check_cached_effective_target ppc_long_double_ibm {
+   check_runtime_nocache ppc_long_double_ibm {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that uses the IEEE
+# 128-bit format.
+
+proc check_ppc_long_double_ieee { } {
+return [check_cached_effective_target ppc_long_double_ieee {
+   check_runtime_nocache ppc_long_double_ieee {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IEEE128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that is 64-bit.
+
+proc check_ppc_long_double_64bit { } {
+return [check_cached_effective_target ppc_long_double_64bit {
+   check_runtime_nocache ppc_long_double_64bit {
+   int main()
+   {
+ #ifndef _ARCH_PPC
+   return 1;
+ #else
+   return sizeof (long double) != 64;
+ #endif
+   }
+   }
+}]
+}
+
 # Return 1 if the target supports executing VSX instructions, 0
 # otherwise.  Cache the result.
 
@@ -7939,6 +7992,9 @@ proc is-effective-target { arg } {
  "power10_hw" { set selected [check_power10_hw_available] }
  "ppc_float128_sw" { set selected [check_ppc_float128_sw_available] }
  "ppc_float128_hw" { set selected [check_ppc_float128_hw_available] }
+ "ppc_long_double_ibm" { set selected [check_ppc_long_double_ibm] }
+ "ppc_long_double_ieee" { set selected [check_ppc_long_double_ieee] }
+ "ppc_long_double_64bit" { set selected [check_ppc_long_double_64bit] }
  "ppc_recip_hw"   { set selected [check_ppc_recip_hw_available] }
  "ppc_cpu_supports_hw" { set selected 
[check_ppc_cpu_supports_hw_available] }
  "ppc_mma_hw" { set selected [check_ppc_mma_hw_available] }
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] PowerPC: Restrict long double test to use IBM long double.

[Michael Meissner via Gcc-patches]

On Wed, Nov 18, 2020 at 01:27:12PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Sun, Nov 15, 2020 at 12:23:50PM -0500, Michael Meissner wrote:
> > --- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > +++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > @@ -1,4 +1,5 @@
> >  /* { dg-skip-if "" { ! "powerpc*-*-linux*" } } */
> > +/* { dg-require-effective-target ppc_long_double_ibm } */
> 
> You can remove the dg-skip-if then (there is nothing in this test that
> requires Linux).  But you want a
> /* { dg-require-effective-target dfp } */
> (or dfprt).
> 
> So what happens if you use IEEE QP float, instead?  You didn't explain.
> (Explain in the source code, with a comment where you require it!)
> 
> 
> Segher

I will post a new version of this patch shortly.

As I will say in the patch description, what happens is the test has a number
that has larger exponent than IBM 128-bit long double can handle, and it
expects the conversion to return infinity.  But IEEE 128-bit has a much larger
exponenent range, so it doesn't return infinity.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.

[Michael Meissner via Gcc-patches]

On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> On Thu, Nov 19, 2020 at 03:08:05AM -0500, Michael Meissner wrote:
> > On Wed, Nov 18, 2020 at 04:29:09PM -0600, Segher Boessenkool wrote:
> > > Mike, please add a comment, what number it represents?  Okay for trunk
> > > with that, thanks.
> > > 
> > > (Should those not be define in some header though?)
> > 
> > When long double is IBM extended double, then LDBL_MAX, etc. is set with 
> > math.h
> > (and the __ version created by the compiler).  We don't have min/max for the
> > funky MD only floating point numbers defined.  I got the number by printing
> > LDBL_MAX in fact and just pasting that in.
> 
> Sure -- I am suggesting to always define __IBM128_MAX__ and the like,
> which then can be used to define LDBL_MAX, but also can be used
> directly.

I have posted patches for this as a new set of patches.  Rather than trying to
create IBM 128-bit long double min/max/etc. defines, I just marked the test as
needing IBM 128-bit long double.

I did look into providing defines for these.  Unfortunately the function that
creates these (builtin_define_float_constants) is static.  And the caller of
that function (c_cpp_builtins) does not have a target hook or other method to
provide for these defines for MD specific floating point types.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATH 0/3] Updated PowerPC tests for long double

[Michael Meissner via Gcc-patches]

These 3 patches are the slight reworking of two separate patches for the
library tests.

The first patch that has been replaced is:
Date: Sun, 15 Nov 2020 12:17:47 -0500
Subject: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.
Message-ID: <20201115171747.ga10...@ibm-toto.the-meissners.org>

The second patch that has been replaced is:
Date: Sun, 15 Nov 2020 12:23:50 -050
Subject: [PATCH] PowerPC: Restrict long double test to use IBM long double.
Message-ID: <20201115172350.ga10...@ibm-toto.the-meissners.org>

These 3 patches are:

1) Patch to target-supports.exp that adds 3 new targets to explicitly test for
the PowerPC long double type.  In the previous patches, I only added the patch
that I needed (long double == IBM 128-bit).  This time, I'm adding all 3
varieties of long double.  I also insured that the target-supports only runs on
PowerPC.

2) Patch to gcc/testsuite/gcc.target/powerpc/pr70117.c to restrict it to IBM
128-bit long double.  I removed the #ifdefs in the test that tried to use
__ibm128.  The previous patch tried to use a #define for the IEEE 128-bit
maximum value.

3) Patch to gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c to only run the
test if long double is IBM 128-bit.  I moved the target supports code to the
first patch in this series.  I also changed the requirement from powerpc-linux
to dfp.

I have run these tests with compilers using IEEE 128-bit long double, IBM
128-bit long double, and 64-bit long double.  I verified that the tests are
skipped as UNSUPPORTED if long double is not IBM 128-bit, and they pass on IBM
128-bit long double.

Can I check these patches into the master branch?  Ideally, I would like to
back port these patches to earlier GCC branches.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] Power10: Add missing IEEE 128-bit XSCMP* built-in mappings.

[Michael Meissner via Gcc-patches]

Power10: Add missing IEEE 128-bit XSCMP* built-in mappings.

This patch is a simplification of earlier patches to fix the built-in functions
that introduced new power10 IEEE 128-bit instructions.  Some of the built-in
functions were already handled, but the scalar_cmp_exp_qp_gt, etc. functions
were not handled.  This shows up in the float128-cmp2-runnable.c test when long
double uses the IEEE 128-bit representation.

I had done the previous patches fairly quickly, forgetting about the switch
inside of rs6000_expand_builtin in rs6000-call.c that switches between KF and
TF built-in functions without having to add overloaded function names.  This
patch uses that simpler method.

The previous patches were at:

Date: Thu, 24 Sep 2020 16:42:59 -0400
Subject: [PATCH 7/9] PowerPC: Update IEEE 128-bit built-in functions to work if 
long double is IEEE 128-bit.
Message-ID: <20200924204259.gg31...@ibm-toto.the-meissners.org>

Date: Thu, 22 Oct 2020 18:03:46 -0400
Subject: PowerPC: Map IEEE 128-bit long double built-in functions
Message-ID: <2020100346.ga8...@ibm-toto.the-meissners.org>

I have built two sets of bootstrap compilers on a little endian power9 server
system running Linux.  One compiler used the default IBM IEEE 128-bit long
double support and the other used IEEE 128-bit for the long double.  This patch
fixes the failure in the float128-cmp2-runnable.c test, and it adds no other
regressions.  Can I check this patch into the master branch?


2020-11-18  Michael Meissner  

* config/rs6000/rs6000-call.c (rs6000_expand_builtin): Add missing
XSCMP* cases for IEEE 128-bit long double.
---
 gcc/config/rs6000/rs6000-call.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 8294e22fb85..1fdb39f15c0 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -12803,6 +12803,22 @@ rs6000_expand_builtin (tree exp, rtx target, rtx 
subtarget ATTRIBUTE_UNUSED,
   case CODE_FOR_xsiexpqp_kf:   icode = CODE_FOR_xsiexpqp_tf;   break;
   case CODE_FOR_xsiexpqpf_kf:  icode = CODE_FOR_xsiexpqpf_tf;  break;
   case CODE_FOR_xststdcqp_kf:  icode = CODE_FOR_xststdcqp_tf;  break;
+
+  case CODE_FOR_xscmpexpqp_eq_kf:
+   icode = CODE_FOR_xscmpexpqp_eq_tf;
+   break;
+
+  case CODE_FOR_xscmpexpqp_lt_kf:
+   icode = CODE_FOR_xscmpexpqp_lt_tf;
+   break;
+
+  case CODE_FOR_xscmpexpqp_gt_kf:
+   icode = CODE_FOR_xscmpexpqp_gt_tf;
+   break;
+
+  case CODE_FOR_xscmpexpqp_unordered_kf:
+   icode = CODE_FOR_xscmpexpqp_unordered_tf;
+   break;
   }
 
   if (TARGET_DEBUG_BUILTIN)
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] PowerPC: Add float128/Decimal conversions

[Michael Meissner via Gcc-patches]

[PATCH] PowerPC: Add float128/Decimal conversions.

I accidently posted this patch on an internal IBM mailing list instead of
gcc-patches.

This patch replaces the following two patches:

September 24th, 2020:
Message-ID: <20200924203545.gd31...@ibm-toto.the-meissners.org>

October 22nd, 2020:
Message-ID: <2020100603.ga11...@ibm-toto.the-meissners.org>

This is a simplification of those patches.  Those patches were initially
written before I was using the final glibc 2.32 (Advance Toolchain AT14.0).
With using that glibc and with the previous IEEE patches submitted, I can
simplify the conversions to just use the long double defaults, compiling the
modules for IEEE 128-bit long double.  It works because stdio.h/gcc switches
the sprintf call to __sprintfieee128, and the strtold call to __strtof128.

While most of the Decimal <-> Long double tests now pass when long doubles are
IEEE 128-bit, there is one test that fails:

c-c++-common/dfp/convert-bfp-11.c

This test explicitly expects long double to be IBM 128-bit extended double.  A
later patch will fix this.

If the glibc is not 2.32 or later, this code just compiles to using abort.
That way the user won't get unknown reference errors due to the calls to the
glibc 2.32 functions that aren't in previous glibcs.

This patch is one of three critical patches needed to be able to build
compilers where the default is IEEE 128-bit.  The other patches were the
patches to rename the built-in functions, and the patches for prs 97543 and
97643 that were both posted earlier.

I have tested this patch on a little endian power9 system running Linux,
building bootstrap compilers with the 3 long double flavors (long double is
128-bit IEEE, long double is 128-bit IBM, and long double is 64-bit).  There
are no regressions with long double set to 128-bit IBM.

With the exception of convert-bfp-11.c mentioned above, none of the regressions
in the long double set to 128-bit IEEE affect the decimal support.

Can I check this into the master branch?

libgcc/
2020-11-17  Michael Meissner  

* config/rs6000/t-float128 (fp128_dec_funcs): New macro.
(ibm128_dec_funcs): New macro.
(fp128_ppc_funcs): Add the Decimal <-> __float128 conversions.
(fp128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(ibm128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(FP128_CFLAGS_DECIMAL): New macro.
(IBM128_CFLAGS_DECIMAL): New macro.
* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
* config/rs6000/_kf_to_sd.c: New file.
* config/rs6000/_kf_to_td.c: New file.
* config/rs6000/_sd_to_kf.c: New file.
* config/rs6000/_td_to_kf.c: New file.
---
 libgcc/config/rs6000/_dd_to_kf.c | 58 +++
 libgcc/config/rs6000/_kf_to_dd.c | 57 ++
 libgcc/config/rs6000/_kf_to_sd.c | 58 +++
 libgcc/config/rs6000/_kf_to_td.c | 56 ++
 libgcc/config/rs6000/_sd_to_kf.c | 59 
 libgcc/config/rs6000/_td_to_kf.c | 58 +++
 libgcc/config/rs6000/t-float128  | 26 +-
 7 files changed, 371 insertions(+), 1 deletion(-)
 create mode 100644 libgcc/config/rs6000/_dd_to_kf.c
 create mode 100644 libgcc/config/rs6000/_kf_to_dd.c
 create mode 100644 libgcc/config/rs6000/_kf_to_sd.c
 create mode 100644 libgcc/config/rs6000/_kf_to_td.c
 create mode 100644 libgcc/config/rs6000/_sd_to_kf.c
 create mode 100644 libgcc/config/rs6000/_td_to_kf.c

diff --git a/libgcc/config/rs6000/_dd_to_kf.c b/libgcc/config/rs6000/_dd_to_kf.c
new file mode 100644
index 000..93601fa280e
--- /dev/null
+++ b/libgcc/config/rs6000/_dd_to_kf.c
@@ -0,0 +1,58 @@
+/* Copyright (C) 1989-2020 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+/* Decimal64 -> _Float128 conversion.  */
+
+/* FINE_GRAINED_LIBRARIES is used so we can isolate just to dd_to_tf 

[PATCH] PowerPC: Set long double size for IBM/IEEE.

[Michael Meissner via Gcc-patches]

[PATCH] PowerPC: Set long double size for IBM/IEEE.

I originally posted this patch to an internal IBM mailing list instead of
gcc-patches.

As I was working with compilers where the long double default was 64-bit, it
became annoying to have to use two options to switch to one of the 128-bit long
double types (i.e. you need both -mlong-double-128 and the
-mabi={ieee,ibm}longdouble to switch the long double type).

I did this patch so that if you explicitly set the long double ABI via the
-mabi= option, it would automatically set the long double size if that was not
set explicitly.

gcc/
2020-11-17  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_option_override_internal): If the
user explicitly used -mabi=ieeelongdouble or -mabi=ibmlongdouble,
set the long double size to 128.
* doc/invoke.texi (PowerPC options): Document that an explicit
-mabi=ieeelongdouble or -mabi=ibmlongdouble implicitly sets
-mlong-double-128.
---
 gcc/config/rs6000/rs6000.c | 9 +++--
 gcc/doc/invoke.texi| 7 ---
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 35e9c844e17..6edd17a0b69 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4131,8 +4131,13 @@ rs6000_option_override_internal (bool global_init_p)
 
   /* Use long double size to select the appropriate long double.  We use
  TYPE_PRECISION to differentiate the 3 different long double types.  We map
- 128 into the precision used for TFmode.  */
-  int default_long_double_size = (RS6000_DEFAULT_LONG_DOUBLE_SIZE == 64
+ 128 into the precision used for TFmode.
+
+ If the user explicitly used -mabi=ieeelongdouble or -mabi=ibmlongdouble,
+ but the compiler was configured for default 64-bit long doubles, set the
+ long double to be 128.  */
+  int default_long_double_size = ((RS6000_DEFAULT_LONG_DOUBLE_SIZE == 64
+  && !global_options_set.x_rs6000_ieeequad)
  ? 64
  : FLOAT_PRECISION_TFmode);
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3510a54c6c4..89d530f1d1e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -27113,7 +27113,8 @@ Change the current ABI to use IBM extended-precision 
long double.
 This is not likely to work if your system defaults to using IEEE
 extended-precision long double.  If you change the long double type
 from IEEE extended-precision, the compiler will issue a warning unless
-you use the @option{-Wno-psabi} option.  Requires @option{-mlong-double-128}
+you use the @option{-Wno-psabi} option.  If this option is used, it
+will implicitly enable @option{-mlong-double-128}.
 to be enabled.
 
 @item -mabi=ieeelongdouble
@@ -27122,8 +27123,8 @@ Change the current ABI to use IEEE extended-precision 
long double.
 This is not likely to work if your system defaults to using IBM
 extended-precision long double.  If you change the long double type
 from IBM extended-precision, the compiler will issue a warning unless
-you use the @option{-Wno-psabi} option.  Requires @option{-mlong-double-128}
-to be enabled.
+you use the @option{-Wno-psabi} option.  If this option is used, it
+will implicitly enable @option{-mlong-double-128}.
 
 @item -mabi=elfv1
 @opindex mabi=elfv1
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] PowerPC: Map IEEE 128-bit long double built-in functions

[Michael Meissner via Gcc-patches]

[PATCH] PowerPC: Map IEEE 128-bit long double built-in functions.

I posted this patch by accident to an internal IBM mailing list instead of
gcc-patches.

This patch replaces patches previously submitted:

September 24th, 2020:
Message-ID: <20200924203159.ga31...@ibm-toto.the-meissners.org>

October 9th, 2020:
Message-ID: <20201009043543.ga11...@ibm-toto.the-meissners.org>

October 24th, 2020:
Message-ID: <2020100346.ga8...@ibm-toto.the-meissners.org>

This patch maps the built-in functions that take or return long double
arguments on systems where long double is IEEE 128-bit.

This patch goes through the built-in functions and changes the name of the
math, scanf, and printf built-in functions to use the functions that GLIBC
provides when long double uses the IEEE 128-bit representation.

In addition, changing the name in GCC allows the Fortran compiler to
automatically use the correct name.

To map the math functions, typically this patch changes l to
__ieee128.  However there are some exceptions that are handled with this
patch.

To map the printf functions,  is mapped to __ieee128.

To map the scanf functions,  is mapped to __isoc99_ieee128.

With the other IEEE long double patches, I have tested this patch by building 3
bootstrap compilers on a little endian power9 system, using the Advance
Toolchain AT14.0 library, which uses GLIBC 2.32:

1)  One compiler defaulted long double to IBM extended double;
2)  One compiler defaulted long double to IEEE 128-bit; (and)
3)  One compiler defaulted long double to 64 bit.

I was able to bootstrap each compiler and run make check.  In addition for the
compilers using the two 128-bit long double types (IBM, IEEE), I have built the
spec 2017 benchmark for both power9 and power10.

At the moment, there are some differences between between the three runs for
make check.  I have some patches to fix these issue that I've done in the past,
and I will be working on resubmitting them in the future.

In addition, there are 3 fortran benchmarks (ieee/large_2.f90,
default_format_2.f90, and default_format_denormal_2.f90) that now pass when the
long double default is IEEE 128-bit.

Can I check this into the master branch?

gcc/
2020-11-17  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_mangle_decl_assembler_name): Add
support for mapping built-in function names for long double
built-in functions if long double is IEEE 128-bit.

gcc/testsuite/
2020-11-17  Michael Meissner  

* gcc.target/powerpc/float128-longdouble-math.c: New test.
* gcc.target/powerpc/float128-longdouble-stdio.c: New test.
* gcc.target/powerpc/float128-math.c: Adjust test for new name
being generated.  Add support for running test on power10.  Add
support for running if long double defaults to 64-bits.
---
 gcc/config/rs6000/rs6000.c| 135 --
 .../powerpc/float128-longdouble-math.c| 442 ++
 .../powerpc/float128-longdouble-stdio.c   |  36 ++
 .../gcc.target/powerpc/float128-math.c|  16 +-
 4 files changed, 589 insertions(+), 40 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-math.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-stdio.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index a5188553593..35e9c844e17 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -27065,57 +27065,128 @@ rs6000_globalize_decl_name (FILE * stream, tree decl)
library before you can switch the real*16 type at compile time.
 
We use the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change this name.  We
-   only do this if the default is that long double is IBM extended double, and
-   the user asked for IEEE 128-bit.  */
+   only do this transformation if the __float128 type is enabled.  This
+   prevents us from doing the transformation on older 32-bit ports that might
+   have enabled using IEEE 128-bit floating point as the default long double
+   type.  */
 
 static tree
 rs6000_mangle_decl_assembler_name (tree decl, tree id)
 {
-  if (!TARGET_IEEEQUAD_DEFAULT && TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128
+  if (TARGET_FLOAT128_TYPE && TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128
   && TREE_CODE (decl) == FUNCTION_DECL
-  && DECL_IS_UNDECLARED_BUILTIN (decl))
+  && DECL_IS_UNDECLARED_BUILTIN (decl)
+  && DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
 {
   size_t len = IDENTIFIER_LENGTH (id);
   const char *name = IDENTIFIER_POINTER (id);
+  char *newname = NULL;
 
-  if (name[len - 1] == 'l')
+  /* See if it is one of the built-in functions with an unusual name.  */
+  switch (DECL_FUNCTION_CODE (decl))
{
- bool uses_ieee128_p = false;
- tree type = TREE_TYPE (decl);
- machine_mode ret_mode = TYPE_MODE (type);
+   case BUILT_IN_DREML:
+ newname = xstrdup ("__remainderieee128");
+ 

[PATCH] PowerPC: PR 97791: Fix gnu attributes.

[Michael Meissner via Gcc-patches]

[PATCH] PowerPC: PR 97791: Fix gnu attributes.

Note, I originally posted this to an internal IBM mailing list, not to
gcc-patches.  Sorry about that.

This patch does two things to fix setting gnu attribute #4 (long double status)

1) Only set gnu attribute #4 if long double was passed.  Passing __float128
when long double is IBM or __ibm128 when long double is IEEE no longer sets the
attribute.  This resulted in a lot of false positives, such as using __float128
and no long double support.

2) Do not set the gnu attribute if a mode used by long double (TF or DF) is
used in a move.  The moves do not differentiate between the long double type
and similar types.  Delete the three tests that tested this.

I wrote the code for the move several years.  I wanted to flag that an object
that used the appropriate long double type got flagged.  Unfortunately, at the
RTL level, we have lost the type nodes, so we can't tell the difference between
two types that use the same mode (for instance if long double is 64-bit, the
attribute would be set if you used normal doubles, and not long doubles).  Alan
Modra and I discussed this, and we think this is just the right thing to do.

It has been tested on power8 big endian Linux server systems and power9 little
endian Linux server systems, and there were no regressions.

gcc/
2020-11-17  Michael Meissner  

PR gcc/97791
* config/rs6000/rs6000-call.c (init_cumulative_args): Only set
that long double was returned if the type is actually long
double.
(rs6000_function_arg_advance_1): Only set that long double was
passed if the type is actually long double.
* config/rs6000/rs6000.c (rs6000_emit_move): Delete code that sets
whether long double was passed based on the modes used in moves.

gcc/testsuite/
2020-11-17  Michael Meissner  

PR target/97791
* gcc.target/powerpc/gnuattr1.c: Delete.
* gcc.target/powerpc/gnuattr2.c: Delete.
* gcc.target/powerpc/gnuattr3.c: Delete.
---
 gcc/config/rs6000/rs6000-call.c | 13 -
 gcc/config/rs6000/rs6000.c  | 17 -
 gcc/testsuite/gcc.target/powerpc/gnuattr1.c | 15 ---
 gcc/testsuite/gcc.target/powerpc/gnuattr2.c | 17 -
 gcc/testsuite/gcc.target/powerpc/gnuattr3.c | 15 ---
 5 files changed, 4 insertions(+), 73 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/powerpc/gnuattr1.c
 delete mode 100644 gcc/testsuite/gcc.target/powerpc/gnuattr2.c
 delete mode 100644 gcc/testsuite/gcc.target/powerpc/gnuattr3.c

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 3bd89a79bad..8294e22fb85 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -6539,11 +6539,8 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, tree fntype,
{
  rs6000_passes_float = true;
  if ((HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT)
- && (FLOAT128_IBM_P (return_mode)
- || FLOAT128_IEEE_P (return_mode)
- || (return_type != NULL
- && (TYPE_MAIN_VARIANT (return_type)
- == long_double_type_node
+ && return_type != NULL
+ && TYPE_MAIN_VARIANT (return_type) == long_double_type_node)
rs6000_passes_long_double = true;
 
  /* Note if we passed or return a IEEE 128-bit type.  We changed
@@ -7001,10 +6998,8 @@ rs6000_function_arg_advance_1 (CUMULATIVE_ARGS *cum, 
machine_mode mode,
{
  rs6000_passes_float = true;
  if ((HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT)
- && (FLOAT128_IBM_P (mode)
- || FLOAT128_IEEE_P (mode)
- || (type != NULL
- && TYPE_MAIN_VARIANT (type) == long_double_type_node)))
+ && type != NULL
+ && TYPE_MAIN_VARIANT (type) == long_double_type_node)
rs6000_passes_long_double = true;
 
  /* Note if we passed or return a IEEE 128-bit type.  We changed the
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index b6fd21a5d6f..a5188553593 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -10076,23 +10076,6 @@ rs6000_emit_move (rtx dest, rtx source, machine_mode 
mode)
   && GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT)
 gcc_unreachable ();
 
-#ifdef HAVE_AS_GNU_ATTRIBUTE
-  /* If we use a long double type, set the flags in .gnu_attribute that say
- what the long double type is.  This is to allow the linker's warning
- message for the wrong long double to be useful, even if the function does
- not do a call (for example, doing a 128-bit add on power9 if the long
- double type is IEEE 128-bit.  Do not set this if __ibm128 or __floa128 are
- used if they aren't the default long dobule type.  */
-  if 

[PATCH] PowerPC: PR libgcc/97543, fix 64-bit long double issues

[Michael Meissner via Gcc-patches]

PowerPC: PR libgcc/97543, fix 64-bit long double issues

I meant to post this to the gcc-patches mailing list last Thursday, but I see I
posted this to an internal IBM mailing list.

This patch replaces the previous iterations of this patch:

October 22nd, 2020:
Message-ID: <2020100510.ga11...@ibm-toto.the-meissners.org>

October 28th, 2020:
Message-ID: <20201029004204.ga15...@ibm-toto.the-meissners.org

If you use a compiler with long double defaulting to 64-bit instead of 128-bit
with IBM extended double, you get linker warnings about mis-matches in the gnu
attributes for long double (PR libgcc/97543).  Even if the compiler is
configured to have long double be 64 bit as the default with the configuration
option '--without-long-double-128' you get the warnings.

You also get the same issues if you use a compiler with long double defaulting
to IEEE 128-bit instead of IBM extended double (PR libgcc/97643).

The issue is the way libgcc.a/libgcc.so is built.  Right now when building
libgcc under Linux, the long double size is set to 128-bits when building
libgcc.  However, the gnu attributes are set, leading to the warnings.

One feature of the current GNU attribute implementation is if you have a shared
library (such as libgcc_s.so), the GNU attributes for the shared library is an
inclusive OR of all of the modules within the library.  This means if any
module uses the -mlong-double-128 option and uses long double, the GNU
attributes for the library will indicate that it uses 128-bit IBM long
doubles.  If you have a static library, you will get the warning only if you
actually reference a module with the attribute set.

This patch does two things:

1)  All of the modules that support IBM 128-bit long doubles explicitly set
the ABI to IBM extended double.

2) I turned off GNU attributes for building the shared library or for
building the IBM 128-bit long double support.

I have discussed this patch with Alan Modra, and made several changes based on
his suggestions.

I have tested this on a little endian power9 system running Linux by building
three separate compilers, using the Advance Toolchain AT14.0 which uses GLIBC
2.32:

1)  A compiler where the long double default is IBM 128-bit double;
2)  A compiler where the long double default is IEEE 128-bit double; (and)
3)  A compiler where the long double default is 64-bit.

Note, for the IEEE build (#2), the other patches that I will be submitting are
needed to enable the full build.

For each of the 3 compilers, I then tested some code with long double's and
verified that each of the long double options worked without generating
warnings.

In addition, I have tested this patch on a big endian power8 system running
Linux, and there were no regressions.

Can I install this patch into the master branch?  Since this is a bug for
64-bit long doubles, I would like to back port it to GCC 10, and GCC 9 after a
shake-in period.

libgcc/
2020-11-17  Michael Meissner  

PR libgcc/97543
PR libgcc/97643
* config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable.
(IBM128_SHARED_OBJS): New make variable.
(IBM128_OBJS): New make variable.  Set all objects to use the
explicit IBM format, and disable gnu attributes.
(IBM128_CFLAGS): New make variable.
(gcc_s_compile): Add -mno-gnu-attribute to all shared library
modules.
---
 libgcc/config/rs6000/t-linux | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/libgcc/config/rs6000/t-linux b/libgcc/config/rs6000/t-linux
index ed821947b66..72e9c2770a6 100644
--- a/libgcc/config/rs6000/t-linux
+++ b/libgcc/config/rs6000/t-linux
@@ -6,3 +6,25 @@ HOST_LIBGCC2_CFLAGS += -mlong-double-128
 # smaller and faster libgcc code.  Directly specifying -mcmodel=small
 # would need to take into account targets for which -mcmodel is invalid.
 HOST_LIBGCC2_CFLAGS += -mno-minimal-toc
+
+# On the modules that deal with IBM 128-bit values, make sure that TFmode uses
+# the IBM extended double format.  Also turn off gnu attributes on the static
+# modules.
+IBM128_STATIC_OBJS = ibm-ldouble$(objext) _powitf2$(objext) \
+ ppc64-fp$(objext) _divtc3$(object) _multc3$(object) \
+ _fixtfdi$(object) _fixunstfdi$(object) \
+ _floatditf$(objext) _floatunsditf$(objext)
+IBM128_SHARED_OBJS = $(IBM128_STATIC_OBJS:$(objext):_s$(objext))
+IBM128_OBJS= $(IBM128_STATIC_OBJS) $(IBM128_SHARED_OBJS)
+
+IBM128_CFLAGS  = -Wno-psabi -mabi=ibmlongdouble -mno-gnu-attribute
+
+$(IBM128_OBJS) : INTERNAL_CFLAGS += $(IBM128_CFLAGS)
+
+# Turn off gnu attributes for long double size on all of the shared library
+# modules, but leave it on for the static modules, except for the functions
+# that explicitly process IBM 128-bit floating point.  Shared libraries only
+# have one gnu attribute for the whole library, and it can lead to warnings if
+# 

Re: [PATCH] PowerPC: Restrict long double test to use IBM long double.

[Michael Meissner via Gcc-patches]

On Wed, Nov 18, 2020 at 01:27:12PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Sun, Nov 15, 2020 at 12:23:50PM -0500, Michael Meissner wrote:
> > --- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > +++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > @@ -1,4 +1,5 @@
> >  /* { dg-skip-if "" { ! "powerpc*-*-linux*" } } */
> > +/* { dg-require-effective-target ppc_long_double_ibm } */
> 
> You can remove the dg-skip-if then (there is nothing in this test that
> requires Linux).  But you want a
> /* { dg-require-effective-target dfp } */
> (or dfprt).
> 
> So what happens if you use IEEE QP float, instead?  You didn't explain.
> (Explain in the source code, with a comment where you require it!)

The test fails because QP doesn't produce the exact value that is looked for.
Given all of the comments in the source explicitly say it is testing IBM
extended double, I just decided we could not support the test wth IEEE
128-bit.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.

[Michael Meissner via Gcc-patches]

On Wed, Nov 18, 2020 at 04:29:09PM -0600, Segher Boessenkool wrote:
> On Wed, Nov 18, 2020 at 10:53:49PM +0100, Jakub Jelinek wrote:
> > On Wed, Nov 18, 2020 at 03:43:20PM -0600, Segher Boessenkool wrote:
> > > Hi!
> > > 
> > > On Sun, Nov 15, 2020 at 12:17:47PM -0500, Michael Meissner wrote:
> > > > --- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > > > +++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > > > @@ -9,9 +9,11 @@
> > > > 128-bit floating point, because the type is not enabled on those
> > > > systems.  */
> > > >  #define LDOUBLE __ibm128
> > > > +#define IBM128_MAX ((__ibm128) 
> > > > 1.79769313486231580793728971405301199e+308L)
> > > 
> > > This is the IEEE QP float number 43fef780 which
> > > I very much doubt is the maximum finite double-double?  See the 0 in the
> > 
> > Numbers without the 0 in the middle-end aren't valid, see
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450#c6
> > for more details.  Without the 0 in the middle the double double number
> > rounded to double would require increasing the higher double, and as it is
> > the largest representable finite number, that is not possible.
> 
> Ah, in that way.  Tricky.
> 
> Mike, please add a comment, what number it represents?  Okay for trunk
> with that, thanks.
> 
> (Should those not be define in some header though?)

When long double is IBM extended double, then LDBL_MAX, etc. is set with math.h
(and the __ version created by the compiler).  We don't have min/max for the
funky MD only floating point numbers defined.  I got the number by printing
LDBL_MAX in fact and just pasting that in.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] PowerPC: Restrict long double test to use IBM long double.

[Michael Meissner via Gcc-patches]

On Tue, Nov 17, 2020 at 11:33:29PM -0600, will schmidt wrote:
> On Sun, 2020-11-15 at 12:23 -0500, Michael Meissner via Gcc-patches wrote:
> > PowerPC: Restrict long double test to use IBM long double.
> > 
> > I posted this patch previously as a set of 3 testsuite patches.  I have
> > separated them into separate patches.  This patch marks the convert-bfp-11.c
> > patch as needing IBM extended double.  If you look at the code, it is
> > specifically designed around testing the limits of the IBM 128-bit extended
> > double representation.  I added a new target-supports that says the test
> > requires IBM extended long double, and changed the test to require this
> > effective test.  Can I check this into the master branch?
> 
> 
> It's harder to review that without all the history handy here.
> 
> This will stand alone better if you lead with what you are adding and
> keep it clean.  i.e.

The patch I was referring to was posted on October 22nd:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556865.html
 
> Subject: PowerPC: Add ppc_long_double_ibm effective-target check
> 
> "Add a ppc_long_double_ibm dg-require-effective-target check to ensure
> tests that require LONG_DOUBLE_IBM128 . "
> An additional statement to clarify it's relationship with I128
> wouldn't  hurt if that is the case.  i.e. 
> "This is a counterpart to LONG_DOUBLE_IEEE 128 " 

At the moment, we don't need a target supports for long double IEEE 128-bit or
long double 64-bit.  I can add them if needed.

> Hmm, I have those backwards in my head apparently.  Can the return 1 if
> not-defined logic be flattened out so we see the direct relationship?

I'm not sure what you are asking.  These are preprocessor macros that are only
defined in certain cases.  And remember this is main returning a value, so
returning 0 is true and 1 is false.

In particular:

If your long double is 128-bits and uses the IEEE 128-bit representation, the
following macros are defined:

__LONG_DOUBLE_128__
__LONG_DOUBLE_IEEE128__

If your long double is 128-bit and uses the IBM 128-bit representation (current
default0, the following macros are defined:

__LONG_DOUBLE_128__
__LONG_DOUBLE_IBM128__

If your long double is 64 bits, neither of those two macros are defined.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] Include math.h in nextafter-2.c test.

[Michael Meissner via Gcc-patches]

On Tue, Nov 17, 2020 at 11:33:23PM -0600, will schmidt wrote:
> On Sun, 2020-11-15 at 12:12 -0500, Michael Meissner via Gcc-patches wrote:
> > Include math.h in nextafter-2.c test.
> > 
> > I previously posted this with two other patches.  I've separated this into 
> > its
> > own patch.  What happens is because the nextafter-2.c test uses 
> > -fno-builtin,
> > and it does not include math.h, the wrong nextafterl and nextforwardl gets
> > called when long double is not IBM 128-bit (i.e. either 64-bit, or IEEE
> > 128-bit).
> 
> Thats a sandbox issue, or something upstream ?

I'm not sure what you are asking.  If you install the three critical IEEE
128-bit long double patches, and then configure a build with long double
defaulting to IEEE 128-bit, the nextafter-2 test will fail.

The reason is the nextafterl function in GLIBC assumes long double is IBM
128-bit extended double.  The __builtin_nextafterl function calls that
function.

If you compile it normally (with long double using IEEE 128-bit), the compiler
will automatically map nextafterl to __nextafterieee128.

Similarly if you include math.h, and use the -fno-builtin option, the math.h
library will still map nextafterl into __nextafterieee128, and the compiler
will call it.

However, if you do not include math.h and use the -fno-builtin option, the
compiler will call nextafterl, and get the wrong results, because the wrong
function was called.

What I meant in terms of the 3 patches being separated, the last time I posted
a patch for this problem, I grouped together 3 test suite failures into one
patch.  This time, I separated the cases into 3 separate patches (this one, the
fix for pr70117, and the fix for the decimal conversion test).

> > 
> > Rather than add the include only for the PowerPC, I thought it was better to
> > always include it.  There might be some port in the future that has the same
> > issue with multiple long double types without using multilibs.
> > 
> > Can I check this into the master branch.
> > 
> > 2020-11-15  Michael Meissner  
> > 
> > * gcc.dg/nextafter-2.c: Include math.h.
> > ---
> >  gcc/testsuite/gcc.dg/nextafter-2.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/gcc/testsuite/gcc.dg/nextafter-2.c 
> > b/gcc/testsuite/gcc.dg/nextafter-2.c
> > index e51ae94be0c..8149a709fa5 100644
> > --- a/gcc/testsuite/gcc.dg/nextafter-2.c
> > +++ b/gcc/testsuite/gcc.dg/nextafter-2.c
> > @@ -6,6 +6,18 @@
> > 
> >  #include 
> > 
> > +/* In order to run on systems like the PowerPC that have 3 different long
> > +   double types, include math.h so it can choose what is the appropriate
> > +   nextafterl function to use.
> > +
> > +   If we didn't use -fno-builtin for this test, the PowerPC compiler would 
> > have
> > +   changed the names of the built-in functions that use long double.  The
> > +   nextafter-1.c function runs with this mapping.
> > +
> > +   Since this test uses -fno-builtin, include math.h, so that math.h can 
> > make
> > +   the appropriate choice to use.  */
> 
> 
> 
> Can this be simplified to stl
> 
> /* Include math.h so that systems like PowerPC that have different long
> double types can choose the appropriate nextafterl function to use.  */
> 
> 
> > +#include 
> > +
> >  #if defined(__GLIBC__) && defined(__GLIBC_PREREQ)
> >  # if !__GLIBC_PREREQ (2, 24)
> >  /* Workaround buggy nextafterl in glibc 2.23 and earlier,
> > -- 
> > 2.22.0
> > 
> > 

Sure, the comment is just trying to explain why math.h needs to be included.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move

[Michael Meissner via Gcc-patches]

Power10: Add IEEE 128-bit fp conditional move.

This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max.  Unlike the previous patch, I
decided to keep two separate patterns for fpmask before splitting (one pattern
for normal compares, and the other pattern for inverted compares).  I can go
back to a single pattern with a new predicate that allows either comparison.

Compared to the original code, these patterns do simplify the fpmask insns to
having one alternative instead of two.  In the original code, the first
alternative tried to use the result as a temporary register.  But that doesn't
work if you are doing a conditional move with SF/DF types, but the comparison
is KF/TF.  That is because the SF/DF types can use the traditional FPR
registers, but IEEE 128-bit floating point can only do arithmetic in the
traditional Altivec registers.

This code also has to insert a XXPERMDI if you are moving KF/TF values, but
the comparison is done with SF/DF values.  In this case, the set and compare
mask for SF/DF clears the bottom 64-bits of the register, and the XXPERMDI is
needed to fill it.

I have tested these patches with a bootstrap compiler on a little endian power9
system and also on a big endian power8 system.  There were no regressions.  Can
I check this patch into the master branch?

gcc/
2020-11-15 Michael Meissner  

* config/rs6000/rs6000.c (have_compare_and_set_mask): Add IEEE
128-bit floating point types.
* config/rs6000/rs6000.md (FPMASK): New iterator.
(FPMASK2): New iterator.
(Fv mode attribute): Add KFmode and TFmode.
(movcc_fpmask): Replace
movcc_p9.  Add IEEE 128-bit fp support.
(movcc_invert_fpmask): Replace
movcc_invert_p9.  Add IEEE 128-bit fp
support.
(fpmask): Add IEEE 128-bit fp support.  Enable generator to
build te RTL.
(xxsel): Add IEEE 128-bit fp support.  Enable generator to
build te RTL.

gcc/testsuite/
2020-11-15  Michael Meissner  

* gcc.target/powerpc/float128-cmove.c: New test.
* gcc.target/powerpc/float128-minmax-3.c: New test.
---
 gcc/config/rs6000/rs6000.c|   8 +-
 gcc/config/rs6000/rs6000.md   | 188 --
 .../gcc.target/powerpc/float128-cmove.c   |  93 +
 .../gcc.target/powerpc/float128-minmax-3.c|  15 ++
 4 files changed, 237 insertions(+), 67 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-cmove.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-minmax-3.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index f6a1f63e842..b6fd21a5d6f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15336,8 +15336,8 @@ rs6000_emit_vector_cond_expr (rtx dest, rtx op_true, 
rtx op_false,
   return 1;
 }
 
-/* Possibly emit the xsmaxcdp and xsmincdp instructions to emit a maximum or
-   minimum with "C" semantics.
+/* Possibly emit the xsmaxc{dp,qp} and xsminc{dp,qp} instructions to emit a
+   maximum or minimum with "C" semantics.
 
Unless you use -ffast-math, you can't use these instructions to replace
conditions that implicitly reverse the condition because the comparison
@@ -15473,6 +15473,10 @@ have_compare_and_set_mask (machine_mode mode)
 case E_DFmode:
   return TARGET_P9_MINMAX;
 
+case E_KFmode:
+case E_TFmode:
+  return FLOAT128_MIN_MAX_FPMASK_P (mode);
+
 default:
   break;
 }
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index d8fbac124fb..0a40f3acf78 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -564,6 +564,19 @@ (define_mode_iterator SFDF [SF DF])
 ; And again, for when we need two FP modes in a pattern.
 (define_mode_iterator SFDF2 [SF DF])
 
+; Floating scalars that supports the set compare mask instruction.
+(define_mode_iterator FPMASK [SF
+ DF
+ (KF "FLOAT128_MIN_MAX_FPMASK_P (KFmode)")
+ (TF "FLOAT128_MIN_MAX_FPMASK_P (TFmode)")])
+
+; And again, for patterns that need two (potentially) different floating point
+; scalars that support the set compare mask instruction.
+(define_mode_iterator FPMASK2 [SF
+  DF
+  (KF "FLOAT128_MIN_MAX_FPMASK_P (KFmode)")
+  (TF "FLOAT128_MIN_MAX_FPMASK_P (TFmode)")])
+
 ; A generic s/d attribute, for sp/dp for example.
 (define_mode_attr sd [(SF   "s") (DF   "d")
  (V4SF "s") (V2DF "d")])
@@ -597,8 +610,13 @@ (define_mode_attr Ff   [(SF "f") (DF "d") (DI 
"d")])
 ; SF/DF constraint for arithmetic on VSX registers using instructions added in
 ; ISA 2.06 (power7).  This includes instructions that normally target DF mode,
 ; but are used on SFmode, since internally SFmode values are kept in the DFmode

[PATCH 1/2] Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.

[Michael Meissner via Gcc-patches]

Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.

This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions.  The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.

Originally, I tried to add the min/max instructions via a super defination that
covers all of the types.  In this patch, based on patch feedback, I rewrote the
patch to be simpler and just provide the new instructions as a separate insn.

I have built little endian power9 bootstrap compilers with these patches in it,
and there were no regressions.  I have also build big endian power8 bootstrap
compilers, and there were no regressions.  Can I check this into the master
branch?

gcc/
2020-11-15  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_emit_minmax): Add support for ISA
3.1 IEEE 128-bit floating point xsmaxcqp and xsmincqp instructions.
* config/rs6000/rs6.h (FLOAT128_MIN_MAX_FPMASK_P): New macro.
* config/rs6000/rs6000.md (s3): Add support for the
ISA 3.1 IEEE 128-bit minimum and maximum instructions.

gcc/testsuite/
2020-11-15  Michael Meissner  

* gcc.target/powerpc/float128-minmax-2.c: New test.
---
 gcc/config/rs6000/rs6000.c|  3 ++-
 gcc/config/rs6000/rs6000.h|  5 +
 gcc/config/rs6000/rs6000.md   | 11 +++
 .../gcc.target/powerpc/float128-minmax-2.c| 15 +++
 4 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index d7dcd93f088..f6a1f63e842 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15741,7 +15741,8 @@ rs6000_emit_minmax (rtx dest, enum rtx_code code, rtx 
op0, rtx op1)
   /* VSX/altivec have direct min/max insns.  */
   if ((code == SMAX || code == SMIN)
   && (VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)
- || (mode == SFmode && VECTOR_UNIT_VSX_P (DFmode
+ || (mode == SFmode && VECTOR_UNIT_VSX_P (DFmode))
+ || FLOAT128_MIN_MAX_FPMASK_P (mode)))
 {
   emit_insn (gen_rtx_SET (dest, gen_rtx_fmt_ee (code, mode, op0, op1)));
   return;
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 5a47aa14722..886559dbfdf 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -345,6 +345,11 @@ extern const char *host_detect_local_cpu (int argc, const 
char **argv);
|| ((MODE) == TDmode)   \
|| (!TARGET_FLOAT128_TYPE && FLOAT128_IEEE_P (MODE)))
 
+/* Macro whether the float128 minimum, maximum, and set compare mask
+   instructions are enabled.  */
+#define FLOAT128_MIN_MAX_FPMASK_P(MODE)
\
+  (TARGET_POWER10 && TARGET_FLOAT128_HW && FLOAT128_IEEE_P (MODE))
+
 /* Return true for floating point that does not use a vector register.  */
 #define SCALAR_FLOAT_MODE_NOT_VECTOR_P(MODE)   \
   (SCALAR_FLOAT_MODE_P (MODE) && !FLOAT128_VECTOR_P (MODE))
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 5e5ad9f7c3d..d8fbac124fb 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -5163,6 +5163,17 @@ (define_insn "*s3_vsx"
 }
   [(set_attr "type" "fp")])
 
+;; Min/max for ISA 3.1 IEEE 128-bit floating point
+(define_insn "s3"
+  [(set (match_operand:IEEE128 0 "altivec_register_operand" "=v")
+   (fp_minmax:IEEE128
+(match_operand:IEEE128 1 "altivec_register_operand" "v")
+(match_operand:IEEE128 2 "altivec_register_operand" "v")))]
+  "TARGET_POWER10"
+  "xscqp %0,%1,%2"
+  [(set_attr "type" "vecfloat")
+   (set_attr "size" "128")])
+
 ;; The conditional move instructions allow us to perform max and min operations
 ;; even when we don't have the appropriate max/min instruction using the FSEL
 ;; instruction.
diff --git a/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c 
b/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c
new file mode 100644
index 000..c71ba08c9f8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c
@@ -0,0 +1,15 @@
+/* { dg-require-effective-target ppc_float128_hw } */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-mdejagnu-cpu=power10 -O2 -ffast-math" } */
+
+#ifndef TYPE
+#define TYPE _Float128
+#endif
+
+/* Test that the fminf128/fmaxf128 functions generate if/then/else and not a
+   call.  */
+TYPE f128_min (TYPE a, TYPE b) { return __builtin_fminf128 (a, b); }
+TYPE f128_max (TYPE a, TYPE b) { return __builtin_fmaxf128 (a, b); }
+
+/* { dg-final { scan-assembler {\mxsmaxcqp\M} } } */
+/* { dg-final { scan-assembler {\mxsmincqp\M} } } */
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 0/2] Power10 IEEE 128-bit min, max, cmove

[Michael Meissner via Gcc-patches]

These two patches add support for the XSMAXCQP, XSMINCQP, XSCMP{EQ,GT,GE}QP
instructions in the Power10.  These instructions allow the compiler to generate
minimum, maxmimum, and conditional move support for IEEE 128-bit floating point
type.

I have posted versions of these patches before, going back to at least the June
time frame.  Because I wanted to focus on getting support in the library to
allow long double to be configured as IEEE 128-bit on little endian PowerPC
server systems, I haven't reposted these patches in awhile.  While the other
patches are more important, it would be nice to get these patches into GCC 11.

In these patches, I attempted to address various comments from the previous
times I posted the patches.

There are 2 patches in this set.  The first adds the min/max support if
-ffast-math is used.  The second adds conditional move support, and it enables
the min/max to be generated more often.

I have done bootstrap compilers on both little endian power9 systems and big
endian power8 system many time.  I would like to commit these patches to the
master branch.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] PowerPC: Restrict long double test to use IBM long double.

[Michael Meissner via Gcc-patches]

PowerPC: Restrict long double test to use IBM long double.

I posted this patch previously as a set of 3 testsuite patches.  I have
separated them into separate patches.  This patch marks the convert-bfp-11.c
patch as needing IBM extended double.  If you look at the code, it is
specifically designed around testing the limits of the IBM 128-bit extended
double representation.  I added a new target-supports that says the test
requires IBM extended long double, and changed the test to require this
effective test.  Can I check this into the master branch?

gcc/testsuite/
2020-11-15  Michael Meissner  

* c-c++-common/dfp/convert-bfp-11.c: Require IBM 128-bit long
double.
* lib/target-supports.exp (check_ppc_long_double_ibm): New
function.
(is-effective-target): Add ppc_long_double_ibm.
---
 .../c-c++-common/dfp/convert-bfp-11.c |  1 +
 gcc/testsuite/lib/target-supports.exp | 19 +++
 2 files changed, 20 insertions(+)

diff --git a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c 
b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
index 95c433d2c24..87f6716afb3 100644
--- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
+++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
@@ -1,4 +1,5 @@
 /* { dg-skip-if "" { ! "powerpc*-*-linux*" } } */
+/* { dg-require-effective-target ppc_long_double_ibm } */
 
 /* Test decimal float conversions to and from IBM 128-bit long double. 
Checks are skipped at runtime if long double is not 128 bits.
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ceee78c26a9..dc1100ba96c 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2336,6 +2336,24 @@ proc check_effective_target_ppc_ieee128_ok { } {
 }]
 }
 
+# Return 1 if the target is a powerpc with the long double format uses the IBM
+# extended double format.
+
+proc check_ppc_long_double_ibm { } {
+return [check_cached_effective_target ppc_long_double_ibm {
+   check_runtime_nocache ppc_long_double_ibm {
+   int main()
+   {
+ #ifndef __LONG_DOUBLE_IBM128__
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+   }
+}]
+}
+
 # Return 1 if the target supports executing VSX instructions, 0
 # otherwise.  Cache the result.
 
@@ -7939,6 +7957,7 @@ proc is-effective-target { arg } {
  "power10_hw" { set selected [check_power10_hw_available] }
  "ppc_float128_sw" { set selected [check_ppc_float128_sw_available] }
  "ppc_float128_hw" { set selected [check_ppc_float128_hw_available] }
+ "ppc_long_double_ibm" { set selected [check_ppc_long_double_ibm] }
  "ppc_recip_hw"   { set selected [check_ppc_recip_hw_available] }
  "ppc_cpu_supports_hw" { set selected 
[check_ppc_cpu_supports_hw_available] }
  "ppc_mma_hw" { set selected [check_ppc_mma_hw_available] }
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.

[Michael Meissner via Gcc-patches]

>From 698d9fd8a5701fa4ed9690ddf71d57765921778c Mon Sep 17 00:00:00 2001
From: Michael Meissner 
Date: Sun, 15 Nov 2020 00:48:23 -0500
Subject: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.

This patch was previously posted as a combined patch with 2 other testsuite
patches.  I moved it to a separate patch.

This patch fixes up a failure that I saw when I built a compiler with the long
double default set to IEEE 128-bit instead of IBM 128-bit.  Now compilers with
either 128-bit long double default pass this test.  Can I check this into the
master branch?

gcc/testsuite/
2020-11-15  Michael Meissner  

PR target/70117
* gcc.target/powerpc/pr70117.c: Add support for long double being
IEEE 128-bit.
---
 gcc/testsuite/gcc.target/powerpc/pr70117.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
b/gcc/testsuite/gcc.target/powerpc/pr70117.c
index 3bbd2c595e0..928efe39c7b 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
@@ -9,9 +9,11 @@
128-bit floating point, because the type is not enabled on those
systems.  */
 #define LDOUBLE __ibm128
+#define IBM128_MAX ((__ibm128) 1.79769313486231580793728971405301199e+308L)
 
 #elif defined(__LONG_DOUBLE_IBM128__)
 #define LDOUBLE long double
+#define IBM128_MAX LDBL_MAX
 
 #else
 #error "long double must be either IBM 128-bit or IEEE 128-bit"
@@ -75,10 +77,10 @@ main (void)
   if (__builtin_isnormal (ld))
 __builtin_abort ();
 
-  ld = LDBL_MAX;
+  ld = IBM128_MAX;
   if (!__builtin_isnormal (ld))
 __builtin_abort ();
-  ld = -LDBL_MAX;
+  ld = -IBM128_MAX;
   if (!__builtin_isnormal (ld))
 __builtin_abort ();
 
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] Include math.h in nextafter-2.c test.

[Michael Meissner via Gcc-patches]

Include math.h in nextafter-2.c test.

I previously posted this with two other patches.  I've separated this into its
own patch.  What happens is because the nextafter-2.c test uses -fno-builtin,
and it does not include math.h, the wrong nextafterl and nextforwardl gets
called when long double is not IBM 128-bit (i.e. either 64-bit, or IEEE
128-bit).

Rather than add the include only for the PowerPC, I thought it was better to
always include it.  There might be some port in the future that has the same
issue with multiple long double types without using multilibs.

Can I check this into the master branch.

2020-11-15  Michael Meissner  

* gcc.dg/nextafter-2.c: Include math.h.
---
 gcc/testsuite/gcc.dg/nextafter-2.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/nextafter-2.c 
b/gcc/testsuite/gcc.dg/nextafter-2.c
index e51ae94be0c..8149a709fa5 100644
--- a/gcc/testsuite/gcc.dg/nextafter-2.c
+++ b/gcc/testsuite/gcc.dg/nextafter-2.c
@@ -6,6 +6,18 @@
 
 #include 
 
+/* In order to run on systems like the PowerPC that have 3 different long
+   double types, include math.h so it can choose what is the appropriate
+   nextafterl function to use.
+
+   If we didn't use -fno-builtin for this test, the PowerPC compiler would have
+   changed the names of the built-in functions that use long double.  The
+   nextafter-1.c function runs with this mapping.
+
+   Since this test uses -fno-builtin, include math.h, so that math.h can make
+   the appropriate choice to use.  */
+#include 
+
 #if defined(__GLIBC__) && defined(__GLIBC_PREREQ)
 # if !__GLIBC_PREREQ (2, 24)
 /* Workaround buggy nextafterl in glibc 2.23 and earlier,
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC: Use __float128 instead of __ieee128 in tests.

[Michael Meissner via Gcc-patches]

On Thu, Nov 12, 2020 at 01:26:32PM -0600, Segher Boessenkool wrote:
> Hi,
> 
> On Thu, Oct 22, 2020 at 06:12:31PM -0400, Michael Meissner wrote:
> > Two of the tests used the __ieee128 keyword instead of __float128.  This
> > patch changes those cases to use the official keyword.
> 
> What is "official" about that?
> 
> Why make this change at all?  __ieee128 should work as well!  Did you
> see failures without this patch?  Thos need fixing, then.

We document '__float128'.  We don't document '__ieee128'.  As I said, using
'__ieee128' internally was due some issues in the GCC 7 time frame,
particularly before we had the glibc changes.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC: Add __float128 conversions to/from Decimal

[Michael Meissner via Gcc-patches]

On Thu, Oct 29, 2020 at 10:05:38PM +, Joseph Myers wrote:
> On Thu, 29 Oct 2020, Segher Boessenkool wrote:
> 
> > > Doing these conversions accurately is nontrivial.  Converting via strings 
> > > is the simple approach (i.e. the one that moves the complexity somewhere 
> > > else).  There are more complicated but more efficient approaches that can 
> > > achieve correct conversions with smaller bounds on resource usage (and 
> > > there are various papers published in this area), but those involve a lot 
> > > more code (and precomputed data, with a speed/space trade-off in how much 
> > > you precompute; the BID code in libgcc has several MB of precomputed data 
> > > for that purpose).
> > 
> > Does the printf code in libgcc handle things correctly for IEEE QP float
> > as long double, do you know?
> 
> As far as I know, the code in libgcc for conversions *from* decimal *to* 
> binary (so the direction that uses strtof128 as opposed to the one using 
> strfrom128, in the binary128 case) works correctly, if the underlying libc 
> has accurate string/numeric conversion operations.
> 
> Binary to decimal is another matter, even for cases such as float to 
> _Decimal64.  I've just filed bug 97635 for that.
> 
> Also note that if you want to use printf as opposed to strfromf128 for 
> IEEE binary128 you'll need to use __printfieee128 (the version that 
> expects long double to be IEEE binary128) which was introduced in glibc 
> 2.32, so that doesn't help with the glibc version dependencies.

My latest patches now switches to using the GLIBC 2.32 and __sprintfieee128.
If we don't have glibc 2.32, it just calls abort, so we don't get linker
errors.  I hope to submit it tonight or tomorrow night.

> When I investigated and reported several bugs in the conversion operations 
> in libdfp, I noted (e.g. https://github.com/libdfp/libdfp/issues/29 ) that 
> the libgcc versions were working correctly for those tests (and filed and 
> subsequently fixed one glibc strtod bug, missing inexact exceptions, that 
> I'd noticed while looking at such issues in libdfp).  But the specific 
> case I tested for badly rounded conversions was the case of conversions 
> from decimal to binary, not the case of conversions from binary to 
> decimal, which, as noted above, turn out to be buggy in libgcc.
> 
> Lots of bugs have been fixed in the glibc conversion code over the years 
> (more on the strtod side than in the code shared by printf and strfrom 
> functions).  That code uses multiple-precision operations from GMP, which 
> avoids some complications but introduces others (it also needs to e.g. 
> deal with locale issues, which are irrelevant for libgcc conversions).

Using the sprintf method, I see an error in

c-c++-common/dfp/convert-bfp-11.c

that I didn't see with the method used in the patches with strtof128 and
strfromf128 directly.  I need to track down exactly what the error is.

All of the other dfp conversion tests work fine.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC: Update long double IEEE 128-bit tests.

[Michael Meissner via Gcc-patches]

On Mon, Nov 02, 2020 at 07:00:15PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Oct 22, 2020 at 06:07:14PM -0400, Michael Meissner wrote:
> > This patch fixes 3 tests in the testsuite that fail if long double is set
> > to IEEE 128-bit.
> 
> > * c-c++-common/dfp/convert-bfp-11.c: If long double is IEEE
> > 128-bit, skip the test.
> 
> > --- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > +++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > @@ -5,6 +5,7 @@
> > Don't force 128-bit long doubles because runtime support depends
> > on glibc.  */
> >  
> > +#include 
> >  #include "convert.h"
> >  
> >  volatile _Decimal32 sd;
> > @@ -39,6 +40,12 @@ main ()
> >if (sizeof (long double) != 16)
> >  return 0;
> >  
> > +  /* This test is written to test IBM extended double, which is a pair of
> > + doubles.  If long double can hold a larger value than a double can, 
> > such
> > + as when long double is IEEE 128-bit, just exit immediately.  */
> 
> A double-double can hold bigger values than a double can, as well
> (if X is the biggest double, then X+Y is a valid double-double whenever
> you take Y small enough).
> 
> > +  if (LDBL_MAX_10_EXP > DBL_MAX_10_EXP)
> > +return 0;

Yes a double-double can hold more mantissa bits than a double, but the exponent
size is the same (which is what I'm testing).

> This is testing something different though: whether the base-10
> logarithm of the maximum finite double is different from that of the
> maximum finite double-double.
> 
> Is there no more direct test you can do?  Just test __FLOAT128__ maybe?
> The test is not even compiled if not powerpc*-linux, so you can test
> such macros just fine.

I will have to look at it.

> > * gcc.dg/nextafter-2.c: On PowerPC, if long double is IEEE
> > 128-bit, include math.h to get the built-in mapped correctly.
> 
> > diff --git a/gcc/testsuite/gcc.dg/nextafter-2.c 
> > b/gcc/testsuite/gcc.dg/nextafter-2.c
> > index e51ae94be0c..64e9e3c485f 100644
> > --- a/gcc/testsuite/gcc.dg/nextafter-2.c
> > +++ b/gcc/testsuite/gcc.dg/nextafter-2.c
> > @@ -13,4 +13,14 @@
> >  #  define NO_LONG_DOUBLE 1
> >  # endif
> >  #endif
> > +
> > +#if defined(_ARCH_PPC) && defined(__LONG_DOUBLE_IEEE128__)
> > +/* On PowerPC systems, long double uses either the IBM long double format, 
> > or
> > +   IEEE 128-bit format.  The compiler switches the long double built-in
> > +   function names and glibc switches the names when math.h is included.
> > +   Because this test is run with -fno-builtin, include math.h so that the
> > +   appropriate nextafter functions are called.  */
> > +#include 
> > +#endif
> > +
> >  #include "nextafter-1.c"
> 
> Please explain *what* mappings are made?  And why is it okay to do this
> in the testsuite, when all "normal" code (that does not do this) will
> just fail?

I can put in a better comment.  However, this test fails because it explicitly
does not include math.h and it uses -fno-builtin.  So the compiler can't
effectively map the nextafter math function.


> > * gcc.target/powerpc/pr70117.c: Add support for long double being
> > IEEE 128-bit.
> 
> That is not what the patch does -- it instead changes the code because
> it does not work correctly with long double ieee128 (which it already
> did claim to support!)
> 
> So what are the actual changes doing, why are they correct, why was the
> original not correct?
> 
> (It is easy to make a test not fail anymore: just delete it!  Something
> here should be better than that :-) )

I will have to look into it.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: PowerPC: Map IEEE 128-bit long double built-in functions

[Michael Meissner via Gcc-patches]

On Wed, Nov 04, 2020 at 06:13:57PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Oct 22, 2020 at 06:03:46PM -0400, Michael Meissner wrote:
> > To map the scanf functions,  is mapped to __isoc99_ieee128.
> 
> Is that correct?  What if you are compiling for c90?

That is the name in GLIBC.

> > * config/rs6000/rs6000.c (rs6000_mangle_decl_assembler_name): Add
> > support for mapping built-in function names for long double
> > built-in functions if long double is IEEE 128-bit.
> 
> "Map the built-in function names" etc.
> 
> > --- a/gcc/config/rs6000/rs6000.c
> > +++ b/gcc/config/rs6000/rs6000.c
> > @@ -26893,56 +26893,127 @@ rs6000_globalize_decl_name (FILE * stream, tree 
> > decl)
> > library before you can switch the real*16 type at compile time.
> >  
> > We use the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change this name.  
> > We
> > -   only do this if the default is that long double is IBM extended double, 
> > and
> > -   the user asked for IEEE 128-bit.  */
> > +   only do this transformation if the __float128 type is enabled.  This
> > +   prevents us from doing the transformation on older 32-bit ports that 
> > might
> > +   have enabled using IEEE 128-bit floating point as the default long 
> > double
> > +   type.  */
> 
> I don't see why that is the right thing to do?  You'll have exactly
> these same problems on 32-bit!

The comment is refering to the remote possiblity that 32-bit VxWorks was
configured to use IEEE long double as the only long double type.  However, you
had to use several non-default options to do this.  All other historic 32-bit
implementations did not allow IEEE long double.

> 
> Hrm, we talked about that before I guess?  Do you just need to change
> this comment now?
> 
> > +   default:
> > + break;
> > +   }
> 
> That is useless, just leave it out?  The end of a switch will always
> fall through, and it is normal idiom to use that.

And it will get a warning that some enumeration elements did not have case
elements.

> > +  /* Update the __builtin_*printf && __builtin_*scanf functions.  */
> 
> "and" :-)
> 
> > + else if (name[len - 1] == 'l')
> > +   {
> > + bool uses_ieee128_p = false;
> > + tree type = TREE_TYPE (decl);
> > + machine_mode ret_mode = TYPE_MODE (type);
> > +
> > + /* See if the function returns a IEEE 128-bit floating point type 
> > or
> > +complex type.  */
> > + if (ret_mode == TFmode || ret_mode == TCmode)
> > +   uses_ieee128_p = true;
> > + else
> > {
> > - machine_mode arg_mode = TYPE_MODE (arg);
> > - if (arg_mode == TFmode || arg_mode == TCmode)
> > + function_args_iterator args_iter;
> > + tree arg;
> 
> (declare that right before the FOREACH)
> 
> > +
> > + /* See if the function passes a IEEE 128-bit floating point 
> > type
> > +or complex type.  */
> > + FOREACH_FUNCTION_ARGS (type, arg, args_iter)
> > {
> > - uses_ieee128_p = true;
> > - break;
> > + machine_mode arg_mode = TYPE_MODE (arg);
> > + if (arg_mode == TFmode || arg_mode == TCmode)
> > +   {
> > + uses_ieee128_p = true;
> > + break;
> > +   }
> > }
> > }
> 
> There is no point in doing all these early-outs in an initialisation
> function, making it much harder to read :-(
> 
> > + /* If we passed or returned an IEEE 128-bit floating point type,
> > +change the name.  Use __ieee128, instead of l.  */
> > + if (uses_ieee128_p)
> > +   newname = xasprintf ("__%.*sieee128", (int)(len - 1), name);
> 
> (int) (len - 1)
> 
> Please comment what the - 1 does, and/or what this is for at all.  (In
> the code / in a comment, not to me, I figured it out after a while.)

The comment just above the line says what it does.  I.e. it does not copy the
'l' in the name (i.e. sinl).

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797