On Wed, Jul 9, 2014 at 12:02 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote:
> Hello,
>
> the implementation of homogenous float aggregates for the ELFv2 ABI has
> unfortunately shown to have a bug in a corner case.
>
> The problem is that because such aggregates are packed in the argument
> save area, but each (4-byte) float occupies one of just 13 registers
> on its own, we may run out of registers while we're still within the
> first 64 bytes of the argument save area.
>
> Usually, any argument that doesn't fit into register should go in
> memory. But that rule doesn't apply within the first 64 bytes, where
> such arguments need to go into GPRs first. This is important since
> the ABI guarantees that the first 64 bytes of the save area are free,
> e.g. to store GPRs into. If an argument is actually passed within
> those first 64 bytes, some code (e.g. libffi assembler stubs) may
> clobber its contents.
>
> Now, the existing rs6000_function_arg code will handle this case
> correctly if the extra floats come in a *new* argument. For example,
> in the following test case
>
> struct float2 { float x[2]; };
> struct float6 { float x[6]; };
> struct float8 { float x[8]; };
>
> float func (struct float8 a, struct float6 b, struct float2 c);
>
> both parts of "c" are correctly expected in r10.
>
> However, the code handles incorrectly the case where a *single*
> aggregate argument is split between FPRs and "extra" floats.
> For example, "b.x[5]" is expected in memory, although it ought
> to reside in r9.
>
> The appended patch fixes the implementation to comply with the ABI.
>
> This is an ABI change for the affected corner cases of the ELFv2
> ABI. However, those cases should be extremely rare; the full
> compat.exe and struct-layout-1.exp ABI compatibility test suite
> passed, with the exception of two tests specifically intended
> to test multiple homogeneous float aggregates.
>
> Tested on powerpc64le-linux.
>
> OK for mainline?
> [ The patch should then also go into the 4.8 and 4.9 branches for
> consistency. ]
Okay everywhere.
Thanks, David
