From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: "John David Anglin" Cc: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: pa reload problem Date: Thu, 04 Jan 2001 09:55:00 -0000 Message-id: <11988.978631067@upchuck> References: <200101040608.BAA05571@hiauly1.hia.nrc.ca> X-SW-Source: 2001-01/msg00183.html 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