On Sat, May 11, 2013 at 1:39 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> >But >> >glancing over the the dumps, I see many of them just have different >> >name >> >spaces. Do we even attempt to merge namespace_decl? How types from >> >same >> >namespaces in different units are supposed to match? >> > >> We do not merge namespace decls, which is likely the issue here. My >> in-progress tree merging should eventually fix this... > > Yep, I think namespaces should to be merged. They are however (always?) > refereed by TYPE_CONTEXT and I do not see that to be part of type merging > rules. So I do not think it prevents us from merging types from different > namespace decls.
Note that only TYPE_DECLs are siblings of NAMESPACE_DECLs and we do stream DECL_CONTEXT (and also factor in that at least for types). So in the end we should only merge same types from the same namespace which means we _should_ factor in the types overall context, even if we fail to do that now. > On the other hand, I alwas saw a lot of duplicates of the same structure/class > getting unmerged even without namespaces. I am not sure how much of those are > just bugs and how much we keep for valid reasons (such as slightly different > debug info attached to them because of different #include order or so) Bugs are certainly possible ;) > I uploaded the list of false negatives when compiling Mozilla's JS > interpretter > to http://atrey.karlin.mff.cuni.cz/~hubicka/binfo.txt > I suppose any bigger C++ project will give such a list and it looks like good > list of cases to analyze. > > Can we resonably expect those to be all merged? Perhaps C++ one decl rule > allows us to simply match names+namespaces (after merging) here? But we cannot assume C++ rules for types. Richard. > Honza > >> >> Richard. >> >> >Honza >> >> >> >> Richard. >> >> >> >> >Honza >> >> >>
