https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68290
--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This issue is host-dependent, it doesn't reproduce with a cross to 64-bit
SPARC.
The problematic types are:
(gdb) p debug_tree(t1)
<template_type_parm fb4ccae0 auto type_0 type_6 VOID
align 8 symtab 0 alias set -1 canonical type fb4ccae0
index 0 level 1 orig_level 1
chain <type_decl fb4ccb40 auto>>
(gdb) p debug_tree(t2)
<template_type_parm fb4cd0e0 auto VOID
align 8 symtab 0 alias set -1 canonical type fb4cd0e0
index 0 level 1 orig_level 1
chain <type_decl fb4cd140 auto>>
and they compare equal according to structural_comptypes but have distinct
TYPE_CANONICAL (themselves actually).
I think that the dependence on the host comes from:
inline hashval_t
auto_hash::hash (tree t)
{
if (tree c = PLACEHOLDER_TYPE_CONSTRAINTS (t))
/* Matching constrained-type-specifiers denote the same template
parameter, so hash the constraint. */
return hash_placeholder_constraint (c);
else
/* But unconstrained autos are all separate, so just hash the pointer. */
return iterative_hash_object (t, 0);
}
and that we have a hash collision on the SPARC machine.
The problem seems to come from comp_template_parms_position:
/* In C++14 we can end up comparing 'auto' to a normal template
parameter. Don't confuse them. */
if (cxx_dialect >= cxx14 && (is_auto (t1) || is_auto (t2)))
return TYPE_IDENTIFIER (t1) == TYPE_IDENTIFIER (t2);
IIUC we should compare t1 and t2 directly here if both are 'auto's.
