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.
