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

[Zong Li <zongbox at gmail dot com>]

> > 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).
>

I can't find the bug because there are some math cases failed, and
this bug was submerged in these fail cases. I will test these macros
manually on next version.