https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127246
Drea Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2026-09-07
Ever confirmed|0 |1
--- Comment #1 from Drea Pinski <pinskia at gcc dot gnu.org> ---
So we end up with:
```
<bb 4> [local count: 1073741764]:
# next_instr_78 = PHI <next_instr_73(24), next_instr_219(3),
next_instr_210(6), next_instr_201(7), next_instr_193(8), next_instr_185(9),
next_instr_177(10), next_instr_169(11), next_instr_161(12), next_instr_153(13),
next_instr_145(14), next_instr_137(15), next_instr_129(16), next_instr_121(17),
next_instr_113(18), next_instr_106(19), next_instr_100(20), next_instr_93(21),
next_instr_87(22), next_instr_80(23)>
# stack_pointer_225 = PHI <_238(24), stack_pointer_224(3), _238(6),
stack_pointer_206(7), _238(8), stack_pointer_190(9), _238(10),
stack_pointer_174(11), _238(12), stack_pointer_158(13), _238(14),
stack_pointer_142(15), _238(16), stack_pointer_126(17), _238(18),
stack_pointer_111(19), _238(20), stack_pointer_98(21), _238(22),
stack_pointer_85(23)>
# gotovar.0_216 = PHI <_63(24), _6(3), _9(6), _12(7), _15(8), _18(9),
_21(10), _24(11), _27(12), _30(13), _33(14), _36(15), _39(16), _42(17),
_45(18), _48(19), _51(20), _54(21), _57(22), _60(23)>
_227 = (long unsigned int) stack_pointer_225;
_228 = (long unsigned int) next_instr_78;
_229 = {_228, _227};
<bb 5> [local count: 1073741824]:
# gotovar.0_66 = PHI <gotovar.0_216(4), _3(2)>
# vect_next_instr_64.7_234 = PHI <_229(4), vect_next_instr_70.6_231(2)>
_237 = BIT_FIELD_REF <vect_next_instr_64.7_234, 64, 64>;
_238 = (long int *) _237;
_235 = BIT_FIELD_REF <vect_next_instr_64.7_234, 64, 0>;
_236 = (const short unsigned int *) _235;
goto gotovar.0_66;
```
Notice how there is an extra bb4 which most locations goto except for the entry
block.
This seems more on accident and how fragile `computed goto unfactoring`
requires just one bb to do the unfactoring.
