This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] PR 85075, Fix PowerPC __float182/__ibm128 types and mangling


PR target/85075 shows that there are some problems with the types for the 3
128-bit floating point types on the PowerPC:

	__float128	(and _Float128 in C, IEEE 128-bit)
	__ieee128	(IBM extended double)
	long double	(either IEEE 128-bit or IBM extended double)

With GCC 8, we are beginning the transition of long double from the IBM
extended double format to IEEE 128-bit.

I implemented __float128 and __ieee128 initially as being separate types when
the long double format was the other type, and mapped to long double when the
long double format was the same as the type.

However, the use of C++ templates and overloaded functions within classes shows
that we really need to have 3 separate types.  Each type needs to have
different mangling.

Since __float128 and __ibm128 are now always separate types, I relaxed the
restriction that __ibm128 can only be used if -mlong-double-128.

In developing this patch, Segher noticed that the mangling for __float128
violated the mangling standards.  This patch includes a change to use a more
official mangling (u10__float128).  This means that GCC 8 will not be able to
link with C++ functions that pass or return __float128 values compiled with GCC
6 or GCC 7.  I have put in a warning if __float128 is mangled.  The warning can
be silenced by using -Wno-psabi.

In addition, when I built this on big endian system, the changes exposed a
latent bug with the way __builtin_packlongdouble was done when it tried to
support the first argument overlapping with the result.  I have removed the
code to support overlapping input/output for this builtin.  I imagine that we
will need to add __builtin_packieee128 and __builtin_unpackieee128 as well in
the future (or make __builtin_{,un}packlongdouble support all three types).

The manglings that are now used are:

For -mabi=ieeelongdouble:

	__float128	"u10__float128"
	__ibm128	"u8__ibm128"
	long double	"u9__ieee128"

For -mabi=ibmlongdouble:

	__float128	"u10__float128"
	__ibm128	"u8__ibm128"
	long double	"g"

For -mlong-double-64:

	__float128	"u10__float128"
	__ibm128	"u8__ibm128"
	long double	"e"

I have tested these patches on a little endian power8 system and a big endian
power7 system (both 32/64-bit).  I also tested a previous version of the patch
on a big endian power8 system (both 32/64-bit).  There were no regressions.

Can I apply these patches to the GCC 8 trunk?

[gcc]
2018-04-15  Michael Meissner  <meissner@linux.vnet.ibm.com>

	PR target/85075
	* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): __ibm128 is
	now a separate type, don't #define __ibm128 as long double.
	* config/rs6000/rs6000.c (rs6000_init_builtins): Make __ibm128 a
	separate type on systems that support IEEE 128-bit floating point.
	(rs6000_mangle_type): Use separate manglings for __ibm128 and
	__float128.  Change __float128 mangling from U10__float128 to
	u10__float128.  Issue a warning that the mangling has changed in
	GCC 8.
	* config/rs6000/rs6000.md (pack<mode>): Do not try handle a pack
	where the inputs overlap with the output.

[gcc/testsuite]
2018-04-15  Michael Meissner  <meissner@linux.vnet.ibm.com>

	PR target/85075
	* g++.dg/pr85075-1.C: New tests.  Make sure that __float128,
	__ibm128, and long double are different types, and that you can
	mix them in templates and with overloaded functions.  Test all 3
	different long dobule variants (IEEE 128 bit, IBM 128 bit, and 64
	bit).
	* g++.dg/pr85075-2.C: Likewise.
	* g++.dg/pr85075-3.C: Likewise.

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

Attachment: pr85075.patch12b
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]