From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F37093858298; Fri, 30 Sep 2022 16:41:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F37093858298 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1664556090; bh=2NOaXGtRHb1+FrMU2iTd+Irr/uqVtm58HfOR6sxKElo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cLC72jcZDLFH/ypYs3n8cK1s/q517cmQM8Ms8uNf/3MWHF07UpyxRMg1DymVTuAWZ Pa60pL8ZVOVLC+6TdJRw2H9E07OXzXdMWVXEUQS/xKamsY86mEXp1Edb3bNA2SP9sb bValHWKK1MIwkmpC5wjunDPlupp4ds0SmV770NYY= From: "cvs-commit at gcc dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ABI, assemble-failure, ice-checking, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107080 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a6d8c61a498e9daa1bc7fe419055ae44ad8289cc commit r13-2992-ga6d8c61a498e9daa1bc7fe419055ae44ad8289cc Author: Jakub Jelinek 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=3Dieeelongdouble), 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 =3D 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 =3D TYPE_MAIN_VARIANT (type); if (TYPE_MAIN_VARIANT (type) =3D=3D 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: ::=3D Dh # IEEE 754r half-precision floating point (16= bits) ::=3D DF _ # 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 __f= p16, 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 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.=