> -----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?

Taylor

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

> -----Original Message-----
> From: Alex Bennée <alex.bennee@linaro.org>
> Sent: Thursday, February 3, 2022 2:00 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
> 
> 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.

How about this?
#if (defined (BYTE_ORDER) && BYTE_ORDER == BIG_ENDIAN) || (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__)

On 2/4/22 07:00, Alex Bennée wrote:
>>> 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?

I see you're not explicitly including <endian.h>.
I would expect that to be of some use.


r~