[PATCH], PowerPC long double transition patches, v2

[PATCH], PowerPC long double transition patches, v2

[Michael Meissner]

I'm going to post long double transition fixes that fix most of the problems
when you switch the long double format as follow-ups to this message.  A few of
the fixes to the tests were previously posted, but I've added some comments.

Here are the remaining failures in the C/C++ tests after these patches are
applied:

    1)	There currently is no converter between Decimal types and IEEE 128-bit
	floating point.  Tulio has said this is on the list, but it is lower in
	priority than the main long double transition code in GLIBC.

    2)	A few of the tests use GLIBC long double support, and will presumably
	work when the GLIBC changes are done.

    3)	Two nan related tests (gcc.dg/torture/float128-nan.c, and
	gcc.target/powerpc/nan128-1.c) fail.  I haven't looked into these yet.

    4)	One test (gcc.target/powerpc/pr70117.c) fails after the long double
	code is converted to use __ibm128.  The failure is in the isnormal
	function.  It generates different code for __ibm128 if long double is
	IEEE 128-bit than it does for long double using IBM extended double.

As before, I would like to install these in the trunk and back port them to GCC
8.2.

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

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Michael Meissner]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

When we started down the road of transitioning long double to IEEE 128-bit, we
thought the only way to do it was to add multi-lib support.  Since then with
work underway in both GLIBC and libstdc++ we no longer feel that we need to use
multilibs.

The code as it is now for GCC 8.x and trunk will automatically build multilibs
on little endian PowerPC Linux by default unless you configure the compiler
with --disable-multilib.  However, things will fail unless the target GLIBC
directory is set up for multlibs.

This code disables the automatic multilib creation unless you use the
--with-advance-toolchain=<xxx> option and the Advance Toolchain directoy has
been modified to have the lib64/ieee128 and/or lib64/ibm128 directories for
multilib support.  This allows the multilib to still be created, but it is not
enabled by default.

Alternatively, I have a patch that disables the IEEE/IBM long double multilib
support completely.

This patch has been tested on a little endian power8 system.  Can I install
this patch on the trunk, and back port it to GCC 8.x?

[gcc]
2018-06-20  Michael Meissner  <meissner@linux.ibm.com>

	* config.gcc (powerpc64le*-*-*): Only enable IEEE/IBM long double
	multilibs if we are building against an Advance Toolchain compiler
	that has multilib support.

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

[-- Attachment #2: ieee128-patch120b --]
[-- Type: text/plain, Size: 1382 bytes --]

Index: gcc/config.gcc
===================================================================
--- gcc/config.gcc	(revision 261755)
+++ gcc/config.gcc	(working copy)
@@ -4560,17 +4560,30 @@ case "${target}" in
 		fi
 
 		# Set up the default long double format if the user changed it.
+		ld_alt=""
 		if test x$with_long_double_format = xieee; then
 		    tm_defines="${tm_defines} TARGET_IEEEQUAD_DEFAULT=1"
+		    ld_alt="ibm128"
 
 		elif test x$with_long_double_format = xibm; then
 		    tm_defines="${tm_defines} TARGET_IEEEQUAD_DEFAULT=0"
+		    ld_alt="ieee128"
 		fi
 
+		# If we are building against a special advance toolchain
+		# directory that has multilib support, enable IEEE/IBM long
+		# double multilibs in the compiler.
+
 		case "${target}:${enable_multilib}:${with_long_double_format}" in
 		    powerpc64le*:yes:ieee | powerpc64le*:yes:ibm)
-			tm_defines="${tm_defines} TARGET_IEEEQUAD_MULTILIB=1"
-			tmake_file="${tmake_file} rs6000/t-ldouble-linux64le-${with_long_double_format}"
+			if test "x$with_advance_toolchain" != x -a \
+			    "x$ld_alt" != x -a \
+			    -d "/opt/$with_advance_toolchain/lib64/." -a \
+			    -d "/opt/$with_advance_toolchain/lib64/$ld_alt/."; then
+
+			    tm_defines="${tm_defines} TARGET_IEEEQUAD_MULTILIB=1"
+			    tmake_file="${tmake_file} rs6000/t-ldouble-linux64le-${with_long_double_format}"
+			fi
 			;;
 		    *)
 			:

Re: [PATCH], PowerPC long double transition patches, v2, Patch #2 (add missing conversion insn)

[Michael Meissner]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

In reworking the ordering of the 128-bit floating point modes (June 18th, 2018
patch), I missed one conversion insn.  This meant the compiler would generate a
conversion to using the IF name.

I have tested this on a little endian power8 system with long double set to
IEEE 128-bit and IBM extended, and it fixes tests that convert between the
128-bit binary floating point types.  Can I install this on the trunk and back
port it to GCC 8.x?

[gcc]
2018-06-20  Michael Meissner  <meissner@linux.ibm.com>

	* config/rs6000/rs6000.md (extendtfif2): Add missing 128-bit
	conversion insn.

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

[-- Attachment #2: ieee128-patch121b --]
[-- Type: text/plain, Size: 659 bytes --]

Index: gcc/config/rs6000/rs6000.md
===================================================================
--- gcc/config/rs6000/rs6000.md	(revision 261602)
+++ gcc/config/rs6000/rs6000.md	(working copy)
@@ -8158,6 +8158,15 @@ (define_expand "extendtfkf2"
   DONE;
 })
 
+(define_expand "extendtfif2"
+  [(set (match_operand:IF 0 "gpc_reg_operand")
+	(float_extend:IF (match_operand:TF 1 "gpc_reg_operand")))]
+  "TARGET_FLOAT128_TYPE"
+{
+  rs6000_expand_float128_convert (operands[0], operands[1], false);
+  DONE;
+})
+
 (define_expand "trunciftf2"
   [(set (match_operand:TF 0 "gpc_reg_operand")
 	(float_truncate:TF (match_operand:IF 1 "gpc_reg_operand")))]

Re: [PATCH], PowerPC long double transition patches, v2, Patch #3 (use correct way to get the IEEE 128-bit complex type)

[Michael Meissner]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

This patch fixes the tests that use IEEE 128-bit float complex to use long
double _Complex on systems where the default is IEEE 128-bit.  Due to needing
to use the same internal type for long double and __float128 (to get the
mangling correct and make templates work), you can't really use KF or KC
attributes to get the float128 type when the long double type is IEEE 128-bit.

The compiler does have defines for __KC__ and __KF__ to convert them to __TC__
and __TF__ to allow older GLIBC include files to work.  But these tests just
used KC and/or KF.

I tested these on a little endian power8 system with toolchains that use both
128-bit long double types, and these test pass.  Can I check these patches into
the trunk and into the GCC 8.x branches?

[gcc/testsuite]
2018-06-20  Michael Meissner  <meissner@linux.ibm.com>

	* gcc.target/powerpc/divkc3-1.c: If the long double default is
	IEEE use long double _Complex to declare the IEEE 128-bit complex
	type.
	* gcc.target/powerpc/float128-complex-1.c: Likewise.
	* gcc.target/powerpc/float128-complex-2.c: Likewise.
	* gcc.target/powerpc/float128-type-1.c: Likewise.
	* gcc.target/powerpc/float128-type-2.c: Likewise.
	* gcc.target/powerpc/mulkc3-1.c: Likewise.

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

[-- Attachment #2: ieee128-patch122b --]
[-- Type: text/plain, Size: 5118 bytes --]

Index: gcc/testsuite/gcc.target/powerpc/divkc3-1.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/divkc3-1.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/divkc3-1.c	(working copy)
@@ -3,7 +3,14 @@
 
 void abort ();
 
-typedef __complex float __cfloat128 __attribute__((mode(KC)));
+#ifndef __LONG_DOUBLE_IEEE128__
+/* If long double is IBM, we have to use __attribute__ to get to the long
+   double complex type.  If long double is IEEE, we can use the standard
+   _Complex type.  */
+typedef _Complex float __attribute__((mode(__KC__)))	__cfloat128;
+#else
+typedef _Complex long double				__cfloat128;
+#endif
 
 __cfloat128 divide (__cfloat128 x, __cfloat128 y)
 {
Index: gcc/testsuite/gcc.target/powerpc/float128-complex-1.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/float128-complex-1.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/float128-complex-1.c	(working copy)
@@ -33,10 +33,13 @@ extern double_complex cdouble2 (void);
 #endif
 
 #ifndef NO_FLOAT128
-#ifdef __VSX__
-typedef _Complex float __attribute__((mode(KC)))	float128_complex;
+#ifndef __LONG_DOUBLE_IEEE128__
+/* If long double is IBM, we have to use __attribute__ to get to the long
+   double complex type.  If long double is IEEE, we can use the standard
+   _Complex type.  */
+typedef _Complex float __attribute__((__mode__(__KC__))) float128_complex;
 #else
-typedef _Complex float __attribute__((mode(TC)))	float128_complex;
+typedef _Complex long double				 float128_complex;
 #endif
 
 extern float128_complex cfloat128_1 (void);
Index: gcc/testsuite/gcc.target/powerpc/float128-complex-2.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/float128-complex-2.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/float128-complex-2.c	(working copy)
@@ -34,10 +34,13 @@ extern double_complex cdouble2 (void);
 #endif
 
 #ifndef NO_FLOAT128
-#ifdef __VSX__
-typedef _Complex float __attribute__((mode(KC)))	float128_complex;
+#ifndef __LONG_DOUBLE_IEEE128__
+/* If long double is IBM, we have to use __attribute__ to get to the long
+   double complex type.  If long double is IEEE, we can use the standard
+   _Complex type.  */
+typedef _Complex float __attribute__((__mode__(__KC__))) float128_complex;
 #else
-typedef _Complex float __attribute__((mode(TC)))	float128_complex;
+typedef _Complex long double				 float128_complex;
 #endif
 
 extern float128_complex cfloat128_1 (void);
Index: gcc/testsuite/gcc.target/powerpc/float128-type-1.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/float128-type-1.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/float128-type-1.c	(working copy)
@@ -8,9 +8,12 @@
    __float128 is not enabled .  Test that power8 generates a call to the
    __addkf3 emulation function.  */
 
-#ifdef __LONG_DOUBLE_IEEE128
-typedef double          __attribute__((__mode__(__TF__))) f128_t;
-typedef _Complex double __attribute__((__mode__(__TC__))) f128c_t;
+#ifdef __LONG_DOUBLE_IEEE128__
+/* If long double is IBM, we have to use __attribute__ to get to the long
+   double complex type.  If long double is IEEE, we can use the standard
+   _Complex type.  */
+typedef long double		f128_t;
+typedef long double _Complex	f128c_t;
 
 #else
 typedef double          __attribute__((__mode__(__KF__))) f128_t;
Index: gcc/testsuite/gcc.target/powerpc/float128-type-2.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/float128-type-2.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/float128-type-2.c	(working copy)
@@ -8,9 +8,12 @@
    __float128 is not enabled .  Test that power9 generates the xsaddqp
    instruction.  */
 
-#ifdef __LONG_DOUBLE_IEEE128
-typedef double          __attribute__((__mode__(__TF__))) f128_t;
-typedef _Complex double __attribute__((__mode__(__TC__))) f128c_t;
+#ifdef __LONG_DOUBLE_IEEE128__
+/* If long double is IBM, we have to use __attribute__ to get to the long
+   double complex type.  If long double is IEEE, we can use the standard
+   _Complex type.  */
+typedef long double		f128_t;
+typedef long double _Complex	f128c_t;
 
 #else
 typedef double          __attribute__((__mode__(__KF__))) f128_t;
Index: gcc/testsuite/gcc.target/powerpc/mulkc3-1.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/mulkc3-1.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/mulkc3-1.c	(working copy)
@@ -3,7 +3,15 @@
 
 void abort ();
 
-typedef __complex float __cfloat128 __attribute__((mode(KC)));
+
+#ifndef __LONG_DOUBLE_IEEE128__
+/* If long double is IBM, we have to use __attribute__ to get to the long
+   double complex type.  If long double is IEEE, we can use the standard
+   _Complex type.  */
+typedef _Complex float __attribute__((mode(__KC__)))	__cfloat128;
+#else
+typedef _Complex long double				__cfloat128;
+#endif
 
 __cfloat128 multiply (__cfloat128 x, __cfloat128 y)
 {

Re: [PATCH], PowerPC long double transition patches, v2, Patch #4 (fix bug in clone/target attributes on long double == IEEE 128-bit systems)

[Michael Meissner]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

This patch prevents the special overriding of the complex float128
multiply/divide functions from being run twice if there are clone or target
attributes.  I wasn't aware that the hook used to initialize the built-in
functions is run each time you change the target options.  The built-in
function handling aborts if the name had already been set.

I have tested this on a little endian power8 sysytem using two builds with long
double set to IEEE and IBM 128-bit.  This patch fixes testsuite errors from
using the clone or target attributes.  Can I install it in the trunk and GCC
8.x branches?

[gcc]
2018-06-20  Michael Meissner  <meissner@linux.ibm.com>

	* config/rs6000/rs6000.c (init_float128_ieee): Prevent complex
	multiply and divide external functions from being created more
	than once.

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

[-- Attachment #2: ieee128-patch123b --]
[-- Type: text/plain, Size: 932 bytes --]

Index: gcc/config/rs6000/rs6000.c
===================================================================
--- gcc/config/rs6000/rs6000.c	(revision 261574)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -17892,9 +17892,14 @@ init_float128_ieee (machine_mode mode)
 {
   if (FLOAT128_VECTOR_P (mode))
     {
-      /* Set up to call __mulkc3 and __divkc3 under -mabi=ieeelongdouble.  */
-     if (mode == TFmode && TARGET_IEEEQUAD)
+      static bool complex_muldiv_init_p = false;
+
+      /* Set up to call __mulkc3 and __divkc3 under -mabi=ieeelongdouble.  If
+	 we have clone or target attributes, this will be called a second
+	 time.  We want to create the built-in function only once.  */
+     if (mode == TFmode && TARGET_IEEEQUAD && !complex_muldiv_init_p)
        {
+	 complex_muldiv_init_p = true;
 	 built_in_function fncode_mul =
 	   (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + TCmode
 				- MIN_MODE_COMPLEX_FLOAT);

Re: [PATCH], PowerPC long double transition patches, v2, Patch #5 (fix negif3)

[Michael Meissner]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

This patch fixes a thinko that I had that prevented negation of __ibm128 values
if long double is IEEE 128-bit binary floating point.

I have checked this on a little endian power8 system with builds where the long
double is set to IEEE and IBM 128-bit binary floating point, and it fixes some
tests in the testsuite when long double is IEEE.  Can I install this on the
trunk and back port it to GCC 8.x?

[gcc]
2018-06-20  Michael Meissner  <meissner@linux.ibm.com>

	* config/rs6000/rs6000.md (neg<mode>2_internal): Use the correct
	mode to check whether the mode is IBM extended.

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

[-- Attachment #2: ieee128-patch124b --]
[-- Type: text/plain, Size: 609 bytes --]

Index: gcc/config/rs6000/rs6000.md
===================================================================
--- gcc/config/rs6000/rs6000.md	(revision 261559)
+++ gcc/config/rs6000/rs6000.md	(working copy)
@@ -7933,7 +7933,7 @@ (define_expand "neg<mode>2"
 (define_insn "neg<mode>2_internal"
   [(set (match_operand:IBM128 0 "gpc_reg_operand" "=d")
 	(neg:IBM128 (match_operand:IBM128 1 "gpc_reg_operand" "d")))]
-  "TARGET_HARD_FLOAT && FLOAT128_IBM_P (TFmode)"
+  "TARGET_HARD_FLOAT && FLOAT128_IBM_P (<MODE>mode)"
 {
   if (REGNO (operands[0]) == REGNO (operands[1]) + 1)
     return "fneg %L0,%L1\;fneg %0,%1";

Re: [PATCH], PowerPC long double transition patches, v2, Patch #6 (fix long double tests for -mno-float128)

[Michael Meissner]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

These patches fix the tests in the testsuite that check whether -mno-float128
works properly.  In these cases, I explicitly run them with long double being
set to IBM extended double.

I have tested these on a little endian power8 system using two builds with long
double being set to IEEE and IBM 128-bit floating point.  These tests now pass
when long double is set to IEEE 128-bit floating point.  Can I check these into
the trunk and back port them to GCC 8.x?

[gcc/testsuite]
2018-06-20  Michael Meissner  <meissner@linux.ibm.com>

	* gcc.target/powerpc/float128-3.c: Change tests that test for
	errors in enabling/disable IEEE 128-bit floating point use the
	-mabi=ibmlongdouble to force long double to be IBM extended.
	* gcc.target/powerpc/float128-5.c: Likewise.
	* gcc.target/powerpc/float128-mix.c: Likewise.

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

[-- Attachment #2: ieee128-patch125b --]
[-- Type: text/plain, Size: 2154 bytes --]

Index: gcc/testsuite/gcc.target/powerpc/float128-3.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/float128-3.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/float128-3.c	(working copy)
@@ -1,8 +1,10 @@
 /* { dg-do compile { target { powerpc*-*-linux* } } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
-/* { dg-options "-O2 -mvsx -mno-float128" } */
+/* { dg-options "-O2 -mvsx -mno-float128 -mabi=ibmlongdouble -Wno-psabi" } */
 
-/* Test that we can use #pragma GCC target to enable -mfloat128.  */
+/* Test that we can use #pragma GCC target to enable -mfloat128.  This depends
+   on the long double format being IBM extended double in order to enable or
+   disable IEEE 128-bit floating point.  */
 
 #ifdef __FLOAT128__
 #error "-mno-float128 should disable initially defining __FLOAT128__"
Index: gcc/testsuite/gcc.target/powerpc/float128-5.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/float128-5.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/float128-5.c	(working copy)
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { powerpc*-*-linux* && lp64 } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-O2 -mpower9-vector -mno-float128" } */
+/* { dg-options "-O2 -mpower9-vector -mno-float128 -mabi=ibmlongdouble -Wno-psabi" } */
 
 /* Test that we can use #pragma GCC target to enable -mfloat128 and generate
    code on ISA 3.0 for the float128 built-in functions.  Lp64 is required
Index: gcc/testsuite/gcc.target/powerpc/float128-mix.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/float128-mix.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/float128-mix.c	(working copy)
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { powerpc*-*-linux* } } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
-/* { dg-options "-O2 -mvsx" } */
+/* { dg-options "-O2 -mvsx -mabi=ibmlongdouble -Wno-psabi" } */
 
 
 /* Test to make sure that __float128 and long double cannot be combined together.  */

Re: [PATCH], PowerPC long double transition patches, v2, Patch #7 (fix IBM extended double tests to use __ibm128 as needed)

[Michael Meissner]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

This patch fixes the tests in the testsuite that implicitly were expecting long
double to be IBM extended double to use __ibm128 if long double is configured
to be IEEE 128-bit floating point.

Note, test pr70117.c will still fail due to bugs in isnormal code generation
for __ibm128.  However, explicitly using the __ibm128 is still the right thing
to do once that bug is fixed.

I have checked these tests on a little endian power8 system where long double
is IEEE 128-bit floating point, and with the exception of pr70117.c, the other
tests pass.  Can I check these patches into trunk and back port them to GCC
8.x?

[gcc/testsuite]
2018-06-20  Michael Meissner  <meissner@linux.ibm.com>

	* gcc.target/powerpc/pack02.c: Use __ibm128 instead of long double
	if the long double format is IEEE 128-bit for tests that are
	explicitly testing IBM extended double support.  Use the
	appropriate pack and unpack built-in functions.  Change calls from
	__builtin_isinfl to __builtin_isinf since the later supports all
	floating point types.
	* gcc.target/powerpc/pr57150.c: Likewise.
	* gcc.target/powerpc/pr60203.c: Likewise.
	* gcc.target/powerpc/pr67808.c: Likewise.
	* gcc.target/powerpc/pr70117.c: Likewise.
	* gcc.target/powerpc/tfmode_off.c: Likewise.

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

[-- Attachment #2: ieee128-patch126b --]
[-- Type: text/plain, Size: 9168 bytes --]

Index: gcc/testsuite/gcc.target/powerpc/pack02.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/pack02.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/pack02.c	(working copy)
@@ -13,36 +13,54 @@
 #include <stdio.h>
 #endif
 
+#if defined(__LONG_DOUBLE_IEEE128__)
+/* If long double is IEEE 128-bit, we need to use the __ibm128 type instead of
+   long double, and to use the appropriate pack/unpack routines.  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 PACK __builtin_pack_ibm128
+#define UNPACK __builtin_unpack_ibm128
+#define LDOUBLE __ibm128
+
+#elif defined(__LONG_DOUBLE_IBM128__)
+#define PACK __builtin_pack_longdouble
+#define UNPACK __builtin_unpack_longdouble
+#define LDOUBLE long double
+
+#else
+#error "long double must be either IBM 128-bit or IEEE 128-bit"
+#endif
+
 int
 main (void)
 {
   double high = pow (2.0, 60);
   double low  = 2.0;
-  long double a = ((long double)high) + ((long double)low);
-  double x0 = __builtin_unpack_longdouble (a, 0);
-  double x1 = __builtin_unpack_longdouble (a, 1);
-  long double b = __builtin_pack_longdouble (x0, x1);
+  LDOUBLE a = ((LDOUBLE)high) + ((LDOUBLE)low);
+  double x0 = UNPACK (a, 0);
+  double x1 = UNPACK (a, 1);
+  LDOUBLE b = PACK (x0, x1);
 
 #ifdef DEBUG
   {
     size_t i;
     union {
-      long double ld;
+      LDOUBLE ld;
       double d;
-      unsigned char uc[sizeof (long double)];
-      char c[sizeof (long double)];
+      unsigned char uc[sizeof (LDOUBLE)];
+      char c[sizeof (LDOUBLE)];
     } u;
 
     printf ("a  = 0x");
     u.ld = a;
-    for (i = 0; i < sizeof (long double); i++)
+    for (i = 0; i < sizeof (LDOUBLE); i++)
       printf ("%.2x", u.uc[i]);
 
     printf (", %Lg\n", a);
 
     printf ("b  = 0x");
     u.ld = b;
-    for (i = 0; i < sizeof (long double); i++)
+    for (i = 0; i < sizeof (LDOUBLE); i++)
       printf ("%.2x", u.uc[i]);
 
     printf (", %Lg\n", b);
@@ -52,28 +70,28 @@ main (void)
     for (i = 0; i < sizeof (double); i++)
       printf ("%.2x", u.uc[i]);
 
-    printf (",%*s %g\n", (int)(2 * (sizeof (long double) - sizeof (double))), "", high);
+    printf (",%*s %g\n", (int)(2 * (sizeof (LDOUBLE) - sizeof (double))), "", high);
 
     printf ("lo = 0x");
     u.d = low;
     for (i = 0; i < sizeof (double); i++)
       printf ("%.2x", u.uc[i]);
 
-    printf (",%*s %g\n", (int)(2 * (sizeof (long double) - sizeof (double))), "", low);
+    printf (",%*s %g\n", (int)(2 * (sizeof (LDOUBLE) - sizeof (double))), "", low);
 
     printf ("x0 = 0x");
     u.d = x0;
     for (i = 0; i < sizeof (double); i++)
       printf ("%.2x", u.uc[i]);
 
-    printf (",%*s %g\n", (int)(2 * (sizeof (long double) - sizeof (double))), "", x0);
+    printf (",%*s %g\n", (int)(2 * (sizeof (LDOUBLE) - sizeof (double))), "", x0);
 
     printf ("x1 = 0x");
     u.d = x1;
     for (i = 0; i < sizeof (double); i++)
       printf ("%.2x", u.uc[i]);
 
-    printf (",%*s %g\n", (int)(2 * (sizeof (long double) - sizeof (double))), "", x1);
+    printf (",%*s %g\n", (int)(2 * (sizeof (LDOUBLE) - sizeof (double))), "", x1);
   }
 #endif
 
Index: gcc/testsuite/gcc.target/powerpc/pr57150.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/pr57150.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/pr57150.c	(working copy)
@@ -12,10 +12,24 @@
 
 /* Insure caller save on long double does not use VSX instructions.  */
 
-extern long double modify (long double);
+#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
+
+extern LDOUBLE modify (LDOUBLE);
 
 void
-sum (long double *ptr, long double value, unsigned long n)
+sum (LDOUBLE *ptr, LDOUBLE value, unsigned long n)
 {
   unsigned long i;
 
Index: gcc/testsuite/gcc.target/powerpc/pr60203.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/pr60203.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/pr60203.c	(working copy)
@@ -4,9 +4,23 @@
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { "-mcpu=power8" } } */
 /* { dg-options "-mcpu=power8 -O3" } */
 
-union u_ld { long double ld; double d[2]; };
+#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
 
-long double
+#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 u_ld { LDOUBLE ld; double d[2]; };
+
+LDOUBLE
 pack (double a, double aa)
 {
   union u_ld u;
@@ -16,7 +30,7 @@ pack (double a, double aa)
 }
 
 double
-unpack_0 (long double x)
+unpack_0 (LDOUBLE x)
 {
   union u_ld u;
   u.ld = x;
@@ -24,7 +38,7 @@ unpack_0 (long double x)
 }
 
 double
-unpack_1 (long double x)
+unpack_1 (LDOUBLE x)
 {
   union u_ld u;
   u.ld = x;
Index: gcc/testsuite/gcc.target/powerpc/pr67808.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/pr67808.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/pr67808.c	(working copy)
@@ -6,37 +6,51 @@
 
 /* PR 67808: LRA ICEs on simple double to long double conversion test case */
 
+#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
+
 void
-dfoo (long double *ldb1, double *db1)
+dfoo (LDOUBLE *ldb1, double *db1)
 {
   *ldb1 = *db1;
 }
 
-long double
+LDOUBLE
 dfoo2 (double *db1)
 {
   return *db1;
 }
 
-long double
+LDOUBLE
 dfoo3 (double x)
 {
   return x;
 }
 
 void
-ffoo (long double *ldb1, float *db1)
+ffoo (LDOUBLE *ldb1, float *db1)
 {
   *ldb1 = *db1;
 }
 
-long double
+LDOUBLE
 ffoo2 (float *db1)
 {
   return *db1;
 }
 
-long double
+LDOUBLE
 ffoo3 (float x)
 {
   return x;
Index: gcc/testsuite/gcc.target/powerpc/pr70117.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/pr70117.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/pr70117.c	(working copy)
@@ -3,10 +3,24 @@
 
 #include <float.h>
 
+#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;
-  long double ld;
+  LDOUBLE ld;
 };
 
 /* This is gnulib's LDBL_MAX which, being 107 bits in precision, is
@@ -22,13 +36,13 @@ volatile double dnan = 0.0/0.0;
 int
 main (void)
 {
-  long double ld;
+  LDOUBLE ld;
 
   ld = gl_LDBL_MAX.ld;
-  if (__builtin_isinfl (ld))
+  if (__builtin_isinf (ld))
     __builtin_abort ();
   ld = -gl_LDBL_MAX.ld;
-  if (__builtin_isinfl (ld))
+  if (__builtin_isinf (ld))
     __builtin_abort ();
 
   ld = gl_LDBL_MAX.ld;
Index: gcc/testsuite/gcc.target/powerpc/tfmode_off.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/tfmode_off.c	(revision 261755)
+++ gcc/testsuite/gcc.target/powerpc/tfmode_off.c	(working copy)
@@ -4,7 +4,19 @@
 /* { dg-require-effective-target longdouble128 } */
 /* { dg-options "-O2 -fno-align-functions -fno-asynchronous-unwind-tables -mtraceback=no -save-temps" } */
 
-typedef float TFmode __attribute__ ((mode (TF)));
+#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 TFmode __ibm128
+
+#elif defined(__LONG_DOUBLE_IBM128__)
+#define TFmode long double
+
+#else
+#error "long double must be either IBM 128-bit or IEEE 128-bit"
+#endif
 
 void w1 (void *x, TFmode y) { *(TFmode *) (x + 32767) = y; }
 void w2 (void *x, TFmode y) { *(TFmode *) (x + 32766) = y; }

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Segher Boessenkool]

On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> This code disables the automatic multilib creation unless you use the
> --with-advance-toolchain=<xxx> option and the Advance Toolchain directoy has
> been modified to have the lib64/ieee128 and/or lib64/ibm128 directories for
> multilib support.  This allows the multilib to still be created, but it is not
> enabled by default.
> 
> Alternatively, I have a patch that disables the IEEE/IBM long double multilib
> support completely.

So what are the advantages and the disadvantages of both approaches?
And, why do you think this one is preferable?


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Michael Meissner]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On Wed, Jun 20, 2018 at 07:31:31PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> > This code disables the automatic multilib creation unless you use the
> > --with-advance-toolchain=<xxx> option and the Advance Toolchain directoy has
> > been modified to have the lib64/ieee128 and/or lib64/ibm128 directories for
> > multilib support.  This allows the multilib to still be created, but it is not
> > enabled by default.
> > 
> > Alternatively, I have a patch that disables the IEEE/IBM long double multilib
> > support completely.
> 
> So what are the advantages and the disadvantages of both approaches?
> And, why do you think this one is preferable?

The main advantge is that it makes it a little easier for me to test things,
since I only have to build one compiler instead of two.  But that is fairly
minor.

Here is the alternate patch to eliminate the multilib support for IEEE/IBM long
double.

[gcc]
2018-06-21  Michael Meissner  <meissner@linux.ibm.com>

	* config.gcc (powerpc64le*): Remove multilib support for IEEE and
	IBM long double.
	* config/rs6000/rs6000.c (rs6000_option_override_internal):
	Likewise.
	* config/rs6000/rs6000.h (TARGET_IEEEQUAD_MULTILIB): Likewise.
	* config/rs6000/t-ldouble-linux64le-ibm: Delete, IEEE/IBM long
	double multilib no longer supported.
	* config/rs6000/t-ldouble-linux64le-ieee: Likewise.
	* doc/install.texi (PowerPC options): Delete information about
	IEEE/IBM long double multilibs.

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

[-- Attachment #2: ieee128-patch119b --]
[-- Type: text/plain, Size: 6984 bytes --]

Index: gcc/config.gcc
===================================================================
--- gcc/config.gcc	(revision 261755)
+++ gcc/config.gcc	(working copy)
@@ -4566,16 +4566,6 @@ case "${target}" in
 		elif test x$with_long_double_format = xibm; then
 		    tm_defines="${tm_defines} TARGET_IEEEQUAD_DEFAULT=0"
 		fi
-
-		case "${target}:${enable_multilib}:${with_long_double_format}" in
-		    powerpc64le*:yes:ieee | powerpc64le*:yes:ibm)
-			tm_defines="${tm_defines} TARGET_IEEEQUAD_MULTILIB=1"
-			tmake_file="${tmake_file} rs6000/t-ldouble-linux64le-${with_long_double_format}"
-			;;
-		    *)
-			:
-			;;
-		esac
 		;;
 
 	s390*-*-*)
Index: gcc/config/rs6000/rs6000.c
===================================================================
--- gcc/config/rs6000/rs6000.c	(revision 261755)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -4578,19 +4578,16 @@ rs6000_option_override_internal (bool gl
   else if (rs6000_long_double_type_size == 128)
     rs6000_long_double_type_size = FLOAT_PRECISION_TFmode;
 
-  /* Set -mabi=ieeelongdouble on some old targets.  In the future, power server
-     systems will also set long double to be IEEE 128-bit.  AIX and Darwin
-     explicitly redefine TARGET_IEEEQUAD and TARGET_IEEEQUAD_DEFAULT to 0, so
-     those systems will not pick up this default.  Warn if the user changes the
-     default unless either the user used the -Wno-psabi option, or the compiler
-     was built to enable multilibs to switch between the two long double
-     types.  */
+  /* Set -mabi=ieeelongdouble on some old targets.  Power server systems may
+     also set long double to be IEEE 128-bit using the configuration option
+     --with-long-double-forrmat=ieee.  AIX and Darwin explicitly redefine
+     TARGET_IEEEQUAD and TARGET_IEEEQUAD_DEFAULT to 0, so those systems will
+     not pick up this default.  Warn if the user changes the default unless
+     either the user used the -Wno-psabi option.  */
   if (!global_options_set.x_rs6000_ieeequad)
     rs6000_ieeequad = TARGET_IEEEQUAD_DEFAULT;
 
-  else if (!TARGET_IEEEQUAD_MULTILIB
-	   && rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT
-	   && TARGET_LONG_DOUBLE_128)
+  else if (rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT && TARGET_LONG_DOUBLE_128)
     {
       static bool warned_change_long_double;
       if (!warned_change_long_double)
Index: gcc/config/rs6000/rs6000.h
===================================================================
--- gcc/config/rs6000/rs6000.h	(revision 261755)
+++ gcc/config/rs6000/rs6000.h	(working copy)
@@ -551,12 +551,6 @@ extern int rs6000_vector_align[];
 #define TARGET_ALTIVEC_ABI rs6000_altivec_abi
 #define TARGET_LDBRX (TARGET_POPCNTD || rs6000_cpu == PROCESSOR_CELL)
 
-/* Define as 1 if we support multilibs for switching long double between IEEE
-   128-bit floating point and IBM extended double.  */
-#ifndef TARGET_IEEEQUAD_MULTILIB
-#define TARGET_IEEEQUAD_MULTILIB 0
-#endif
-
 /* ISA 2.01 allowed FCFID to be done in 32-bit, previously it was 64-bit only.
    Enable 32-bit fcfid's on any of the switches for newer ISA machines.  */
 #define TARGET_FCFID	(TARGET_POWERPC64				\
Index: gcc/config/rs6000/t-ldouble-linux64le-ibm
===================================================================
--- gcc/config/rs6000/t-ldouble-linux64le-ibm	(revision 261755)
+++ gcc/config/rs6000/t-ldouble-linux64le-ibm	(working copy)
@@ -1,26 +0,0 @@
-# Long double multilib libraries for PowerPC 64-bit little endian systems using
-# IBM extended double as the long double type.
-#
-# Copyright (C) 2018 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.
-#
-# You should have received a copy of the GNU General Public License
-# along with GCC; see the file COPYING3.  If not see
-# <http://www.gnu.org/licenses/>.
-
-MULTILIB_OPTIONS	+= mabi=ieeelongdouble/mabi=ibmlongdouble
-MULTILIB_DIRNAMES	+= ieee128 ibm128
-MULTILIB_OSDIRNAMES	+= mabi.ibmlongdouble=../lib64$(call if_multiarch,:powerpc64-linux-gnu) \
-			   mabi.ieeelongdouble=../lib64/ieee128$(call if_multiarch,:powerpc64-linux-gnu) \
-			   ../lib64$(call if_multiarch,:powerpc64-linux-gnu)
Index: gcc/config/rs6000/t-ldouble-linux64le-ieee
===================================================================
--- gcc/config/rs6000/t-ldouble-linux64le-ieee	(revision 261755)
+++ gcc/config/rs6000/t-ldouble-linux64le-ieee	(working copy)
@@ -1,26 +0,0 @@
-# Long double multilib libraries for PowerPC 64-bit little endian systems using
-# IEEE 128-bit floating point as the long double type.
-#
-# Copyright (C) 2018 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.
-#
-# You should have received a copy of the GNU General Public License
-# along with GCC; see the file COPYING3.  If not see
-# <http://www.gnu.org/licenses/>.
-
-MULTILIB_OPTIONS	+= mabi=ieeelongdouble/mabi=ibmlongdouble
-MULTILIB_DIRNAMES	+= ieee128 ibm128
-MULTILIB_OSDIRNAMES	+= mabi.ibmlongdouble=../lib64/ibm128$(call if_multiarch,:powerpc64-linux-gnu) \
-			   mabi.ieeelongdouble=../lib64$(call if_multiarch,:powerpc64-linux-gnu) \
-			   ../lib64$(call if_multiarch,:powerpc64-linux-gnu)
Index: gcc/doc/install.texi
===================================================================
--- gcc/doc/install.texi	(revision 261755)
+++ gcc/doc/install.texi	(working copy)
@@ -1902,17 +1902,6 @@ Until all of the libraries are converted
 point, it is not recommended to use
 @option{--with-long-double-format=ieee}.
 
-On little endian PowerPC Linux systems, if you explicitly set the
-@code{long double} type, it will build multilibs to allow you to
-select either @code{long double} format, unless you disable multilibs
-with the @code{--disable-multilib} option.  At present,
-@code{long double} multilibs are not built on big endian PowerPC Linux
-systems.  If you are building multilibs, you will need to configure
-the compiler using the @option{--with-system-zlib} option.
-
-If you do not set the @code{long double} type explicitly, no multilibs
-will be generated.
-
 @item --enable-fdpic
 On SH Linux systems, generate ELF FDPIC code.
 

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Segher Boessenkool]

On Thu, Jun 21, 2018 at 12:58:06PM -0400, Michael Meissner wrote:
> On Wed, Jun 20, 2018 at 07:31:31PM -0500, Segher Boessenkool wrote:
> > On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> > > This code disables the automatic multilib creation unless you use the
> > > --with-advance-toolchain=<xxx> option and the Advance Toolchain directoy has
> > > been modified to have the lib64/ieee128 and/or lib64/ibm128 directories for
> > > multilib support.  This allows the multilib to still be created, but it is not
> > > enabled by default.
> > > 
> > > Alternatively, I have a patch that disables the IEEE/IBM long double multilib
> > > support completely.
> > 
> > So what are the advantages and the disadvantages of both approaches?
> > And, why do you think this one is preferable?
> 
> The main advantge is that it makes it a little easier for me to test things,
> since I only have to build one compiler instead of two.  But that is fairly
> minor.
> 
> Here is the alternate patch to eliminate the multilib support for IEEE/IBM long
> double.
> 
> [gcc]
> 2018-06-21  Michael Meissner  <meissner@linux.ibm.com>
> 
> 	* config.gcc (powerpc64le*): Remove multilib support for IEEE and
> 	IBM long double.
> 	* config/rs6000/rs6000.c (rs6000_option_override_internal):
> 	Likewise.
> 	* config/rs6000/rs6000.h (TARGET_IEEEQUAD_MULTILIB): Likewise.
> 	* config/rs6000/t-ldouble-linux64le-ibm: Delete, IEEE/IBM long
> 	double multilib no longer supported.
> 	* config/rs6000/t-ldouble-linux64le-ieee: Likewise.
> 	* doc/install.texi (PowerPC options): Delete information about
> 	IEEE/IBM long double multilibs.

This reverts r256775 (the commit message should say), except the linux64.h
parts, and it seems you just missed those?


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Michael Meissner]

On Thu, Jun 21, 2018 at 12:09:12PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 21, 2018 at 12:58:06PM -0400, Michael Meissner wrote:
> > On Wed, Jun 20, 2018 at 07:31:31PM -0500, Segher Boessenkool wrote:
> > > On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> > > > This code disables the automatic multilib creation unless you use the
> > > > --with-advance-toolchain=<xxx> option and the Advance Toolchain directoy has
> > > > been modified to have the lib64/ieee128 and/or lib64/ibm128 directories for
> > > > multilib support.  This allows the multilib to still be created, but it is not
> > > > enabled by default.
> > > > 
> > > > Alternatively, I have a patch that disables the IEEE/IBM long double multilib
> > > > support completely.
> > > 
> > > So what are the advantages and the disadvantages of both approaches?
> > > And, why do you think this one is preferable?
> > 
> > The main advantge is that it makes it a little easier for me to test things,
> > since I only have to build one compiler instead of two.  But that is fairly
> > minor.
> > 
> > Here is the alternate patch to eliminate the multilib support for IEEE/IBM long
> > double.
> > 
> > [gcc]
> > 2018-06-21  Michael Meissner  <meissner@linux.ibm.com>
> > 
> > 	* config.gcc (powerpc64le*): Remove multilib support for IEEE and
> > 	IBM long double.
> > 	* config/rs6000/rs6000.c (rs6000_option_override_internal):
> > 	Likewise.
> > 	* config/rs6000/rs6000.h (TARGET_IEEEQUAD_MULTILIB): Likewise.
> > 	* config/rs6000/t-ldouble-linux64le-ibm: Delete, IEEE/IBM long
> > 	double multilib no longer supported.
> > 	* config/rs6000/t-ldouble-linux64le-ieee: Likewise.
> > 	* doc/install.texi (PowerPC options): Delete information about
> > 	IEEE/IBM long double multilibs.
> 
> This reverts r256775 (the commit message should say), except the linux64.h
> parts, and it seems you just missed those?

No it only reverts part of r256775.  The main part of the r256775 change is to
add support for --with-long-double-format={ieee,ibm} which we need to keep.

Yeah, I probably missed them.

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

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Segher Boessenkool]

On Thu, Jun 21, 2018 at 01:26:19PM -0400, Michael Meissner wrote:
> On Thu, Jun 21, 2018 at 12:09:12PM -0500, Segher Boessenkool wrote:
> > > 	* config.gcc (powerpc64le*): Remove multilib support for IEEE and
> > > 	IBM long double.
> > > 	* config/rs6000/rs6000.c (rs6000_option_override_internal):
> > > 	Likewise.
> > > 	* config/rs6000/rs6000.h (TARGET_IEEEQUAD_MULTILIB): Likewise.
> > > 	* config/rs6000/t-ldouble-linux64le-ibm: Delete, IEEE/IBM long
> > > 	double multilib no longer supported.
> > > 	* config/rs6000/t-ldouble-linux64le-ieee: Likewise.
> > > 	* doc/install.texi (PowerPC options): Delete information about
> > > 	IEEE/IBM long double multilibs.
> > 
> > This reverts r256775 (the commit message should say), except the linux64.h
> > parts, and it seems you just missed those?
> 
> No it only reverts part of r256775.  The main part of the r256775 change is to
> add support for --with-long-double-format={ieee,ibm} which we need to keep.

That is r256558 as far as I see?


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #2 (add missing conversion insn)

[Segher Boessenkool]

Hi!

On Wed, Jun 20, 2018 at 10:32:06AM -0400, Michael Meissner wrote:
> In reworking the ordering of the 128-bit floating point modes (June 18th, 2018
> patch), I missed one conversion insn.  This meant the compiler would generate a
> conversion to using the IF name.

Is there some existing test this fixes?  Which?

Okay for trunk.


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #3 (use correct way to get the IEEE 128-bit complex type)

[Segher Boessenkool]

On Wed, Jun 20, 2018 at 10:38:10AM -0400, Michael Meissner wrote:
> This patch fixes the tests that use IEEE 128-bit float complex to use long
> double _Complex on systems where the default is IEEE 128-bit.  Due to needing
> to use the same internal type for long double and __float128 (to get the
> mangling correct and make templates work), you can't really use KF or KC
> attributes to get the float128 type when the long double type is IEEE 128-bit.

Which is a problem that needs fixing.  Make a separate testcase for that
then, please.

> +#ifndef __LONG_DOUBLE_IEEE128__
> +/* If long double is IBM, we have to use __attribute__ to get to the long
> +   double complex type.  If long double is IEEE, we can use the standard
> +   _Complex type.  */
> +typedef _Complex float __attribute__((mode(__KC__)))	__cfloat128;
> +#else
> +typedef _Complex long double				__cfloat128;
> +#endif

The comment doesn't make much sense.  If long double is IBM, the long
double complex mode is ICmode, not KCmode.  "To get the IEEE128 complex
type", perhaps?  And can't you do _Complex __ieee128 or such?


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #2 (add missing conversion insn)

[Michael Meissner]

On Thu, Jun 21, 2018 at 04:25:29PM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Jun 20, 2018 at 10:32:06AM -0400, Michael Meissner wrote:
> > In reworking the ordering of the 128-bit floating point modes (June 18th, 2018
> > patch), I missed one conversion insn.  This meant the compiler would generate a
> > conversion to using the IF name.
> 
> Is there some existing test this fixes?  Which?

pr85657-3.c.
 
> Okay for trunk.
> 
> 
> Segher
> 

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

Re: [PATCH], PowerPC long double transition patches, v2, Patch #4 (fix bug in clone/target attributes on long double == IEEE 128-bit systems)

[Segher Boessenkool]

On Wed, Jun 20, 2018 at 10:42:38AM -0400, Michael Meissner wrote:
> This patch prevents the special overriding of the complex float128
> multiply/divide functions from being run twice if there are clone or target
> attributes.  I wasn't aware that the hook used to initialize the built-in
> functions is run each time you change the target options.  The built-in
> function handling aborts if the name had already been set.
> 
> I have tested this on a little endian power8 sysytem using two builds with long
> double set to IEEE and IBM 128-bit.  This patch fixes testsuite errors from
> using the clone or target attributes.  Can I install it in the trunk and GCC
> 8.x branches?

Next time, please mention what tests are fixed.

> --- gcc/config/rs6000/rs6000.c	(revision 261574)
> +++ gcc/config/rs6000/rs6000.c	(working copy)
> @@ -17892,9 +17892,14 @@ init_float128_ieee (machine_mode mode)
>  {
>    if (FLOAT128_VECTOR_P (mode))
>      {
> -      /* Set up to call __mulkc3 and __divkc3 under -mabi=ieeelongdouble.  */
> -     if (mode == TFmode && TARGET_IEEEQUAD)
> +      static bool complex_muldiv_init_p = false;
> +
> +      /* Set up to call __mulkc3 and __divkc3 under -mabi=ieeelongdouble.  If
> +	 we have clone or target attributes, this will be called a second
> +	 time.  We want to create the built-in function only once.  */
> +     if (mode == TFmode && TARGET_IEEEQUAD && !complex_muldiv_init_p)
>         {
> +	 complex_muldiv_init_p = true;
>  	 built_in_function fncode_mul =
>  	   (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + TCmode
>  				- MIN_MODE_COMPLEX_FLOAT);

The indentation here is wrong (was before, too).

Is there no more elegant, less error-prone way to see things are already
initialised?  Maybe use maybe_get_identifier?

But, okay for trunk.


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #5 (fix negif3)

[Segher Boessenkool]

On Wed, Jun 20, 2018 at 10:46:04AM -0400, Michael Meissner wrote:
> This patch fixes a thinko that I had that prevented negation of __ibm128 values
> if long double is IEEE 128-bit binary floating point.
> 
> I have checked this on a little endian power8 system with builds where the long
> double is set to IEEE and IBM 128-bit binary floating point, and it fixes some
> tests in the testsuite when long double is IEEE.  Can I install this on the
> trunk and back port it to GCC 8.x?

Okay, thanks.


Segher


> 	* config/rs6000/rs6000.md (neg<mode>2_internal): Use the correct
> 	mode to check whether the mode is IBM extended.

Re: [PATCH], PowerPC long double transition patches, v2, Patch #3 (use correct way to get the IEEE 128-bit complex type)

[Joseph Myers]

On Thu, 21 Jun 2018, Segher Boessenkool wrote:

> The comment doesn't make much sense.  If long double is IBM, the long
> double complex mode is ICmode, not KCmode.  "To get the IEEE128 complex
> type", perhaps?  And can't you do _Complex __ieee128 or such?

You can do _Complex _Float128, in C only, not C++ (which doesn't have the 
_Float128 keyword).  _Complex can be used with keywords for type names, 
but not with a typedef name (built-in or otherwise, see discussion in bug 
32187).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH], PowerPC long double transition patches, v2, Patch #4 (fix bug in clone/target attributes on long double == IEEE 128-bit systems)

[Michael Meissner]

On Thu, Jun 21, 2018 at 05:18:19PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:42:38AM -0400, Michael Meissner wrote:
> > This patch prevents the special overriding of the complex float128
> > multiply/divide functions from being run twice if there are clone or target
> > attributes.  I wasn't aware that the hook used to initialize the built-in
> > functions is run each time you change the target options.  The built-in
> > function handling aborts if the name had already been set.
> > 
> > I have tested this on a little endian power8 sysytem using two builds with long
> > double set to IEEE and IBM 128-bit.  This patch fixes testsuite errors from
> > using the clone or target attributes.  Can I install it in the trunk and GCC
> > 8.x branches?
> 
> Next time, please mention what tests are fixed.

It was at least clone1.c and clone2.c.

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

Re: [PATCH], PowerPC long double transition patches, v2, Patch #7 (fix IBM extended double tests to use __ibm128 as needed)

[Segher Boessenkool]

On Wed, Jun 20, 2018 at 10:54:18AM -0400, Michael Meissner wrote:
> This patch fixes the tests in the testsuite that implicitly were expecting long
> double to be IBM extended double to use __ibm128 if long double is configured
> to be IEEE 128-bit floating point.

And just always using __ibm128 does not work?  That needs fixing then.

(Perhaps test long double in a separate testcase, too, then, and only run
that if the appropriate long double type is active).

Patch is okay for now.


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #7 (fix IBM extended double tests to use __ibm128 as needed)

[Michael Meissner]

On Thu, Jun 21, 2018 at 06:07:36PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:54:18AM -0400, Michael Meissner wrote:
> > This patch fixes the tests in the testsuite that implicitly were expecting long
> > double to be IBM extended double to use __ibm128 if long double is configured
> > to be IEEE 128-bit floating point.
> 
> And just always using __ibm128 does not work?  That needs fixing then.

As we've discussed before, __ibm128 is only created when the float128 support
is enabled (VSX and Linux).  If I changed the tests without adding a condition
to only run it on the appropriate systems, it would give errors on AIX, and
32-bit embedded systems.

> (Perhaps test long double in a separate testcase, too, then, and only run
> that if the appropriate long double type is active).
> 
> Patch is okay for now.
> 
> 
> Segher
> 

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

Re: [PATCH], PowerPC long double transition patches, v2, Patch #6 (fix long double tests for -mno-float128)

[Segher Boessenkool]

On Wed, Jun 20, 2018 at 10:49:41AM -0400, Michael Meissner wrote:
> These patches fix the tests in the testsuite that check whether -mno-float128
> works properly.  In these cases, I explicitly run them with long double being
> set to IBM extended double.

So what happened without this patch?


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #6 (fix long double tests for -mno-float128)

[Michael Meissner]

On Thu, Jun 21, 2018 at 06:12:52PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 20, 2018 at 10:49:41AM -0400, Michael Meissner wrote:
> > These patches fix the tests in the testsuite that check whether -mno-float128
> > works properly.  In these cases, I explicitly run them with long double being
> > set to IBM extended double.
> 
> So what happened without this patch?

To give context, it was this patch you were asking about:

2018-06-20  Michael Meissner  <meissner@linux.ibm.com>

	* gcc.target/powerpc/float128-3.c: Change tests that test for
	errors in enabling/disable IEEE 128-bit floating point use the
	-mabi=ibmlongdouble to force long double to be IBM extended.
	* gcc.target/powerpc/float128-5.c: Likewise.
	* gcc.target/powerpc/float128-mix.c: Likewise.

float128-3.c and float128-5.c both issues no error (because they both test if
__FLOAT128__ defined even if you use the -mno-float128 option), instead of the
two errors that the test checks for.

float128-mix.c also issues no error because with -mabi=ieeelongdouble, it is
legal to allow __float128 and long double to be combined.

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

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Michael Meissner]

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

On Thu, Jun 21, 2018 at 02:22:50PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 21, 2018 at 01:26:19PM -0400, Michael Meissner wrote:
> > On Thu, Jun 21, 2018 at 12:09:12PM -0500, Segher Boessenkool wrote:
> > > > 	* config.gcc (powerpc64le*): Remove multilib support for IEEE and
> > > > 	IBM long double.
> > > > 	* config/rs6000/rs6000.c (rs6000_option_override_internal):
> > > > 	Likewise.
> > > > 	* config/rs6000/rs6000.h (TARGET_IEEEQUAD_MULTILIB): Likewise.
> > > > 	* config/rs6000/t-ldouble-linux64le-ibm: Delete, IEEE/IBM long
> > > > 	double multilib no longer supported.
> > > > 	* config/rs6000/t-ldouble-linux64le-ieee: Likewise.
> > > > 	* doc/install.texi (PowerPC options): Delete information about
> > > > 	IEEE/IBM long double multilibs.
> > > 
> > > This reverts r256775 (the commit message should say), except the linux64.h
> > > parts, and it seems you just missed those?
> > 
> > No it only reverts part of r256775.  The main part of the r256775 change is to
> > add support for --with-long-double-format={ieee,ibm} which we need to keep.
> 
> That is r256558 as far as I see?

Yes you were right, r256775 was the patch that enabled multilibs by default,
and 256558 was the patch that added --with-long-double-format=<xxx>.  I thought
I had submitted them as part of one patch.

Here is the patch redone to disable multilib support altogether.  I verified
that without --{enable,disable}-multilib that it no longer builds a multilib
compiler.  Can I install this into the trunk and to the GCC 8.x branch?

2018-06-22  Michael Meissner  <meissner@linux.ibm.com>

	* config.gcc (powerpc64le*): Revert January 16th, 2018 patch that
	added IEEE/IBM long double multilib support on PowerPC little
	endian Linux systems.
	* config/rs6000/linux64.h (MULTILIB_DEFAULTS_IEEE): Likewise.
	(MULTILIB_DEFAULTS): Likewise.
	* config/rs6000/rs6000.c (rs6000_option_override_internal):
	Likewise.
	* config/rs6000/rs6000.h (TARGET_IEEEQUAD_MULTILIB): Likewise.
	* config/rs6000/t-ldouble-linux64le-ibm: Delete, no longer used.
	* config/rs6000/t-ldouble-linux64le-ieee: Delete, no longer used.

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

[-- Attachment #2: ieee128-patch127b --]
[-- Type: text/plain, Size: 6312 bytes --]

Index: gcc/config.gcc
===================================================================
--- gcc/config.gcc	(revision 261910)
+++ gcc/config.gcc	(working copy)
@@ -4566,16 +4566,6 @@ case "${target}" in
 		elif test x$with_long_double_format = xibm; then
 		    tm_defines="${tm_defines} TARGET_IEEEQUAD_DEFAULT=0"
 		fi
-
-		case "${target}:${enable_multilib}:${with_long_double_format}" in
-		    powerpc64le*:yes:ieee | powerpc64le*:yes:ibm)
-			tm_defines="${tm_defines} TARGET_IEEEQUAD_MULTILIB=1"
-			tmake_file="${tmake_file} rs6000/t-ldouble-linux64le-${with_long_double_format}"
-			;;
-		    *)
-			:
-			;;
-		esac
 		;;
 
 	s390*-*-*)
Index: gcc/config/rs6000/linux64.h
===================================================================
--- gcc/config/rs6000/linux64.h	(revision 261910)
+++ gcc/config/rs6000/linux64.h	(working copy)
@@ -245,18 +245,11 @@ extern int dot_symbols;
 #define DYNAMIC_LINKER_PREFIX	""
 #endif
 
-#if TARGET_IEEEQUAD_DEFAULT
-#define MULTILIB_DEFAULTS_IEEE "mabi=ieeelongdouble"
-
-#else  /* TARGET_IEEEQUAD_DEFAULT.  */
-#define MULTILIB_DEFAULTS_IEEE "mabi=ibmlongdouble"
-#endif /* TARGET_IEEEQUAD_DEFAULT.  */
-
-#undef MULTILIB_DEFAULTS
+#undef	MULTILIB_DEFAULTS
 #if DEFAULT_ARCH64_P
-#define MULTILIB_DEFAULTS { "m64", MULTILIB_DEFAULTS_IEEE }
+#define MULTILIB_DEFAULTS { "m64" }
 #else
-#define MULTILIB_DEFAULTS { "m32", MULTILIB_DEFAULTS_IEEE }
+#define MULTILIB_DEFAULTS { "m32" }
 #endif
 
 /* Split stack is only supported for 64 bit, and requires glibc >= 2.18.  */
Index: gcc/config/rs6000/rs6000.c
===================================================================
--- gcc/config/rs6000/rs6000.c	(revision 261910)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -4582,15 +4582,11 @@ rs6000_option_override_internal (bool gl
      systems will also set long double to be IEEE 128-bit.  AIX and Darwin
      explicitly redefine TARGET_IEEEQUAD and TARGET_IEEEQUAD_DEFAULT to 0, so
      those systems will not pick up this default.  Warn if the user changes the
-     default unless either the user used the -Wno-psabi option, or the compiler
-     was built to enable multilibs to switch between the two long double
-     types.  */
+     default unless -Wno-psabi.  */
   if (!global_options_set.x_rs6000_ieeequad)
     rs6000_ieeequad = TARGET_IEEEQUAD_DEFAULT;
 
-  else if (!TARGET_IEEEQUAD_MULTILIB
-	   && rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT
-	   && TARGET_LONG_DOUBLE_128)
+  else if (rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT && TARGET_LONG_DOUBLE_128)
     {
       static bool warned_change_long_double;
       if (!warned_change_long_double)
Index: gcc/config/rs6000/rs6000.h
===================================================================
--- gcc/config/rs6000/rs6000.h	(revision 261910)
+++ gcc/config/rs6000/rs6000.h	(working copy)
@@ -551,12 +551,6 @@ extern int rs6000_vector_align[];
 #define TARGET_ALTIVEC_ABI rs6000_altivec_abi
 #define TARGET_LDBRX (TARGET_POPCNTD || rs6000_cpu == PROCESSOR_CELL)
 
-/* Define as 1 if we support multilibs for switching long double between IEEE
-   128-bit floating point and IBM extended double.  */
-#ifndef TARGET_IEEEQUAD_MULTILIB
-#define TARGET_IEEEQUAD_MULTILIB 0
-#endif
-
 /* ISA 2.01 allowed FCFID to be done in 32-bit, previously it was 64-bit only.
    Enable 32-bit fcfid's on any of the switches for newer ISA machines.  */
 #define TARGET_FCFID	(TARGET_POWERPC64				\
Index: gcc/config/rs6000/t-ldouble-linux64le-ibm
===================================================================
--- gcc/config/rs6000/t-ldouble-linux64le-ibm	(revision 261910)
+++ gcc/config/rs6000/t-ldouble-linux64le-ibm	(working copy)
@@ -1,26 +0,0 @@
-# Long double multilib libraries for PowerPC 64-bit little endian systems using
-# IBM extended double as the long double type.
-#
-# Copyright (C) 2018 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.
-#
-# You should have received a copy of the GNU General Public License
-# along with GCC; see the file COPYING3.  If not see
-# <http://www.gnu.org/licenses/>.
-
-MULTILIB_OPTIONS	+= mabi=ieeelongdouble/mabi=ibmlongdouble
-MULTILIB_DIRNAMES	+= ieee128 ibm128
-MULTILIB_OSDIRNAMES	+= mabi.ibmlongdouble=../lib64$(call if_multiarch,:powerpc64-linux-gnu) \
-			   mabi.ieeelongdouble=../lib64/ieee128$(call if_multiarch,:powerpc64-linux-gnu) \
-			   ../lib64$(call if_multiarch,:powerpc64-linux-gnu)
Index: gcc/config/rs6000/t-ldouble-linux64le-ieee
===================================================================
--- gcc/config/rs6000/t-ldouble-linux64le-ieee	(revision 261910)
+++ gcc/config/rs6000/t-ldouble-linux64le-ieee	(working copy)
@@ -1,26 +0,0 @@
-# Long double multilib libraries for PowerPC 64-bit little endian systems using
-# IEEE 128-bit floating point as the long double type.
-#
-# Copyright (C) 2018 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.
-#
-# You should have received a copy of the GNU General Public License
-# along with GCC; see the file COPYING3.  If not see
-# <http://www.gnu.org/licenses/>.
-
-MULTILIB_OPTIONS	+= mabi=ieeelongdouble/mabi=ibmlongdouble
-MULTILIB_DIRNAMES	+= ieee128 ibm128
-MULTILIB_OSDIRNAMES	+= mabi.ibmlongdouble=../lib64/ibm128$(call if_multiarch,:powerpc64-linux-gnu) \
-			   mabi.ieeelongdouble=../lib64$(call if_multiarch,:powerpc64-linux-gnu) \
-			   ../lib64$(call if_multiarch,:powerpc64-linux-gnu)

Re: [PATCH], PowerPC long double transition patches, v2, Patch #3 (use correct way to get the IEEE 128-bit complex type)

[Segher Boessenkool]

On Thu, Jun 21, 2018 at 10:43:16PM +0000, Joseph Myers wrote:
> On Thu, 21 Jun 2018, Segher Boessenkool wrote:
> 
> > The comment doesn't make much sense.  If long double is IBM, the long
> > double complex mode is ICmode, not KCmode.  "To get the IEEE128 complex
> > type", perhaps?  And can't you do _Complex __ieee128 or such?
> 
> You can do _Complex _Float128, in C only, not C++ (which doesn't have the 
> _Float128 keyword).  _Complex can be used with keywords for type names, 
> but not with a typedef name (built-in or otherwise, see discussion in bug 
> 32187).

__ieee128 is a type, not a typedef:

lang_hooks.types.register_builtin_type (ieee128_float_type_node, "__ieee128");

(Or what am I missing?  Or are we talking past eachother?)


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #7 (fix IBM extended double tests to use __ibm128 as needed)

[Segher Boessenkool]

On Thu, Jun 21, 2018 at 07:11:37PM -0400, Michael Meissner wrote:
> On Thu, Jun 21, 2018 at 06:07:36PM -0500, Segher Boessenkool wrote:
> > On Wed, Jun 20, 2018 at 10:54:18AM -0400, Michael Meissner wrote:
> > > This patch fixes the tests in the testsuite that implicitly were expecting long
> > > double to be IBM extended double to use __ibm128 if long double is configured
> > > to be IEEE 128-bit floating point.
> > 
> > And just always using __ibm128 does not work?  That needs fixing then.
> 
> As we've discussed before, __ibm128 is only created when the float128 support
> is enabled (VSX and Linux).  If I changed the tests without adding a condition
> to only run it on the appropriate systems, it would give errors on AIX, and
> 32-bit embedded systems.

See the next lines:

> > (Perhaps test long double in a separate testcase, too, then, and only run
> > that if the appropriate long double type is active).

So, have a test for long double (gated on when long double is an appropriate
type for those tests), and one for __ibm128 (with a quite different
condition for those).


Segher

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Segher Boessenkool]

On Fri, Jun 22, 2018 at 05:04:14PM -0400, Michael Meissner wrote:
> Here is the patch redone to disable multilib support altogether.  I verified
> that without --{enable,disable}-multilib that it no longer builds a multilib
> compiler.  Can I install this into the trunk and to the GCC 8.x branch?

Okay for trunk and 8.  Thanks!


Segher


> 2018-06-22  Michael Meissner  <meissner@linux.ibm.com>
> 
> 	* config.gcc (powerpc64le*): Revert January 16th, 2018 patch that
> 	added IEEE/IBM long double multilib support on PowerPC little
> 	endian Linux systems.
> 	* config/rs6000/linux64.h (MULTILIB_DEFAULTS_IEEE): Likewise.
> 	(MULTILIB_DEFAULTS): Likewise.
> 	* config/rs6000/rs6000.c (rs6000_option_override_internal):
> 	Likewise.
> 	* config/rs6000/rs6000.h (TARGET_IEEEQUAD_MULTILIB): Likewise.
> 	* config/rs6000/t-ldouble-linux64le-ibm: Delete, no longer used.
> 	* config/rs6000/t-ldouble-linux64le-ieee: Delete, no longer used.

Re: [PATCH], PowerPC long double transition patches, v2, Patch #3 (use correct way to get the IEEE 128-bit complex type)

[Joseph Myers]

On Sat, 23 Jun 2018, Segher Boessenkool wrote:

> On Thu, Jun 21, 2018 at 10:43:16PM +0000, Joseph Myers wrote:
> > On Thu, 21 Jun 2018, Segher Boessenkool wrote:
> > 
> > > The comment doesn't make much sense.  If long double is IBM, the long
> > > double complex mode is ICmode, not KCmode.  "To get the IEEE128 complex
> > > type", perhaps?  And can't you do _Complex __ieee128 or such?
> > 
> > You can do _Complex _Float128, in C only, not C++ (which doesn't have the 
> > _Float128 keyword).  _Complex can be used with keywords for type names, 
> > but not with a typedef name (built-in or otherwise, see discussion in bug 
> > 32187).
> 
> __ieee128 is a type, not a typedef:
> 
> lang_hooks.types.register_builtin_type (ieee128_float_type_node, "__ieee128");

A type registered with register_builtin_type is effectively a built-in 
typedef name and is handled in the front ends through the same code paths 
as typedef names (as opposed to types made up of type-specifier keywords, 
which are handled by custom logic in the front ends that maps multisets of 
such keywords to the corresponding types).

It would be possible, as discussed in bug 32187, to handle such types 
differently (so allowing _Complex together with __ieee128 while still not 
allowing it together with a user-defined typedef), but that's not the 
current situation.

-- 
Joseph S. Myers
joseph@codesourcery.com