Re: pa reload problem

[Jeffrey A Law <law at redhat dot com>]

  In message <200101040608.BAA05571@hiauly1.hia.nrc.ca>you write:
  > In this particular situation, the op0 register dies and the hard register
  > that reload asigns to it is reused.  However, reload doesn't check for this
  > and still goes ahead and substitutes the mem to eliminate the "equivalent"
  > pseudo. 
And that is the bug.  Blind replacement by reload is a constant source of
problems.

Now as I've mentioned before I've got changes to fix these kinds of problems.
But I haven't had time to finish testing them.

  > My impression is that it would be easier to not create the REG_EQUIV
  > notes in local-alloc after the op0 register dies than fix the problem in
  > reload.  It appears that reload may substitute a mem for a psuedo whenever 
  > it finds such a note without much testing.
That sound like you're barking up the wrong tree.  The REG_EQUIV note is
perfectly valid.  It's reload's fault for blindly substituting it in for
a pseudo that doesn't get a hard register.

  > ./xgcc -B./ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -isystem /usr/local/hppa
  > 1.1-hp-hpux10.20/include -O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstric
  > t-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g1  -DIN_LIBGC
  > C2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/
  > config -I../../gcc/../include -DUSE_COLLECT2 -DL_fixunstfdi -c ../../gcc/li
  > bgcc2.c -o libgcc/./_fixunstfdi.o
  > ../../gcc/libgcc2.c: In function `__fixunstfdi':
  > ../../gcc/libgcc2.c:865: Internal compiler error in mark_referenced_resourc
  > es, at resource.c:229
  > 
  > This occurs in stage 2 when built with -O3.  For some reason, virtual-stack
  > -vars
  > doesn't get a hard register during reload.  This is a new problem introduce
  > d
  > in the last few days.
Yes.  It's due to some additional checking Alex put into reorg recently.

jeff