Patch causes segv

[Dale Johannesen]

Unfortunately this patch

http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00269.html

isn't correct after all.  Calling into loop_invariant_p at this point is
not safe, because the unrolling code is allocating new REGs as it goes
along, and loop_invariant_p looks up things in loop->array[reg] which
has not been expanded to include the new REGs.  This can result in a 
segv.
On darwin this happens when building SPEC's 176.gcc with
-DHOST_WORDS_BIG_ENDIAN -O3 -mcpu=7400 -funroll-loops

A quick fix is to put

loop_regs_scan(loop, 0);

before the code you added, and make the definition in loop.c extern.
(Not adequately tested.)  This is pretty inefficient though and I hope
you can do better.