Quoting emscripten documentation:

> Function pointers must be called with the correct type: it is undefined
> behavior in C and C++ to cast a function pointer to another type and call it
> that way. This does work in most native platforms, however, despite it being
> UB, but in asm.js and in wasm it can fail.

Unfortunately, Python code exploits this behaviour quite a lot.

FuncCastEmulation is a wasm-opt pass that helps bypass this issue by
redefining every function to take a fixed number of i64s, and then manually
converting the arguments to feed into the original function.

To do so, the fixed number of i64s must be at least the number of actual
arguments our functions take, and binaryen decided that 16 is enough for
everyone. Turns out scipy has functions that take in a huge number of
arguments, so we bump it up to 61.

An upstream patch has been submitted and accepted that makes this number
configurable at runtime, and should be present in binaryen version_99:
https://github.com/WebAssembly/binaryen/pull/3411

--- a/emsdk/binaryen/src/passes/FuncCastEmulation.cpp	2019-04-03 11:30:13.556074729 -0400
+++ b/emsdk/binaryen/src/passes/FuncCastEmulation.cpp	2019-04-03 11:30:32.817143862 -0400
@@ -39,7 +39,7 @@
 // This should be enough for everybody. (As described above, we need this
 // to match when dynamically linking, and also dynamic linking is why we
 // can't just detect this automatically in the module we see.)
-static const int NUM_PARAMS = 16;
+static const int NUM_PARAMS = 61;   // needed by scipy.odr._odrpack
 
 // Converts a value to the ABI type of i64.
 static Expression* toABI(Expression* value, Module* module) {