https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Seems to be a FE bug. Already in *.gimple bug with -fdump-tree-all-uid one can see: __attribute__((fn spec (". "))) void p () { static voidD.27 sD.4214 (void); struct array01_character(kind=1) yD.4238; static integer(kind=8)D.9 .yD.4216; static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B}; bitsizetype D.4278; sizetype D.4279; try { ... __attribute__((fn spec (". "))) void s () { bitsizetype D.4285; sizetype .y.10D.4286; integer(kind=8)D.9 iftmp.14D.4287; { static integer(kind=8)D.9 .yD.4216; static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B}; bitsizetype D.4278; sizetype D.4279; That means that BLOCK_VARS of a BLOCK inside of p function contain s var with DECL_UID 4214, its DECL_CHAIN is y with DECL_UID 4238 and its DECL_CHAIN is .y with DECL_UID 4216. But the same .y var with DECL_UID 4216 is also in BLOCK_VARS of another BLOCK inside of s. Vars in BLOCK_VARS are chained through DECL_CHAIN, aren't in some vec or TREE_VEC etc., so can't be part of multiple chains.