Re: PATCH 1: Re: BOOTSTRAP FAILURE: segementation fault in genattrtab

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> 
>   In message <200011181939.OAA10162@hiauly1.hia.nrc.ca>you write:
>   > >   > I think the reversal occurs because r3 is being used as an index regi
>   > ster.
>   > >   > There is stuff in the machine definition like this:
>   > > I seriously doubt it since hard_frame_pointer_rtx shouldn't have %r3 as
>   > > its value unless %r3 really is the frame pointer.  ie, if the frame point
>   > er
>   > > is eliminated %r3 should not be the value of hard_frame_pointer_rtx.
>   > > jeff
>   > 
>   > The following patch resolves the above issue (ie, after reload starts,
>   > gen_rtx_REG should should not return the frame_pointer_rtx for the frame
>   > pointer register number).  Tested with a full bootstrap and check under
>   > hpux 10.20.
>   > 
>   > Please review for installation.
> It seems to me that we should return the hard frame pointer if it is
> being used that way.  Else we should not.
>
> ie, if we did not eliminate the frame pointer, then returning frame_pointer_rtx
> would be the right thing to do.
>
> If we did eliminate the frame pointer, then we do not want to return
> frame_pointer_rtx.

Is there a simple test to determine whether the frame pointer or other
eliminable register has been eliminated?  When I wrote the patch, I assumed
that no code would call gen_rtx_REG if it needed the frame_pointer_rtx
after reload even if it hadn't been eliminated.  If there was such code,
the hack in the pa.md probably would have broken long ago.  Isn't the above
unnecessarily complicating things?

This gets even messier for the arg_pointer_rtx.  On the pa 64 bit target,
the arg pointer isn't eliminable or always invariant, so the register could be
used for multiple purposes in a function.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)