Recent GCC v14 conflicts with stdatomic.h from the xtensa toolchain (esp-13.2.0_20240305) (IDFGH-13033)

[M-Bab]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

The whole setup is a bit tricky: In some cases you will build xtensa toolchain code with another GCC than provided from the toolchain. In our case it is unit tests we run on x86 platforms compiled with the local GCC. But even outside this scope the xtensa toolchain will run into the problem when upgrading its GCC.

The stdatomic.h (in ~/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20240305/xtensa-esp-elf/xtensa-esp-elf/include/stdatomic.h) tries to determine the right setup for different compilers:

#if __has_extension(c_atomic) || __has_extension(cxx_atomic)
#define	__CLANG_ATOMICS
#elif __GNUC_PREREQ__(4, 7)
#define	__GNUC_ATOMICS
#elif defined(__GNUC__)
#define	__SYNC_ATOMICS
#else
#error "stdatomic.h does not support your compiler"
#endif

Unfortunately the most recent GCC also replies __has_extension(c_atomic) with true. So we get the define __CLANG_ATOMICS which is obviously for Clang. Consequently the build also fails with:

error: implicit declaration of function ‘__c11_atomic_thread_fence’; did you mean ‘__atomic_thread_fence’? [-Wimplicit-function-declaration]
  143 |         __c11_atomic_thread_fence(__order);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~
      |         __atomic_thread_fence

And many other errors if stdatomic.h is somehow included. For now I will workaround that by modifying the xtensa toolchain:

diff stdatomic.h stdatomic-fixed.h 
37c37
< #define       __CLANG_ATOMICS
---
> #define       __GNUC_ATOMICS

But maybe you got a better solution. This issue is also a hint for other users having a similar problem. And to make you aware there is a change necessary when upgrading GCC.

[Lapshin]

Hi @M-Bab !

In some cases you will build xtensa toolchain code with another GCC than provided from the toolchain.

Could you please explain what you want to achieve?

There are my thoughts regarding the ticket:

• Thank you for posting the problem here I will take it into account for the next release
• This task is related to https://github.com/espressif/crosstool-NG repo. (but it's ok to continue here)
• GCC 14.1.0 does not look good for us to make an espressif toolchain release. Waiting for 14.2.0 with bug fixes. Approximately the toolchain will be released in August
• The issue you described should be resolved on newlib side https://github.com/bminor/newlib/blob/master/newlib/libc/include/stdatomic.h

[M-Bab]

Well there might be other use-cases but ours is unit testing our code. We run the tests on a local x86 platform with Ceedling/Unity/CMock. So far we never had to care about mismatches of the local x86 gcc in the system and the gcc version of the xtensa toolchain.

This is the first time it breaks.

[M-Bab]

What do you think about

#if defined(__clang__) && (__has_extension(c_atomic) || __has_extension(cxx_atomic))
#define	__CLANG_ATOMICS
#elif __GNUC_PREREQ__(4, 7)
...

[Lapshin]

@M-Bab , your change looks good!

BTW, did not catch why you need to mix toolchain internals. Anyway, you may be interested in idf.py --preview set-target linux build monitor command. It's still under development but could be useful for unit testing that does not require esp32 hardware..

[M-Bab]

BTW, did not catch why you need to mix toolchain internals.

Our unit-tests only run on the host platform - this is an x86 system. And of course it uses the GCC compiler which is installed on the host system. And this can be virtually any modern GCC. We are not mixing toolchains.

[M-Bab]

Any updates on this? Did you notify xtensa to fix this?

Other projects also started to recognize that this is an issue:

• freebsd/freebsd-src@680f40f
• eschnett/macports-ports@a747f83

[Lapshin]

@M-Bab , I sent a patch to newlib, but seems they are not interested in applying it. Thank you for posting the link to freebsd patch, it will be a good argument for dispute :)

There is a mailing list thread: https://sourceware.org/pipermail/newlib/2024/021163.html

[Lapshin]

@M-Bab , don't worry. Our next release will have all the required patches

[Lapshin]

@M-Bab , change is in newlib now https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=d001c01a7c5277194e7f8891f0228a2e3c4c64e1