Skip to content

Should Py_Initialize() control the floating point mode? #81655

Closed
Closed
Should Py_Initialize() control the floating point mode?#81655
Labels
3.9 (EOL)end of lifeinterpreter-core(Objects, Python, Grammar, and Parser dirs)

Description

@vstinner
vstinner
opened on Jul 1, 2019
BPO 37474
Nosy @malemburg, @tim-one, @mdickinson, @vstinner
PRs
  • bpo-37474: Don't call fedisableexcept() on FreeBSD #16515
    		•
    Files
  • fp_except.c
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2019-10-01.11:14:10.826>
created_at = <Date 2019-07-01.17:39:03.909>
labels = ['interpreter-core', '3.9']
title = 'Should Py_Initialize() control the floating point mode?'
updated_at = <Date 2019-10-01.11:14:10.825>
user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2019-10-01.11:14:10.825>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2019-10-01.11:14:10.826>
closer = 'vstinner'
components = ['Interpreter Core']
creation = <Date 2019-07-01.17:39:03.909>
creator = 'vstinner'
dependencies = []
files = ['48511']
hgrepos = []
issue_num = 37474
keywords = ['patch']
message_count = 11.0
messages = ['347048', '347226', '347228', '348696', '348698', '348723', '348724', '348725', '348727', '353671', '353672']
nosy_count = 5.0
nosy_names = ['lemburg', 'tim.peters', 'mark.dickinson', 'vstinner', 'stutzbach']
pr_nums = ['16515']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue37474'
versions = ['Python 3.9']

    Activity

    1. vstinner commented on Jul 1, 2019

      @vstinner
      vstinner
      on Jul 1, 2019
      MemberAuthor

      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).

    2. vstinner
      added
      3.9 (EOL)end of life
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      on Jul 1, 2019

    3. mdickinson commented on Jul 3, 2019

      @mdickinson
      mdickinson
      on Jul 3, 2019
      Member

      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.

    4. mdickinson commented on Jul 3, 2019

      @mdickinson
      mdickinson
      on Jul 3, 2019
      Member

      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.

    5. vstinner commented on Jul 29, 2019

      @vstinner
      vstinner
      on Jul 29, 2019
      MemberAuthor

      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.

    6. vstinner commented on Jul 29, 2019

      @vstinner
      vstinner
      on Jul 29, 2019
      MemberAuthor

      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.

    7. mdickinson commented on Jul 30, 2019

      @mdickinson
      mdickinson
      on Jul 30, 2019
      Member

      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.

    8. mdickinson commented on Jul 30, 2019

      @mdickinson
      mdickinson
      on Jul 30, 2019
      Member

      And since it was only introduced

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

    9. vstinner commented on Jul 30, 2019

      @vstinner
      vstinner
      on Jul 30, 2019
      MemberAuthor

      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?

    10. mdickinson commented on Jul 30, 2019

      @mdickinson
      mdickinson
      on Jul 30, 2019
      Member

      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.

    11. vstinner commented on Oct 1, 2019

      @vstinner
      vstinner
      on Oct 1, 2019
      MemberAuthor

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

    12. vstinner commented on Oct 1, 2019

      @vstinner
      vstinner
      on Oct 1, 2019
      MemberAuthor

      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.

    13. vstinner
      closed this as completedon Oct 1, 2019
    14. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      3.9 (EOL)end of lifeinterpreter-core(Objects, Python, Grammar, and Parser dirs)

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions