Skip to content

pyatomic_gcc.h with GCC discards const qualifier  #120593

Description

@ndparker

Bug report

Bug description:

Hi,

including Python.h with gcc and -Wcast-qual raises the following issue (Regression from 3.12):

    /usr/include/python3.13/cpython/pyatomic_gcc.h: In function '_Py_atomic_load_ptr':
    /usr/include/python3.13/cpython/pyatomic_gcc.h:300:34: error: cast discards 'const' qualifier from pointer target type [-Werror=cast-qual]
      300 | { return (void *)__atomic_load_n((void **)obj, __ATOMIC_SEQ_CST); }
          |                                  ^
    /usr/include/python3.13/cpython/pyatomic_gcc.h: In function '_Py_atomic_load_ptr_relaxed':
    /usr/include/python3.13/cpython/pyatomic_gcc.h:359:34: error: cast discards 'const' qualifier from pointer target xt (line 8))
$ python3.13 -V
Python 3.13.0b1

This is a follow-up to #120293

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

Activity

  1. picnixz commented on Jun 17, 2024

    @picnixz
    Member

    For the record, this is not the only place where const qualifiers are lost. If you compile cpython with make CFLAGS=-Wcast-qual -j12 you end up with a lot of warnings. For the line 359, the fix would be:

    // pyatomic_gcc.h
    static inline void *
    _Py_atomic_load_ptr_relaxed(const void *obj)
    -{ return (void *)__atomic_load_n((void **)obj, __ATOMIC_RELAXED); }
    +{ return (void *)__atomic_load_n((void * const *)obj, __ATOMIC_RELAXED); }

    As you can see you lose constness twice, namely when calling __atomic_load_n and when returning the type. Note that we have

    // pyatomic_std.h
    static inline void *
    _Py_atomic_load_ptr_relaxed(const void *obj)
    {
        _Py_USING_STD;
        return atomic_load_explicit((const _Atomic(void*)*)obj,
                                    memory_order_relaxed);
    }

    As you can see, the cast here is essentially using a const void **, but still the return type should be a const as well (in the case of __atomic_load_n, the signature is type __atomic_load_n(type *ptr, int memorder);).

    EDIT: I edited my comment in order to reflect the real signature of _Py_atomic_load_ptr_relaxed in cpython. The return type is a void * and not a const void * but the inner cast fix remains correct.

  2. ndparker commented on Jun 17, 2024

    @ndparker
    ContributorAuthor

    Yes, I'd like to clarify that this is specifically not about compiling CPython, it's about including Python.h only.

  3. picnixz commented on Jun 18, 2024

    @picnixz
    Member

    Yes, I understood that from the other issue but since you only mentioned 2 lines, I wanted to 1) give a way to fix it 2) say that it's not just 2 lines that are affected but a lot of calls.

  4. changed the title [-]Python.h with GCC discards const qualifier [/-] [+]pyatomic_gcc.h with GCC discards const qualifier [/+] on Jun 26, 2024
  5. added 2 commits that reference this issue on Jun 26, 2024
  6. added 2 commits that reference this issue on Jun 26, 2024
  7. added a commit that references this issue on Jun 26, 2024
  8. added 3 commits that reference this issue on Jun 26, 2024
  9. 2 remaining items

  10. vstinner commented on Jun 27, 2024

    @vstinner
    Member

    The warnings were fixed by 9cd2dcb and e51e880.

    I also added a check in test_cext for check for non-regression: b7a95df.

    Thanks @ndparker for your bug report. It's now fixed, I close the issue.

  11. added 3 commits that reference this issue on Jun 30, 2024
  12. added 3 commits that reference this issue on Jul 11, 2024
  13. markshannon commented on Jul 15, 2024

    @markshannon
    Member

    I don't think weakening the type of calls that should be const is the correct thing to do here.
    Where there is a conflict in types we should be strengthening the type, not weakening it.
    Why not strengthen the types in the callees, rather than weakening them in the callers?

  14. added 3 commits that reference this issue on Jul 17, 2024
  15. added a commit that references this issue on Jul 27, 2024
  16. vstinner commented on Jul 27, 2024

    @vstinner
    Member

    @markshannon:

    I don't think weakening the type of calls that should be const is the correct thing to do here.

    If you're talking about _PyLong_CompactValue(): I wrote PR gh-122367 to restore the const modifier.

    If you're talking about something else, please elaborate which function/code you are referring to.

  17. added a commit that references this issue on Jul 28, 2024
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

    type-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions