Hi, sorry for late reply - I did not identify it as a patch to symbol table. Indeed we want can_refer_decl_in_current_unit_p is a good place to test this. Is there a reason to resrict this to functions with no body? I see that we may be able to inline the function, but all the devirtualization code works by first turning call to a direct call and inlining later. We would need to teach the code that it can't devirtualize without inlining (which can be done by the speculative call macinery) and probably we will need to check that the function body does not contain some calls to similar symbols.
We don't have support for this (do we want to do that in future)? For GCC 9 it would thus seem more consistent to simply return false on all symbols with this combination of flags. We probably also can teach symtab verifiers that we do not contain any references to such symbols. Thanks, Honza > Ping^3? > > On Wed, Feb 13, 2019 at 4:28 PM Jason Merrill <ja...@redhat.com> wrote: > > > > Ping^2 > > > > On Mon, Feb 4, 2019 at 4:09 PM Jason Merrill <ja...@redhat.com> wrote: > > > > > > Ping > > > > > > On Fri, Jan 25, 2019 at 10:06 AM Jason Merrill <ja...@redhat.com> wrote: > > > > > > > > Here we warn because i<l>::dispatch has internal linkage (because l > > > > does) and is never instantiated (because the vtable is never emitted). > > > > The regression happened because devirtualization started adding it to > > > > cgraph as a possible target. I think the way to fix this is to avoid > > > > adding an undefined internal function to cgraph as a possible target, > > > > since it is not, in fact, possible for it to be the actual target. > > > > > > > > I think that the best place to fix this would be in > > > > can_refer_decl_in_current_unit_p, since the same reasoning applies to > > > > other possible references. But we could fix it only in > > > > gimple_get_virt_method_for_vtable. > > > > > > > > First patch tested x86_64-pc-linux-gnu. > > > >
