public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/107080] ICE in verify_symtab_nodes using _Float64x with long double Date: Fri, 30 Sep 2022 16:41:28 +0000 [thread overview] Message-ID: <bug-107080-4-3B4IDInMPD@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-107080-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107080 --- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: 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.
next prev parent reply other threads:[~2022-09-30 16:41 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-09-29 0:09 [Bug c++/107080] New: " jsm28 at gcc dot gnu.org 2022-09-29 2:31 ` [Bug c++/107080] " pinskia at gcc dot gnu.org 2022-09-29 11:41 ` jakub at gcc dot gnu.org 2022-09-30 16:41 ` cvs-commit at gcc dot gnu.org [this message] 2022-09-30 16:43 ` jakub at gcc dot gnu.org 2022-09-30 17:53 ` cvs-commit at gcc dot gnu.org 2022-09-30 19:55 ` cvs-commit at gcc dot gnu.org
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=bug-107080-4-3B4IDInMPD@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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).