From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AA8613858C52; Thu, 4 May 2023 11:04:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA8613858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683198275; bh=m251m1FVzC4oFiRliKqzuhUGVWy+sYiw5J74Zva9KIE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=etPsE6NgmquhssbRjnuV2y32uuLua6L6c/7gJBP+PjD66qjyCXyD31VbcqXfQ4WK+ Oggf+PvN7yS0nkYdqS661waxwWU4M4x7/mgu7URbwivDicsvUVar/XlNyjuJxy4Pru b4v/JxnBespiBADUaDEDRogk0cv4JeKcqNP7EJRo= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI Date: Thu, 04 May 2023 11:04:35 +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: redi at gcc dot gnu.org 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 #8 from Jonathan Wakely --- (In reply to frankhb1989 from comment #7) > (In reply to Jonathan Wakely from comment #6) >=20 > > What are the mangled type names that are unordered? (that's all you nee= d to > > describe, everything about flat_map and partition_point is irrelevant; = just > > tell us which names are unordered). >=20 > Here are the pair of the unordered names in the actual case: >=20 > 1. > St5_BindIFPFN3NPL15ReductionStatusERNS0_8TermNodeERNS0_11ContextNodeEESt1= 7ref > erence_wrapperIS2_ESt12_PlaceholderILi1EEEE > 2. > St5_BindIFZN3NPL2A112_GLOBAL__N_113DoDefineOrSetILb0EE4CallIJEEENS0_15Red= ucti > onStatusERNS0_8TermNodeERNS0_11ContextNodeESt10shared_ptrINS0_11Environme= ntEE > S8_DpOT_EUlRKS7_RKSD_E_S7_SD_EE Thanks. This second one has "*St5_BindIFZN3NPL..." in type_info::__name, so yes, they'll be incorrectly ordered with the out-of-line definition. t1.before(t2) will do a string comparison, but t2.before(t1) will do a poin= ter comparison and depend on the string table layout. > The unordered pair occurs iff. __GXX_TYPEINFO_EQUALITY_INLINE =3D=3D 0, i= .e. the > out-of-line definition is used, and regardless to the value of > __GXX_MERGED_TYPEINFO_NAMES (either 0 or 1). 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 t= he platform ABI and compiler and linker really do guarantee that all typeinfo names are unique, then address comparison works correctly. The problem case is when both __GXX_MERGED_TYPEINFO_NAMES and __GXX_TYPEINFO_EQUALITY_INLINE are zero. > As above, I've later tested all 4 combinations for sure. You can't expect that to give meaningful results though, you would need to rebuild the entire compiler for meaningful results with redefined macros, a= nd even then it would fail when you use RTTI across dynamic library boundaries. You can't just redefine those macros and expect the compiler and OS to chan= ge how they work. > Accidentally the > inline definition of std::type_info::before does the right thing I don't think it's an accident. > (hopefully), so __GXX_TYPEINFO_EQUALITY_INLINE =3D=3D 1 just works. Other= wise > there would be no easy workaround without the modification on the standard > headers. >=20 > Forcing address comparisons is wrong in general, but with some additional > assumptions to rule out all potential offending features, then all type_i= nfo > objects follow ODR in the strict sense, so this just works. When this is = an > issue, __GXX_TYPEINFO_EQUALITY_INLINE =3D=3D 1 && __GXX_MERGED_TYPEINFO_N= AMES =3D=3D > 0 should be safe for all names not from unnamed namespaces. This is a real > 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 code > fails elsewhere due to this reason. So stop redefining those macros then, you're lying to the compiler. __GXX_MERGED_TYPEINFO_NAMES=3D1 is a lie on your target. Don't do that.=