[Bug tree-optimization/123518] gimple_make_forwarder_block should not create degenerated phis

[rguenther at suse dot de]

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 <gcc-bugzilla@gcc.gnu.org>:
> 
> 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.