https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843
Alan Lawrence <alan.lawrence at arm dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alan.lawrence at arm dot com
--- Comment #8 from Alan Lawrence <alan.lawrence at arm dot com> ---
Passing a vector of one double as argument also ICE'd prior to this patch, so
no worries there. Likewise passing such a vector in as varargs.
Regarding struct layout:
*IIUC, gcc generally lays out structs in memory according to the sizes of the
data members, which hasn't changed.
*The AAPCS64 does not mention gcc vector extensions explicitly, only the
architectural concept of short vectors, but if we consider gcc vector
extensions as mapping to these short vectors (as they have done) - then there
is no dependency on gcc's concept of "mode".
*I've verified this with some by-hand testcases, using
typedef double gcc_vector_f64x1 __attribute__ ((__vector_size__ ((8))));
passing and returning by value
*a small struct of a single gcc_vector_f64x1
*a small struct of a char and a gcc_vector_f64x1
*a struct of four gcc_vector_f64x1's (classed as a Homogenous Vector
Aggregate)
....all passed in registers, and
*a large struct (of over 16 bytes, containing char, gcc_vector_f64x1, char,
gcc_vector_f64x2)
...written to memory and passing a pointer. Also explicitly passing pointers to
structs in memory. In all cases the layout (in registers/memory) is the same
regardless of whether we have V1DFmode or the gcc_vector_f64x1 is just assigned
BLKmode. (FWIW code generation is usually, tho not in all cases, better with
V1DFmode.)
Do you believe the ABI has changed, or are you merely concerned that it may
have? Whilst I can never claim my checks have been exhaustive, at this point I
don't see reason for concern.
