Having said that, I will check if the generation of FP exception flag for RISC-V in sis are as accurate as for SPARC. Generating the wrong flags could cause the type of failures we are seeing ...
On 8/14/19 10:42 PM, Jiri Gaisler wrote: > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel