This is the mail archive of the
mailing list for the GCC project.
Re: Question about ARM -mapcs-frame documentation
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Mon, 13 Oct 2003 13:25:28 +0100
- Subject: Re: Question about ARM -mapcs-frame documentation
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> Ian Lance Taylor <firstname.lastname@example.org> writes:
> > The documentation for the ARM -mapcs-frame option says this:
> And another question. The ARM backend code supports TARGET_ATPCS, and
> it is used in a few places. But there is no option for it in
> TARGET_SWITCHES, which means that there is no way to control it. It's
> turned on automatically for TARGET_IWMMXT, and it's turned on for the
> arm*-*-netbsdelf* target. The latter decision is quite reasonable.
> The former is, in my opinion, somewhat questionable.
IMO it's more than questionable, it's broken, and I said so at the time
the code was committed. Changing the target processor should NOT change
the default ABI.
The reason for doing it was that some instructions on the XScale require
double-word aligned memory, and there have been a whole load of gross
hacks introduced to try and work around this limitation.
> The only effect of TARGET_ATPCS on the compiler appears to be to
> change the definition of which types are returned in memory, and to
> require that the stack be aligned on a 64-bit boundary. Both of these
> requirements are from the ATPCS document. The former requirement
> means that the ATPCS code does not completely interoperate with
> non-ATPCS code.
> Should there be -matpcs and -mno-atpcs options?
No, support wasn't really finished. It was close enough for NetBSD to use
it, but it isn't really the ATPCS. The intention on NetBSD was that it
would be used until such time as the (now-named) AAPCS specification was
published, and then NetBSD would switch to that (with a compatibility
layer for old apps).
As for the XScale mess, then I think the code there is fundamentally
broken. As I said at the time, support for that hack will have to go once
the AAPCS is implemented.