hash policy patch

[François Dumont]

On 08/19/2011 12:13 PM, Paolo Carlini wrote:
> Hi,
> Before further discussing the details of the patch - for sure we have 
> bugs in this area which we have to fix asap, and with something like 
> your patch - can you please double check the patch on 32-bit targets? 
> I ran the testsuite on x86_64-linux -m32 and got:
>
> FAIL: 23_containers/unordered_set/hash_policy/change_load_factor.cc 
> execution test
>
> (it's: terminate called after throwing an instance of 'St9bad_alloc'
>   what():  std::bad_alloc)
>
>
Hi

     I will need time to have a 32bits build to check this failure but 
waiting for that I start the analysis based on your report.

     Looks like there is an unexpected bad_alloc exception. The test 
expect one to be generated when the max load factor is set to a very 
small value 0.001 but not in any other place. To do so I used the 
testsuite __gnu_test::set_memory_limits method and I just discover that 
AFAIC see this new test is the first one to use this feature ! It is 
documented this way in testsuite_hooks.h:

// 2)  set_memory_limits()
//   set_memory_limits() uses setrlimit() to restrict dynamic memory
//   allocation.  We provide a default memory limit if none is passed by the
//   calling application.  The argument to set_memory_limits() is the
//   limit in megabytes (a floating-point number).  If 
_GLIBCXX_RES_LIMITS is
//   not #defined before including this header, then no limiting is 
attempted.

     To define _GLIBCXX_RES_LIMITS for the test I use a:

// { dg-options "-std=gnu++0x -D_GLIBCXX_RES_LIMITS" }

     But in fact defining _GLIBCXX_RES_LIMITS when including this header 
is not enough and is even rather useless. This  macro is also used in 
testsuite_hooks.cc so it must be defined when this translation unit is 
built.  So could you try to run the test again with this command:

make CXXFLAGS=-D_GLIBCXX_RES_LIMITS check

     There is still a chance it fails because the amount of memory won't 
be the same on a 32 and 64 bits platform but at least this code will 
have the expected behavior and running it correctly on 64 bits platform 
do work. I am going to get a closer look to the correct level of memory 
to use, for the moment it is a completely empirical value.

François