On Tue, 2026-06-23 at 14:11 +0100, Maciej W. Rozycki wrote: > On Tue, 23 Jun 2026, Xi Ruoyao wrote: > > > > > 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. > > Thanks, however this is not enough, patches still need to be posted to > gcc-patches; cf. <https://gcc.gnu.org/contribute.html#patches>. If a > change has been approved off-list, then tag it with [COMMITTED] and use > the discussion section to explain the details. > > However the change discussed in PR125628 isn't the same as (or trivially > different, such as with a comment typo or formatting fix, from) one you > have pushed, so you haven't actually obtained approval for your ultimate > change. Especially as the commit description itself is subject to review > as well. > > And last but not least the commit description was supposed to refer to > PR125628, especially since you meant to backport it. With the situation > as it stands nobody will be able to refer the PR from the change. > > I think this change has to be reverted on trunk/gcc-16, the final version > of the fix properly posted with the commit description corrected, approval > obtained, and only then the patch reapplied and backported.
Already reverted. But with all due respect: the fact that GCC 16.1 could be released with such a severe and obvious breakage on MIPS made me believe nobody really cared about the port so I could do things not so formally as long as it didn't worsen the situation. -- Xi Ruoyao <[email protected]>
