Re: Fix SPARC64 ICE in function_arg_slotno (PR 31070)

[Eric Botcazou <ebotcazou at adacore dot com>]

> This patch fixes the following test failures for sparc64-linux-gnu,
> making the test PASS on execution.
>
> FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o compile, 
> (internal compiler error) FAIL: tmpdir-g++.dg-struct-layout-1/t026
> cp_compat_y_tst.o compile,  (internal compiler error) UNRESOLVED:
> tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_tst.o link
> UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t026
> cp_compat_x_tst.o-cp_compat_y_tst.o execute

Thanks for tackling these long-standing failures.

> The problem argument has type struct S2400 { v8qi a; }, with a vector
> integer mode but a structure rather than a vector type, so the code
> causing vectors of integers to be handled like floating-point types
> doesn't come into play.  I couldn't find documentation of the ABI
> Sun's compiler might use in this case, or of the API for any Sun
> vector extensions we are trying to be compatible with, and don't have
> access to any such Sun compiler, but handling such structures in the
> structure case seems consistent with the comments in the SPARC back
> end: the structure element will be extracted and go through the
> processing done on elements of structures being passed as arguments,
> resulting in it being handled like a structure containing a
> floating-point value would be.
 
I think that it would be slightly more consistent to handle them like
struct S { int i; } or struct S { float f; }, which don't go through the 
MODE_RANDOM case in function_arg_slotno.  Would that also work?

-- 
Eric Botcazou