public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "de34 at live dot cn" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/109383] New: [QoI] std::type_index::operator<=> should not call __builtin_strcmp twice Date: Mon, 03 Apr 2023 03:12:49 +0000 [thread overview] Message-ID: <bug-109383-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109383 Bug ID: 109383 Summary: [QoI] std::type_index::operator<=> should not call __builtin_strcmp twice Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: de34 at live dot cn Target Milestone: --- The current the current implementation of type_index::operator<=> in libstdc++ is the following: ``` strong_ordering operator<=>(const type_index& __rhs) const noexcept { if (*_M_target == *__rhs._M_target) return strong_ordering::equal; if (_M_target->before(*__rhs._M_target)) return strong_ordering::less; return strong_ordering::greater; } ``` When the two referenced type_info are not equal, the current implementation may needed to call __builtin_strcmp twice (each in type_info::operator== and type_info::before). IIUC whenever it's necessary to call __builtin_strcmp from operator<=>, we should just call it once and return __builtin_strcmp(...) <=> 0. Perhaps it would be better to add a member function to type_info for convenience. It's a bit strange to me that while all implementations I investigated (libc++, libstdc++, and msvc stl) need to use strcmp/__builtin_strcmp for type_info comparison in some cases, currently none of them avoids calling it twice from type_index::operator<=>, although strcmp/__builtin_strcmp is already performing three-way comparison.
next reply other threads:[~2023-04-03 3:12 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-03 3:12 de34 at live dot cn [this message] 2023-04-03 10:05 ` [Bug libstdc++/109383] " redi at gcc dot gnu.org 2023-04-03 10:35 ` redi at gcc dot gnu.org 2023-04-03 10:37 ` redi at gcc dot gnu.org 2023-04-04 0:50 ` pinskia at gcc dot gnu.org
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-109383-4@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).