Skip to content

always_inline makes build fail with -Og and --without-pydebug #121266

Description

@mgorny

Bug report

Bug description:

We're trying to build CPython to debug a crash in third-party extension. To do that, I've set CFLAGS="-Og -g" and passed --with-assertions. However, we're not using --with-pydebug since that has had side effects that broke multiple third-party packages in the past. Unfortunately, in this configuration CPython fails to build due to use of always_inline:

gcc -c -fno-strict-overflow -fstack-protector-strong -Wtrampolines -Wsign-compare -g -O3 -Wall -Og   -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal -I./Include/internal/mimalloc  -I. -I./Include    -DPy_BUILD_CORE -o Objects/dictobject.o Objects/dictobject.c
In function ‘do_lookup’,
    inlined from ‘unicodekeys_lookup_unicode’ at Objects/dictobject.c:1137:12:
Objects/dictobject.c:1120:1: error: inlining failed in call to ‘always_inline’ ‘compare_unicode_unicode’: function not considered for inlining
 1120 | compare_unicode_unicode(PyDictObject *mp, PyDictKeysObject *dk,
      | ^~~~~~~~~~~~~~~~~~~~~~~
Objects/dictobject.c:1052:30: note: called from here
 1052 |             Py_ssize_t cmp = check_lookup(mp, dk, ep0, ix, key, hash);
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Objects/dictobject.c:1120:1: error: inlining failed in call to ‘always_inline’ ‘compare_unicode_unicode’: function not considered for inlining
 1120 | compare_unicode_unicode(PyDictObject *mp, PyDictKeysObject *dk,
      | ^~~~~~~~~~~~~~~~~~~~~~~
Objects/dictobject.c:1068:30: note: called from here
 1068 |             Py_ssize_t cmp = check_lookup(mp, dk, ep0, ix, key, hash);
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘do_lookup’,
    inlined from ‘unicodekeys_lookup_generic’ at Objects/dictobject.c:1116:12:
Objects/dictobject.c:1085:1: error: inlining failed in call to ‘always_inline’ ‘compare_unicode_generic’: function not considered for inlining
 1085 | compare_unicode_generic(PyDictObject *mp, PyDictKeysObject *dk,
      | ^~~~~~~~~~~~~~~~~~~~~~~
Objects/dictobject.c:1052:30: note: called from here
 1052 |             Py_ssize_t cmp = check_lookup(mp, dk, ep0, ix, key, hash);
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Objects/dictobject.c:1085:1: error: inlining failed in call to ‘always_inline’ ‘compare_unicode_generic’: function not considered for inlining
 1085 | compare_unicode_generic(PyDictObject *mp, PyDictKeysObject *dk,
      | ^~~~~~~~~~~~~~~~~~~~~~~
Objects/dictobject.c:1068:30: note: called from here
 1068 |             Py_ssize_t cmp = check_lookup(mp, dk, ep0, ix, key, hash);
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘do_lookup’,
    inlined from ‘dictkeys_generic_lookup’ at Objects/dictobject.c:1171:12:
Objects/dictobject.c:1141:1: error: inlining failed in call to ‘always_inline’ ‘compare_generic’: function not considered for inlining
 1141 | compare_generic(PyDictObject *mp, PyDictKeysObject *dk,
      | ^~~~~~~~~~~~~~~
Objects/dictobject.c:1052:30: note: called from here
 1052 |             Py_ssize_t cmp = check_lookup(mp, dk, ep0, ix, key, hash);
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Objects/dictobject.c:1141:1: error: inlining failed in call to ‘always_inline’ ‘compare_generic’: function not considered for inlining
 1141 | compare_generic(PyDictObject *mp, PyDictKeysObject *dk,
      | ^~~~~~~~~~~~~~~
Objects/dictobject.c:1068:30: note: called from here
 1068 |             Py_ssize_t cmp = check_lookup(mp, dk, ep0, ix, key, hash);
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:3051: Objects/dictobject.o] Error 1

CPython versions tested on:

3.13, CPython main branch

Operating systems tested on:

Linux

Linked PRs

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Jul 2, 2024
  2. mgorny commented on Jul 2, 2024

    @mgorny
    ContributorAuthor

    I've confirmed this with 3.13 @ 78e96bd, main @ 6343486. This is Gentoo Linux amd64 with GCC 14.1.1_p20240622 p2.

  3. added
    buildThe build process and cross-build
    on Jul 2, 2024
  4. vstinner commented on Jul 5, 2024

    @vstinner
    Member

    However, we're not using --with-pydebug since that has had side effects that broke multiple third-party packages in the past.

    Would you mind to elaborate? The ABI is now the same between release and debug build since Python 3.8.

  5. mgorny commented on Jul 6, 2024

    @mgorny
    ContributorAuthor

    Back when I've tried debugging an assertion failure and enabled --with-pydebug, I've ended up hitting different failures in dependencies even before I managed to get to "my" failure. It was #108295 (comment) back then.

  6. added 3 commits that reference this issue on Jul 8, 2024
  7. vstinner commented on Jul 8, 2024

    @vstinner
    Member

    I proposed PR gh-121493 to remove Py_ALWAYS_INLINE. I'm not sure if my PR is correct.

  8. added a commit that references this issue on Jul 10, 2024
  9. added 3 commits that reference this issue on Jul 17, 2024
  10. added a commit that references this issue on Jul 18, 2024
  11. chris-eibl commented on Jul 20, 2024

    @chris-eibl
    Member

    If there are problems with Py_ALWAYS_INLINE in compare_unicode_generic(), compare_unicode_unicode() and compare_generic(), I assume their *_threaded versions are affected, too, since they also have those asserts?
    Except for compare_generic_threadsafe(), where the
    assert(ep->me_key != NULL);
    IMHO would be an improvement (or at least not hurt)?

    Or maybe just for symmetry those should't use Py_ALWAYS_INLINE if their non-threaded versions don't?

  12. chris-eibl commented on Jul 20, 2024

    @chris-eibl
    Member

    OTOH, if those asserts are the culprit and you are unsure about the performance impact of removing the Py_ALWAYS_INLINE (see #issuecomment-2213996110), you could use an #ifdef NDEBUG, but is it worth the hassle?

    Since there is the convenient pyperformance infrastructure let's measure?

  13. added a commit that references this issue on Jul 20, 2024
  14. added a commit that references this issue on Jul 21, 2024
  15. added a commit that references this issue on Jul 21, 2024
  16. vstinner commented on Jul 27, 2024

    @vstinner
    Member

    The issue should now be fixed in 3.13 and main branches. Thanks for the report @mgorny.

  17. mgorny commented on Jul 28, 2024

    @mgorny
    ContributorAuthor

    Thanks a lot!

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

    buildThe build process and cross-buildtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions