Re: Solaris bootstrap failure

[Mike Stump <mrs at windriver dot com>]

> Date: Wed, 7 Mar 2001 22:40:08 -0800 (PST)
> From: Colin Howell <chowell@redhat.com>
> To: gcc@gcc.gnu.org

> The question is why cselib_lookup() is giving different results in the
> two cases.  I strongly suspect the hash table used by cselib, but I
> can't yet pin down an exact fault in it.  While comparing its behavior
> in the stage1 and stage2 compilers, however, one thing caught my eye.
> Check out lines 2663-2666 of simplify-rtx.c, within the function
> hash_rtx():

>     case SYMBOL_REF:
>       hash
>         += ((unsigned) SYMBOL_REF << 7) + (unsigned long) XSTR (x, 0);
>       return hash ? hash : (unsigned int) SYMBOL_REF;

> Date: Thu, 8 Mar 2001 16:42:10 +0000 (GMT)
> From: Bernd Schmidt <bernds@cambridge.redhat.com>
> To: Colin Howell <chowell@redhat.com>
> Cc: <gcc@gcc.gnu.org>

> In theory the layout of the hash table should have no effect on the code.
> However, using pointers can lead to problems if there's a bug that makes
> us depend on the hash table layout...

Well, it was tracked down to cselib_loopup giving different results,
so lets investigate it some.  Code review by hand might be the best
technique, since it is so rare and hard to pin down.

I too thought that using the machine addresses might cause problems,
but after reviewing the way in which the table works, assuming that
the equality operator actually works, I'll agree with Bernd, I don't
think te SYMBOL_REF case can cause the problem.

However, after looking at the code, I am suspicious of:

  switch (code)
    {
    case MEM:
    case REG:
      e = cselib_lookup (x, GET_MODE (x), create);
      if (! e)
      return 0;

      hash += e->value;
      return hash;


Should it not be:

  switch (code)
    {
    case MEM:
    case REG:
      e = cselib_lookup (x, GET_MODE (x), create);
      if (! e)
      return 0;

      hash += e->value;
      return hash ? hash : (unsigned int) MEM;

It should be beyond rare that this overflows to 0 exactly, but if it
does, blam.  Colin, could you run the two binaries that are known to
differ, and see if in either of them hash is zero before the return?
If it is, maybe Bernd can confirm that this would be bad.

Also, you can do a set hash = 1, and then continue it, and then see if
the code then matches the other instance of the compiler.  If it does,
this will confirm this as the culprit, thanks Colin for your hard work
tracking it down.