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). 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? Christophe.
