+CC @pinskia On 5/10/25 06:55, Jeff Law wrote: > > On 5/9/25 2:27 PM, Vineet Gupta wrote: >> gcc/ChangeLog: >> >> * emit-rtl.cc (next_nonnote_nondebug_insn): Update comments. >> >> Signed-off-by: Vineet Gupta <vine...@rivosinc.com> >> --- >> gcc/emit-rtl.cc | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc >> index 3e2c4309dee6..b78b29ecf989 100644 >> --- a/gcc/emit-rtl.cc >> +++ b/gcc/emit-rtl.cc >> @@ -3677,7 +3677,11 @@ next_nonnote_nondebug_insn (rtx_insn *insn) >> >> /* Return the next insn after INSN that is not a NOTE nor DEBUG_INSN, >> but stop the search before we enter another basic block. This >> - routine does not look inside SEQUENCEs. */ >> + routine does not look inside SEQUENCEs. >> + NOTE: This can potentially bleed into next BB. If current insn is >> + last insn of BB, followed by a code_label before the start of >> + the next BB, code_label will be returned. But this is the >> + behavior rest of gcc assumes/relies on e.g. get_last_bb_insn. */ > I don't see how get_last_bb_insn itself inherently needs this behavior. > I could believe something that *calls* get_last_bb_insn might depend on > this behavior -- but I'd also consider that bogus. The CODE_LABEL is > part of the next block, so returning that seems quite wrong given the > original comment and users like get_last_bb_insn.
Back when I stumbled into this, @pinskia mentioned on IRC that fixing next_nonnote_nondebug_insn would affect get_last_bb_insn as that expects BARRIERS (in next bb too) Thx, -Vineet > I don't mind adding the comment, but I'd much rather chase down the > offenders and fix them. > > Jeff > >
