On Tue, 2026-06-23 at 13:17 +0100, Maciej W. Rozycki wrote: > On Mon, 8 Jun 2026, Xi Ruoyao via Gcc-cvs wrote: > > > https://gcc.gnu.org/g:1d6d7e982a982724ed8d9efc7eaa0f38638f8027 > > > > commit r17-1414-g1d6d7e982a982724ed8d9efc7eaa0f38638f8027 > > Author: Xi Ruoyao <[email protected]> > > Date: Sun Jun 7 14:34:26 2026 +0800 > > > > mips: fix unintialized operand use in sync_{old,new}_<optab>_12 > > > > 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. > > I can't see this change posted/reviewed on gcc-patches, would you please > point me at the original submission? Thank you.
The concept of it has been discussed in https://gcc.gnu.org/PR125628. -- Xi Ruoyao <[email protected]>
