This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix type merging deficiency during WPA

> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]