https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92882

--- Comment #3 from Matthew Malcomson <matmal01 at gcc dot gnu.org> ---
(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++;
    }
}

Reply via email to