vsk added a comment. In https://reviews.llvm.org/D33588#765768, @mclow.lists wrote:
> I can reproduce this, but I'd rather figure out why we're calling > `__next_hash_pow2(0)` or `(1)` before deciding how to fix it. It looks like we hit the UB while attempting to shrink a hash table during a rehash. If the current bucket count is a power of two, we try and find a smaller bucket count (also a power of two) large enough to accommodate all entries in the table. The argument passed in to next_hash_pow2 from hash_table::rehash is `__n = size_t(ceil(float(size()) / max_load_factor()))`. I think `__n = 0` if the table is empty. And `__n = 1` when the maximum load factor is (roughly) equal to the table's size. As an alternate fix, it might be worth considering changing the rehashing algorithm. But I'd like to start with a more conservative fix for the UB issue, at least initially. https://reviews.llvm.org/D33588 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
