public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/104945] New: std::hash<std::uint64_t> ignores the top 32 bits when size_t is 32 bit
@ 2022-03-16 0:46 pdimov at gmail dot com
2022-03-16 0:59 ` [Bug libstdc++/104945] " pinskia at gcc dot gnu.org
2022-03-16 9:39 ` redi at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: pdimov at gmail dot com @ 2022-03-16 0:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104945
Bug ID: 104945
Summary: std::hash<std::uint64_t> ignores the top 32 bits when
size_t is 32 bit
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
A benchmark in Boost.Unordered uses uint64_t keys of the form `i << 40`:
https://github.com/boostorg/unordered/blob/33f81fd49039bccd1aa3dfd5a29ef6073b93009c/benchmark/uint64.cpp#L65
which leads to pathological behavior with std::unordered_map in 32 bit mode,
because std::hash<std::uint64_t> ignores the top 32 bits:
https://godbolt.org/z/PncKbT7aq
I'm not entirely sure whether this would be considered a bug, but decided that
it's worth reporting. Ideally, std::hash ought to take into account all bits of
the integral input, instead of truncating it to size_t.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libstdc++/104945] std::hash<std::uint64_t> ignores the top 32 bits when size_t is 32 bit
2022-03-16 0:46 [Bug libstdc++/104945] New: std::hash<std::uint64_t> ignores the top 32 bits when size_t is 32 bit pdimov at gmail dot com
@ 2022-03-16 0:59 ` pinskia at gcc dot gnu.org
2022-03-16 9:39 ` redi at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-03-16 0:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104945
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Yes this is definitely an issue I think:
// Explicit specializations for integer types.
#define _Cxx_hashtable_define_trivial_hash(_Tp) \
template<> \
struct hash<_Tp> : public __hash_base<size_t, _Tp> \
{ \
size_t \
operator()(_Tp __val) const noexcept \
{ return static_cast<size_t>(__val); } \
};
....
/// Explicit specialization for long long.
_Cxx_hashtable_define_trivial_hash(long long)
....
/// Explicit specialization for unsigned long long.
_Cxx_hashtable_define_trivial_hash(unsigned long long)
With no check on size of size_t vs long long.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libstdc++/104945] std::hash<std::uint64_t> ignores the top 32 bits when size_t is 32 bit
2022-03-16 0:46 [Bug libstdc++/104945] New: std::hash<std::uint64_t> ignores the top 32 bits when size_t is 32 bit pdimov at gmail dot com
2022-03-16 0:59 ` [Bug libstdc++/104945] " pinskia at gcc dot gnu.org
@ 2022-03-16 9:39 ` redi at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-16 9:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104945
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-03-16
Keywords| |ABI
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=98781
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-03-16 9:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-16 0:46 [Bug libstdc++/104945] New: std::hash<std::uint64_t> ignores the top 32 bits when size_t is 32 bit pdimov at gmail dot com
2022-03-16 0:59 ` [Bug libstdc++/104945] " pinskia at gcc dot gnu.org
2022-03-16 9:39 ` redi at gcc dot gnu.org
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).