https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071
--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> --- > On 08/14/2014 07:13 PM, Jan Hubicka wrote: > >>On 08/14/2014 02:10 PM, Jan Hubicka wrote: > >>>I wonder what we should do with both external and comdat here. Jason, can > >>>we devirtualize? > >> > >>No, we're setting comdat now to avoid devirtualization, because we > >>can't be confident that we'll be able to refer to the definition > >>where it gets emitted. > > > >We had issues where function body was not produced because it is not > >reachable > >by the frontend's definition and it would be comdat otherwise. The case of > >inline function whose out of line body is keyed to another unit seems bit > >different... > > It doesn't seem that different to me. In both cases we don't have a > local definition to refer to. I think the difference is that in one case we break ABI (by referring to the symbol without providing a comdat body). In the other case we just require user to link with classes he declares in headers. So far I was always able to convince users to do the second. We won't devirtualize when explicit hidden attribute is present on the function body. > > >>>The constructor is keyed to other compilation unit here, but we are > >>>provided with a body > >>>that we will never use (modulo the tree-ssa-pre bug that brings the > >>>reference into code). > >> > >>Hmm, we might consider overriding DECL_EXTERNAL so that there's a > >>definition available for devirtualization. > > > >I can always implement logic to use it only when it is inlined, but that > >will probably drag > >in references to other symbols belonging to the class... > > I'm not too concerned about that; users should expect an inline > function to be inlined. I guess I will need to add the necessary infrastructure then - so far we make no difference in between referring symbol and inlining body becuase before inlining we always temporarily produce the direct reference. Honza
