[Bug libstdc++/108883] New: [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

[Bug libstdc++/108883] New: [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

[jakub at gcc dot gnu.org]

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

            Bug ID: 108883
           Summary: [13 Regression] ABI problems with
                    _Float16/std::bfloat16_t rtti symbols on i?86
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

My https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612342.html patch
works fine on i?86 in Fedora 38/39, but when I try it in my local
bootstrap/regtest,
_ZTIDF16b
_ZTIDF16_
_ZTIPKDF16_
_ZTIPDF16b
_ZTIPDF16_
_ZTIPKDF16b
symbols are missing.  This is because _Float16 and decltype(0.0bf16) on
i?86/x86_64
are only supported with -msse2 (because psABI passes those in SSE registers). 
While x86_64 has -msse2 on by default, ia32 doesn't and it would be problematic
if these 6 exports depend on whether libstdc++.{so,a} or libsupc++.a has been
built with -msse2 or not; programs could be compiled with -msse2 and use those
types and if libstdc++ doesn't
have the rtti for it, it wouldn't link.

Not sure what we can do, either detect that and compile
libstdc++-v3/libsupc++/fundamental_type_info.cc in that case forcefully with
-msse2 and
arrange in that case for [[gnu::target ("no-sse")]] to be on the destructor
definition
so that SSE/SSE2 instructions don't leak by accident into the dtor code, or
supply the RTTI symbols by hand say in assembly (we are doing this sort of
things in
RHEL GTS), or arrange somehow for the backend(s) to pretend support for the
extra types even if they are just supported conditionally, say by adding a new
target hook which would be called when emitting the fundamental type info.

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-02-22
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |redi at gcc dot gnu.org
   Target Milestone|---                         |13.0

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i?86-*-*

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can we split them out to a separate CU that we can build with -msse2?

That is, does it work to simply add tinfo-x86-sse2.o by compiling
fundamental_type_info.cc with -msse2 and the linker will sort out duplicates
via comdats appropriately?

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Can we split them out to a separate CU that we can build with -msse2?
> 
> That is, does it work to simply add tinfo-x86-sse2.o by compiling
> fundamental_type_info.cc with -msse2 and the linker will sort out duplicates
> via comdats appropriately?

Hmm, but we have no way to tell it to prefer the -mno-sse2 variant if that
exists ...(?)

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54506&action=edit
gcc13-pr108883.patch

Untested fix on the compiler side of emit_support_tinfos.

That said, these fundamental types whose presence/absence depends on ISA flags
are quite problematic IMHO, as they are incompatible with the target
attribute/pragmas.  Whether they are available or not available depends on
whether in this case SSE2 is enabled during compiler initialization (aka after
parsing command line options) and then they are available or unavailable to
everything else based on that.

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:6978df2c04df165eaa6aac9e17b6c770bed460e3

commit r13-6426-g6978df2c04df165eaa6aac9e17b6c770bed460e3
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 3 00:34:59 2023 +0100

    c++, v3: Emit fundamental tinfos for _Float16/decltype(0.0bf16) types on
ia32 with -mno-sse2 [PR108883]

    _Float16 and decltype(0.0bf16) types are on x86 supported only with
    -msse2.  On x86_64 that is the default, but on ia32 it is not.
    We should still emit fundamental type tinfo for those types in
    libsupc++.a/libstdc++.*, regardless of whether libsupc++/libstdc++
    is compiled with -msse2 or not, as user programs can be compiled
    with different ISA flags from libsupc++/libstdc++ and if they
    are compiled with -msse2 and use std::float16_t or std::bfloat16_t
    and need RTTI for it, it should work out of the box.  Furthermore,
    libstdc++ ABI on ia32 shouldn't depend on whether the library
    is compiled with -mno-sse or -msse2.

    Unfortunately, just hacking up libsupc++ Makefile/configure so that
    a single source is compiled with -msse2 isn't appropriate, because
    that TU emits also code and the code should be able to run on CPUs
    which libstdc++ supports.  We could add [[gnu::attribute ("no-sse2")]]
    there perhaps conditionally, but it all gets quite ugly.

    The following patch instead adds a target hook which allows the backend
    to temporarily tweak registered types such that emit_support_tinfos
    emits whatever is needed.

    Additionally, it makes emit_support_tinfos_1 call emit_tinfo_decl
    immediately, so that temporarily created dummy types for emit_support_tinfo
    purposes only can be nullified again afterwards.  And removes the
    previous fallback_* types used for dfloat*_type_node tinfos even when
    decimal types aren't supported.

    2023-03-03  Jakub Jelinek  <jakub@redhat.com>

            PR target/108883
    gcc/
            * target.h (emit_support_tinfos_callback): New typedef.
            * targhooks.h (default_emit_support_tinfos): Declare.
            * targhooks.cc (default_emit_support_tinfos): New function.
            * target.def (emit_support_tinfos): New target hook.
            * doc/tm.texi.in (emit_support_tinfos): Document it.
            * doc/tm.texi: Regenerated.
            * config/i386/i386.cc (ix86_emit_support_tinfos): New function.
            (TARGET_EMIT_SUPPORT_TINFOS): Redefine.
    gcc/cp/
            * cp-tree.h (enum cp_tree_index): Remove CPTI_FALLBACK_DFLOAT*_TYPE
            enumerators.
            (fallback_dfloat32_type, fallback_dfloat64_type,
            fallback_dfloat128_type): Remove.
            * rtti.cc (emit_support_tinfo_1): If not emitted already, call
            emit_tinfo_decl and remove from unemitted_tinfo_decls right away.
            (emit_support_tinfos): Move &dfloat*_type_node from fundamentals
array
            into new fundamentals_with_fallback array.  Call
emit_support_tinfo_1
            on elements of that array too, with the difference that if
            the type is NULL, use a fallback REAL_TYPE for it temporarily.
            Drop the !targetm.decimal_float_supported_p () handling.  Call
            targetm.emit_support_tinfos at the end.
            * mangle.cc (write_builtin_type): Remove references to
            fallback_dfloat*_type.  Handle bfloat16_type_node mangling.

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed now.