Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.

[Christophe Lyon <christophe dot lyon at linaro dot org>]

On 22 January 2015 at 12:19, Tejas Belagod <tejas.belagod@arm.com> wrote:
> On 21/01/15 15:07, Christophe Lyon wrote:
>>
>> On 19 January 2015 at 17:54, Marcus Shawcroft
>> <marcus.shawcroft@gmail.com> wrote:
>>>
>>> On 19 January 2015 at 15:43, Christophe Lyon <christophe.lyon@linaro.org>
>>> wrote:
>>>>
>>>> On 19 January 2015 at 14:29, Marcus Shawcroft
>>>> <marcus.shawcroft@gmail.com> wrote:
>>>>>
>>>>> On 16 January 2015 at 17:52, Christophe Lyon
>>>>> <christophe.lyon@linaro.org> wrote:
>>>>>
>>>>>>> OK provided, as per the previous couple, that we don;t regression or
>>>>>>> introduce new fails on aarch64[_be] or aarch32.
>>>>>>
>>>>>>
>>>>>> This patch shows failures on aarch64 and aarch64_be for vmax and vmin
>>>>>> when the input is -NaN.
>>>>>> It's a corner case, and my reading of the ARM ARM is that the result
>>>>>> should the same as on aarch32.
>>>>>> I haven't had time to look at it in more details though.
>>>>>> So, not OK?
>>>>>
>>>>>
>>>>> They should have the same behaviour in aarch32 and aarch64. Did you
>>>>> test on HW or a model?
>>>>>
>>>> I ran the tests on qemu for aarch32 and aarch64-linux, and on the
>>>> foundation model for aarch64*-elf.
>>>
>>>
>>> Leave this one out until we understand why it fails. /Marcus
>>
>>
>> I've looked at this a bit more.
>> We have
>> fmax    v0.4s, v0.4s, v1.4s
>> where v0 is a vector of -NaN (0xffc00000) and v1 is a vector of 1.
>>
>> The output is still -NaN (0xffc00000), while the test expects
>> defaultNaN (0x7fc00000).
>>
>
> In the AArch32 execution state, Advanced SIMD FP arithmetic always uses the
> DefaultNaN setting regardless of the DN-bit value in the FPSCR. In AArch64
> execution state, result of Advanced SIMD FP arithmetic operations depend on
> the value of the DN-bit i.e. either propagate the input NaN or generate
> DefaultNaN depending on the value of DN.

Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I
can see only the latter (no diff between aarch32 and aarch64 in
FPProcessNan pseudo-code)

> If you're running your test in the AArch64 execution state, you'd want to
> define the DN bit and modify the expected results accordingly or have the
> test poll at runtime what the DN-bit is set to and check expected results
> dynamically.
Makes sense, I hadn't noticed the different aarch64 spec here.

> I think the test already has expected behaviour for AArch32 execution state
> by expecting DefaultNaN regardless.
Yes.

>> I have executed the test under GDB on AArch64 HW, and noticed that fpcr
>> was 0.
>> I forced it to have DN==1:
>> set $fpcr=0x1000000
>> but this didn't change the result.
>>
>> Does setting fpcr.dn under gdb actually work?
>>
>
> It should. Possibly a bug, patches welcome :-).
>
:-)