Interesting. I think we could add these as suggested, and also modify the default destructor to make sure this happens. (May also want ot add it to the divide function.) I'll want ot check this carefully, but I think we could put this into 1.9.2
Hi, and thanks for writing. That is really strange. You might well have identified it -- if you can't apply that path, then the command line might not be able to "find" your new compiler and associated dll files. At the command line, can you please type "g++ --version" and "make --version"? I'm curious what turns up. The other thing that can crop up is that after you edit the path / environment, you need to reopen any open shells / command prompts for it to take effect. Can you give me also a screencap...
Thanks, Randy. I think it's the "this CPU is too new for march=native to handle properly" error. Seems there was a bug in gcc prior to 8.4, and we're stuck at 8.1.0 in windows. Probably changing to skylake will fix, Or adding the flag: -fno-asynchronous-unwind-tables
For my own reference: https://github.com/numpy/numpy/issues/14787
(You'll want to do a make clean before retrying)
Thanks! (Awesome setup!) Huh, I wonder if march=native isn't able to correctly figure out your CPU. In your makefile, can you please try uncommenting out this line: ARCH := skylake
Hello! Could you please let us know what kind of CPU you are using? Also, can you run: make --version g++ --version And let's see what those report. This seems to me like a CPU architecture mismatch issue, but we can definitely work through it. Thanks!
If you feel that's the appropriate place, we can move it into main.cpp in version 1.8.1