https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125628
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-16 branch has been updated by Xi Ruoyao <[email protected]>: https://gcc.gnu.org/g:29d615964a9ac4b5109f2cc5765e295d9b26808e commit r16-9170-g29d615964a9ac4b5109f2cc5765e295d9b26808e Author: Xi Ruoyao <[email protected]> Date: Tue Jun 23 22:07:34 2026 +0800 mips: fix unintialized operand use in sync_{old,new}_<optab>_12 [PR 125628] In GCC, if the RTL template of define_insn has multiple elements, it's treated as a parallel expression. And, "in parallel" means that first all the values used in the invidiviual side-effects are computed, and second all the actual side-effects are performed. So when the value of operand 1 (the output reg) is used, it's not set yet. When optimization is enabled, the uninitialized value is replaced with 0 and then for e.g. if atomic_hiqi_op is plus, (plus (0) (val)) is folded to simply (val). Now the RTL template happens to be matched by sync_old_nand_12 (of which the RTL is written in a really inconsistent way), causing "0 + 1 = -1". So fix the uninitialized operand use, i.e. (match_dup 0) should be (match_dup 1). Also slightly alter the source of the set for the memory in sync_new_<optab>_12 to make it clear the value in the reg and in the memory should be same after the operation. gcc/ PR target/125628 * config/mips/sync.md (sync_old_<optab><mode>): Fix uninitialized operand use. (sync_new_<optab><mode>): Fix uninitialized operand use, use the same expression for the set source of operand 0 and 1. (cherry picked from commit e7efddbd351e00fc5cda58dd063947784bf7e8b3)
