> Looking at the generated code, I see references to __ARMEB__ and
__ILP32__.
> The former is probably a bug,
>>>
>>> Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__!
>>
>> Indeed:
>>
>> $ aarch64-linux-gnu-gcc -dM -E - <<<"" |grep AARCH
>> #define __AARCH64_CMODEL_SMALL_
>>> (+ Andy)
>>>
>>> ...
Looking at the generated code, I see references to __ARMEB__ and
>>> __ILP32__.
The former is probably a bug,
>>
>> Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__!
>
> Indeed:
>
> $ aarch64-linux-gnu-gcc -dM -E - <<<"" |grep AARCH
> #define _
On 13 November 2016 at 15:12, Andy Polyakov wrote:
>> (+ Andy)
>>
>> ...
>>>
>>> Looking at the generated code, I see references to __ARMEB__ and
>> __ILP32__.
>>> The former is probably a bug,
>
> Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__!
Indeed:
$ aarch64-linux-gnu-gcc -dM -E
> (+ Andy)
>
> ...
>>
>> Looking at the generated code, I see references to __ARMEB__ and
> __ILP32__.
>> The former is probably a bug,
Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__! Apparently I
simply went on assuming that it would be __ARMEB__/__ARMEL__ even in
64-bit case. As Ard
Hi Ard,
On Sat, Nov 12, 2016 at 01:32:33PM +0100, Ard Biesheuvel wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>
> Relative performance compared to the respective generic C versions:
>
>
