Re: [PATCH v2 10/12] soft-fp: Add the lack of implementation for 128 bit

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 19 Jul 2018, DJ Delorie wrote:

> > +      r2 -= __FP_FRAC_SUB_8_c4;                                         \
> > +      r2 -= __FP_FRAC_SUB_8_c5;                                         \
> > +      r2 -= __FP_FRAC_SUB_8_c6;                                         \
> 
> Should these be r4, r5, r6, and r7 ?
> 
> Do we know if this code ever gets tested with our testsuite?  Since
> these are new macros, I'd expect a new test to go with them...

We don't have any unit tests for soft-fp.  It wouldn't be impossible to 
write such tests (tests that test different things sfp-machine.h can do, 
rather than testing a particular machine's sfp-machine.h implementation; 
tests that work for testing most of extended.h and quad.h even on systems 
without the relevant machine modes), but it would be a large project.  
There's soft-fp/testit.c, but nothing runs it, it's only designed to test 
libgcc functions and it doesn't test very much.

So soft-fp testing is effectively through running the glibc testsuite for 
functionality using the soft-fp code (of course sometimes this is really 
testing the libgcc copy of soft-fp, if e.g. testing most float128 libm 
functions on x86_64).  This is actually pretty thorough at finding soft-fp 
problems.  Unfortunately the RV32 port submission just asserted the 
presence of math/ test failures without giving any details, so it's 
entirely possible the issue you identified actually showed up as test 
failures for fmal that were then dismissed as irrelevant.  (No functions 
other than fmal for systems with 32-bit _FP_W_TYPE and using 
sysdeps/ieee754/soft-fp/s_fmal.c would exercise this code.  Probably x86 
*should* be using it for fmaf128, as a direct soft-fp implementation of 
fmaf128 should be faster than the ldbl-128 implementation involving lots 
of calls to separate float128 operations all implemented separately using 
soft-fp in libgcc.)

I used the glibc testsuite to test updates to the Linux kernel copy of 
soft-fp, where it's also pretty effective at finding kernel emulation 
issues (if you're testing glibc in a configuration where it uses 
instructions that in turn use kernel emulation).  Unfortunately that 
series has been in limbo since 2015 (powerpc kernel maintainers accepted 
it for a tree they intended to propose for a then-near-future merge 
window, but nothing further happened after that to actually get it into 
Linus's tree).

-- 
Joseph S. Myers
joseph@codesourcery.com