[Bug c++/94454] New: ICE 'canonical types differ for identical types'

[Bug c++/94454] New: ICE 'canonical types differ for identical types'

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

            Bug ID: 94454
           Summary: ICE 'canonical types differ for identical types'
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

This a bug reported by Eric Niebler when building the ranges-v3 code on
Darwin19, however it's not a Darwin-specific problem.

This is a very slippery bug to pin down (possibly a dup of 90301, but unknown
at present)

The failure on a given platform seems to depend on the compiler build.

I have now seen fails on x86-64-linux-gnu, powerpc64-linux-gnu, *darwin*.

Some compiler builds fail almost consistently on a given platform, but a later
build could easily pass every time.  Often the fail is ≈ 1 time in 5 attempts.

tried:
 --with-checking=yes,gcac
 --param ggc-min-expand=0 --param ggc-min-heapsize=0

Neither altered the repeatability.

Jonathan did a run under valgrind which was also inconclusive.

I've tried (manually) a fairly large number of permutation of options etc.
without any pattern emerging.  At present a hunch is that it's maybe an
uninitialised var, or perhaps something that depends on the order in which
things get initialised.

** Trying to reduce on x86-64-linux-gnu and x86-64-darwin16 (but going very
slowly).

====

/home/iains/range-v3/include/meta/meta.hpp:1216:11: internal compiler error:
canonical types differ for identical types ‘std::integral_constant<bool,
and_v<__is_constructible(Ts)...> >’ and ‘std::integral_constant<bool,
and_v<__is_constructible(Ts)...> >’
 1216 |     using if_c = _t<detail::_if_<bool_<If>, Args...>>;
      |           ^~~~
0x1054ba4b comptypes(tree_node*, tree_node*, int)
        ../../src/gcc/cp/typeck.c:1519
0x1053679f cp_tree_equal(tree_node*, tree_node*)
        ../../src/gcc/cp/tree.c:3940
0x10536523 cp_tree_equal(tree_node*, tree_node*)
        ../../src/gcc/cp/tree.c:3933
0x1043318f template_args_equal(tree_node*, tree_node*, bool)
        ../../src/gcc/cp/pt.c:9043
0x10432e13 template_args_equal(tree_node*, tree_node*, bool)
        ../../src/gcc/cp/pt.c:8985
0x10432e13 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
        ../../src/gcc/cp/pt.c:9072
0x10432e13 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
        ../../src/gcc/cp/pt.c:9052
0x104463bf spec_hasher::equal(spec_entry*, spec_entry*)
        ../../src/gcc/cp/pt.c:1703
0x104c577f hash_table<spec_hasher, false,
xcallocator>::find_with_hash(spec_entry* const&, unsigned int)
        ../../src/gcc/hash-table.h:917
0x1049545b lookup_template_class_1
        ../../src/gcc/cp/pt.c:9680
0x10499da3 lookup_template_class(tree_node*, tree_node*, tree_node*,
tree_node*, int, int)
        ../../src/gcc/cp/pt.c:10020
0x10499da3 tsubst_aggr_type
        ../../src/gcc/cp/pt.c:13301
0x1048e023 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
        ../../src/gcc/cp/pt.c:13092
0x1048e66b tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*)
        ../../src/gcc/cp/pt.c:13040
0x1048e0f3 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
        ../../src/gcc/cp/pt.c:13090
0x10499d4f tsubst_aggr_type
        ../../src/gcc/cp/pt.c:13295
0x1048e023 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
        ../../src/gcc/cp/pt.c:13092
0x1048965b tsubst(tree_node*, tree_node*, int, tree_node*)
        ../../src/gcc/cp/pt.c:14946
0x10479c0b tsubst_decl
        ../../src/gcc/cp/pt.c:14377
0x1049a5e3 instantiate_template_1
        ../../src/gcc/cp/pt.c:20588
Please submit a full bug report,

[Bug c++/94454] ICE 'canonical types differ for identical types'

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-04-02
           Keywords|                            |ice-on-valid-code
   Target Milestone|---                         |10.0
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
      Known to fail|                            |10.0

[Bug c++/94454] ICE 'canonical types differ for identical types'

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
there's a gist here:
https://gist.github.com/jwakely/e131d3a268a78764458186eff02f29ec

with Jonathan's valgrind session and some debug output from one case where I
managed to catch the fail under a debugger.

[Bug c++/94454] ICE 'canonical types differ for identical types'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd suggest to tweak the compiler, so that spec_hasher::hash always returns 0,
if the bug is reproduceable with that, perhaps it might be much faster to
reduce it that way.

[Bug c++/94454] ICE 'canonical types differ for identical types'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
See also PR94044 for this, including a patch to do so.

[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at gcc dot gnu.org

--- Comment #4 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
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

[Bug c++/94454] ICE 'canonical types differ for identical types'

[iains at gcc dot gnu.org]

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.

[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at acm dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

--- Comment #6 from Nathan Sidwell <nathan at acm dot org> ---
On 4/2/20 12:37 PM, iains at gcc dot gnu.org wrote:
> 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.

Ok, BTW spec_hasher::hash forwards to hash_tmpl_and_args.  They must 
agree, so ...

> Neither made any difference, the entire ranges-v3 suite built without issue.

surprises me.

> 
> Maybe that's informative in its own right.
> 
> Will hopefully have some kind of reduced test-case for x86-64-linux tomorrow.
>

[Bug c++/94454] ICE 'canonical types differ for identical types'

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 48175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48175&action=edit
un-reduced pre-processed on x86_64-linux

working on reducing this.

[Bug c++/94454] ICE 'canonical types differ for identical types'

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Nathan Sidwell from comment #6)
> On 4/2/20 12:37 PM, iains at gcc dot gnu.org wrote:
> > 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:
> > I bootstrapped with this patch, and then built a --disable-bootstrap with the
> > "spec_hasher::hash always returns 0" applied too.
> 
> Ok, BTW spec_hasher::hash forwards to hash_tmpl_and_args.  They must 
> agree, so ...
> 
> > Neither made any difference, the entire ranges-v3 suite built without issue.
> 
> surprises me.

hum .. both alter the code that's executed to compute the hash - which is the
code that seems to be complaining. 

So .. maybe I need to cook up something that computes the hash via the path
that's failing, but then throws it away... still might not exercise the case.

[Bug c++/94454] ICE 'canonical types differ for identical types'

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #48175|0                           |1
        is obsolete|                            |

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 48176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48176&action=edit
original unreduced test case on x86_64 linux.

the previous attachment had been partially creduce-d (this is the original).

[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

--- Comment #10 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
I cannot reproduce it, but looking at the gist referenced in comment #1 I see
that the complaint is about two instances of the same instantiation of struct
std::integral_constant<bool, and_v<__is_constructible(Ts)...> >

One of which has __attribute__ ((__abi_tag__ ("cxx11"))) attached to it.  That
seems to be the error -- how did that abi_tag get there? it's not on the
original declaration. 

I can't see how those could have become attached. AFAICT we don't propagate
attributes from the arguments of an instantiation, to the instantiation itself
(and that wouldn't explain it here, as 'and_v' and __is_constructible are
unattributed.

[Bug c++/94454] ICE 'canonical types differ for identical types'

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Nathan Sidwell from comment #10)
> I cannot reproduce it,

it is frustratingly difficult to do so.

> but looking at the gist referenced in comment #1 I
> see that the complaint is about two instances of the same instantiation of
> struct std::integral_constant<bool, and_v<__is_constructible(Ts)...> >
> 
> One of which has __attribute__ ((__abi_tag__ ("cxx11"))) attached to it. 
> That seems to be the error -- how did that abi_tag get there? it's not on
> the original declaration. 
> 
> I can't see how those could have become attached. AFAICT we don't propagate
> attributes from the arguments of an instantiation, to the instantiation
> itself (and that wouldn't explain it here, as 'and_v' and __is_constructible
> are unattributed.

this does not seem to be reproducible, possibly a result of some other bug
that's since been fixed.

- I don't think it's the smoking gun (but could be that the relevant field
contains something random).

[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

--- Comment #12 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Created attachment 48270
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48270&action=edit
asserts to trigger it

I have found the cause, but not the underlying reason.  We have template
arguments that compare equal but hash differently.  So the earlier attempts to
cause hash collisions by neutering the hasher, made the bug go away.
This patch neuters the hasher, but adds an assert into the argyment comparator
-- if the args compare equal, they better hash equal.
This triggers on the testcase with a pair of template_id_exprs.

[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |nathan at gcc dot gnu.org

[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

--- Comment #13 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Created attachment 48313
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48313&action=edit
testing shim

[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Fixed:
* a6f400239d7 2020-04-20 | c++: tpl-tpl-parms are not canonicalizable types
[pr94454] (HEAD -> master, origin/master, origin/HEAD) [Nathan Sidwell]
* 7fcb93431ef 2020-04-20 | c++: Expr pack expansion equality [pr94454] [Nathan
Sidwell]
* aa576f2a860 2020-04-20 | c++: Template argument hashing [pr94454] [Nathan
Sidwell]