https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720
--- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) > > Dom transformed: > c$a$0_6 = .DEFERRED_INIT (8, 2, 0); > _1 = .DEFERRED_INIT (8, 2, 0); > > into: > c$a$0_6 = .DEFERRED_INIT (8, 2, 0); > _1 = c$a$0_6; > > Which it should not be done. FRE had did the same thing but it was fixed, > see PR 102608. Yes, looks like that the current definition of .DEFERRED_INIT might trigger more other similar potential issues. it's might be better to change the 3rd parameter from the current IS_VLA to a string that represent the name of the original variable. then different variables will map to a different .DEFERRED_INIT, as a result, all such optimization will not happen anymore. this can be combined with the patch to fix -Wuninitialized + -ftrivial-auto-var-init for address taken variable issue as: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586491.html As I just checked, that patch did resolve this issue.
