This is the mail archive of the
mailing list for the GCC project.
Re: Urgent: bug fixes needed for GCC 3.0.2
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: Urgent: bug fixes needed for GCC 3.0.2
- From: law at redhat dot com
- Date: Thu, 04 Oct 2001 09:28:25 -0600
- cc: "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 <email@example.com>you write:
> > Presumably we set the bit because the argument is marked as "const".
> > So the question becomes should we have set the unchanging bit in the
> > first place (probably yes)?
> 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 misunderstand
> 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.
If we believe that without the sibcall that having RTX_UNCHANGING_P set is
correct and desirable, then we need to clear the bit if we have a sibcall
since the sibcall sequence will overwrite the incoming stack slots. This
may (or may not) be a difficult thing to do.