Make --enable-imprecise-c99-float-ops the default on CPU that doesn't support FMA

[kit-ty-kate]

While calling ./configure on my desktop (Intel Core i5-750) on Windows with MSVC i get the following error:

Configure: error: fma does not work, enable emulation with --enable-imprecise-c99-float-ops

using --enable-imprecise-c99-float-ops works fine but given my CPU doesn't support FMA I would expect this option to be the default on such hardware as there is no way to have precise float operations on it.

According to https://en.wikipedia.org/wiki/FMA_instruction_set, anything pre-Haswell (Intel) or pre-Piledriver (AMD) does not have it.

This is also a common issue encountered by people running Windows inside emulators such as VirtualBox: diskuv/dkml-installer-ocaml#23. cc @jonahbeckford

[nojb]

As I understand, the idea was to have an explicit opt-in from the user since the "imprecise" C99 emulations can give you incorrect results and so introduce bugs in your program.

[xavierleroy]

Technically, this behavior is not tied to hardware support for FMA: OCaml goes through the fma function from the C standard library, which can either use hardware support or provide software emulation. What configure is trying to detect is an incorrect implementation of fma in (some versions of) the MSVC / MinGW C standard library. But a case could be made that --enable-imprecise-c99-float-ops could be the default, instead of opt-in. @dra27 is our expert on this question.

[dra27]

Indeed - fma's been a special case on Windows since it was added (see #2177, which was a follow-on from #1354). When the C99 requirement was added in #944, Windows got an opt-out for it being an error (see the "logic" in OCAML_C99_CHECK_FMA in aclocal.m4). At that time, it was observed that fma worked correctly in VS 2019+, so configure assumed that if _MSC_VER >= 1920 then fma should work, which is the cause of this error.

Further reading reveals that Microsoft didn't fix the software version of fma in VS 2019, what they fixed was the compiler's selection of the appropriate fma intrinsic which means that the broken function no longer gets called. That causes this error to surface in two unexpected places:

• As @kit-ty-kate has seen, if you have a pre-Haswell or pre-Piledriver CPU that lacks the hardware support
• As @jonahbeckford has seen, VirtualBox bug #15471 means that even with hardware FMA support, the configure test fails when building OCaml in VirtualBox.

I was already working on this, and have finished off two proposals. For 4.14, I suggest #12518 which just makes the emulation automatic in VirtualBox or on older hardware. The 4.14 solution is a bit disappointing for VirtualBox, given that it's only the detection of the hardware support which fails, not the actual support itself. Therefore, for trunk, in #12519, I propose unconditionally requiring hardware support for FMA on Windows, which results in considerable simplifications of both the configuration and, more importantly, the runtime.

[cr1901]

FWIW (as another data point), I have also run into this bug trying to compile with Cygwin on Windows (as part of opam switch create compiler 5.1.0). And yes, my laptop is also old (2011 Core i7 Sandy Bridge). I don't have any current plans to shell out $2000+ for a new one while this one still works fine.

So there's at least 2 people using OCaml on Windows on pre-Haswell hardware :P.

[dra27]

@cr1901 - I think what's likely to happen is that were you to use Float.fma in OCaml 5.2+ then the program will crash, but otherwise OCaml 5.2+ would still be fine to build and run... hopefully you wouldn't be trying to run high performance numerical code on a 12 year old CPU 😉

[cr1901]

but otherwise OCaml 5.2+ would still be fine to build and run...

I can work with that. I've seen the horror stories of floating point and can deal with "please use a not-ancient CPU" for floating point. My intended use case for installing OCaml after not using it since 2020 (before a clean install) is for SAIL. That doesn't use Float.fma AFAICT. But they're on an old OCaml version anyway; I'm just future-proofing :D.

hopefully you wouldn't be trying to run high performance numerical code on a 12 year old CPU 😉

Once upon a time I ran MATLAB heavily on this CPU, but those days are long gone :D.