[Bug target/125628] [16/17 Regression] mips64el: wrong code for stdatomic-op-1.c with -O -march=mips64r2

[cvs-commit at gcc dot gnu.org]

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 <xry111@gcc.gnu.org>:

https://gcc.gnu.org/g:29d615964a9ac4b5109f2cc5765e295d9b26808e

commit r16-9170-g29d615964a9ac4b5109f2cc5765e295d9b26808e
Author: Xi Ruoyao <xry111@xry111.site>
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)