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] |
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] |