From: Jason Merrill <jason@redhat.com>
To: Jakub Jelinek <jakub@redhat.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] arm, aarch64, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]
Date: Fri, 30 Sep 2022 15:44:16 -0400 [thread overview]
Message-ID: <4451b58d-d270-3f07-6748-fa82abd444a6@redhat.com> (raw)
In-Reply-To: <Yzcjxp+y+yXlUO8y@tucnak>
On 9/30/22 13:13, Jakub Jelinek wrote:
> On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote:
>>> 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?
>
> Actually, they already were distinct types that just mangled the same.
> So the same issue that had to be solved on i?86, ia64 and rs6000 for
> _Float64x vs. long double is a problem on arm and aarch64 with _Float16
> vs. __fp16.
> The following patch fixes it.
>
>>> 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?
>
> And seems even on csky __fp16 is distinct type from _Float16 (which is a
> good thing for consistency, these 3 targets are the only ones that have
> __fp16 type), so instead the patch handles it the same as on arm/aarch64,
> Dh mangling for __fp16 and DF16_ for _Float16.
>
> Tested with cross-compilers, ok for trunk?
OK.
> 2022-09-30 Jakub Jelinek <jakub@redhat.com>
>
> PR c++/107080
> * config/arm/arm.cc (arm_mangle_type): Mangle just __fp16 as Dh
> and _Float16 as DF16_.
> * config/aarch64/aarch64.cc (aarch64_mangle_type): Likewise.
> * config/csky/csky.cc (csky_init_builtins): Fix a comment typo.
> (csky_mangle_type): Mangle __fp16 as Dh and _Float16 as DF16_
> rather than mangling __fp16 as __fp16.
>
> * g++.target/arm/pr107080.C: New test.
> * g++.target/aarch64/pr107080.C: New test.
>
> --- gcc/config/arm/arm.cc.jj 2022-09-29 18:11:28.746750048 +0200
> +++ gcc/config/arm/arm.cc 2022-09-30 19:01:48.774286551 +0200
> @@ -30359,6 +30359,8 @@ arm_mangle_type (const_tree type)
> /* Half-precision floating point types. */
> if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
> {
> + if (TYPE_MAIN_VARIANT (type) == float16_type_node)
> + return NULL;
> if (TYPE_MODE (type) == BFmode)
> return "u6__bf16";
> else
> --- gcc/config/aarch64/aarch64.cc.jj 2022-09-29 18:11:34.806667210 +0200
> +++ gcc/config/aarch64/aarch64.cc 2022-09-30 19:02:02.079108171 +0200
> @@ -20664,6 +20664,8 @@ aarch64_mangle_type (const_tree type)
> /* Half-precision floating point types. */
> if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
> {
> + if (TYPE_MAIN_VARIANT (type) == float16_type_node)
> + return NULL;
> if (TYPE_MODE (type) == BFmode)
> return "u6__bf16";
> else
> --- gcc/config/csky/csky.cc.jj 2022-09-08 13:01:19.239779562 +0200
> +++ gcc/config/csky/csky.cc 2022-09-30 19:06:09.126794587 +0200
> @@ -7300,7 +7300,7 @@ csky_init_cumulative_args (CUMULATIVE_AR
> void
> csky_init_builtins (void)
> {
> - /* Inint fp16. */
> + /* Init fp16. */
> static tree csky_floatHF_type_node = make_node (REAL_TYPE);
> TYPE_PRECISION (csky_floatHF_type_node) = GET_MODE_PRECISION (HFmode);
> layout_type (csky_floatHF_type_node);
> @@ -7313,10 +7313,10 @@ csky_init_builtins (void)
> static const char *
> csky_mangle_type (const_tree type)
> {
> - if (TYPE_NAME (type) && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
> - && DECL_NAME (TYPE_NAME (type))
> - && !strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type))), "__fp16"))
> - return "__fp16";
> + if (TREE_CODE (type) == REAL_TYPE
> + && TYPE_PRECISION (type) == 16
> + && TYPE_MAIN_VARIANT (type) != float16_type_node)
> + return "Dh";
>
> /* Use the default mangling. */
> return NULL;
> --- gcc/testsuite/g++.target/arm/pr107080.C.jj 2022-09-30 18:56:08.885797047 +0200
> +++ gcc/testsuite/g++.target/arm/pr107080.C 2022-09-30 18:58:07.812221153 +0200
> @@ -0,0 +1,16 @@
> +// PR c++/107080
> +// { dg-do compile }
> +// { dg-options "-mfp16-format=ieee" }
> +
> +template <typename T, typename T1>
> +int
> +foo (T x, T1 y)
> +{
> + return 3;
> +}
> +
> +int
> +main ()
> +{
> + return (foo (0.0f16, 0.0f16) + foo (0.0f16, (__fp16) 0.0)) != 6;
> +}
> --- gcc/testsuite/g++.target/aarch64/pr107080.C.jj 2022-09-30 18:56:08.885797047 +0200
> +++ gcc/testsuite/g++.target/aarch64/pr107080.C 2022-09-30 18:56:04.805851530 +0200
> @@ -0,0 +1,16 @@
> +// PR c++/107080
> +// { dg-do compile }
> +// { dg-options "" }
> +
> +template <typename T, typename T1>
> +int
> +foo (T x, T1 y)
> +{
> + return 3;
> +}
> +
> +int
> +main ()
> +{
> + return (foo (0.0f16, 0.0f16) + foo (0.0f16, (__fp16) 0.0)) != 6;
> +}
>
>
> Jakub
>
next prev parent reply other threads:[~2022-09-30 19:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 10:01 [PATCH] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080] Jakub Jelinek
2022-09-30 13:54 ` Jason Merrill
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 [this message]
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=4451b58d-d270-3f07-6748-fa82abd444a6@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.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).