Oh my god, it's full of NULLs

["Dave Korn" <dk at artimi dot com>]

[ with apologies to the memory of Stanley Kubrick :) ]

    Hi Gcc hackers,

  Working on an in-house version of dlx-elf-gcc, based on the released 3.2
sources with pretty much no changes except to the backend, I stumbled across
one (or more) of the alias-analysis-vs-loop-unrolling bugs that I see from
the list archives caused everyone a great deal of pain during spring and
summer 2003 [PRs PR/9745, PR/10021, PR/11319 IIRC].

  I backported a whole bunch of the patches that came up in the surrounding
discussions, but my new build of the compiler SEGVs.  I took a great deal of
care to see that I had a consistent set of patches, but I guess I got
something wrong!

[  The patches I backported were for the loop.c removed SEQUENCE / loop regs
update bug, the MEM_IN_STRUCT_P bug relating to arrays, the caller-save.c
sequence removal, and the doloop_modify_runtime fix for the unrolled loop
count (Alan Modra's improved version using the preconditioning flag/notes,
rather than Dale Johannesen's initial version that had to be reverted).
  I mention these details in case it suddenly occurs to someone to say "You
mean you ported all those but forgot the patch relating to XXX?  Of course
that won't work!".  However I do think I got a consistent patchset, so it's
more likely I'm going to have to debug this for real. ]

  The offending code is in loop.c/loop_regs_scan, which is being called from
scan_loop() from loop_optimize(), and it looks like this:

  /* Invalidate all hard registers clobbered by calls.  With one exception:
     a call-clobbered PIC register is still function-invariant for our
     purposes, since we can hoist any PIC calculations out of the loop.
     Thus the call to rtx_varies_p.  */
  if (LOOP_INFO (loop)->has_call)
    for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
      if (TEST_HARD_REG_BIT (regs_invalidated_by_call, i)
    	  && rtx_varies_p (regno_reg_rtx[i], 1))
        {
          regs->array[i].may_not_optimize = 1;
          regs->array[i].set_in_loop = 1;
        }

and the problem is that regno_reg_rtx[0] is NULL, which causes the
rtx_varies_p call to immediately bomb.  Stepping through the code and
watching it in the debugger, I can see that the regno_reg_rtx array has
entries for the various special-purpose (virtual) regs that are setup in
emit-rtl.c/init_virtual_regs(), but the entire rest of the array contains
NULL pointers.

Q1)  I take it this isn't meant to be the case?

  I've found where gen_reg_rtx (not gen_rtx_REG!) sets the entry for each
new pseudo that's allocated, but I haven't managed to find any code that
sets up entries for the hard regs.

Q2)  I take it that this is supposed to happen?
Q3)  But where's the code to set it up?



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....