[Bug sanitizer/83388] reference statement index not found error with -fsanitize=null
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Dec 12 12:27:00 GMT 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83388
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-12-12
CC| |hubicka at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Index: gcc/lto-streamer-in.c
===================================================================
--- gcc/lto-streamer-in.c (revision 255578)
+++ gcc/lto-streamer-in.c (working copy)
@@ -1175,6 +1175,16 @@ input_function (tree fn_decl, struct dat
}
if (remove)
{
+ /* If we are asked to remove a non-debug stmt replace it
+ with a nop instead to not confuse IPA references that
+ might refer to the original. */
+ if (! is_gimple_debug (stmt))
+ {
+ gimple *nop = gimple_build_nop ();
+ gimple_set_uid (nop, gimple_uid (stmt));
+ gsi_insert_before (&bsi, nop, GSI_SAME_STMT);
+ stmts[gimple_uid (nop)] = nop;
+ }
gimple_stmt_iterator gsi = bsi;
gsi_next (&bsi);
unlink_stmt_vdef (stmt);
works to fix the ICE. We'll end up with a "dangling" IPA reference but
hopefully that's safe...
The other option would be to remove those IPA references on-the-fly.
Honza, would it be safe to simply do
Index: gcc/lto-streamer-in.c
===================================================================
--- gcc/lto-streamer-in.c (revision 255578)
+++ gcc/lto-streamer-in.c (working copy)
@@ -921,8 +921,6 @@ fixup_call_stmt_edges_1 (struct cgraph_n
fatal_error (input_location,
"Reference statement index out of range");
ref->stmt = stmts[ref->lto_stmt_uid - 1];
- if (!ref->stmt)
- fatal_error (input_location, "Reference statement index not found");
}
}
instead? Thus leave ref->stmt == NULL? Or would it be safe to remove
the IPA reference at this stage (I suppose IPA transform phase might get
confused if they stream references to such references?)
More information about the Gcc-bugs
mailing list