Re: [gcc 4.5 patch] Permit smaller hash tables for hash_map and hash_set

[Ian Lance Taylor <iant at google dot com>]

Paolo Carlini <paolo.carlini@oracle.com> writes:

>>> I have a few patches to make them better in some circumstances.
>>> These
>>> ideas are incorporated in different from in the newer unordered_set
>>> and unordered_map.  However, existing code still uses hash_map and
>>> hash_set, so it may be useful to update them if we think that is OK.
>>
>> I believe there was a previous attempt to fix up this stuff. It was
>> not
>> well-received, although I don't especially remember the details. At
>> this
>> point, I think this kind of stuff should just be checked in.
>
> Well, probably I'm the one not receiving well that kind of change in
> the past ;) Really, I'm still of the same opinion, that code should be
> just frozen by now, we do *not* want to deal with regressions, at
> least, certainly not me.

Clearly we don't want to deal with regressions, but that is true of all
the libstdc++ code.  That is not in itself a reason to never change the
hash_map and hash_set code.


> In the case at issue, I have also some small
> concerns from the point of view of binary compatibility: are we really
> sure that two different binaries built before and after this change
> can interoperate smoothly?

The patch in question is:

http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00316.html

The only possible danger is that code compiled with one value of
_S_num_primes will be linked with a copy of the __stl_prime_list array
which was compiled with a different value.

However, __stl_prime_list, as a static const array with namespace scope,
will, if emitted at all, be emitted as a local symbol in the .rodata
section.  It will not be emitted in a COMDAT section group.  The
functions which refer to __stl_prime_list (max_bucket_count and
__stl_next_prime) will always refer to the version of __stl_prime_list
which is defined in the current object file.  If we use a different
version of those functions, we will use a different version of the
array.

Thus I see no possibility for a mismatch between _S_num_primes and
__stl_prime_list due to this change.

(By the way, this does indeed mean that if two different object files
use __gnu_cxx::hash_map<>, you can get two different copies of the
__stl_prime_list array in your .rodata section.  I am not proposing to
fix that.)

Ian