https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497
--- Comment #5 from Jeffrey A. Law <law at gcc dot gnu.org> --- 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.
