From: Jason Merrill <jason@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>,
"Joseph S. Myers" <joseph@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org,
Richard Earnshaw <richard.earnshaw@arm.com>,
Kyrylo Tkachov <kyrylo.tkachov@arm.com>,
richard.sandiford@arm.com
Subject: Re: [PATCH] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]
Date: Fri, 30 Sep 2022 09:54:49 -0400 [thread overview]
Message-ID: <60f5d708-a233-2c36-6f74-ae064fdf6ffd@redhat.com> (raw)
In-Reply-To: <YzVtB20h3jGKmYg1@tucnak>
On 9/29/22 06:01, Jakub Jelinek wrote:
> Hi!
>
> 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.
>
> Tested on x86_64, i686 and powerpc64le, ok for trunk?
OK.
> 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_ ?
You argued for keeping __float128 separate from _Float128, does the same
argument not apply to this case?
> 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?
Sounds good.
> 2022-09-29 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.
>
> --- gcc/config/i386/i386.cc.jj 2022-09-29 09:13:25.713718513 +0200
> +++ gcc/config/i386/i386.cc 2022-09-29 11:29:20.828358152 +0200
> @@ -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";
> --- gcc/config/ia64/ia64.cc.jj 2022-09-27 08:03:26.977984661 +0200
> +++ gcc/config/ia64/ia64.cc 2022-09-29 11:29:44.071037677 +0200
> @@ -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)
> --- gcc/config/rs6000/rs6000.cc.jj 2022-09-27 08:03:26.999984363 +0200
> +++ gcc/config/rs6000/rs6000.cc 2022-09-29 11:26:10.290985331 +0200
> @@ -20270,13 +20270,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)
> --- gcc/config/s390/s390.cc.jj 2022-09-26 18:47:26.950349802 +0200
> +++ gcc/config/s390/s390.cc 2022-09-29 11:26:51.180421534 +0200
> @@ -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. */
> --- gcc/testsuite/g++.dg/cpp23/ext-floating11.C.jj 2022-09-29 11:33:46.331697320 +0200
> +++ gcc/testsuite/g++.dg/cpp23/ext-floating11.C 2022-09-29 11:40:30.610123406 +0200
> @@ -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
> +}
>
> Jakub
>
next prev parent reply other threads:[~2022-09-30 13:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 10:01 Jakub Jelinek
2022-09-30 13:54 ` Jason Merrill [this message]
2022-09-30 17:13 ` [PATCH] arm, aarch64, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080] Jakub Jelinek
2022-09-30 17:38 ` Richard Sandiford
2022-09-30 17:49 ` Jakub Jelinek
2022-09-30 19:44 ` Jason Merrill
2022-09-30 15:07 ` [PATCH] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080] Segher Boessenkool
2022-09-30 15:31 ` Jakub Jelinek
2022-09-30 15:50 ` Segher Boessenkool
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=60f5d708-a233-2c36-6f74-ae064fdf6ffd@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=joseph@codesourcery.com \
--cc=kyrylo.tkachov@arm.com \
--cc=richard.earnshaw@arm.com \
--cc=richard.sandiford@arm.com \
/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: link
Be 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).