public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-2992] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080] Date: Fri, 30 Sep 2022 16:41:27 +0000 (GMT) [thread overview] Message-ID: <20220930164127.9B5293858C55@sourceware.org> (raw) https://gcc.gnu.org/g:a6d8c61a498e9daa1bc7fe419055ae44ad8289cc commit r13-2992-ga6d8c61a498e9daa1bc7fe419055ae44ad8289cc Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Sep 30 18:40:35 2022 +0200 i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080] The following testcase ICEs on x86 as well as ppc64le (the latter with -mabi=ieeelongdouble), because _Float64x there isn't mangled as DF64x but e or u9__ieee128 instead. Those are the mangling that should be used for the non-standard types with the same mode or for long double, but not for _Float64x. All the 4 mangle_type targhook implementations start with type = TYPE_MAIN_VARIANT (type); so I think it is cleanest to handle it the same in all and return NULL before the switches on mode or whatever other tests. s390 doesn't actually have a bug, but while I was there, having type = TYPE_MAIN_VARIANT (type); if (TYPE_MAIN_VARIANT (type) == long_double_type_node) looked useless to me. Note, there is one further problem on aarch64/arm, types with HFmode (_Float16 and __fp16) are there mangled as Dh (which is standard Itanium mangling: ::= Dh # IEEE 754r half-precision floating point (16 bits) ::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits) so in theory is also ok, but DF16_ is more specific. Should we just change Dh to DF16_ in those backends, or should __fp16 there be distinct type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ? And there is csky, which mangles __fp16 (but only if type's name is __fp16, not _Float16) as __fp16, that looks clearly invalid to me as it isn't valid in the mangling grammar. So perhaps just nuke csky's mangle_type and have it mangled as DF16_ by the generic code? 2022-09-30 Jakub Jelinek <jakub@redhat.com> PR c++/107080 * config/i386/i386.cc (ix86_mangle_type): Always return NULL for float128_type_node or float64x_type_node, don't check float128t_type_node later on. * config/ia64/ia64.cc (ia64_mangle_type): Always return NULL for float128_type_node or float64x_type_node. * config/rs6000/rs6000.cc (rs6000_mangle_type): Likewise. Don't check float128_type_node later on. * config/s390/s390.cc (s390_mangle_type): Don't use TYPE_MAIN_VARIANT on type which was set to TYPE_MAIN_VARIANT a few lines earlier. * g++.dg/cpp23/ext-floating11.C: New test. Diff: --- gcc/config/i386/i386.cc | 8 +-- gcc/config/ia64/ia64.cc | 3 ++ gcc/config/rs6000/rs6000.cc | 9 ++-- gcc/config/s390/s390.cc | 3 +- gcc/testsuite/g++.dg/cpp23/ext-floating11.C | 79 +++++++++++++++++++++++++++++ 5 files changed, 91 insertions(+), 11 deletions(-) diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index 4386caf843e..ff4de2d6dd5 100644 --- a/gcc/config/i386/i386.cc +++ b/gcc/config/i386/i386.cc @@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type) && TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE) return NULL; + if (type == float128_type_node || type == float64x_type_node) + return NULL; + switch (TYPE_MODE (type)) { case E_BFmode: @@ -22735,10 +22738,7 @@ ix86_mangle_type (const_tree type) return "DF16_"; case E_TFmode: /* __float128 is "g". */ - if (type == float128t_type_node) - return "g"; - /* _Float128 should mangle as "DF128_" done in generic code. */ - return NULL; + return "g"; case E_XFmode: /* "long double" or __float80 is "e". */ return "e"; diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc index d510573a0a4..995ff906940 100644 --- a/gcc/config/ia64/ia64.cc +++ b/gcc/config/ia64/ia64.cc @@ -11225,6 +11225,9 @@ ia64_mangle_type (const_tree type) && TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE) return NULL; + if (type == float128_type_node || type == float64x_type_node) + return NULL; + /* On HP-UX, "long double" is mangled as "e" so __float128 is mangled as "e". */ if (!TARGET_HPUX && TYPE_MODE (type) == TFmode) diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc index b9496d7f268..d2743f7bce6 100644 --- a/gcc/config/rs6000/rs6000.cc +++ b/gcc/config/rs6000/rs6000.cc @@ -20276,13 +20276,12 @@ rs6000_mangle_type (const_tree type) if (type == bool_int_type_node) return "U6__booli"; if (type == bool_long_long_type_node) return "U6__boolx"; + if (type == float128_type_node || type == float64x_type_node) + return NULL; + if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IBM_P (TYPE_MODE (type))) return "g"; - if (SCALAR_FLOAT_TYPE_P (type) - && FLOAT128_IEEE_P (TYPE_MODE (type)) - /* _Float128 should mangle as DF128_ (done in generic code) - rather than u9__ieee128 (used for __ieee128 and __float128). */ - && type != float128_type_node) + if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IEEE_P (TYPE_MODE (type))) return "u9__ieee128"; if (type == vector_pair_type_node) diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc index 9861913af05..ae309471f04 100644 --- a/gcc/config/s390/s390.cc +++ b/gcc/config/s390/s390.cc @@ -7642,8 +7642,7 @@ s390_mangle_type (const_tree type) if (type == s390_builtin_types[BT_BV4SI]) return "U6__booli"; if (type == s390_builtin_types[BT_BV2DI]) return "U6__booll"; - if (TYPE_MAIN_VARIANT (type) == long_double_type_node - && TARGET_LONG_DOUBLE_128) + if (type == long_double_type_node && TARGET_LONG_DOUBLE_128) return "g"; /* For all other types, use normal C++ mangling. */ diff --git a/gcc/testsuite/g++.dg/cpp23/ext-floating11.C b/gcc/testsuite/g++.dg/cpp23/ext-floating11.C new file mode 100644 index 00000000000..2a52c94d64c --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp23/ext-floating11.C @@ -0,0 +1,79 @@ +// P1467R9 - Extended floating-point types and standard names. +// { dg-do compile { target c++23 } } +// { dg-options "" } + +#include "ext-floating.h" + +#ifdef __STRICT_ANSI__ +#undef __SIZEOF_FLOAT128__ +#endif + +extern "C" void abort (); + +using namespace std; + +template <typename T, typename U> +int +foo (T x, U y) noexcept +{ + return 3; +} + +int +main () +{ + if (foo (0.0f, 0.0f) != 3) + abort (); + if (foo (0.0, 0.0) != 3) + abort (); + if (foo (0.0L, 0.0L) != 3) + abort (); +#ifdef __STDCPP_FLOAT16_T__ + if (foo (0.0f16, 0.0f16) != 3) + abort (); + if (foo (0.0f, 0.0f16) != 3) + abort (); +#endif +#ifdef __STDCPP_FLOAT32_T__ + if (foo (0.0f32, 0.0f32) != 3) + abort (); + if (foo (0.0f, 0.0f32) != 3) + abort (); +#endif +#ifdef __STDCPP_FLOAT64_T__ + if (foo (0.0f64, 0.0f64) != 3) + abort (); + if (foo (0.0, 0.0f64) != 3) + abort (); +#endif +#ifdef __STDCPP_FLOAT128_T__ + if (foo (0.0f128, 0.0f128) != 3) + abort (); + if (foo (0.0L, 0.0f128) != 3) + abort (); +#endif +#ifdef __STDCPP_BFLOAT16_T__ + if (foo (0.0bf16, 0.0bf16) != 3) + abort (); + if (foo (0.0f, 0.0bf16) != 3) + abort (); +#endif +#ifdef __FLT32X_MANT_DIG__ + if (foo (0.0f32x, 0.0f32x) != 3) + abort (); + if (foo (0.0, 0.0f32x) != 3) + abort (); +#endif +#ifdef __FLT64X_MANT_DIG__ + if (foo (0.0f64x, 0.0f64x) != 3) + abort (); + if (foo (0.0L, 0.0f64x) != 3) + abort (); +#endif +#ifdef __FLT128X_MANT_DIG__ + if (foo (0.0f128x, 0.0f128x) != 3) + abort (); + if (foo (0.0L, 0.0f128x) != 3) + abort (); +#endif +}
reply other threads:[~2022-09-30 16:41 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220930164127.9B5293858C55@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).