Hi, On Wed, 20 Apr 2011, Richard Guenther wrote:
> >> If t is a type, why fix up its field if it may not be the canonical > >> variant? > > > > Because type merging to work sometimes requires already canonicalized > > fields, at least that's what I found in investigating why some types > > weren't merged that should have been. Hence I'm first canonicalizing all > > fields of everything and then see if something merged. > > That sounds like a bug in type-merging. You don't happen to have > a small testcase? ;) cc1 was my testcase :-/ > > Think shared field_decl chains. I'll have fixed up the chain for one of > > the type pairs already and can later come to a type referring exactly the > > same field_decls again. > > But only in case the first one is already equal. What I wanted to say is > that we shouldn't have partially shared chains, so > > if (TYPE_FIELDS (t) != TYPE_FIELDS (oldt)) > for (...) > if (TREE_CODE (f1) == FIELD_DECL) > ... > > should be enough, no? Indeed. > In fact, why restrict fixing up the cache to > FIELD_DECLs and not also do it for TYPE_DECLs or FUNCTION_DECLs > that may reside in this chain? non-FIELD_DECLs are removed in free_lang_data. But even more so I can remove the test for FIELD_DECL. > > Hmm, it's gross but seems to me still required for the diagnostic and > > to emit the VIEW_CONVERT_EXPR, at least for invalid input code. OTOH > > if the streamed out code ensures that a field_decl in a component_ref > > always is included in its DECL_CONTEXT, then the new merging should > > indeed make sure that this also holds after streaming in. Do we have > > testcases specifically trying this code? greping for "mismatching" in > > testsuite/ doesn't show anything relevant. > > The lto testsuite harness doesn't support dg-error/warning, so there are > no testcases. There are testcases that ICEd (type verification) before > introducing these fixups though. Okay, I'll leave investigating this to a follow up. Ciao, Michael.
