Re: cgraph: does node->inlined_to imply node->clones is non-empty?

Hi, Martin Jambor writes: > Hi, > > On Sat, Mar 18 2023, Arsen Arsenović wrote: >> Martin Jambor writes: > > [...] > For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC seems to try to remove an unreachable function that was already inlined into a different

Re: cgraph: does node->inlined_to imply node->clones is non-empty?

Hi, > > It seems to me that the most correct fix is to add to > walk_polymorphic_call_targets a check that the obtained possible target > is still referenced_from_vtable_p() - because the alias that was > originally a virtual function is referenced from a vtable that at this > point is also known

Re: cgraph: does node->inlined_to imply node->clones is non-empty?

Hi, On Sat, Mar 18 2023, Arsen Arsenović wrote: > Martin Jambor writes: [...] >>> >>> For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC >>> seems to try to remove an unreachable function that was already inlined >>> into a different unreachable function. >> >> No, it fails

Re: cgraph: does node->inlined_to imply node->clones is non-empty?

Hi Martin, Thank you for the thorough response, and apologies for replying so late (I'm busy most hours of most workdays nowadays). Martin Jambor writes: > Hello, > > I had been aware of your message even before Martin Liška pointed to it, > but I could not answer the questions without looking

cgraph: does node->inlined_to imply node->clones is non-empty?

Hi, I was debugging PR96059 and ran into a question which does not seem obvious from the code. For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC seems to try to remove an unreachable function that was already inlined into a different unreachable function. When the original