https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> --- Odd use case found! Repeating my analysis from https://bugs.gentoo.org/934688 regarding a new compilation error in antlr-cpp-4.11.1: Here's a minimal reproducer that fails with GCC trunk, unless you use -DFIX #include <unordered_map> template <typename Key, typename Value, #ifdef FIX typename Hash = std::hash<Key>, typename Equal = std::equal_to<Key>, typename Allocator = std::allocator<std::pair<const Key, Value>>> #else typename Hash = typename std::unordered_map<Key, Value>::hasher, typename Equal = typename std::unordered_map<Key, Value>::key_equal, typename Allocator = typename std::unordered_map<Key, Value>::allocator_type> #endif using FlatHashMap = std::unordered_map<Key, Value, Hash, Equal, Allocator>; struct S { }; struct Hash { std::size_t operator==(const S&) const { return 0; } }; struct Eq { bool operator()(const S&, const S&) const { return true; } }; FlatHashMap<S, int, Hash, Eq> m; The problem is that the alias template FlatHashMap instantiates std::unordered_map<Key, Value> to obtain any of the Hash, Equal or Allocator types that are not provided explicitly. When used by PredictionContextMergeCache, the Hash and Equal types are provided explicitly (because antlr-cpp has custom hasher and comparison types for the map's key type). But the Allocator type is not provided, so it uses the default template argument, which is: std::unordered_map<Key, Value>::allocator_type This triggers the instantiation of std::unordered_map<Key, Value> which uses *its* default hasher, which is std::hash<Key>, which is invalid, which triggers the static_assert. That instantiation isn't actually wanted, they never use it, they're just trying to get some nested types out of it. The commit https://github.com/antlr/antlr4/commit/9d7741d3fb1e0befe1ca32502a42a2809741053c (which is in antlr-cpp-4.12.0) avoids instantiating it just to get some types that can be obtained far more directly than by instantiating an unusable specialization of std::unordered_map. Basically the same problem as they encountered upstream with a static_assert that I added (and then I think reverted) in GCC 7: https://github.com/antlr/antlr4/pull/3885
