Hi Jeff, Thanks for the pointers.
Based on my understanding, both locations correspond to issues that we had already tracked as PR127796 and PR127726. I have now checked them again on the current trunk. The skip_consecutive_labels case does occur in practice. A source derived from gcc.c-torture/compile/pr110705-1.c can place a DEBUG_INSN between consecutive labels, causing the scan to stop at the debug instruction and producing an -fcompare-debug failure. The bounded backward scan in find_basic_block is also affected. DEBUG_INSNs consume the max-delay-slot-live-search budget and can prevent an otherwise usable instruction from filling a delay slot. The same function also has a forward label scan with the corresponding debug dependence. I have prepared separate patches and focused SPARC regression tests for the two issues. Each new test fails without its patch and passes with it, and the complete sparc.exp comparisons show no regressions. The native x86_64 bootstrap and full regression comparisons are still running -- my desktop is too slow so it may take some time. I will send the patches once that validation is complete. Thank you again and have a great one. Thanks, Yongqiang On Tue, 13 Oct 2026 at 23:56, Jeff Law <[email protected]> wrote: > > > > On 10/11/26 4:56 PM, Yongqiang Tian wrote: > > relax_delay_slots checks whether a BARRIER immediately precedes a jump > > target at two sites. pass_cleanup_barriers can place a DEBUG_INSN > > between the BARRIER and CODE_LABEL, so prev_nonnote_insn makes both > > decisions depend on whether debug information is present. > > > > Use prev_nonnote_nondebug_insn for both queries. Add two SPARC tests > > covering the separate decisions. > > > > This follows up Jeff Law's review of the patch for PR127795, which > > pointed out that these BARRIER queries could potentially depend on > > DEBUG_INSN placement. I initially replied that I had not seen GCC put > > a DEBUG_INSN in that position. Further investigation showed that > > pass_cleanup_barriers can create exactly that sequence, so this patch > > corrects that earlier conclusion. > > > > Tested at GCC revision a02e2004cb707155d5b9b0a82dd428ded0ee2f6f: > > > > * Instrumented baseline runs confirm that the first and second SPARC > > tests reach the first and second modified queries, respectively. > > Both fail without this patch and pass with it. > > * A complete sparc-elf `make -k -j8 check-gcc` comparison has no > > regressions. > > * Native x86_64-pc-linux-gnu `make -j24 bootstrap` and > > `make -k -j24 check` completed with and without the two-patch series. > > After normalizing build paths, both produced the same outcomes: > > 621579 PASS, 6 FAIL, 1 XPASS, 4872 XFAIL, and 8114 UNSUPPORTED. > > * `contrib/check_GNU_style.sh` and `git diff --check` pass. > > > > Assisted-by: OpenAI Codex 5.6 Sol, co-reviewed by Claude and Yongqiang Tian. > > > > PR rtl-optimization/127808 > > > > gcc/ChangeLog: > > > > * reorg.cc (relax_delay_slots): Ignore debug insns when looking for > > a BARRIER before a jump target. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/sparc/reorg-relax-barrier-debug-1.c: New test. > > * gcc.target/sparc/reorg-relax-barrier-debug-2.c: New test. > > > > Signed-off-by: Yongqiang Tian <[email protected]> > Thanks. I've pushed this to the trunk. > > It's worth noting that LLM review had some concerns about NULL pointer > dereferences, but I don't think those cases can happen. > > If you want to keep chasing these kinds of things, look in > skip_consecutive_labels. If we were to have something like > > CODE_LABEL > DEBUG_INSN > CODE_LABEL > BARRIER > > Then I think first loop can exit based on the existence of the > DEBUG_INSN (due to the !INSN_P check). I don't know if this happens in > practice. > > There may be problems in find_basic_block as well (resource.cc). There's > probably more given reorg.cc's history (written before we had > DEBUG_INSNs) and isn't as widely used as delay slots aren't that common. > > Jeff
