This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: testcase for hppa64 gcc bug
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Subject: Re: testcase for hppa64 gcc bug
- From: Alan Modra <alan at linuxcare dot com dot au>
- Date: Tue, 31 Oct 2000 09:16:43 +1100 (EST)
- cc: gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, parisc-linux at thepuffingroup dot com, law at cygnus dot com
On Mon, 30 Oct 2000, John David Anglin wrote:
> > * rtl.h (ARG_POINTER_INVARIANT): Define as 1 if undef.
> > * rtlanal.c (rtx_unstable_p): Qualify arg_pointer_rtx match with
> > ARG_POINTER_INVARIANT.
> > (rtx_varies_p): Likewise.
> > (rtx_addr_can_trap_p): Likewise.
> > * local-alloc.c (function_invariant_p): Likewise.
> > * loop.c (loop_invariant_p): Likewise.
> > * tm.texi (ARG_POINTER_INVARIANT): Describe.
>
> I don't think this is the correct fix. Isn't r29 used for 128 bit
> return values?
Yes, r29 is used for 128 bit return values, but how is that relevant to
use of r29 as the arg pointer?
I tried setting up ELIMINATE_REGS and so forth (see puffin CVS
gcc/config/pa/pa-linux64.h) but that failed badly with what looked like,
from a very cursory inspection, a use of r29 as a temporary reg being
"eliminated" to r30+const. Oops.
Anyway, nothing in the above patch should make the situation worse. All
it really does is let the compiler see places where arg_pointer changes,
instead of blindly assuming that arg_pointer will not change. Take a peek
at the .lreg rtl for the test case I posted.
Alan Modra
--
Linuxcare. Support for the Revolution.