Interesting. I can confirm that the griscv bsp is using hard floats and doubles, it is compiled with -march=rv32imafd -mabi=ilp32d. The paranoia benchmark runs successfully and uses float instructions and registers. The sis simulator emulates all float and double instructions as define in the RISC-V specification. So the failures in psxfenv01 are likely be due to some gcc/newlib limitations or possibly some shortcomings in the RTEMS RISC-V port.
Jiri. On 8/14/19 8:44 PM, Joel Sherrill wrote: > Hi > > I emailed Jim Wilson of SiFive and got a quick response. Much thanks > to him and this is his reply: > > ================== > I don't have any embedded hardware that I can use for testing. I just > have linux and simulators (qemu, gdb sim). I haven't seen gcc > testsuite failures related to fenv, but not sure if those tests are > being run for embedded elf targets. The testcase doesn't work with > gdb sim, probably a gdb sim bug. It does work with qemu, but only if > I use a -march that has FP support. Checking the code, it looks > pretty obvious, fegetexceptflag for instance is > > int fegetexceptflag(fexcept_t *flagp, int excepts) > { > #if __riscv_flen > ... > #endif > return 0; > } > > __riscv_flen is the number of bits (bytes?) in the FP registers, and > is zero if this is target has no FP support. So fenv for soft-float > targets hasn't been implemented. Was probably implemented for hard > float targets because it is easy, we just directly read/write the fp > status register. > > feraiseexcept isn't fully supported, but that seems to be a standards > interpretation question. RISC-V hardware doesn't have a way to > automatically trap when an exception is raised. We can only set a bit > in the fp status register and something else needs to check that and > trap. So is feraiseexcept full implemented if we set the bit but > don't trap? Newlib says no. Glibc says yes. But glibc has > feenableexcept and FE_NOMASK_ENV. Newlib does not. So on RISC-V, all > exceptions are masked, and that can't be changed. > ================== > > This test (and fenv in general) is unlikely to work on an target with > soft float per Jim and some newlib discussions. On those BSPs, > it may have to be marked as NA with a comment about soft float. > Unless the test is automatically disabled if the CPU_HARDWARE_FP > define in RTEMS is false. But this is always defined to FALSE on risc-v. > > Q: Is hardware FP even supported right now on RISC-V? I don't see the > context switch code assuming there are registers to switch. > > And as Jim notes, even on some hardware targets (yes RISC-V), some > things don't work. > > So let's try this on a HW FP target and see if the works. > > Then address how to automatically disable this test with fall back to > updating a lot of .tcfg files. > > --joel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel