Re: Urgent: bug fixes needed for GCC 3.0.2

[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
  > 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
  > http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00806.html
  > 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.

jeff