public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "frankhb1989 at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI Date: Sat, 29 Apr 2023 18:01:22 +0000 [thread overview] Message-ID: <bug-103240-4-SE8OeVZmmL@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103240-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240 --- Comment #5 from frankhb1989 at gmail dot com --- There are multiple issues. 1. The out-of-line definition and the inline definition of std::type_info::before do different things. Specifically, only one name is detected against to '*' in the former, but two in the latter. It seems the latter is more correct. ("More", because it is still not quite correct, see below.) 2. As stated in https://reviews.llvm.org/D100134, mixture of different methods of comparisons breaks the ordering. I've actually encountered the problem with std::type_index as the key type when using flat_map::emplace (like https://github.com/WG21-SG14/SG14/blob/master/SG14/flat_map.h, which uses std::partition_point to find the position of insertion). The insertion suddenly fails when std::partition_point meets two std::type_info objects x and y which are unordered. It works with the workaround '-U__GXX_MERGED_TYPEINFO_NAMES -D__GXX_MERGED_TYPEINFO_NAMES=1' in the compiler command line, but it seems not enough in general without fixing the issue 2 here. (Although the same sequence of key on std::map does not fail, occasionally, due to less comparisons are made.) 3. Not sure the original change in r179236 is correct. 4. '||' in the condition of the inline definition of std::type_info::before seems an overkill. '&&' may be enough. Assuming string comparison is more expensive, this is a simple optimization. But once the issue 2 is fixed, the change would look quite different.
next prev parent reply other threads:[~2023-04-29 18:01 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-15 0:20 [Bug libstdc++/103240] New: " redi at gcc dot gnu.org 2021-11-15 0:21 ` [Bug libstdc++/103240] " redi at gcc dot gnu.org 2021-11-15 0:36 ` redi at gcc dot gnu.org 2021-11-17 17:22 ` cvs-commit at gcc dot gnu.org 2021-11-17 17:42 ` redi at gcc dot gnu.org 2021-11-23 21:17 ` cvs-commit at gcc dot gnu.org 2023-04-29 16:15 ` frankhb1989 at gmail dot com 2023-04-29 18:01 ` frankhb1989 at gmail dot com [this message] 2023-05-02 16:56 ` redi at gcc dot gnu.org 2023-05-04 10:31 ` frankhb1989 at gmail dot com 2023-05-04 11:04 ` redi at gcc dot gnu.org 2023-05-05 16:28 ` frankhb1989 at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-103240-4-SE8OeVZmmL@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).