Skip to content
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

DEP: drop support for msvc<=1900 and Interix #22139

Merged
merged 8 commits into from Aug 19, 2022
Merged
Show file tree
Hide file tree
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
5 changes: 5 additions & 0 deletions doc/release/upcoming_changes/22139.expired.rst
@@ -0,0 +1,5 @@
* Support for Visual Studio 2015 has been removed. Please update to at least
Visual Studio 2019.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're still building with vc141 and it is Visual Studio 2017 that defaults to that toolchain, I think that is what you want to say here. Otherwise, please make it explicit: you must use at least Visual Studio 2019 (then the first sentence should say 2017 not 2015), and you must use at least the vc141 compiler toolchain.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think mandating a lower bound that contains a non-default toolset makes little sense. Either vs2017+vc141 or vs2019+vc142.

In the previous discussions on this, one of the last relevant constraints for moving to vc142 (as I understood it) was conda-forge still being on vc141. That's being changed now, so from that POV - and as I understood it - a move to vc142 would be possible, notwithstanding that the CI isn't at that point yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think mandating a lower bound that contains a non-default toolset makes little sense. Either vs2017+vc141 or vs2019+vc142.

Agreed

That's being changed now, so from that POV - and as I understood it - a move to vc142 would be possible,

It's not, vc141 is a hard requirement until we get rid of SciPy depending on libnpymath at least.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's being changed now, so from that POV - and as I understood it - a move to vc142 would be possible,

It's not, vc141 is a hard requirement until we get rid of SciPy depending on libnpymath at least.

If this is about the mingw / gfortran interaction, the issue with the unknown assembly section can be solved with a single flag to the same effective level of (non-)support

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have a link for how to make the mingw-w64 toolchain work with vc142? I may have missed that part.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, see this comment and preceding discussion.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Support for the flag and vc142 was added in #21360. All of our windows CI jobs

vmImage: 'windows-2019'
and
- [windows-2019, win_amd64]
- [windows-2019, win32]
run on windows 2019 images with Visual Studio 2019. I would prefer not to recommend out-of-date software. I could just drop the whole sentence, recommendations are not really not part of a release note. The important part is that we are dropping <=2015

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

Copy link
Member

@rgommers rgommers Aug 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Support for the flag and vc142 was added in #21360.

Hmm, I just spent a lot of time doing archeology to determine exactly which versions to avoid for SciPy wheel builds because they were built with vc142 (answer: 1.21.4, 1.21.5, 1.22.0 and 1.22.1). If we now went back to vc142 again but with a different flag, it would be great to record that somewhere prominent (e.g., the release notes, or a central doc page), because next time it'll perhaps be even harder to figure out.

mattip marked this conversation as resolved.
Show resolved Hide resolved

* Support for the Windows Interix POSIX interop layer has been removed.

12 changes: 2 additions & 10 deletions numpy/core/include/numpy/npy_math.h
Expand Up @@ -219,11 +219,7 @@ double npy_spacing(double x);
#ifndef NPY_HAVE_DECL_ISNAN
#define npy_isnan(x) ((x) != (x))
#else
#if defined(_MSC_VER) && (_MSC_VER < 1900)
#define npy_isnan(x) _isnan((x))
#else
#define npy_isnan(x) isnan(x)
#endif
#define npy_isnan(x) isnan(x)
#endif
#endif

Expand All @@ -250,11 +246,7 @@ double npy_spacing(double x);
#ifndef NPY_HAVE_DECL_ISINF
#define npy_isinf(x) (!npy_isfinite(x) && !npy_isnan(x))
#else
#if defined(_MSC_VER) && (_MSC_VER < 1900)
#define npy_isinf(x) (!_finite((x)) && !_isnan((x)))
#else
#define npy_isinf(x) isinf((x))
#endif
#define npy_isinf(x) isinf((x))
#endif
#endif

Expand Down
8 changes: 0 additions & 8 deletions numpy/core/setup.py
Expand Up @@ -257,14 +257,6 @@ def check_complex(config, mathlibs):
priv = []
pub = []

try:
if os.uname()[0] == "Interix":
warnings.warn("Disabling broken complex support. See #1365", stacklevel=2)
return priv, pub
except Exception:
# os.uname not available on all platforms. blanket except ugly but safe
pass

# Check for complex support
st = config.check_header('complex.h')
if st:
Expand Down
6 changes: 3 additions & 3 deletions numpy/core/src/common/npy_config.h
Expand Up @@ -29,7 +29,7 @@
#endif

/* Disable broken MS math functions */
#if (defined(_MSC_VER) && (_MSC_VER < 1900)) || defined(__MINGW32_VERSION)
#if defined(__MINGW32_VERSION)

#undef HAVE_ATAN2
#undef HAVE_ATAN2F
Expand All @@ -41,7 +41,7 @@

#endif

#if defined(_MSC_VER) && (_MSC_VER >= 1900)
#if defined(_MSC_VER)

#undef HAVE_CASIN
#undef HAVE_CASINF
Expand Down Expand Up @@ -71,7 +71,7 @@
#endif

/* MSVC _hypot messes with fp precision mode on 32-bit, see gh-9567 */
#if defined(_MSC_VER) && (_MSC_VER >= 1900) && !defined(_WIN64)
#if defined(_MSC_VER) && !defined(_WIN64)

#undef HAVE_CABS
#undef HAVE_CABSF
Expand Down
8 changes: 4 additions & 4 deletions numpy/random/src/pcg64/pcg64.h
Expand Up @@ -128,7 +128,7 @@ static inline pcg128_t pcg128_add(pcg128_t a, pcg128_t b) {
static inline void _pcg_mult64(uint64_t x, uint64_t y, uint64_t *z1,
uint64_t *z0) {

#if defined _WIN32 && _MSC_VER >= 1900 && _M_AMD64
#if defined _WIN32 && _M_AMD64
z0[0] = _umul128(x, y, z1);
#else
uint64_t x0, x1, y0, y1;
Expand Down Expand Up @@ -182,7 +182,7 @@ static inline void pcg_setseq_128_srandom_r(pcg_state_setseq_128 *rng,

static inline uint64_t
pcg_setseq_128_xsl_rr_64_random_r(pcg_state_setseq_128 *rng) {
#if defined _WIN32 && _MSC_VER >= 1900 && _M_AMD64
#if defined _WIN32 && _M_AMD64
uint64_t h1;
pcg128_t product;

Expand Down Expand Up @@ -212,7 +212,7 @@ static inline pcg128_t pcg128_mult_64(pcg128_t a, uint64_t b) {
}

static inline void pcg_cm_step_r(pcg_state_setseq_128 *rng) {
#if defined _WIN32 && _MSC_VER >= 1900 && _M_AMD64
#if defined _WIN32 && _M_AMD64
uint64_t h1;
pcg128_t product;

Expand Down Expand Up @@ -255,7 +255,7 @@ static inline uint64_t pcg_cm_random_r(pcg_state_setseq_128* rng)
hi *= lo;

/* Run the CM step. */
#if defined _WIN32 && _MSC_VER >= 1900 && _M_AMD64
#if defined _WIN32 && _M_AMD64
uint64_t h1;
pcg128_t product;

Expand Down