On 22 January 2015 at 12:19, Tejas Belagod <tejas.bela...@arm.com> wrote: > On 21/01/15 15:07, Christophe Lyon wrote: >> >> On 19 January 2015 at 17:54, Marcus Shawcroft >> <marcus.shawcr...@gmail.com> wrote: >>> >>> On 19 January 2015 at 15:43, Christophe Lyon <christophe.l...@linaro.org> >>> wrote: >>>> >>>> On 19 January 2015 at 14:29, Marcus Shawcroft >>>> <marcus.shawcr...@gmail.com> wrote: >>>>> >>>>> On 16 January 2015 at 17:52, Christophe Lyon >>>>> <christophe.l...@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 :-). > :-)
