This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Does gcc violate the ia64 ABI?
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: hjl at lucon dot org (H. J. Lu)
- Cc: gcc at gcc dot gnu dot org, rth at redhat dot com, schwab at suse dot de
- Date: Sat, 17 May 2003 23:10:17 -0400 (EDT)
- Subject: Re: Does gcc violate the ia64 ABI?
> > This is talking about what happens in a procedure call. It's not talking
> > about what happens to gp in the body of a procedure. 'c' and 'd' don't
> > guarantee that gp won't be modified when a local call returns. For that,
>
> 'c' and 'd' require the compiler guarantees gp won't be modified when
> a local call returns since gp will be the same at procedure entry and
> exit.
That's not how I interpret them. They say that gp will be valid at
procedure entry and at procedure return. The returning procedure is
not bar if it does a tail call to another procedure. So, I can't
see how you can argue that gp always will be preserved across local
calls if tail calls are ok.
The last sentence in 'd' is not a requirement. The same compiler
does both the tail call optimization and the local call optimization.
So, it can decide to perform one or the other, or none in situations
where there is an incompatibility. I don't see that not being able
to optimize calls known to be local is an ABI violation. Generating
tail calls might be an ABI violation but again I can't see how 'a' to
'd' explicitly rule them out.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)