Repository navigation
Compiling numpy 1.17 on cygwin fails with `Error: invalid register for .seh_savexmm #14787
Description
Activity
Sounds like a hardware detection or compiler problem. What GCC version do you have? Are you running 32 or 64 bits?
64-bit Cygwin with GCC 8.3.0.
Numpy 1.17.3 installs fine on 32-bit Cygwin with gcc 7.4.0 and python 3.6.9
Installing numpy 1.17.3 from source with pip on 64-bit WSL-debian using python 3.7.3 and gcc 8.3.0 worked fine.
All trials here were on the same machine.Running git bisect points to the following commit:
651e03c0019d4c4c6ca8c43cb7d7c0d344a72cc1 is the first bad commit commit 651e03c0019d4c4c6ca8c43cb7d7c0d344a72cc1 Author: Raghuveer Devulapalli Date: Thu Mar 28 15:07:35 2019 -0700 BUG: Adding macro HAVE_ATTRIBUTE_TARGET_@ISA@_WITH_INTRINSICS 1) use __builtin_cpu_supports("avx512f") only for gcc ver >= 5 2) Introduced two new macro's: HAVE_ATTRIBUTE_TARGET_@ISA@_WITH_INTRINSICS for ensuring compiler can compile functions that use intrinsics and are compiled with avx2/avx512f attributes :040000 040000 17c469bd32baf93f8306d76ea3d7bcec9b98f286 5c129001b713ed2edf09f2e98c8c0fa61316d985 M numpy bisect run successI restricted attention to
numpy/core/src/umath/loops.c.src, so it might also be a tad before this commit.What is your cpu? I think this is a compiler/configuration problem. Are you running in a virtual environment by any chance.
No virtual environment, Intel core i5.
/proc/cpuinfolistsavx2but notavx512f. I think the chip is 6th generation/Skylake. Manually running the probes for avx2 and avx512f target attribute support both succeed.In order to freeze the build, you can do this, the
-bshould then have the results of the failed build.python3 -m pip install numpy==1.17.3 -b /tmp/numpyThis stack overflow suggests adding
-fno-asynchronous-unwind-tables. You could try just running the line that fails once with that flag and once withoutThank you,
-fno-asynchronous-unwind-tablesfixed it. I'll report back once the tests have run.According to gcc bug report, it has not been fixed. We could add the flag unconditionally when cygwin is detected, but then it would get lost inside distutils and we would not know to update it when gcc fixes the problem.
Should we add a config test for the need for this flag, which is what I did last time I got a compiler bug?
sure, maybe we should have done that with the -std=c99 fix as well. It is a flag, not a "HAVE" test. Where would we add that?
Hmm, I hadn't thought of that. This is the change I'd made before I was thinking about: https://github.com/numpy/numpy/pull/13739/files#diff-33315af1a22893e97676ee134db5ce1cR466-R471
We could some new
moredefs.append('NPY_DO_NOT_OPTIMIZE_XXX'). While I don't think we should add a cygwin Azure run, maybe I can set up an environment somewhere- NumPy 1.17.5 is compiling and has no new test failures compared to 1.16.6. I did have to move a few "#include <Python.h>" lines before system includes so it could define "_GNU_SOURCE" before "#include"ing system headers. I will submit those as a separate pull request if I still need to do that for "master".
I got 1.18.4 to pass all tests expected, with
CFLAGS="-fno-asynchronous-unwind-tables -ffixed-xmm16 -ffixed-xmm17 -ffixed-xmm18 -ffixed-xmm19 -ffixed-xmm20 -ffixed-xmm21 -ffixed-xmm22 -ffixed-xmm23 -ffixed-xmm24 -ffixed-xmm25 -ffixed-xmm26 -ffixed-xmm27 -ffixed-xmm28 -ffixed-xmm29 -ffixed-xmm30 -ffixed-xmm31"I think I also tested it with just the
-ffixed-xmm16-30flags, and that also worked.
I'll get my environment set up to submit the patches for that to work: I'm not sure where I would add the flags.I forgot to pass the flags when testing a PR, so apparently this is gone. The GCC bug report above now says "fixed", so I'm not sure whether it's GCC or NumPy that did something to make this go away.
Current NumPy master (will be 1.19) on 64-bit Cygwin 3.1.4 with GCC 9.3.0.
1.17.3 compiles just fine now as well, so I'm suspecting this is a GCC fix.
- added a commit that references this issue
on Oct 14, 2020
Attempting to install numpy 1.17.3 on cygwin fails, with the only reported error message being
invalid register for .seh_savexmm.I can't figure out where this would be getting called, since the reported file is
standard inputand grepping the source forsavexmmdoes not produce any obvious clues.Reproducing code example:
Error message:
Error message on third and subsequent compilations
The first and second compilations produce different output before the block of errors, but are otherwise identical.
Numpy/Python version information:
Compiling numpy 1.17.3 on python 3.5.7 fails as described above.
Compiling numpy 1.17.0 on python 3.7.4 fails in the manner described above.
Numpy 1.16.5 built just fine and passed most tests.
How would I go about debugging this?