Hash table iteration order and compiler optimizations

[Florian Weimer <fw at deneb dot enyo dot de>]

Is it acceptable if the hash table iteration order depends on compiler
optimizations (and other compiler implementation details)?

I'm concerned that the use of floating point in the hash policy has
such an effect.

For example, in bits/hashtable_policy.h, _Prime_rehash_policy contains
this:

    // Return a bucket count appropriate for n elements
    std::size_t
    _M_bkt_for_elements(std::size_t __n) const
    { return __builtin_ceil(__n / (long double)_M_max_load_factor); }

It should probably use __builtin_ceill to avoid an excess precision
issue on i386.

There's also the matter of using long double, which differs from
architecture to architecture.  Arithmetic on float and double should
be much more uniform across architectures.

Unfortunately, getting matching behavior between i386 and x86-64 on
the one hand, and getting consistent behavior across more
architectures are conflicting goals in this case, I think.