This is the mail archive of the
mailing list for the GCC project.
Re: Urgent: bug fixes needed for GCC 3.0.2
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: Urgent: bug fixes needed for GCC 3.0.2
- From: law at redhat dot com
- Date: Fri, 05 Oct 2001 16:47:24 -0600
- cc: Mark Mitchell <mark at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "wilson at redhat dot com" <wilson at redhat dot com>, "jh at suse dot cz" <jh at suse dot cz>
- Reply-To: law at redhat dot com
In message <20011004182122.S3251@sunsite.ms.mff.cuni.cz>you write:
> On Thu, Oct 04, 2001 at 08:57:13AM -0700, Mark Mitchell wrote:
> > > > I'm not sure. This is a MEM on the stack, and one that is not
> > > > necessarily going to be around for the entire function -- witness
> > > > the fact that we are going to overwrite it. Perhaps I misunderstan
> > > > a subtlety of RTX_UNCHANGING_P (quite likely, in fact!) but to me
> > > > it doesn't make sense to set it for this MEM; the value there is
> > > > likely to change.
> > > >
> > > > Am I speaking nonsense?
> > > Well, if it wasn't for the sibcall optimization the stack slot would be
> > > unchanging. That's the crux of the issue.
> This looks to me like ressurected
> thread which was exactly about this.
Sounds like the same general issue. However, your patch (as others have
pointed out) is wrong.
> I'm using following patch for this in gcc-2.96-RH (which Richard Kenner did
> not like but it certainly is less invasive change then ignoring
> RTX_UNCHANGING_P with sibling call optimization). IMHO clearing
> RTX_UNCHANGING_P is a safe thing to do even if it cleared some innocent
> variable's (which would be sharing the same stack slot) RTX_UNCHANGING_P
> flag as opposed to setting it.
My recommendation (and what I plan to try) is to find stack slots for
incoming arguments and turn off RTX_UNCHANGING_P on those stack slots
if and only if we have optimized a call into a sibling call. That is
non-intrusive and makes the use of RTX_UNCHANGING_P match the reality
of the RTL.