From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Andreas Schwab Cc: gcc@gcc.gnu.org Subject: Re: Reload bug Date: Thu, 02 Sep 1999 00:32:00 -0000 Message-id: <25863.936257014@upchuck.cygnus.com> References: X-SW-Source: 1999-09/msg00053.html In message < jeyaeq4p4n.fsf@hawking.suse.de >you write: [ ... ] > $ b=/cvs/test/i686-linux/egcs/gcc; $b/xgcc -B$b/ -O2 -fpic -S random.c -da > random.c: In function `Default_RandInt': > random.c:34: Internal compiler error in `change_address', at emit-rtl.c:151 > 6 > Please submit a full bug report. > See for instructio > ns. > [ ... ] > During global alloc register 31 is replaced by (mem:DI (symbol_ref)), but > a symbol_ref is not a valid memory operand due to PIC. In other words, > register 31 is _not_ equivalent to what insn 256 claims. Note, REG_EQUIV indicates that a pseudo is equivalent to a particular VALUE, not whether or not the REG_EQUIV expression can be directly substituted into the insn without additional work. So insn 256 is fine. I'll note this doesn't occur in the mainline tree, but I have no idea if that is because the bug has actually been fixed or because we're just not triggering the problem anymore. jeff From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Andreas Schwab Cc: gcc@gcc.gnu.org Subject: Re: Reload bug Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <25863.936257014@upchuck.cygnus.com> References: X-SW-Source: 1999-09n/msg00053.html Message-ID: <19990930180200.JtZOx38gRwDImmK1e96YLtNdlJwSDHlE6bQWj1U4IsI@z> In message < jeyaeq4p4n.fsf@hawking.suse.de >you write: [ ... ] > $ b=/cvs/test/i686-linux/egcs/gcc; $b/xgcc -B$b/ -O2 -fpic -S random.c -da > random.c: In function `Default_RandInt': > random.c:34: Internal compiler error in `change_address', at emit-rtl.c:151 > 6 > Please submit a full bug report. > See for instructio > ns. > [ ... ] > During global alloc register 31 is replaced by (mem:DI (symbol_ref)), but > a symbol_ref is not a valid memory operand due to PIC. In other words, > register 31 is _not_ equivalent to what insn 256 claims. Note, REG_EQUIV indicates that a pseudo is equivalent to a particular VALUE, not whether or not the REG_EQUIV expression can be directly substituted into the insn without additional work. So insn 256 is fine. I'll note this doesn't occur in the mainline tree, but I have no idea if that is because the bug has actually been fixed or because we're just not triggering the problem anymore. jeff