On Thu, 13 Oct 2011 16:12:17 +0100
Richard Earnshaw rearn...@arm.com wrote:
On 13/10/11 15:56, Joseph S. Myers wrote:
Indeed, vector initializers are part of the target-independent GNU
C language and have target-independent semantics that the elements
go in memory order, corresponding to
On 14/10/11 11:42, Julian Brown wrote:
On Thu, 13 Oct 2011 16:12:17 +0100
Richard Earnshaw rearn...@arm.com wrote:
On 13/10/11 15:56, Joseph S. Myers wrote:
Indeed, vector initializers are part of the target-independent GNU
C language and have target-independent semantics that the elements
On Fri, 14 Oct 2011, Julian Brown wrote:
* The vectorizer can use whatever layout it wants for vectors in
either endianness. Vectorizer vectors never interact with either
GCC generic (source-level) vectors, nor the NEON intrinsics. Also
they never cross ABI boundaries.
I don't
On 14/10/11 16:21, Joseph S. Myers wrote:
On Fri, 14 Oct 2011, Richard Earnshaw wrote:
One way we might address this is to redefine our 128-bit vector types as
structs of low/high Dwords. Each Dword remains a vector (apart from
64-bit lane types), but the Dword order then matches the ABI
On 13/10/11 00:21, Janis Johnson wrote:
Tests gcc.target/arm/pr48252.c and gcc.target/arm/neon-vset_lanes8.c
expect little-endian code and fail when compiled with -mbig-endian.
This patch skips the test if the current multilib does not generate
little-endian code.
I'm not able to run
On Thu, 13 Oct 2011, Richard Earnshaw wrote:
2) Change the compiler to make initializers of vectors assign elements
of initializers to consecutive lanes in a vector, rather than the
current behaviour of 'casting' an array of elements to a vector.
While the second would be my preferred
On 13/10/11 15:56, Joseph S. Myers wrote:
On Thu, 13 Oct 2011, Richard Earnshaw wrote:
2) Change the compiler to make initializers of vectors assign elements
of initializers to consecutive lanes in a vector, rather than the
current behaviour of 'casting' an array of elements to a vector.
Tests gcc.target/arm/pr48252.c and gcc.target/arm/neon-vset_lanes8.c
expect little-endian code and fail when compiled with -mbig-endian.
This patch skips the test if the current multilib does not generate
little-endian code.
I'm not able to run execution tests for -mbig-endian for GCC mainline
