This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [arm patch]: Fix scalar-return-3


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]