This patch was previously discussed at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670354.html
I have attempted to fix it per the feedback in the above thread. Note that
this version is a change in behavior. In my v2 patch, I changed it so as to
preserve the exact existing behavior -- if a NOTE_INSN is encountered with a
null this_block, then it ends up calling change_scope(). In v3, following
the suggestions, it now just continues on instead. Please let me know if I
misunderstood anything there.
-- >8 --
This function has a code path that calls INSN_LOCATION on an rtl note. For a
note, this returns the note type enum rather than a location, but it runs
without complaint even with --enable-checking=rtl because both are stored in
the rt_int member of the rtunion. A subsequent commit will add a new rtl
format code specifically for locations, in which case attempting to call
INSN_LOCATION on a note will trigger an error. Fix it up by handling the
case of a note missing a location separately.
gcc/ChangeLog:
* final.cc (reemit_insn_block_notes): Don't try to call
INSN_LOCATION on a NOTE rtl object. Don't call change_scope () for a
NOTE missing a location.
---
gcc/final.cc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/final.cc b/gcc/final.cc
index ea08c4956fb..1fe34c55853 100644
--- a/gcc/final.cc
+++ b/gcc/final.cc
@@ -1513,6 +1513,8 @@ reemit_insn_block_notes (void)
case NOTE_INSN_BEGIN_STMT:
case NOTE_INSN_INLINE_ENTRY:
this_block = LOCATION_BLOCK (NOTE_MARKER_LOCATION (insn));
+ if (!this_block)
+ continue;
goto set_cur_block_to_this_block;
default:
@@ -1538,7 +1540,6 @@ reemit_insn_block_notes (void)
this_block = choose_inner_scope (this_block,
insn_scope (body->insn (i)));
}
- set_cur_block_to_this_block:
if (! this_block)
{
if (INSN_LOCATION (insn) == UNKNOWN_LOCATION)
@@ -1547,6 +1548,7 @@ reemit_insn_block_notes (void)
this_block = DECL_INITIAL (cfun->decl);
}
+ set_cur_block_to_this_block:
if (this_block != cur_block)
{
change_scope (insn, cur_block, this_block);
