fmod nan_mix usage

[enh]

On Wed, Jul 25, 2018 at 12:34 AM Bruce Evans <brde at optusnet.com.au> wrote:

> On Mon, 23 Jul 2018, enh wrote:
>
> > On Mon, Jul 23, 2018 at 12:54 PM Bruce Evans <brde at optusnet.com.au>
> wrote:
> > ...
> > bionic doesn't have as many as it should, though i do add them any time
> we
> > catch a regression. all our tests are in
> > https://android.googlesource.com/platform/bionic/+/master/tests/ with
> > complex_test.cpp and math_test.cpp being the interesting ones.
> > (complex_test.cpp is laughably perfunctory right now, but sadly *did*
> catch
> > bugs where historically the makefiles were broken and we weren't shipping
> > all the functions for all the architectures.)
>
> Are most of your systems arm?


to a first-order approximation, pretty much all Android devices run arm
code (even the x86-based ones, via binary translation!). about half also
run arm64. x86/x86-64 is mostly used for the emulator (because that's what
everyone's desktop/laptop is, and virtualization gets you a ridiculously
fast emulator).


>   I think libm doesn't get much testing on arm
> in FreeBSD (I have never even run cc on an arm system), so it especially
> useful to have tests for it on other systems.  This also partly explains
> why my recent tests didn't see the bug -- x86 has fmod, remainder and
> remquo in asm or builtins so the C versions are not normally used.  Maybe
> arm should have a bit more in asm or builtins.
>

in bionic we've actually been trying to encourage them to fix clang to use
intrinsics, and then -- where clang can produce equivalent code -- we
replace our .S files with something like `T f(T x) { return __builtin_f(x);
}`. that way, sure, we get good code in libm, but far more importantly
callers get to skip libm entirely and just get a single instruction inlined.

(bionic's tests are then full of the usual tricks to ensure that we
actually call the libm functions.)


> > ...
>
> >>> it looks like e_remainder.c might have the same issue, but Android's
> >> tests
> >>> didn't catch that :-( i'll improve the tests...
> >>
> >> Indeed.  Also remquo* and ctanh* :-(.  ctanh* should be more like csinh*
> >> and ccosh*, and it was.
> >
> > yeah, i caught remquo after i hit send (and have just uploading a CL with
> > the missing tests). i'm glad to hear that ctanh* actually works because
> i'd
> > failed to break it :-) i'll commit those extra tests too anyway.
>
> ctanh* turned out to not need multiplicative NaN mixing.  It is both more
> complicated and simpler than ccosh* and csinh*, since it has more
> complicated
> expressions so needs more special cases for exceptional args, but then the
> individual cases are simpler.
>
> >...
> >> The only other complicated case seems to be hypot[fl]().  This subtracts
> >> instead of adds, since it wants to convert Inf-Inf to NaN.
> >
> > hypot seems okay from my testing. am i missing another test?
>
> It passes my tests too, but uses a complicated method to pass.  I first
> noticed difference related to precisions with it, and fixed them less
> systematically than with nan_mix*.  I think it only uses subtractive
> mixing because that worked to preserve the arg order in SSE because
> SSE doesn't have reverse subtraction.  That is too special.
>
> Bruce
>