[Bug c++/107080] ICE in verify_symtab_nodes using _Float64x with long double

[cvs-commit at gcc dot gnu.org]

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.