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.
