fenv on RISC-V

[Gedare Bloom]

On Wed, Aug 14, 2019 at 12:44 PM Joel Sherrill <joel at rtems.org> 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.
>

The test should not be disabled. The test should report a failure,
because the functionality is not implemented *but it could be.*

We should not be using the tcfg filtering simply to disable tests that
we know fail. As I understand it, the filter mechanism is mainly there
to help us with tests that can't be executed on the target due to some
missing resources e.g., insufficient memory, no cache, etc. Even
though no one implemented the support for soft-float, it could be
done, and a user might want to know that these tests fail for this
target.

This is not the first time I've noticed it mentioned to exclude tests
that we know fail, but there is a difference between something we know
is missing/never-to-be-implemented versus something that is impossible
to implement. We should exclude the latter, but fail on the former.

Gedare

> --joel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel