User account creation filtered due to spam.
The attached testcase compiles and runs correctly with gcc 3.3.4, but gives the
following compilation errors with gcc 3.4.4:
hashtest.cxx: In function `int main()':
hashtest.cxx:11: error: cannot convert `int*' to `std::pair<const int, int>*' in
hashtest.cxx:12: error: no matching function for call to
`std::allocator<int>::construct(std::pair<const int, int>*&, std::pair<const
note: candidates are: void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, const
_Tp&) [with _Tp = int]
hashtest.cxx:17: error: no matching function for call to
`std::allocator<int>::destroy(std::pair<const int, int>*&)'
note: candidates are: void __gnu_cxx::new_allocator<_Tp>::destroy(_Tp*) [with
_Tp = int]
hashtest.cxx:18: error: no matching function for call to
`std::allocator<int>::deallocate(std::pair<const int, int>*&, int)'
note: candidates are: void __gnu_cxx::new_allocator<_Tp>::deallocate(_Tp*,
size_t) [with _Tp = int]
The reason for the errors are wrong default allocators in ext/hash_map. A patch
that fixes the problem is attached.
Created attachment 9563 [details]
The testcase that exemplifies the error
It fails with gcc 3.4.4 but works correctly with gcc 3.3.4
Created attachment 9564 [details]
Patch against the gcc 3.4.4 STL headers
With this patch applied to gcc 3.4.4 it compiles correctly with this compiler
This works in both on the mainlline and in 4.0.0. Also the fix is not really a correct fix as this area was
not what changed between 3.4.0 and 4.0.0.
I agree that something much more subtle is going on, maybe even a C++ front-end
bug in 3_4-branch. Notice that hash_map<>::allocator_type is typedef-ed as
_Ht::allocator_type, which, in turn (see the hashtable class in hashtable.h) is,
correctly, an allocator of pair<const _Key, _Tp>. Likewise for
hash_map<>::value_type. More analysis is required...
I forgot to mention that the preprocessed source from 4.1.0 compiles just fine with the 3.4.0 compiler.
(In reply to comment #5)
I find this very hard to believe: the ext/ headers are basically frozen.
(In reply to comment #6)
Ok, Andrew is right, just double checked. A big mistery...
(In reply to comment #7)
> A big mistery...
Actually, in 3_4-branch memory allocation in class hashtable was rather different,
forgot about that. The bug is there.
Oh and the preprocessed created with 3.4.0 gives the same error on the mainline too.
It looks like the problem has been fixed in revision 1.6 of hashtable.h.
Mattias, can you experiment a bit with just changing in class hashtable:
typedef _Alloc allocator_type;
typedef typename _Alloc::template rebind<value_type>::other allocator_type;
(likely, you have available code using hash_map much more complex than I do)
(In reply to comment #10)
Your proposed alternative patch works for me. Both for the testcase in this bug
report and when I compile the code I was building when I found the bug.
(In reply to comment #11)
Thanks a lot. I think adding a proper rebind is the right way to fix the problem,
already used in mainline and 4_0-branch, by the way.
2005-08-29 Paolo Carlini <email@example.com>
Port from HEAD/4_0-branch:
2004-07-28 Matt Austern <firstname.lastname@example.org>
* include/ext/hashtable.h: Use rebind so that allocator_type
has correct type for a container's allocator.
* testsuite/ext/23528.cc: New.