Fatal error stdatomic h no such file or directory

Description of problem:
fatal error: stdatomic.h: No such file or directory

Version-Release number of selected component (if applicable):
[root@storageqe-31 fio]# rpm -qf /usr/bin/gcc
gcc-4.8.5-44.el7.x86_64


How reproducible:
100%

Steps to Reproduce:
1. compiling the latest fio source code
2.
3.

Actual results:


Expected results:


Additional info:
# cd fio && ./configure && make && make install
STDOUT:
Operating system              Linux
CPU                           x86_64
Big endian                    no
Compiler                      gcc
Cross compile                 no

Static build                  no
Wordsize                      64
zlib                          yes
Linux AIO support             yes
Linux AIO support rw flags    no
Linux AIO over io_uring       no
POSIX AIO support             yes
POSIX AIO support needs -lrt  yes
POSIX AIO fsync               yes
POSIX pshared support         yes
pthread_condattr_setclock()   yes
pthread_sigmask()             yes
Solaris AIO support           no
__sync_fetch_and_add          yes
__sync_synchronize            yes
__sync_val_compare_and_swap   yes
libverbs                      no
rdmacm                        no
asprintf()                    yes
vasprintf()                   yes
Linux fallocate               yes
POSIX fadvise                 yes
POSIX fallocate               yes
sched_setaffinity(3 arg)      yes
sched_setaffinity(2 arg)      no
clock_gettime                 yes
CLOCK_MONOTONIC               yes
CLOCK_MONOTONIC_RAW           yes
CLOCK_MONOTONIC_PRECISE       no
clockid_t                     yes
gettimeofday                  yes
fdatasync                     yes
pipe()                        yes
pipe2()                       yes
pread()                       yes
sync_file_range               yes
EXT4 move extent              yes
Linux splice(2)               yes
GUASI                         no
libnuma                       no
strsep                        yes
strcasestr                    yes
strlcat                       no
getopt_long_only()            yes
inet_aton                     yes
socklen_t                     yes
__thread                      yes
RUSAGE_THREAD                 yes
SCHED_IDLE                    yes
TCP_NODELAY                   yes
Net engine window_size        yes
TCP_MAXSEG                    yes
RLIMIT_MEMLOCK                yes
pwritev/preadv                yes
pwritev2/preadv2              no
IPv6 helpers                  yes
http engine                   no
Rados engine                  no
Rados Block Device engine     no
setvbuf                       yes
Gluster API engine            no
s390_z196_facilities          no
HDFS engine                   no
MTD                           yes
libpmem                       yes
libpmemblk                    yes
PMDK pmemblk engine           yes
PMDK dev-dax engine           yes
PMDK libpmem engine           yes
DDN's Infinite Memory Engine  no
iscsi engine                  no
NBD engine                    no
lex/yacc for arithmetic       no
getmntent                     yes
getmntinfo                    no
Static Assert                 yes
bool                          yes
strndup                       yes
Valgrind headers              no
Zoned block device support    no
libzbc engine                 no
march_armv8_a_crc_crypto      no
cuda                          no
Build march=native            yes
CUnit                         no
__kernel_rwf_t                no
-Wimplicit-fallthrough=2      no
MADV_HUGEPAGE                 yes
gettid                        no
statx(2)/libc                 no
statx(2)/syscall              no
TCMalloc support              no
make[1]: Entering directory `/mnt/tests/kernel/storage/NVDIMM/btt_md_randio/fio'
make[1]: Leaving directory `/mnt/tests/kernel/storage/NVDIMM/btt_md_randio/fio'
make[1]: Entering directory `/mnt/tests/kernel/storage/NVDIMM/btt_md_randio/fio'
    CC crc/crc16.o
    CC crc/crc32.o
    CC crc/crc32c-arm64.o
make[1]: Leaving directory `/mnt/tests/kernel/storage/NVDIMM/btt_md_randio/fio'
STDERR:FIO_VERSION = fio-3.20-57-g6532
In file included from crc/crc32c.h:23:0,
                 from crc/crc32c-arm64.c:1:
crc/../arch/arch.h:4:23: fatal error: stdatomic.h: No such file or directory
 #include <stdatomic.h>
                       ^
compilation terminated.
make[1]: *** [crc/crc32c-arm64.o] Error 1

Comment 2

Marek Polacek

2020-06-23 16:18:38 UTC

stdatomic.h was only added in gcc4.9 so it's expected that this file is missing in gcc4.8.

You can use the Developer Toolset which provides newer versions of gcc.

Comment 3

Zhang Yi

2020-06-24 03:14:42 UTC

It works now

[root@hpe-dl380gen9-01 fio]# scl enable devtoolset-7 bash
[root@hpe-dl380gen9-01 fio]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-7/root/usr --mandir=/opt/rh/devtoolset-7/root/usr/share/man --infodir=/opt/rh/devtoolset-7/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --with-default-libstdcxx-abi=gcc4-compatible --with-isl=/builddir/build/BUILD/gcc-7.3.1-20180303/obj-x86_64-redhat-linux/isl-install --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) 

[root@hpe-dl380gen9-01 fio]# rpm -qa devtoolset-7-gcc
devtoolset-7-gcc-7.3.1-5.16.el7.x86_64

Comment 4

Marek Polacek

2020-06-24 14:01:17 UTC

Great.  DTS7 is unsupported so I'd recommend using DTS 9, if possible.

Description

Jeff Hammond

2013-07-28 18:18:34 UTC

GCC 4.8.1 provides a -std=c11 option that defines __STDC_VERSION__ >= 201112L and does not define __STDC_NO_ATOMICS__, hence is required to provide stdatomic.h.  This requirement is not met.

This ticket is closely related to 53769 but I am not reporting the fact that the macros aren't defined, but rather the missing header.

> cat test-c11-atomics.c 
#if __STDC_VERSION__ >= 201112L
# ifdef __STDC_NO_ATOMICS__
#  error Your C11 compiler is not required to provide stdatomic.h
# else
#  include <stdatomic.h>
# endif
#else
# error Your C compiler isn't providing C11.
#endif

int main(int argc, char * argv[])
{
    return 0;
}

> gcc-mp-4.8 -g -Wall -std=c11 test-c11-atomics.c 
test-c11-atomics.c:4:23: fatal error: stdatomic.h: No such file or directory
 #include <stdatomic.h>
                       ^
compilation terminated.

> gcc-mp-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-mp-4.8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-4.8.1/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8.1_0'
Thread model: posix
gcc version 4.8.1 (MacPorts gcc48 4.8.1_0) 

> uname -a
Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64

Comment 1

joseph@codesourcery.com

2013-07-28 19:27:20 UTC

I don't know whether Andrew intends stdatomic.h to go in GCC or glibc, but 
in any case I consider this a duplicate of bug 53769, which in turn I 
don't really consider a useful bug report at all (incompleteness of the 
implementation of an option documented in the manual as incomplete should 
not be considered a bug).

Comment 2

Jeff Hammond

2013-07-28 20:42:50 UTC

If GCC doesn't support C11, it should not claim to support C11 via __STDC_VERSION__.  The C11 standard definition isn't a recommendation from which implementers can pick and choose based upon their priorities.  Documentation an implementations failure to comply with a standard does not absolve an implementation from lying about its features with ISO standard macros.  The macro is part of the standard; the documentation is not.

In any case, there is an absolutely trivial way for GCC to satisfy the C11 standard with respect to stdatomic.h, and it involves __STDC_NO_ATOMICS__.  The failure to define this macro or to provide stdatomic.h make GCC non-compliant with C11, in which case __STDC_VERSION__ is defined improperly.

Comment 3

Jonathan Wakely

2013-07-29 10:27:35 UTC

Noone disputes it's not conforming. The point is the support is incomplete. It's known to be incomplete. It's documented as incomplete.  Reporting a bug to say it's incomplete doesn't serve any useful purpose, it will be complete when it's completed.

Comment 4

joseph@codesourcery.com

2013-07-29 13:43:27 UTC

__STDC_VERSION__ describes *intent* of command-line options (as regards 
differences between standard versions, to the extent that those are 
implemented).  This is the same principle that has been documented for 
__STDC__ since at least GCC 2.0.

  "Sometimes people say that defining @code{__STDC__} in a compiler that
  does not completely conform to the ANSI C standard somehow violates the
  standard.  This is illogical.  The standard is a standard for compilers
  that are supposed to conform.  It says nothing about what any other
  compilers should do.  Whatever the ANSI C standard says is relevant to
  the design of plain @samp{gcc} without @samp{-ansi} only for pragmatic
  reasons, not as a requirement."

(quoted from the GCC 2.0 manual).

As a pragmatic matter, it's useful for users of standards modes that are 
incomplete to be able to tell which of those modes is in use, and 
__STDC_VERSION__ is the natural macro to define to distinguish between 
them.  gcc -std=c11 is a compiler explicitly claimed not to conform.

Comment 5

Jeff Hammond

2013-07-29 16:15:18 UTC

Can someone tell me where the appropriate place to define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ in GCC so I can submit a patch?  I'd rather solve the problem and take 1-2 steps forward towards C11 compliance rather than debate the philosophical aspects of the problem.

Comment 6

Jeff Hammond

2013-07-29 16:33:58 UTC

Created attachment 30568 [details]
patch to define macros indicating missing C11 support

If GCC defines __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__, it is no longer non-compliant w.r.t. C11 to not provide stdatomic.h and threads.h.  This would resolve bugs 53769 and 58016, albeit in a trivial way.

I will not be surprised at all if this patch is rejected, if for no other reason than my institution has not signed a contributor agreement with FSF (they almost certainly will if I ask).  My goal is to inspire someone else to do it properly since it seems trivial and arguably necessary.

Comment 7

joseph@codesourcery.com

2013-07-29 16:39:32 UTC

__STDC_NO_THREADS__ is defined in glibc's stdc-predef.h because it 
describes combination compiler and library properties.

The correct fix for atomics for 4.9 will be to implement them - see Andrew 
MacLeod's patches and recent discussion on gcc-patches - and the state of 
C11 in 4.8 is what it is and 4.8 is subject to normal release branch rules 
(regression and documentation fixes only, generally).

Comment 8

Jeff Hammond

2013-07-29 18:45:55 UTC

My patch was w.r.t. the trunk as of earlier today, not 4.8 but that's fine.  I just subscribed to various GCC lists to track these developments.

I'll apply my patch locally so that I can use 4.8.1 and get the desired behavior.

There is a related forum post with the title «Atomic variables in XC32» but it’s locked… silly.  The «answer» to that post states that yes, xc32 does support the new c++11 stdatomic.h.

 I’m not an expert, but after quite a bit of effort sorting this out, I believe this is NOT exactly the case for PIC32MX and PIC32MZ devices.

 The gcc documentation (gcc-4.8.5) which the previous post points you to states the compiler has a legacy «__sync» built-in function — but if you search the xc32 v2.15 compiler documentation and there is not mention of such an atomic operation built-in function. I even tried making a new new hello world project in MPLabX 5x as was not able to get it to compile when using __sync.

 The gcc documentation (gcc-4.8.5) which the previous post also points you to states the compiler also has «Built-in functions for memory model aware atomic operations» such as, for example «__atomic_add_fetch» — but the compiler documentation for xc32 v2.15 also makes no mention of any __atomic_xxx named built-in functions. Furthermore, there is no mention of built-in atomic operations inside of section «D.2 Built-in Function Descriptions.»  Trying to make the compiler compile something with, for example __atomic_add_fetch does not work.

 Can some compiler expert chime in here are explain where the hole in our logic is?  Even though xc32 is «based» on gcc, we seem to be completely missing these built-in functions (my test compiler sates this during compilation: GNU C++ (Microchip Technology) version 4.8.3 MPLAB XC32 Compiler v2.15 pic32mx.

 Why, if xc32 is based on GCC, would it not include these built-in functions? Why would it be missing stdatomic.h as well? What else is missing?  Is there a list of deviations from true GCC functionality for xc32?  

 Back story (if you’re interested):

 I’m trying to make RIOT os (https://www.riot-os.org/) compile on a PIC32MZ with xc32 v2.15. Has anyone else tried to do this? I wonder if I’m the only person on planet earth that has tried this…

I’m running into an error trying to compile a simple hello world example using xc32-g++:
…/RIOT/core/atomic_c11.c:40:23: fatal error: stdatomic.h: No such file or directory
#include <stdatomic.h>

 I get a similar error (missing stdatomic.h) when compiling with xc32-gcc as well.  Also note, there is a pic32mx-wifire board in the RIOT source tree but this is built using real GCC with MIPS support (not using xc32).

 Searching the xc32/v2.15/pic32mx/ folder tree shows there is no «atomic.h» or «stdatomic.h.»

 What else is interesting is that the SAM and AVR parts (arm) which use xc32/v2.15/pic32c/ folder tree does have stdatomic.h!

 Another interesting thing is that the RIOT os source tree has a /cpu/mips430_common/include/stdatomic.h — and in that file there is a note about how the file was copied into the source tree from newLib v2.3.0.  The folder tree xc32/v2.15/pic32mx/include/newlib does NOT have a stdatomic.h file though.  It appears that PIC32 devices can be compiled with newlib support, but even that library seems to be missing stuff from the real newLib source tree!

 Can anyone explain any of this? 

 Thanks.