Hi, Sam, This bug has same sympton as https://gcc.gnu.org/pipermail/gcc-bugs/2026-October/980073.html, but is triggered if and only if built with "-Og -g -fno-exceptions" on loong64 from gcc-13.1 to gcc-master. On ARM64, neither gcc-13.1 or gcc-master triggered this bug.
Dumped with -fdump-rtl-vartrack-details, we found BB 13 repeated add and remove NBasename, see https://gcc.gnu.org/pipermail/gcc-bugs/2026-October/978717.html With help of AI, I get a reduced test case https://gcc.gnu.org/bugzilla/attachment.cgi?id=65904 and a fix https://gcc.gnu.org/bugzilla/attachment.cgi?id=65904 AI says: @@ -4239,6 +4239,13 @@ variable_merge_over_src (variable *s2var, struct dfset_merge *dsm) if (!s2var->onepart) + /* A multi-part variable that occurs only in SRC2 makes the merged + set larger than SRC1. Do not let the caller replace it with + SRC1 merely because all other entries could be shared. Otherwise + the incoming set may lose a variable between dataflow rounds, + causing vt_find_locations to oscillate indefinitely. */ + if (!shared_hash_find(dsm->cur->vars, dv)) + dst_can_be_shared = false; Honestly, I don't understand var tracking, including this fix and I can't be sure who is the maitainer of var-tracing.cc(The original author has not show up on gcc mail list since 2004) This reduced test case can reproduce this bug both on *arm64* and loong64 on gcc-master, so I suppose this is a bug of var-tracking, not just caused by strage rtl output of early pass from loong64. The rtl dump show same BB 13 (interesting) repeated add and remove NBasename. The fix based on gcc-master and works on arm64 and loong64 PS: the reduced case without return is intended, or the bug is not reproduced.
