From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A4C033858D35; Fri, 5 May 2023 16:28:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A4C033858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683304139; bh=wF8NvtXcsTG5+WE8oCTY6OabZEEuX/ELidhb9v/AvB8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X92+Eb/Xk8ZguVutAY4WCNjn6DdZcTfS1qHi0JtmbXcPg8nqrtT7w/8kZFLQKUJ55 kJzooxCsEQU6ldaqejkcV4WjnXEdzYNRJV/+Ko2wugGKRInDL4v2dDcf6tl+LYoFhd Jxv3Os3FDQDgwEKiMdnaibrLPilSHiLjgVeeUV2g= From: "frankhb1989 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI Date: Fri, 05 May 2023 16:28:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ABI, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: frankhb1989 at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi 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=3D103240 --- Comment #9 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #8) > I don't think that's true. If __GXX_MERGED_TYPEINFO_NAMES is true then the > out-of-line definition is correct. You can't just redefine that macro to 1 > in your code and expect it to affect the out-of-line definition in the > library. Even if you recompile the library with=20 > -D__GXX_MERGED_TYPEINFO_NAMES=3D1 that doesn't magically make it true. If= the > platform ABI and compiler and linker really do guarantee that all typeinfo > names are unique, then address comparison works correctly. >=20 Yes, -D__GXX_MERGED_TYPEINFO_NAMES=3D1 is harmful and unnecessary to work a= round the issue. As illustrated, it just works for some of my cases accidentally,= and fails for some other cases. Further, I want to make sure no out-of-line definition of type_info::before= is called in the system libraries (which I can't rebuild). Does libstdc++ have calls to type_info::before internally? > You can't expect that to give meaningful results though, you would need to > rebuild the entire compiler for meaningful results with redefined macros, > and even then it would fail when you use RTTI across dynamic library > boundaries. >=20 > You can't just redefine those macros and expect the compiler and OS to > change how they work. >=20 I don't quite get this point about the compiler. Do you mean not only libst= dc++ and the linker, but also the compiler's codegen of the mangled names works differently depending on the macro definitions, besides the possible duplic= ate (but having identical mangled names) definitions of the internal objects providing the mangle names? Will it affect the section layout of the object code? Are there existing optimizations relying on the assumptions? I know it will not be formally supported to have consistent behavior just by rebuilding the user programs, and it will be plain wrong without things like ICF or in cases dynamic loading is relied on, but I'm curious: what are the actual consequences from the compiler's view, when (1) all TUs of the progr= am code eventually use these macro definitions consistently, (2) definitions of RTTI information for identical types are totally merged; and, (3) each inst= ance of the call to the out-of-line definition of type_info::before is avoided? I am interesting in such questions because there are cases where rebuiding = the toolchain is impossible. It is not even possible to rebuilt libstdc++ for production system unless more than one instance can be deployed side by side (e.g. by static linking), because I cannot make sure no other part of the environment have relied on the bug-to-bug compatibility to the existing sys= tem libraries. In my case, I have to make sure which parts of the deployed code= are actually affected before the toolchain update (either system-wide or not) is possible. And before that, the redefinition of macros seems the only viable workaround (with certain limitations). > > Accidentally the > > inline definition of std::type_info::before does the right thing >=20 > I don't think it's an accident. >=20 Good news to me. > > (hopefully), so __GXX_TYPEINFO_EQUALITY_INLINE =3D=3D 1 just works. Oth= erwise > > there would be no easy workaround without the modification on the stand= ard > > headers. > >=20 > > Forcing address comparisons is wrong in general, but with some addition= al > > assumptions to rule out all potential offending features, then all type= _info > > objects follow ODR in the strict sense, so this just works. When this i= s an > > issue, __GXX_TYPEINFO_EQUALITY_INLINE =3D=3D 1 && __GXX_MERGED_TYPEINFO= _NAMES =3D=3D > > 0 should be safe for all names not from unnamed namespaces. This is a r= eal > > problem for MinGW (at least with GNU ld which does not perform ICF on > > PE/COFF AFAIK), where __GXX_TYPEINFO_EQUALITY_INLINE =3D=3D 1 && > > __GXX_MERGED_TYPEINFO_NAMES =3D=3D 1 causes something like > > &typeid(shared_ptr<...>) not unique across module boundaries, and my co= de > > fails elsewhere due to this reason. >=20 > So stop redefining those macros then, you're lying to the compiler. >=20 Sadly, we *have to* lie for some degrees... ODR in ISO C++ is already conceptually violated in cases when dynamic libraries are taken into accoun= t. There is no such strong guarantee (like ICF) for all implementations, so implementation-specific details are already kicked in. > __GXX_MERGED_TYPEINFO_NAMES=3D1 is a lie on your target. Don't do that. Agreed for the current case, though.=