[BUG] ESP32C3 implicit declaration of `ATOMIC_VAR_INIT`

[linguini1]

Description / Steps to reproduce the issue

Reproduce:

$ ./tools/configure.sh esp32c3-xiao:nimble
$ make -j
Cloning Espressif HAL for 3rd Party Platforms
Clone: chip/esp-hal-3rdparty   % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
  0      0   0      0   0      0      0      0                              0LN: platform/board to /home/linguini/coding/nuttx-space/apps/platform/dummy
  0      0   0      0   0      0      0      0                              0
100  1.77M   0  1.77M   0      0  1.28M      0           00:01          1.39M
Register: dumpstack
Register: hello
Register: dd
Register: nimble
Register: nsh
Register: sh
Espressif HAL for 3rd Party Platforms: cleaning current repository...
Espressif HAL for 3rd Party Platforms: d41c921a724da2b4955832ca9d4b117b004b61c6
Espressif HAL for 3rd Party Platforms: initializing submodules...
Applying patches...
chip/esp-hal-3rdparty/components/esp_hw_support/esp_gpio_reserve.c:13:47: error: implicit declaration of function 'ATOMIC_VAR_INIT'; did you mean 'ATOMIC_FLAG_INIT'? [-Wimplicit-function-declaration]
   13 | static _Atomic uint64_t s_reserved_pin_mask = ATOMIC_VAR_INIT(~(SOC_GPIO_VALID_GPIO_MASK));
      |                                               ^~~~~~~~~~~~~~~
      |                                               ATOMIC_FLAG_INIT
chip/esp-hal-3rdparty/components/esp_hw_support/esp_gpio_reserve.c:13:47: error: initializer element is not constant
CC:  obstack/lib_obstack_copy.c make[1]: *** [Makefile:144: chip/esp-hal-3rdparty/components/esp_hw_support/esp_gpio_reserve.o] Error 1
make[1]: *** Waiting for unfinished jobs....
CC:  mmap/fs_anonmap.c make: *** [tools/LibTargets.mk:170: arch/risc-v/src/libarch.a] Error 2
make: *** Waiting for unfinished jobs....

It appears this is an issue in the ESP32 HAL.

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Linux 6.19.11-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 02 Apr 2026 23:33:01 +0000 x86_64 GNU/Linux

NuttX Version

master

Issue Architecture

[Arch: risc-v]

Issue Area

[Area: Board support]

Host information

$ make host_info
No matching array found.

Looks like another bug with make host_info?

Verification

• I have verified before submitting the report.

[linguini1]

I should note my version of riscv-none-elf-gcc is 15.2.0. So maybe something in stdatomic is not being included properly?

[simbit18]

Hi @linguini1, I’ve just run a test using this tool #18568

CMake and Make built without any errors

Nuttx repository: apache/nuttx
    Nuttx branch: master
 Apps repository: apache/nuttx-apps
     Apps branch: master
          Config: esp32c3-xiao:nimble
    Build system: all

Workflow -> Manually Compiling with Make or Cmake for test

https://github.com/simbit18/manual-nuttx-ci/actions/runs/24962040078

[linguini1]

Thanks @simbit18 ! Do you know what version of gcc is used there? Maybe it's an issue with my environment.

[simbit18]

@linguini1 Use the Nuttx Docker image
https://github.com/apache/nuttx/blob/master/tools/ci/docker/linux/Dockerfile

RISCV GCC toolchain

nuttx/tools/ci/docker/linux/Dockerfile

Line 253 in b2b78d2

curl -s -L "https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/download/v14.2.0-3/xpack-riscv-none-elf-gcc-14.2.0-3-linux-x64.tar.gz" \

GCC

nuttx/tools/ci/docker/linux/Dockerfile

Line 383 in b2b78d2

# Set GCC-12 as Default compiler

[linguini1]

Hmmm looks like mine is a new version, maybe I'll try that version

[eren-terzioglu]

Hi,

We are using dockerfile suggested version of toolchain and we did not face any issue. It should be related to version but also worth to have a look because we will to switch newer version one day. Thanks for reporting

[linguini1]

After looking into this issue further, it appears the problem is:

__STDC_VERSION___ = 201710L with my compiler, which means that the shim definition of ATOMIC_VAR_INIT is not being defined. However, the definition isn't pulled from anywhere else. Either:

• The check should be __STDC_VERSION__ >= 201710L
• OR my toolchain should be finding some other <stdatomic.h> definition but it isn't

The clang toolchain's stdatomic.h says:

#if ((defined(__stdc_version__) && __stdc_version__ >= 201710l &&              \
      __stdc_version__ < 202311l) ||                                           \
     (defined(__cplusplus) && __cplusplus >= 202002l)) &&                      \
    !defined(_clang_disable_crt_deprecation_warnings)
/* atomic_var_init was deprecated in c17 and c++20. */
#pragma clang deprecated(atomic_var_init)
#endif

which leads me to believe that the check should use >=.

riscv-none-elf-gcc has the following definition in stdatomic.h:

#if defined(__CLANG_ATOMICS)
#define	ATOMIC_VAR_INIT(value)		(value)
#define	atomic_init(obj, value)		__c11_atomic_init(obj, value)
#else
#define	ATOMIC_VAR_INIT(value)		{ .__val = (value) }
#define	atomic_init(obj, value)		((void)((obj)->__val = (value)))
#endif

So it should be defined properly. Maybe this header is not getting found properly somehow.

EDIT: the header stdatomic.h in arch/risc-v/src/esp32c3/esp-hal-3rdparty/components/esp_libc/platform_include/ is not getting included in the build as far as I can tell. But, this is a good thing (sort of), because adding that path as an include with -I causes a bunch of other things to be re-defined.

[linguini1]

It appears the C version is set to 202311L, and so when the stdatomic.h file included with riscv-none-elf-gcc is included, this definition:

#if !(defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L)
#define ATOMIC_VAR_INIT(VALUE)	(VALUE)
#endif

is not compiled, so there is no definition of ATOMIC_VAR_INIT. ESP32's HAL does not define it either/their definition is not getting included. This causes the error.

My work-around for now has been adding #define ATOMIC_VAR_INIT(value) (value) in the file that fails to compile, but it would be great if the Espressif team could patch the HAL?

[eren-terzioglu]

Nice catch, we will try to reproduce error in our setup and try to find best fit solution.

Thanks for detailed reporting. We will check that.