https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 16 Mar 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 > > --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > Ah, but > 1690 if (flag_checking > 1691 && (lra_assignment_iter_after_spill > 1692 > LRA_MAX_ASSIGNMENT_ITERATION_NUMBER)) > 1693 internal_error > 1694 ("maximum number of LRA assignment passes is achieved (%d)", > 1695 LRA_MAX_ASSIGNMENT_ITERATION_NUMBER); > is guarded with -fchecking. So it really hangs with -fno-checking. > Now, on the > error: ‘asm’ operand has impossible constraints > errors the problematic insns are removed: > 1864 PATTERN (insn) = gen_rtx_USE (VOIDmode, const0_rtx); > 1865 lra_set_insn_deleted (insn); > or nulified in case of asm goto, so wonder whether some LRA state shouldn't be > reset at that point as well or what is the reason for the > 30 iterations. "easy" out would be to do flag_checking || error_count?
