https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123518
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- > 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). Richard > > -- > You are receiving this mail because: > You are on the CC list for the bug.
