https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123518

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to [email protected] from comment #6)
> > Am 11.01.2026 um 01:25 schrieb pinskia at gcc dot gnu.org 
> > <[email protected]>:
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123518
> > 
> > --- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> > (In reply to Richard Biener from comment #4)
> >> But it surely needs to set_cfun() around loop_optimizer_init, so I wonder
> >> what the issue really is.
> > 
> > The issue is the newly created phi node is the one not in the forwarder 
> > block
> > but in the other block.
> > 
> > We had originally (where a is non-local variable):
> > ```
> > _1 = PHI <&a(2), _3(4), &a(3)>
> > bb4:
> > ...
> > ```
> > 
> > And then adding the forwarder block we get:
> > ```
> > _2 = PHI <&a(2), &a(3)>// This was actually a old phi stmt originally from 
> > bb4
> > Newbb:
> > goto bb4;
> > 
> > _1 = PHI <_2(newbb), _3(4)> // this is a new phi stmt
> > bb4:
> > ...
> > ```
> > 
> > And in symboltable, for symbol a, there is a reference to the old phi still 
> > so
> > removing it causes an verification ICE saying a dead stmt is still 
> > referenced.
> > 
> > That is we don't update the symbol table references when creating the phis.
> > I wonder if this would cause other issues besides what I found here though
> > since the symbol might not actually be referenced in that phi but the other
> > one.
> > 
> > I tried to look to see if there is a way to update the symbol table (cgraph)
> > but I could not find one that but maybe I was just missing it.
> 
> Hmm, but the same situation could happen now when each edge has a different
> global variable referenced?  IMO having the new PHI in the forwarder would
> be better (but not solve this issue).

Correct that would defintely be an issue without any patches. Switching around
which phis are where is something I can definitely look into but I am suspect
this is getting into stage 1 material than stage 4. But obvious that does not
solve the symbol table issue at all which is something needs to be solved
either way. Obvious the best way is not have ipa-fnsummary modify the phis and
have it correct by that time. But that is also stage 1 material.

Reply via email to