Will try checking this out locally and seeing if it solves my problem tomorrow.

Yeah, this fixes the problems I was having. Running the full test suite now, but I'm expecting a pass

Yeah, this fixes everything for me.

It might still be worth holding off on merging this until we can reproduce the failure in CI

Thanks for checking. Added a comment so this hopefully won't happen again

What is even more confusing is that AFAICT Visual Studio 2015 uses Visual C++ 14.0 compiler, but so does Visual Studio 2017? The information on the python windows compiler page is confusing. What exact version of cl do you have?

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23918 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

It looks like I have the complete VS2015 Update 2 installation.

When we merge this, we should:

• Squash the commits so that a git blame shows the comment and code as the same change
• Include the text gh-12520 in the commit message, to help anyone using blame find the thing we're trying to work around.

It looks like I have the complete VS2015 Update 2 installation.

According to wikipeida, there was update 3 in June 2016. Is there a reason you cannot update?

Nope, no reason I cannot update - but if the resolution is "update 3 or newer required", then we should blacklist my compiler version

I think we are done. We have a workaround for your (assumed broken) compiler, I would prefer not to add a CI run for a niche compiler. Do we have a mechanism to blacklist compilers, other than documenting the situation?

I would prefer not to add a CI run for a niche compiler

Fair enough, saves me some work, but in that case I would prefer either:

1. Robustly detect and blacklist the compiler
2. Come up with a (likely creative) unit test for reproducing / preventing regression

Come up with a (likely creative) unit test for reproducing / preventing regression

Such a unit test already exists, which is how we found this in the first place

Robustly detect and blacklist the compiler

I feel like config.h holds the secret to detecting this kind of thing (by compiling and running a dummy program at build time).

Sorry, by creative I meant a test that will cause a failure with compilers currently used in CI unless the fix is applied. But yeah, I guess putting some kind of dummy code that will fail for the offending compiler is probably an order of magnitude less ugly & does the job of failing early / reproducibly instead of build successfully and then maybe only failing an isolated unit test.

I suppose the dummy code could even suggest the reason for a specific failure, although I don't know offhand if we annotate that stuff.

Is this still WIP ?

The fix itself is good to go. The remaining question is how much energy we should invest in making sure the problem does not repeat by crafting a stand-alone test for faulty compilation at build time, to let a potential user know early that their build will give wrong results. I am of the opinion we do not need to do anything further, this should just be merged as-is, and users of these kinds of compilers should be running the test suite which would detect the problem.

Let's put this in. The fact that such a new compiler can cause problems is disturbing, but it seems we have a workaround. I'll tag this with the compiler label.

Does this mean that the invalid value bit is getting set by some platforms?

Hmm, I think @charris has a point - don't we have to go back to explicitly clearing the invalid bit again?

I did not remove the existing call to npy_clear_floatstatus_barrier on lines 1879, 1907 and 1065. Without those we would have seen warnings in the tests.

Huh, I thought we did the initial reordering in order to eliminate those. Guess that's what happens when I respond from mobile. Thanks for fixing this for me, anyway!