Code explanation for absence of stdatomic.h for python build

Rosuav · 2025-08-11T09:14:09.681Z

Mohammed Zuhaib:

The above is returned correctly in my configure, however once it finishes, I get this,
configure: Your compiler or platform does have a working C11 stdatomic.h. A future version of Python may require stdatomic.h.
should the message be “doesn’t have stdatomic.h” and instead a typo came in?

Yeah, I think that’s a straight-forward mistake of language; I’m looking at configure.ac and it makes a lot more sense as “does not have”. However, that does still imply that it’s currently optional. A more serious concern is whether that’s true, or if we have now reached that “future version” when it becomes required - if we have, the configure script needs to be updated.

zuhu2195 · 2025-08-11T09:19:24.841Z

Rosuav:

A more serious concern is whether that’s true, or if we have now reached that “future version” when it becomes required - if we have, the configure script needs to be updated.

Yes, I agree. This needs to be brought to attention. If stdatomic.h is not present and mandatory for build, then configure itself should not go through.

Rosuav · 2025-08-11T09:26:51.691Z

Mohammed Zuhaib:

If stdatomic.h is not present and mandatory for build, then configure itself should not go through.

Yeah, I agree. I’m not sure whether it’s meant to be optional or required, but all three (compilation, configuration, and documentation) should say the same thing.

I opened a thread where the core devs are more likely to see it.

Rosuav · 2025-08-11T20:19:47.731Z

Mohammed Zuhaib:

Regarding your first question, my platform is NonStop(Non-Standard but similar to IBM AIX). Our compilers support C11 standards.

Presumably it isn’t GCC though, as there’s separate support for GCC’s atomics.

Can you tell us anything more about the compiler toolchain you’re using?

It’s possible that this is an error of wording in the configure script, and as of CPython 3.13, stdatomic is in fact required. If that’s the case, you’ll need to get compiler support for atomics, or downgrade to CPython 3.12, which was the last version before that became an error.

zuhu2195 · 2025-08-12T00:57:37.683Z

It’s a x86 based in house compiler currently on C and C++11 standards. It is not supported by Python(but as said earlier, to an extent mimics AIX). So atomics support need to be brought in then. This should answer my question. Inclusion of atomics doesn’t violate PEP 11?(as mentioned earlier)

Rosuav · 2025-08-12T01:04:08.039Z

Mohammed Zuhaib:

So atomics support need to be brought in then. This should answer my question. Inclusion of atomics doesn’t violate PEP 11?(as mentioned earlier)

I think it probably should? I’m not sure. This isn’t my decision to make, there are two distinct approaches possible.

What happens if you remove the #include "pyatomic.h" line in Python.h? Can you get most/all of Python to build, and if so, what parts don’t work?

zuhu2195 · 2025-08-12T01:08:13.353Z

Rosuav:

What happens if you remove the #include "pyatomic.h" line in Python.h? Can you get most/all of Python to build, and if so, what parts don’t work?

I need to try this out. Let me check and get back.

zuhu2195 · 2025-08-12T07:38:47.476Z

I tried compilation after removing pyatomic.h

 “/home/Python-3.13.5/Include/cpython/lock.h”, line 48: error(114):identifier “_Py_atomic_compare_exchange_uint8” is undefined    if 
(!_Py_atomic_compare_exchange_uint8(&m->_bits, &expected, _Py_UNLOCKED)) {        ^ “/home/Python-3.13.5/Include/cpython/lock.h”, line 59: error(114):identifier “_Py_atomic_compare_exchange_uint8” is undefined

I am hitting undefined symbol errors, and in the beginning of compilation. So atomics are important then, there is no other option than to get those on our platform for C.

colesbury · 2025-08-12T14:40:24.756Z

Does NonStop support GCC-style __atomic builtins? If so, we just need to adjust the guards in pyatomic.h. If not, does it support the legacy __sync extensions?

For example, do either of these two programs compile?

#include <stdio.h>

int main(void) {
    int x = 0;
    int old = __atomic_fetch_add(&x, 1, __ATOMIC_SEQ_CST);
    printf("__atomic_fetch_add %d %d\n", old, x);
    return 0;
}

#include <stdio.h>

int main(void) {
    int x = 0;
    __sync_fetch_and_add(&x, 1);
    printf("legacy __sync_fetch_and_add: %d\n", x);
    return 0;
}

The only documentation I found online is this: https://support.hpe.com/hpesc/public/docDisplay?docId=c02128447&docLocale=en_US and I can’t find definitive answers.

zuhu2195 · 2025-08-12T16:39:57.303Z

None of these compile for C on NonStop.

colesbury · 2025-08-12T17:37:17.610Z

What about the atomic intrinsics mentioned in the HPE docs?

For example:

#include <stdio.h>
#include <stdint.h>

int main(void) {
    int32_t x = 0;
    int32_t old = _atmAdd32(&x, 1);
    printf("_atmAdd32 %d %d\n", (int)old, (int)x);
    return 0;
}

zuhu2195 · 2025-08-12T17:38:44.827Z

Yes, this might compile, I have seen these declarations in a header file.

zuhu2195 · 2025-08-13T05:06:06.582Z

This compiled fine for NonStop. So you are suggesting to use these atomic intrinsics in place of atomics in pyatomic_std.h. Although I doubt there is full support. To begin with this can be done.

colesbury · 2025-08-13T14:17:33.239Z

Yes, I’m suggesting you implement the pyatomic.h functions in terms of the available atomic intrinsics.

zuhu2195 · 2025-08-13T14:30:03.248Z

Thank you @colesbury , @Rosuav for your help, much appreciated.

da-woods · 2025-08-13T15:31:33.549Z

I’d also suggest not writing special _acquire/_release/_relaxed functions. Those are optimisations so it’ll work fine if you fall back to the plain version.

zuhu2195 · 2025-08-13T15:33:14.729Z

Noted, Thanks.

zuhu2195 · 2026-03-20T12:49:16.886Z

I found a piece of code segment written for 16 bit atomic operation but type casting to 32 bit in pyatomic_std.h. atomic_load type case is of 32 bit, while obj is of 16 bit type.


static inline uint16_t
_Py_atomic_load_uint16(const uint16_t *obj)
{
    _Py_USING_STD;
    return atomic_load((const _Atomic(uint32_t)*)obj);
}

is this a mistake or was it deliberately added? I couldn’t find any other place where such a cast was done.

colesbury · 2026-03-20T16:58:15.788Z

That definitely looks like a mistake to me.

colesbury · 2026-03-20T17:24:12.015Z

Thanks for catching this. It will be fixed in gh-146227: Fix wrong type in _Py_atomic_load_uint16 in pyatomic_std.h by colesbury · Pull Request #146229 · python/cpython · GitHub