[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92882 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92882 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Dec 10 21:05:59 2019 New Revision: 279196 URL: https://gcc.gnu.org/viewcvs?rev=279196=gcc=rev Log: PR rtl-optimization/92882 * regstat.c (regstat_bb_compute_calls_crossed): Don't check INSN_UID against DF_INSN_SIZE or use DF_INSN_INFO_GET unless NONDEBUG_INSN_P. * gfortran.dg/pr92882.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr92882.f Modified: trunk/gcc/ChangeLog trunk/gcc/regstat.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92882
--- Comment #3 from Matthew Malcomson ---
(In reply to Jakub Jelinek from comment #2)
> The question is if we just have some exception that for new labels etc. we
> don't grow the tables, while for insns we always do. If yes, the patch is a
> real fix, if not, we can wait for further ICEs on the same assertion.
>
That's a good point.
At the time I proposed r279124 I decided that the comment inside
`df_recompute_luids` was enough of an indication that labels should be in the
tables, but another interpretation could be that we already know labels can be
outside of a table for some period of computation.
void
df_recompute_luids (basic_block bb)
{
rtx_insn *insn;
int luid = 0;
df_grow_insn_info ();
/* Scan the block an insn at a time from beginning to end. */
FOR_BB_INSNS (bb, insn)
{
struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
/* Inserting labels does not always trigger the incremental
rescanning. */
if (!insn_info)
{
gcc_assert (!INSN_P (insn));
insn_info = df_insn_create_insn_record (insn);
}
DF_INSN_INFO_LUID (insn_info) = luid;
if (INSN_P (insn))
luid++;
}
}
[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92882
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Dunno if it isn't just workaround, but it makes absolutely no sense to
DF_INSN_INFO_GET on insns for which we really don't need it, such as debug
insns, CODE_LABEL etc. for which we never use insn_info and we just continue;.
Patch like below fixes the ICE for me.
The question is if we just have some exception that for new labels etc. we
don't grow the tables, while for insns we always do. If yes, the patch is a
real fix, if not, we can wait for further ICEs on the same assertion.
2019-12-10 Jakub Jelinek
PR rtl-optimization/92882
* regstat.c (regstat_bb_compute_calls_crossed): Don't check
INSN_UID against DF_INSN_SIZE or use DF_INSN_INFO_GET unless
NONDEBUG_INSN_P.
* gfortran.dg/pr92882.f: New test.
--- gcc/regstat.c.jj2019-12-09 15:02:30.112287863 +0100
+++ gcc/regstat.c 2019-12-10 13:36:23.231327649 +0100
@@ -324,13 +324,13 @@ regstat_bb_compute_calls_crossed (unsign
FOR_BB_INSNS_REVERSE (bb, insn)
{
+ if (!NONDEBUG_INSN_P (insn))
+ continue;
+
gcc_assert (INSN_UID (insn) < (int) DF_INSN_SIZE ());
struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
unsigned int regno;
- if (!NONDEBUG_INSN_P (insn))
- continue;
-
/* Process the defs. */
if (CALL_P (insn))
{
--- gcc/testsuite/gfortran.dg/pr92882.f.jj 2019-12-10 13:38:17.737571868
+0100
+++ gcc/testsuite/gfortran.dg/pr92882.f 2019-12-10 13:38:07.453729553 +0100
@@ -0,0 +1,4 @@
+C PR rtl-optimization/92882
+C { dg-do compile }
+C { dg-options "-O2 -fno-inline" }
+ INCLUDE 'secnds.f'
[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92882 Rainer Orth changed: What|Removed |Added Target|s390x-linux-gnu |s390x-linux-gnu, ||sparc-sun-solaris2.11 CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth --- I'm seeing the same ICE on 32-bit SPARC (only; 64-bit is fine): +FAIL: gfortran.fortran-torture/execute/math.f90, -O3 -g (internal compiler error) during RTL pass: sched1 /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.fortran-torture/execute/math.f90:19:0: internal compiler error: in regstat_bb_compute_calls_crossed, at regstat.c:327 0xbc723b regstat_bb_compute_calls_crossed /vol/gcc/src/hg/trunk/local/gcc/regstat.c:327 0xbc723b regstat_compute_calls_crossed() /vol/gcc/src/hg/trunk/local/gcc/regstat.c:380 0x142882f sched_init() /vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:7337 0x142a5ab haifa_sched_init() /vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:7354 0xc0e59f schedule_insns() /vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3514 0xc0ef63 schedule_insns() /vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3508 0xc0ef63 rest_of_handle_sched /vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3726 0xc0ef63 execute /vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3834
[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92882 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-10 CC||matmal01 at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
