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

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

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107080

            Bug ID: 107080
           Summary: ICE in verify_symtab_nodes using _Float64x with long
                    double
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jsm28 at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---
            Target: x86_64-* i?86-* ia64-*

Compiling the following C++ test for x86_64 (or i686 or ia64) produces an ICE,
no optimization or other options required (presumably introduced by the _FloatN
/ _FloatNx support for C++).


template<typename> struct S;

template<> struct S<long double>
{
  static int call (long double x, long double y) throw ()
  {
    return 3;
  }
};

template<> struct S<_Float64x>
{
  static int call (_Float64x x, _Float64x y) throw ()
  {
    return 3;
  }
};

template<typename T1, typename T2>
inline int
g (T1 x, T2 y) throw ()
{
  typedef decltype (x + y) T3;
  return S<T3>::call (x, y);
}

int
f ()
{
  return g (0.0f64x, 0.0f64x) + g (0.0f64x, 0.0L);
}



t.cc:31:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
   31 | }
      | ^
_Z1gIeeEiT_T0_/4 (int g(T1, T2) [with T1 = _Float64x; T2 = long double])
  Type: function definition analyzed
  Visibility: semantic_interposition no_reorder public weak comdat
comdat_group:_Z1gIeeEiT_T0_ one_only
  previous sharing asm name: 3
  References: __gxx_personality_v0/5 (addr) 
  Referring: 
  Function flags: body
  Called by: _Z1fv/2 
  Calls: _ZN1SIeE4callEee/1 
_Z1gIeeEiT_T0_/3 (int g(T1, T2) [with T1 = _Float64x; T2 = _Float64x])
  Type: function definition analyzed
  Visibility: semantic_interposition no_reorder public weak comdat
comdat_group:_Z1gIeeEiT_T0_ one_only
  next sharing asm name: 4
  References: __gxx_personality_v0/5 (addr) 
  Referring: 
  Function flags: body
  Called by: _Z1fv/2 
  Calls: _ZN1SIeE4callEee/1 
t.cc:31:1: internal compiler error: symtab_node::verify failed
0xc9ba69 symtab_node::verify_symtab_nodes()
        /scratch/jmyers/glibc/many13/src/gcc/gcc/symtab.cc:1410
0xcb4ab3 symtab_node::checking_verify_symtab_nodes()
        /scratch/jmyers/glibc/many13/src/gcc/gcc/cgraph.h:682
0xcb4ab3 symbol_table::compile()
        /scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2264
0xcb80cd symbol_table::compile()
        /scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2261
0xcb80cd symbol_table::finalize_compilation_unit()
        /scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2529
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107080

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-09-29
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is a reduced testcase:
```
template<typename T, typename T1> 
int f (T x, T1 y) throw ()
{
    return 3;
}

int
main ()
{
  return (f (0.0f64x, 0.0f64x) + f (0.0f64x, 0.0L)) != 6;
}
```
This ICEs and with release checking it produces an assembler error:
```
/tmp/ccJDRaEi.s: Assembler messages:
/tmp/ccJDRaEi.s:93: Error: symbol `_Z1fIeeEiT_T0_' is already defined
```

I can only assume the issue is _Float64x is not treated the same as long double
for type comparison but is treated the same for mangling (which is why I marked
it as an ABI issue).

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107080

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602475.html

[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.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107080

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.

[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 #5 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:e564021e4c225420cd8986e9a7a42efe741f92d1

commit r13-2993-ge564021e4c225420cd8986e9a7a42efe741f92d1
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Sep 30 19:52:49 2022 +0200

    aarch64: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

    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 so far for aarch64.

    2022-09-30  Jakub Jelinek  <jakub@redhat.com>

            PR c++/107080
            * config/aarch64/aarch64.cc (aarch64_mangle_type): Mangle just
__fp16
            as Dh and _Float16 as DF16_.

            * g++.target/aarch64/pr107080.C: New test.

[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 #6 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:61786edf7a82ffb4979207b43a8204ebc2a7671d

commit r13-2995-g61786edf7a82ffb4979207b43a8204ebc2a7671d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Sep 30 21:54:08 2022 +0200

    arm, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

    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 for arm after aarch64 has been changed
    already before.

    > > 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.

    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/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.