fenv on RISC-V

[Chris Johns]

On 16/8/19 1:38 am, Gedare Bloom wrote:
> 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.

Well said and 100% correct.

I am considering a tool that helps us manage these settings. My hope is that may
generate some more activity in this area.

Chris