Re: [RFC PATCH 0/4] improve coverage of vector backend

["Alex Bennée" <alex.bennee@linaro.org>]

Taylor Simpson <tsimpson@quicinc.com> writes:

>> -----Original Message-----
>> From: Alex Bennée <alex.bennee@linaro.org>
>> Sent: Thursday, February 3, 2022 12:26 PM
>> To: Taylor Simpson <tsimpson@quicinc.com>
>> Cc: richard.henderson@linaro.org; qemu-devel@nongnu.org; qemu-
>> arm@nongnu.org; fam@euphon.net; berrange@redhat.com;
>> f4bug@amsat.org; aurelien@aurel32.net; pbonzini@redhat.com;
>> stefanha@redhat.com; crosa@redhat.com
>> Subject: Re: [RFC PATCH 0/4] improve coverage of vector backend
>> 
>> > Any chance the problem is in the test itself (e.g., some sort of
>> > undefined behavior or a 64-bit vs 32-bit difference)?
>> 
>> It does have a 64 bit byteswap in - it's possible I broke it copying from the
>> upstream:
>> 
>>   https://ccodearchive.net/info/crypto/sha512.html
>> 
>> but it does pass on *all* the other architectures which is a mix of 32 and 64
>> bit code. I did have to hack the endian detection code though.
>> Does:
>> 
>>   #if BYTE_ORDER == BIG_ENDIAN
>> 
>> work for your compiler?
>
> No, but this does
> #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
>
> With that change in the source, the tests passes.  Will that work for
> other targets?

At least not hppa-linux-user. The joy of having no standard compile time
way to report byte order in the C standard despite most things needing
to know one way or another.

Richard,

Any ideas?

>
> Taylor


-- 
Alex Bennée