This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Urgent: bug fixes needed for GCC 3.0.2

  In message <>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
  > d
  > > >   > 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]