This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [arm patch]: Fix scalar-return-3
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Mon, 05 Jan 2004 10:15:58 +0000
- Subject: Re: [arm patch]: Fix scalar-return-3
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> Richard,
> this patch fixes scalar-return-3 in thumb mode. The problem is with
> returning a complex long long object.
>
> The arm backend returns non-aggregate types in registers, and gcc
> considers complex to be such a type. a complex long long requires
> four registers, and thus works for non-thumb, but fails in thumb
> mode were r3 is clobbered by the return code.
>
> The arm ABI does not specify what to do with such a type, as it
> only considers non-aggregate types of up to 64 bits (there being
> no larger type in ISO C).
>
> This patch is the least intrusive change in the ABI I could come
> up with. It changes the return mechanism only in thumb mode for
> those non-aggregates that are larger than 64 bits.
>
> built and tested with an arm-none-elf cross compiler in thumb mode.
>
> ok?
Sadly, no. The calling conventions for public interfaces *must* be the
same for both ARM and Thumb or interworking will not work.
There are two possible solutions to this problem that I can think of:
1) It ought to be possible to rewrite the Thumb return code so that it
doesn't need to clobber r3 (ok, it will be less efficient, but it only
need do that on rare occasions).
2) I'm not sure why this case isn't return-in-mem in the first place for
both ARM and Thumb -- making it so would make the problem go away.
However, I don't know if any important library functions would change if
we used solution 2. Maybe the correct thing to do is to adopt solution 1
for now.
The AAPCS is much more precise about how results are returned -- it
doesn't mention this particular case (though I could rectify that at the
next revision if necessary), but I still think it is sufficiently clear
that this case should be handled in the same way as an aggreate. When we
come to implement the AAPCS rules we will have to use solution 2.
R.