Just after calling _PyRuntime_Initialize(), Py_Main() calls:

    /* 754 requires that FP exceptions run in "no stop" mode by default,
     * and until C vendors implement C99's ways to control FP exceptions,
     * Python requires non-stop mode.  Alas, some platforms enable FP
     * exceptions by default.  Here we disable them.
     */
#ifdef __FreeBSD__
    fedisableexcept(FE_OVERFLOW);
#endif

It's done before calling Py_Initialize(). So applications embedding Python don't call it. But "customized Python" which call the new Py_RunMain() with Py_InititializeFromConfig() will not call it neither.

I would like to know if this setup code should be moved into Py_Initialize()? Especially into the new PyConfig API:
https://docs.python.org/dev/c-api/init_config.html

PyConfig got 2 flags to control parameters which affect the whole process:

• configure_c_stdio
• configure_locale

What is the behavior on FreeBSD when fedisableexcept(FE_OVERFLOW) is not called?

Note: I'm not sure why this call is only needed on FreeBSD, but not on macOS, OpenBSD or NetBSD (operating systems close to FreeBSD).

What is the behavior on FreeBSD when fedisableexcept(FE_OVERFLOW) is not called?

That's an excellent question, that I'd love to have an answer to for currently supported FreeBSD versions.

I think the old behaviour is that anything that you'd expect to raise an FPE (e.g., math.sqrt(-1.0) would segfault the interpreter). It may be that that's no longer an issue with FreeBSD versions that we care about.

That code comment dates from over 16 years ago (see 4643bd9), so there's some hope that the situation's changed since then.

The current FreeBSD documentation for fedisableexcept says:

All exceptions are masked by default.

Source: https://www.freebsd.org/cgi/man.cgi?query=fedisableexcept&apropos=0&sektion=0&manpath=FreeBSD+12.0-RELEASE+and+Ports&arch=default&format=html

So it looks as though it may be safe to remove this.

The current FreeBSD documentation for fedisableexcept says: All exceptions are masked by default.

The fedisableexcept manual page says that since this manual page was added to FreeBSD 6.0 which was released in 2005.

Python started to tune FPU control on FreeBSD in 2002.

Should I understand that fedisableexcept(FE_OVERFLOW) is useless since FreeBSD 6?

I'm also surprised that I never saw any complain about that on other BSD: OpenBSD, NetBSD, macOS, etc. It seems like the fedisableexcept(FE_OVERFLOW) call is useless since a long time.

fp_except.c: C program to test for float point exceptions:

• FE_OVERFLOW
• FE_UNDERFLOW
• FE_INVALID

I prefer to avoid testing FE_INEXACT which a test might be too specific to an implementation of the libm.

I also chose to avoid testing FE_DIVBYZERO, since the default behavior is to kill the process with SIGFPE.

Should I understand that fedisableexcept(FE_OVERFLOW) is useless since FreeBSD 6?

That's my understanding, yes. And since it was only introduced in FreeBSD 6, it's been useless forever. IOW, I think it's true that this line of code, in its current form, hasn't ever had any effect.

And since it was only introduced

Sorry, that was unclear. "it" refers to "fedisableexcept" in the above.

Mark: Do you think that it's worth it to convert attached fp_except.c into tests run by test_float, to check floating point exceptions in Python?

Mark: Do you think that it's worth it to convert attached fp_except.c into
tests run by test_float, to check floating point exceptions in Python?

Sure, it wouldn't harm. I'd expect that all these cases are already being tested indirectly by some part of test_math, but direct tests are better.

Note that Python still can't/won't assume IEEE 754 floating-point, so if the tests use special values like infinities and nans, or other IEEE 754 assumptions, then they should be guarded by a suitable "skipIf" decorator.

New changeset 5e0ea75 by Victor Stinner in branch 'master':
bpo-37474: Don't call fedisableexcept() on FreeBSD (GH-16515)
5e0ea75

Sorry, I failed to find time to convert attached tests to tests in the Python test suite. But I understood that existing tests should be enough to control the rounding mode.

I removed the call. If something goes wrong, we can add it back.