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
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
> specification correctly. For example, the
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 t
On 14/10/11 11:42, Julian Brown wrote:
> On Thu, 13 Oct 2011 16:12:17 +0100
> Richard Earnshaw 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
On Thu, 13 Oct 2011 16:12:17 +0100
Richard Earnshaw 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 the target-
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 vect
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 c
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 e
