I'm trying to build Python 3.7 on CentOS 7 with Intel compilers. To compile I do the following:

export CC=icc
export CXX=icpc
export FC=ifort

./configure --prefix=my_prefix --enable-optimizations --without-gcc
make
make install

In the configure, no error is seen, but when I execute make, the following message is printed:

Running code to generate profile data (this can take a while):

First, we need to create a clean build with profile generation

enabled.

make profile-gen-stamp
make[1]: se ingresa al directorio /home/python/source/Python-3.7.3' Building with support for profile generation: make build_all_generate_profile make[2]: se ingresa al directorio /home/python/source/Python-3.7.3'
make build_all CFLAGS_NODIST=" -prof-gen" LDFLAGS_NODIST=" -prof-gen" LIBS="-lcrypt -lpthread -ldl -lutil"
make[3]: se ingresa al directorio `/home/python/source/Python-3.7.3'
icc -pthread -c -Wsign-compare -Wunreachable-code -DNDEBUG -g -O3 -Wall -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wno-cast-function-type -Werror=implicit-function-declaration -fp-model strict -prof-gen -I. -I./Include -DPy_BUILD_CORE -o Programs/python.o ./Programs/python.c
icc: command line warning bpo-10006: ignoring unknown option '-Wno-cast-function-type'
In file included from ./Include/Python.h(75),
from ./Programs/python.c(3):
./Include/pyatomic.h(39): error: identifier "atomic_uintptr_t" is undefined
atomic_uintptr_t _value;
^

compilation aborted for ./Programs/python.c (code 2)

atomic_uintptr_t is used if HAVE_STD_ATOMIC defined is defined. Can you please check in pyconfig.h if it's defined?

So <stdatomic.h> doesn't provide atomic_uintptr_t with ICC?

In pyconfig.h the variable HAVE_STD_ATOMIC appears like this:

/* Has stdatomic.h with atomic_int */
#define HAVE_STD_ATOMIC 1

I searched at <stdatomic.h> atomic_uintptr_t and found nothing.

I searched at <stdatomic.h> atomic_uintptr_t and found nothing.

That's not good. I expectd std to stand for standard. I expected that atomic_uintptr_t would always be available on <stdatomic.h>.

GCC defines the type as:

typedef _Atomic __UINTPTR_TYPE__ atomic_uintptr_t;

Maybe you should try:

typedef struct _Py_atomic_address {
    _Atomic Py_uintptr_t _value;
} _Py_atomic_address;

Two things.

I searched a bit more and found "atomic_uint" inside <stdatomic.h>, but it's not exactly the same as what you wrote.

What you have put me to try, where do I put it?

I attached <stdatomic.h> in case it helps.

I suggested you to test the following change on the master branch of Python:

diff --git a/Include/internal/pycore_atomic.h b/Include/internal/pycore_atomic.h
index 336bc3fec2..c624a0cf1c 100644
--- a/Include/internal/pycore_atomic.h
+++ b/Include/internal/pycore_atomic.h
@@ -44,7 +44,7 @@ typedef enum _Py_memory_order {
 } _Py_memory_order;
 
 typedef struct _Py_atomic_address {
-    atomic_uintptr_t _value;
+    _Atomic uintptr_t _value;
 } _Py_atomic_address;
 
 typedef struct _Py_atomic_int {

Is it available with -std=c11? It is a bit strange that we use -std=c99. I thought that header is C11:

https://en.cppreference.com/w/c/atomic

I have the same problem on RH6 with icc 2019.4 and Python 3.6.9. Do you want a new bug for that?
Changing Include/pyatomic.h to use _Atomic as suggested by Victor in msg346785 leads to the error that _Atomic was undefined.

Changing Include/pyatomic.h to use _Atomic as suggested by Victor in msg346785 leads to the error that _Atomic was undefined.

No idea how to define a "_Py_atomic_address" type with icc 2019.4 in this case. If someone has a working patch, I can review it ;-)

We have been experiencing the same problem with compiling Python-3.7.4 on a system with CentOS 7.6 (aka glib-2.17): Intel Compiler 2019.6 implements stdatomic.h. but lacks the definition of atomic_uintptr_t.

From a configure-point of view just failing to define HAVE_STDATOMIC_H would suffice.
Therefore just add another otherwise unused variable (which might warn & bail out in case of -Werror / -Werror-all)...

The following patch works for us to compile.

Granted, the "proper" way would be to add another configure check for the underlying type and not blurry the check for stdatomic.h -- but then again, Intel should just implement all of C11...

I wrote PR 16717 which uses a similar approach than python.patch.

Can someone please test PR 16717 with ICC?

I marked bpo-35473 as duplicate of this issue.

New changeset 028f734 by Victor Stinner in branch 'master':
bpo-37415: Fix stdatomic.h header check for ICC compiler (GH-16717)
028f734

New changeset b102e4f by Miss Skeleton (bot) in branch '3.7':
bpo-37415: Fix stdatomic.h header check for ICC compiler (GH-16717)
b102e4f

New changeset dbcea39 by Miss Skeleton (bot) in branch '3.8':
bpo-37415: Fix stdatomic.h header check for ICC compiler (GH-16717)
dbcea39

According to Adam J. Stewart, my PR 16717 fix the Python build on ICC:
#16717 (comment)

So I merged it in 3.7, 3.8 and master branches.

Adam saw other failures, but it's unrelated issues which should be reported separately.

Thanks for the bug report Borja. It should now be fixed. Until a new Python version is released with the fix, you should either apply the patch manually or use a different compiler. GCC and Clang are well supported on Linux for example.