-
-
Notifications
You must be signed in to change notification settings - Fork 11k
1.16 maintenance branch fails tests on MSVC 2015 (VS2015 update 2) #12520
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Reproduces after deleting the |
Try undefining |
|
This perhaps resembles #7601 |
Doesn't help |
It's annoying that these problems are slipping through the CI testing. |
More updates:
|
I assume master is also broken? |
The commit I built was master in the very recent past. I also assume it is, but haven't gone as far as checking. |
1.15.4 is pretty old, there have been ~400 PR's since. The micro versions aren't new branches off master. |
Right - but 1.16.x is the branch that I'm reporting at the top of this PR, which is very recent. |
Yes, suggestions for preventing this are most welcome of course. It is, however, also true that it is quite easy to "break" NumPy while having the CI all green. Can we make the CI testing sensitive to this low-level issue in a straightforward way? What's happening on your machine that isn't happening in CI? |
#12411 failed on my machine but worked on azure because python and msvc are installed in a path with spaces on my machine.. Some possible causes of my floating point behavior differing from CI in this case:
Perhaps we should add |
Thanks Eric, I've made a note of these ideas; I can test a few on my fork to see if I can get reliable failures. |
That's what the |
@eric-wieser can you attach the |
Where can you even download msvc 2015? There used to be a link in https://visualstudio.microsoft.com/downloads/ -> All Downloads -> Other Tools, but it seems to be gone now |
Azure can pull in msvc 2015, but for Python 3.5 I see The image code is open source I think ( https://github.com/Microsoft/azure-pipelines-image-generation/blob/master/images/win/Vs2015-Server2012R2-Readme.md ) -- can perhaps grep around in that repo to find it. |
@eric-wieser can you check if adding an exception for that compiler to the loop in loops.c.src:1861 helps? I am not sure what path through the loop the cases take, perhaps it would be enough to disable the simd part of the loop. Note we had to work around a similar bug in #7678, here is the code that was added there
|
I tried inserting that pragma (as well as playing with diff --git a/numpy/core/src/umath/loops.c.src b/numpy/core/src/umath/loops.c.src
index f96e621b8..7a3824846 100644
--- a/numpy/core/src/umath/loops.c.src
+++ b/numpy/core/src/umath/loops.c.src
@@ -132,6 +132,20 @@
npy_intp i;\
for(i = 0; i < n; i++, ip1 += is1, ip2 += is2, op1 += os1)
+// https://github.com/numpy/numpy/issues/7601
+#if _MSC_VER == 1900
+ #define BINARY_LOOP_NO_VECTOR_MSVC_1900\
+ char *ip1 = args[0], *ip2 = args[1], *op1 = args[2];\
+ npy_intp is1 = steps[0], is2 = steps[1], os1 = steps[2];\
+ npy_intp n = dimensions[0];\
+ npy_intp i;\
+ __pragma(loop(no_vector)) \
+ for(i = 0; i < n; i++, ip1 += is1, ip2 += is2, op1 += os1)
+#else
+ #define BINARY_LOOP_NO_VECTOR_MSVC_1900 BINARY_LOOP
+#endif
+
+
/*
* loop with contiguous specialization
* op should be the code working on `tin in1`, `tin in2` and
@@ -1849,6 +1863,7 @@ NPY_NO_EXPORT void
}
}
+#pragma float_control(precise, on, push)
/**begin repeat1
* #kind = maximum, minimum#
* #OP = >=, <=#
@@ -1867,7 +1882,7 @@ NPY_NO_EXPORT void
}
}
else {
- BINARY_LOOP {
+ BINARY_LOOP_NO_VECTOR_MSVC_1900 {
@type@ in1 = *(@type@ *)ip1;
const @type@ in2 = *(@type@ *)ip2;
in1 = (npy_isnan(in1) || in1 @OP@ in2) ? in1 : in2;
@@ -1894,7 +1909,7 @@ NPY_NO_EXPORT void
*((@type@ *)iop1) = io1;
}
else {
- BINARY_LOOP {
+ BINARY_LOOP_NO_VECTOR_MSVC_1900 {
const @type@ in1 = *(@type@ *)ip1;
const @type@ in2 = *(@type@ *)ip2;
*((@type@ *)op1) = (npy_isnan(in2) || in1 @OP@ in2) ? in1 : in2;
@@ -1903,6 +1918,7 @@ NPY_NO_EXPORT void
npy_clear_floatstatus_barrier((char*)dimensions);
}
/**end repeat1**/
+#pragma float_control(pop)
NPY_NO_EXPORT void
@TYPE@_floor_divide(char **args, npy_intp *dimensions, npy_intp *steps, void *NPY_UNUSED(func))
@@ -2769,6 +2785,7 @@ NPY_NO_EXPORT void
}
}
+#pragma float_control(precise, on, push)
/**begin repeat1
* #kind = maximum, minimum#
* #OP = CGE, CLE#
@@ -2776,7 +2793,7 @@ NPY_NO_EXPORT void
NPY_NO_EXPORT void
@TYPE@_@kind@(char **args, npy_intp *dimensions, npy_intp *steps, void *NPY_UNUSED(func))
{
- BINARY_LOOP {
+ BINARY_LOOP_NO_VECTOR_MSVC_1900 {
@ftype@ in1r = ((@ftype@ *)ip1)[0];
@ftype@ in1i = ((@ftype@ *)ip1)[1];
const @ftype@ in2r = ((@ftype@ *)ip2)[0];
@@ -2799,7 +2816,7 @@ NPY_NO_EXPORT void
NPY_NO_EXPORT void
@TYPE@_@kind@(char **args, npy_intp *dimensions, npy_intp *steps, void *NPY_UNUSED(func))
{
- BINARY_LOOP {
+ BINARY_LOOP_NO_VECTOR_MSVC_1900 {
const @ftype@ in1r = ((@ftype@ *)ip1)[0];
const @ftype@ in1i = ((@ftype@ *)ip1)[1];
const @ftype@ in2r = ((@ftype@ *)ip2)[0];
@@ -2816,6 +2833,7 @@ NPY_NO_EXPORT void
npy_clear_floatstatus_barrier((char*)dimensions);
}
/**end repeat1**/
+#pragma float_control(pop)
#define @TYPE@_true_divide @TYPE@_divide |
Fixed via #12526 |
Uh oh!
There was an error while loading. Please reload this page.
On my windows 10 machine, I get a lot of NaN-based failures, with:
3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)]
Build logs
Minimal repro:
The text was updated successfully, but these errors were encountered: