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

[Tejas Belagod <tejas dot belagod at arm dot com>]

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.

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.

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

> 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 :-).

Tejas.