Re: more m68k breakage on m68k-linux

[Richard Zidlicky <rz@linux-m68k.org>]

On Wed, Mar 03, 2004 at 09:22:08AM +0100, Bernardo Innocenti wrote:
> Richard Zidlicky wrote:
> 
> >>>Note the typo "FIRST_PSEOUDO_REGISTER".. made it somewhat hard to
> >>>find the change.
> >>
> >>Oops!  That's very unfortunate.  I've fixed it in the ChangeLog.
> >
> >thanks.. I should have used agrep or something :)
> 
> What's that?  Is it perhaps an heuristic version of grep?
> I'd badly need something like that! :-)

http://laurikari.net/tre/

I have just installed it a few days ago so not many experiences
yet.

 agrep -2 FIRST_PSEUDO_REGISTER ChangeLog*

> >>If I didn't increment FIRST_PSEUDO_REGISTER, register 25 would
> >>be used both as the argptr and as a placeholder for some
> >>temporary register, with very interesting consequences :-)
> >
> >hm.. the problem I see is that the register allocator is initialised
> >with random garbage. Eg FIXED_REGISTERS is 24 elts big, thus 
> >initial_fixed_regs[] is also only 24 elts and in init_reg_sets() we
> >copy a random 25th elt into fixed_regs[] and risk segfault.
> >I am pretty sure more it results in more damage later on.
> 
> That's a nice catch, and it would explain all the strange
> bootstrap failures we've seen, but... I can't see this bug
> in current mainline code:
> 
> void
> init_reg_sets (void)
> {
>  int i, j;
> 
>  /* First copy the register information from the initial int form into
>     the regsets.  */
> 
>  for (i = 0; i < N_REG_CLASSES; i++)
>    {
>      CLEAR_HARD_REG_SET (reg_class_contents[i]);
> 
>      /* Note that we hard-code 32 here, not HOST_BITS_PER_INT.  */
>      for (j = 0; j < FIRST_PSEUDO_REGISTER; j++)
>        if (int_reg_class_contents[i][j / 32]
>            & ((unsigned) 1 << (j % 32)))
>          SET_HARD_REG_BIT (reg_class_contents[i], j);
>    }
> 
>  memcpy (fixed_regs, initial_fixed_regs, sizeof fixed_regs);


  sizeof fixed_regs != sizeof initial_fixed_regs

<rant>
I vote for rewriting gcc in Lisp, Ocaml or Prolog. It does already
have two garbage collectors and implements a large superset of every
Lisp interpreter out there. It can only get faster if implemented
in a higher level PL. Many Lisp dialects (and not only those) offer
far superior HW independence and portability compared to C and we
do still spend too much time hunting bugs that would be outright
impossible in a higher level language.
</rant>

Richard