https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #19 from John David Anglin <danglin at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #17) > (In reply to John David Anglin from comment #15) > > While bootstrap is okay, there are some new test fails: > > > > AIL: gcc.c-torture/compile/pr92618.c -O1 (internal compiler error: > > maximum number of generated reload insns per insn achieved (90)) > > (And all failures are like this. Are they all caused buy the same thing, > too?) > > > I think the maximum number of generated reloads per insn may need increasing > > to fix above. > > No, no finite number will fix it. The problem is that LRA sees some > problematic insn for which it needs some reloading, but one of the insns > it comes up with is the same exact shape as the original problematic insn, > so we are in an infinite loop here. There were some problems like this that I managed to fix by changing pa_secondary_reload. > > The maximum used to be 30 btw, but apparently there were cases where we > actually needed that many reloads. But we never need anything close to 90, > on any target. So far, anyway. The above test generates a large number of reload insns with SUBREGs. Doesn't appear to be an infinite loop. Test only fails on 32-bit hppa. That's why I thought it was caused by triggering limit. > > > FAIL: 20_util/variant/run.cc -std=gnu++17 (test for excess errors) > > UNRESOLVED: 20_util/variant/run.cc -std=gnu++17 compilation failed to > > produce executable > > FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc > > -std=gnu++17 (test for excess errors) > > UNRESOLVED: > > 23_containers/vector/requirements/exception/generation_prohibited.cc > > -std=gnu++17 compilation failed to produce executable > > FAIL: std/ranges/cartesian_product/1.cc -std=gnu++23 (test for excess > > errors) > > UNRESOLVED: std/ranges/cartesian_product/1.cc -std=gnu++23 compilation > > failed to produce executable > > FAIL: std/ranges/cartesian_product/1.cc -std=gnu++26 (test for excess > > errors) > > UNRESOLVED: std/ranges/cartesian_product/1.cc -std=gnu++26 compilation > > failed to produce executable > > > > These appear caused by incorrect selection of class R1_REGS. Not sure > > why or what to do about it. > > Chosen by LRA? Chosen for new insns generated by LRA? I think so based on looking at the dump for the reload pass but I'm not sure. I believe the insn was not generated by LRA. LRA was unable to find hard registers for a (set (MEM (REG1)) (REG2)) insn in the above test failures. This is a very common pattern. Need to look at what happened to the sets for REG1 and REG2. Register r1 is somewhat special in that it is the only register that can be used as the destination of addil instructions. I will open bug reports when I have more information.
