I'm going to ping @rgommers here.

Do we test clang properly in CI?

We'll only be testing it on macOS I believe. So it depends, if it's a simple flag that may be enough.

Perhaps @r-devulap can check. I'd be more comfortable if the other workarounds hadn't been removed, we want to be sure this works first.

I was going through the details of #13623 and looks like that was bug on a specific version of clang and might have nothing to do with enforcing strict floating point compliance. I think I agree with @charris, I would keep the workarounds. They are pretty harmless anyway.

Adding the ffp-exception-behavior=strict flag should prevent such problems in the future. +1 to that.

Yeah, reverting those changes was too optimistic. Removed it.

Thanks Sebastian.

This seems to break scipy build on windows ☹️ and breaks the build surprisingly and exactly at the same place that #18295 fixed. I don't have the beginning of the log but it seems like it is early enough for the meat of it. I'm using OpenBLAS 0.3.15, Python 3.9.2 and latest Numpy on master. Dissected on the distutils commits and it is indeed this one starts coughing.

Pinging @mckib2 as maybe he can recognize something relevant

build.log

This seems to break scipy build on windows

Strange, the new flag addition should not even take place. The problem seems to be undefined reference to 'xerror_'. Can you put some print statements in the change to see what might be going on? Is it still an error if the if is explicitly False?

My bad, everything was scrambled because I still worked with master while the fixes went into main, so in my script then hell broke loose. Because dissect works with commit numbers regardless of the branch name.

Sorry for the noise.

@ilayn Is this still a problem or did switching to main resolve the build problems?

All good after fixing the branches and commits

@rgommers, I just noticed on another PR this build log: https://dev.azure.com/numpy/27346c6a-2774-4eac-bf85-e068127c0ccc/_apis/build/builds/18280/logs/57

Which does not include exception-behavior anywhere, but it probably has to? So that this code doesn't actually work/do anything?

Argh, this is why I'm working so hard on a new build system - so we can stop trying to debug the current one.

Guess I didn't read the PR description - review made sense, but no one actually tested it.

Maybe I did test, can't remember. The code path does get hit, but only once in the "test compile" stage and once when compiling numpy extensions (in the customize UnixCCompiler stage):

creating build/temp.macosx-10.9-x86_64-3.9/numpy/random
creating build/temp.macosx-10.9-x86_64-3.9/numpy/random/src
creating build/temp.macosx-10.9-x86_64-3.9/numpy/random/src/distributions
compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Ibuild/src.macosx-10.9-x86_64-3.9/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Users/rgommers/mambaforge/envs/scipy-dev/include/python3.9 -Inumpy/core/src/common -Inumpy/core/src/npymath -c'
extra options: '-msse -msse2 -msse3'
x86_64-apple-darwin13.4.0-clang: numpy/random/src/distributions/logfactorial.c
x86_64-apple-darwin13.4.0-clang: numpy/random/src/distributions/distributions.c
x86_64-apple-darwin13.4.0-clang: numpy/random/src/distributions/random_mvhg_marginals.c
x86_64-apple-darwin13.4.0-clang: numpy/random/src/distributions/random_mvhg_count.c
x86_64-apple-darwin13.4.0-clang: numpy/random/src/distributions/random_hypergeometric.c
x86_64-apple-darwin13.4.0-ar: adding 5 object files to build/temp.macosx-10.9-x86_64-3.9/libnpyrandom.a
x86_64-apple-darwin13.4.0-ranlib:@ build/temp.macosx-10.9-x86_64-3.9/libnpyrandom.a
creating numpy/random/lib
customize UnixCCompiler
customize UnixCCompiler using new_build_ext
Python 3.9.5 | packaged by conda-forge | (default, Jun 19 2021, 00:27:35) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.24.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: exit

CCompilerOpt.__init__[781] : hit the memory cache
CCompilerOpt.generate_dispatch_header[2267] : generate CPU dispatch header: (build/src.macosx-10.9-x86_64-3.9/numpy/distutils/include/npy_cpu_dispatch_config.h)
building 'numpy.core._multiarray_tests' extension
compiling C sources
C compiler: x86_64-apple-darwin13.4.0-clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -fwrapv -O2 -Wall -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -isystem /Users/rgommers/mambaforge/envs/scipy-dev/include -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -isystem /Users/rgommers/mambaforge/envs/scipy-dev/include -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -isystem /Users/rgommers/mambaforge/envs/scipy-dev/include -D_FORTIFY_SOURCE=2 -isystem /Users/rgommers/mambaforge/envs/scipy-dev/include

Maybe we end up not winning the monkey patching race or something. This seems like a good moment to share this picture:

I don't have time to look at it more right now. There's no real design, it's just trial and error. We should find a place where the change doesn't get overwritten by something else.

Sure, I only noticed this because fmod(1, 0) does not set the correct floating point error flags on Mac. But I am not sure that is a problem with clang at all, it may also be the fmod in libc (can't reproduce it on linux anyway).