🚀 go-pugleaf

    When debugging gcc, I have almost always managed to get the uid of
  the rtl which causes the abort (by going up a couple of stack frames
  and doing a pr).  With this, the rtl dumps are very valuable; you
  simply search for the insn uid of the deadly rtl in the dump from
  the last pass before the crash.  Usually, this will show you which
  part of the md file is screwing up (eg. this piece of rtl *should*
  match this define_insn, but it doesn't.  Why not?).  In your case,
  insn_extract is called with a specific instruction.  Work out
  which define_insn in the machine description it matches, and look at
  it.  A careful comparision of the insn insn_extract is called with
  vs. the one in the machine description is matches will usually show
  you the problem.  (Are any of these suggestions useful?)

    I will say that debugging gcc is harder than debugging any other
  program I've worked with (for the reasons you've mentioned).
  However, this strikes me as reasonable for a program of the
  complexity of an optimizing C compiler.  In fact, I think gcc is
  extremely cleanly written, and as a result it is much easier to
  debug than a less cleanly written optimizing compiler.

						-- Randy