https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Nathan Sidwell from comment #4) > Oh, it is from the template specialization hash table. I suggest making > that very poor to increase collisions: > > pt.c: > static hashval_t > hash_tmpl_and_args (tree tmpl, tree args) > { > hashval_t val = iterative_hash_object (DECL_UID (tmpl), 0); > return val; // INSERT THIS LINE > return iterative_hash_template_arg (args, val); > } > > sorry for not realizing this earlier [not wishing to disturb the c-reduce sessions already started] On Darwin17 @r10-7488, which was always succeeding I bootstrapped with this patch, and then built a --disable-bootstrap with the "spec_hasher::hash always returns 0" applied too. Neither made any difference, the entire ranges-v3 suite built without issue. Maybe that's informative in its own right. Will hopefully have some kind of reduced test-case for x86-64-linux tomorrow.