classification
Title: Should Py_Initialize() control the floating point mode?
Type: Stage: resolved
Components: Interpreter Core Versions: Python 3.9
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: lemburg, mark.dickinson, stutzbach, tim.peters, vstinner
Priority: normal Keywords: patch

Created on 2019-07-01 17:39 by vstinner, last changed 2019-10-01 11:14 by vstinner. This issue is now closed.

Files
File name Uploaded Description Edit
fp_except.c vstinner, 2019-07-29 23:34
Pull Requests
URL Status Linked Edit
PR 16515 merged vstinner, 2019-10-01 10:45
Messages (11)
msg347048 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-07-01 17:39
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).
msg347226 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2019-07-03 12:43
> 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 https://github.com/python/cpython/commit/4643bd9a9cf43332992d10982c52debf3f0d980c), so there's some hope that the situation's changed since then.
msg347228 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2019-07-03 12:49
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.
msg348696 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-07-29 23:09
> 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.
msg348698 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-07-29 23:34
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.
msg348723 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2019-07-30 08:58
> 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.
msg348724 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2019-07-30 08:59
> And since it was only introduced 

Sorry, that was unclear. "it" refers to "fedisableexcept" in the above.
msg348725 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-07-30 09:01
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?
msg348727 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2019-07-30 09:09
> 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.
msg353671 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-10-01 11:12
New changeset 5e0ea7540f577c9684e272000fdfc80d29bb78a2 by Victor Stinner in branch 'master':
bpo-37474: Don't call fedisableexcept() on FreeBSD (GH-16515)
https://github.com/python/cpython/commit/5e0ea7540f577c9684e272000fdfc80d29bb78a2
msg353672 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-10-01 11:14
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.
History
Date User Action Args
2019-10-01 11:14:10vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg353672

stage: patch review -> resolved
2019-10-01 11:12:32vstinnersetmessages: + msg353671
2019-10-01 10:45:17vstinnersetkeywords: + patch
stage: patch review
pull_requests: + pull_request16105
2019-07-30 09:09:02mark.dickinsonsetmessages: + msg348727
2019-07-30 09:01:36vstinnersetmessages: + msg348725
2019-07-30 08:59:20mark.dickinsonsetmessages: + msg348724
2019-07-30 08:58:13mark.dickinsonsetmessages: + msg348723
2019-07-29 23:34:12vstinnersetfiles: + fp_except.c

messages: + msg348698
2019-07-29 23:09:22vstinnersetmessages: + msg348696
2019-07-03 12:49:29mark.dickinsonsetmessages: + msg347228
2019-07-03 12:43:55mark.dickinsonsetnosy: + tim.peters
2019-07-03 12:43:33mark.dickinsonsetmessages: + msg347226
2019-07-01 17:39:03vstinnercreate