> I see. I think the solution is to perform cgraph/varpool merging > before attempting to read in > the global decl stream. IIRC Micha had (old) patches for this.
How can you merge varpool nodes if you haven't merged types? > But I wonder why we don't tree-merge 'n' here (from my C example) and > thus figure > that the type domain of x is equal? Or is it that 'n' and 'x' are in > the same SCC (they > referece each other in some way)? In this case the bug would be that we > fail to treat them equal optimistically. That said, I don't see how > TYPE_CANONICAL computation is relevant - what is relevant is the failure to > merge the two types. > In debugging this I'd start to see if the hashes are not equal or if > they are equal > at which node we consider them to differ. We just have 2 different DECLs with different DECL_UIDs, the definition from a compilation unit and a reference from another compilation unit, so the hashes naturally differ too. What's supposed to have them reconciled at this point? The TYPE_CANONICAL computation is relevant because, with GCC 6, the criterion for compatibility of pointer types is the alias set, which is based on the TYPE_CANONICAL of the pointed-to type, so we fail to merge pointer types because warn_type_compatibility_p returns non-zero if TYPE_CANONICAL differs. -- Eric Botcazou
