[SciPy-Dev] win32 binaries and scipy 0.17.0 release

[Nathaniel Smith]

On Sat, Jan 2, 2016 at 5:54 PM, Tony Kelman <tony at kelman.net> wrote:
> Nathaniel Smith <njs <at> pobox.com> writes:
>
>> "don't use x87" is a great option. It's just that if you want to do
>> that, then someone has to do the work to rewrite the code in openlibm
>> that currently uses x87 . E.g. here's openlibm's x86 "sin"
>> implementation, based around the x87 "fsin" instruction:
>>   https://github.com/JuliaLang/openlibm/blob/master/i387/s_sin.S
>
> Interesting, but that file isn't getting built in the current makefiles.
> We're using the C implementation in https://github.com/JuliaLang/openlibm
> /blob/0036d707347b27c580bf25c28cfc43dcbe412437/src/s_sin.c at the moment.
> Ref https://github.com/JuliaLang/openlibm/issues/11

Oh interesting!

>> Compare to the x87-free implementation in bionic (using SSE):
>>   https://github.com/android/platform_bionic/blob/master/libm/x86/s_sin.S
>
> Benchmarking openlibm vs bionic is certainly worth doing. I'll bug my
> neighborhood math-functions-implementation-anorak about it some time.
>
>> Note that I haven't actually tested openlibm in MSVC-compatible mode,
>> so it might be fine; I just wouldn't trust it without testing it
>> first, and I doubt anyone has tried.
>
> We should do this. What exactly do you mean here by "MSVC-compatible
> mode?" Just using mingwpy and linking against a versioned (or universal)
> crt? If you build with mingwpy you're still using the GNU assembler aren't
> you? Tranlating all of openlibm's assembly into Intel syntax so ml64.exe
> can understand it has been present but very low on my to-do list.

This is orthogonal to the CRT issue.

By default, all mingw-w64-compiled DLLs have some startup code that
unconditionally resets the current thread's x87 control word to enable
extended precision. Altering global environment state like this is
very dubious behavior in a program that uses a mix of
mingw-w64-compiled code and non-mingw-w64-compiled code, and can also
cause other weird issues. (Example: if you call mingw-w64 compiled
code from a thread that was spawned by MSVC-compiled code, then it
might give the wrong result, even though the same code works when
invoked from the main thread or a thread spawned from mingw-w64
compiled code, because the mingw-w64 thread spawning functions take
care to set up 80-bit precision in x87 control word in the new thread,
while the vanilla Windows thread spawning functions don't bother and
leave you with the default 64-bit precision. Basically it's a huge
headache.)

mingw-w64 does have an upstream-supported way to disable this
behavior, to make it act like MSVC: you make sure to link the
CRT_fp8.o object (which is included in mingw-w64 toolchains) into your
build. Unfortunately I can't give you any more detailed instructions
than that, but maybe that's a useful clue to start with :-).

(You might also want -mlong-double-64, since mingw-w64's default
80-bit long double is definitely not going to work in this
configuration.)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org