On Wed, Jul 6, 2016 at 11:33 AM, Eric Botcazou <ebotca...@adacore.com> wrote: >> 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?
I am talking about tree/SCC merging which happily merges global decls as well. It uses custom hashing (see lto-streamer-out.c:hash_tree) which doesn't hash DECL_UID (obviously). This merging process should be optimistic for all nodes in the same SCC as well. That said, I expect the types to be tree merged and wonder why they are not. If they were merged they'd obviously share TYPE_CANONICAL because there would be only one type to compute TYPE_CANONICAL for. Richard. > 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
