A very recent regression. Will bisect.
Starts from r14-5367: Author: Jin Ma <jinma@linux.alibaba.com> Date: Sat Nov 11 13:11:45 2023 -0700 [PATCH v2] In the pipeline, USE or CLOBBER should delay execution if it star ts a new live range.
FWIW, GCC configured with: --with-system-zlib --disable-fixincludes --enable-default-ssp --enable-default-pie --disable-werror --disable-multilib
If at all possible, cc Jin Ma in this since it's his change, I just reviewed and committed the bits on Jin's behalf.
(In reply to Jeffrey A. Law from comment #3) > If at all possible, cc Jin Ma in this since it's his change, I just reviewed > and committed the bits on Jin's behalf. I've replied the gcc-patch thread. It seems Jin Ma does not have a Bugzilla account. Generally how do we debug a comparison failure? I've not seen it before.
This failure means the stage1 and stage2 compilers generated different code for the same input. So when I need to debug this I usually start by first getting that source code. Based in the title of this bugzilla you're going to want the .ii file for constraint-manager as built by either the stage1 or stage2 compiler. Then I feed that into the stage1 and stage2 compiler with the same optimization options to verify that they indeed generate different code. Sometimes that doesn't work when the issue is debug insns, but that's where I start. Once I have confirmed the two compilers generate different code, then I try to isolate where/why. This can often be done by looking a debug dumps to narrow things down to a pass that's behaving differently. Alternately you can replace objects in the stage2 compiler with those from the stage1 compiler to narrow it down to a single .o that causes the compiler's behavior to diverge. Then it's usually a matter going into the debugger and understanding why the given pass is behaving differently. It's a long, painful process. *Sometimes* you can just build the stage1 compiler and run the testsuite and see if there are new failures on your target. It doesn't always generate something useful, but when it does it's often faster than the process I mentioned above.
The problematic commit reverted at r14-5371. I've tested the reversion locally, so marking this fixed.