It seems like check_mathlib actually depends on the signature for exp being wrong to work correctly? Very strange.

If this is testa.c:

int exp (void); // some incorrect signature for `exp`
int main (void) {
  exp();
  return 0;
}

and testb.c:

double exp (double); // the correct signature for `exp`
int main (void) {
  exp();
  return 0;
}

then cc -c testa.c -o testa.o followed by cc testa.o -o testa fails, but if you link with -lm the linking works. On the other hand, when declared with the correct signature, it will link even without -lm.

Out of

MANDATORY_FUNCS = ["sin", "cos", "tan", "sinh", "cosh", "tanh", "fabs",
        "floor", "ceil", "sqrt", "log10", "log", "exp", "asin",
        "acos", "atan", "fmod", 'modf', 'frexp', 'ldexp']

if the wrong signatures are given, every single function requires -lm to link. However, with correct signatures, only log and fmod do. Does anyone understand this?!

On Mac, dynamic linking is failing with "Symbol not found: _npy_pow"
Cygwin also seems to be failing due to missing npy_pow symbol
On windows, TestSpecialFloats.test_arcsinh and TestSpecialFloats.test_arccosh fail, they expected nan but get +/-inf.

I think the windows second failure suggests that on windows:

1. for some reason my modification makes it detect that asinh and acosh aren't available
2. the fallback implementations of acosh and asinh handle nan slightly differently than the system math library implementations.

Does anyone understand this?!

Not really. Does it depend on compiler/version of compiler? I find the Compiler Explorer https://godbolt.org/ can be useful for things like this.

That old code hurts a little to look at. Changes are more verbose, but I don't see a problem merging them to improve WASM support - it won't really make build system migration more difficult.

A few other thoughts since I didn't look at this code in ages:

• The whole math library checking business will be replaced by 3 lines of code at some point: https://mesonbuild.com/howtox.html#add-math-library-lm-portably. Pretty sure the Compaq Portable Math Library is no longer a thing we have to care about:)
• Some of the functions in OPTIONAL_HEADERS can probably become mandatory, we can rely on C99 support (except for complex support in a few cases).
• A lot of stuff like the IEEE macros check hasn't been touched in 8 years, it's going to be fun deciding whether to replicate that or throw it all away.

On Mac, dynamic linking is failing with "Symbol not found: _npy_pow"
Cygwin also seems to be failing due to missing npy_pow symbol

Incidentally, I was also looking for npy_pow today, and couldn't find the source (commenting here because this is the only issue/PR that shows up by searching for it). I don't have full confidence that the GH code search finds all instances, but also locally I didn't get much more:

> findstr /L /S /N npy_pow numpy/*.*
numpy/core/include/numpy/npy_math.h:201:NPY_INPLACE double npy_pow(double x, double y);
numpy/core/include/numpy/npy_math.h:305:NPY_INPLACE float npy_powf(float x, float y);
numpy/core/include/numpy/npy_math.h:348:NPY_INPLACE npy_longdouble npy_powl(npy_longdouble x, npy_longdouble y);
numpy/core/src/npymath/npy_math_complex.c.src:422:/* private function for use in npy_pow{f, ,l} */
numpy/core/src/npymath/npy_math_internal.h.src:569:        return -npy_pow@c@(-x, 1. / 3.);
numpy/core/src/npymath/npy_math_internal.h.src:572:        return npy_pow@c@(x, 1. / 3.);
numpy/core/src/umath/scalarmath.c.src:419:    *out = npy_pow@c@(a, b);
numpy/core/src/umath/scalarmath.c.src:428:    const npy_float outf = npy_powf(af,bf);

@h-vetinari while there are some dummy fallback definitions (using double power), those are just aliases for the C power functions (they are C99, so they at least should always exist). I bet we don't need them. However, the ufunc, operator, and scalars may have their own paths (especially for integer powers) and to define fast-paths for certain powers.

However, the ufunc, operator, and scalars may have their own paths (especially for integer powers) and to define fast-paths for certain powers.

That's actually what I was trying to find out. I wanted to know how power is implemented to try to determine whether it would be more beneficial performance-wise to translate power(2, x) to exp(log(2) * x) (even though it's likely implemented like that...).

@h-vetinari there are some special paths for the operator **, trying the following:

The ufunc is "generated":

That is... If it is worthwhile.

Would appreciate if someone could review this @rgommers. We have merged exactly this patch into Pyodide
pyodide/pyodide#2256
so in addition to passing the CI here, it also works correctly in wasm as I asserted (previously we had a hack to disable the feature detection and hard code the results).

Could you add a note in doc/release/upcoming_changes? Look at other notes to see how that is done.

@charris How's this look?

Bumping this.

here is the rendered note.

Flaky test_vector_matrix_values on win32 failure not connected to this PR. Merging

Thanks @hoodmane

Thanks @mattip (and @charris, @rgommers)!

xref #21584 where these changes seem to cause some failure during detection of the required math functions (cos, etc.) on https://termux.com/.

I just read this article which suggests feature detecting as follows:

int main()
{
    double (*p)(const char *, char **, locale_t) = strtod_l;
}

Though this won't work if some toolchains define the function as a function-like macro.

Though this won't work if some toolchains define the function as a function-like macro.

The article seems to say that that's a feature - but it seems to me it's a problem, right?

To be fair I think neither the approach prior to this pr nor the one in this pr detect function-like macros. You would need to include the real headers for that.

But I don't think the linked article is very clearly written -- it doesn't have any examples so it's hard to know in what edge cases these approaches behave differently.