This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix _Hashtable extension
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 21 Mar 2014 22:59:18 +0000
- Subject: Re: Fix _Hashtable extension
- Authentication-results: sourceware.org; auth=none
- References: <532CB1A7 dot 5020906 at gmail dot com>
On 21/03/14 22:39 +0100, François Dumont wrote:
Hi
Here is a patch to fix _Hashtable Standard extension type which
is almost unusable at the moment if instantiated with anything else
that the types used for the std unordered containers that is to say
__detail::_Default_ranged_hash and __detail::_Mod_range_hashing.
Good catch.
Also, it seems that this specialization is missing the "hasher"
typedef:
/// Specialization: ranged hash function, no caching hash codes. H1
/// and H2 are provided but ignored. We define a dummy hash code type.
template<typename _Key, typename _Value, typename _ExtractKey,
typename _H1, typename _H2, typename _Hash>
struct _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2, _Hash, false>
: private _Hashtable_ebo_helper<0, _ExtractKey>,
private _Hashtable_ebo_helper<1, _Hash>
{
From the comments I think it is intentional, is that right?
It is a really safe patch so I would propose it for current trunk
but at the same time it only impacts a Standard extension and it
hasn't been reported by anyone so just tell me when to apply it.
As it doesn't fix a regression and apparently isn't affecting anyone I
think it would be safer to add it to trunk after the 4.9 branch is
created.