This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, ARM] Constant vector permute for the Neon vext insn


On 08/27/2012 08:02 AM, Christophe Lyon wrote:
> [ Richard, sorry for the duplicate message where I omitted the mailing-list]
> 
> On 24 August 2012 10:40, Richard Earnshaw <rearnsha@arm.com> wrote:
>>
>> Has this been tested for big-endian?
>>
> 
> Hi,
> While improving my tests and trying to turn them into execution tests,
> I realized that vector initialization such as:
>   uint16x4_t vec1 = {0x1234, 0x5678, 0x9abc, 0xdef0};
> is endianness dependent.
> 
> However, I have noticed that other tests (such as neon-vrev.c,
> neon-vset_lanes8.c, pr48252) do use such constructs.... and the last
> two ones fail at execution in big-endian mode (the 1st one is only
> compiled).
> 
> I guess that the 'right' (portable) was of initializing a vector is to
> load it from an array, right?

See http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01114.html for Richard
Earnshaw's suggestion on how to fix neon-vset_lanes8.c, and an alternate
suggestion for changing the compiler.

Janis


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]