Dereference of Null pointer in loop.c

[Ian Dall <ian at beware dot dropbear dot id dot au>]

I am not making this a formal bug report yet, because I am working on
a locally patched version (so it is hard for someone else to
duplicate). However, the code looks wrong!

Currently I get a core dump during make bootstrap:

/usr/src/gnu/gcc-local/gcc/regmove.c: In function `find_matches':
/usr/src/gnu/gcc-local/gcc/regmove.c:1573: Internal error: Segmentation fault.

A limited trace back is:

#0  0x14f00a in add_insn_before (insn=0x86a9aa0, before=0x0)
    at /usr/src/gnu/gcc-local/gcc/emit-rtl.c:2633
#1  0x14f638 in emit_insn_before (pattern=0x86aa560, before=0x0)
    at /usr/src/gnu/gcc-local/gcc/emit-rtl.c:2925
#2  0x19595d in maybe_eliminate_biv_1 (loop=0x2f3800, x=0x869c380, 
    insn=0x869b7a0, bl=0x38b340, eliminate_p=1, where_bb=0x0, 
    where_insn=0x0, 3095688) at /usr/src/gnu/gcc-local/gcc/loop.c:7944
#3  0x1953b4 in maybe_eliminate_biv (loop=0x2f3800, bl=0x38b340, 
    eliminate_p=1, threshold=54, insn_count=8)
    at /usr/src/gnu/gcc-local/gcc/loop.c:7736


The problem is that in maybe_eliminate_biv, there is this code:

       rtx where_insn = threshold >= insn_count ? 0 : p;

Unless threshold is always less than insn_count (in which case
it should be an assert, not an assignment), this can lead to
maybe_eliminate_biv_1 being called with a null pointer which it can't
handle.

Since the assignment of where_insn to zero looks deliberate, somewhere
else, the null pointer should be specially handled. The comments for
maybe_eliminate_biv_1 say:

   WHERE_INSN/WHERE_BB indicate where extra insns should be added.
   Depending on how many items have been moved out of the loop, it
   will either be before INSN (when WHERE_INSN is non-zero) or at the
   start of the loop (when WHERE_INSN is zero).  */

yet nowhere is there a test for where_insn.

Any clues appreciated.

Ian