Showing results for 
Search instead for 
Did you mean: 
New Contributor I

stdatomic.h missing 24 atomic types

C11 requires many atomic_* types be defined in stdatomic.h (see § 7.16.6), and both GCC and clang have them all in their stdatomic.h implementations, but 24 of them are missing in ICC (at least in 16.0.3).  This reproduces the problem:

#include <stdatomic.h>

int main(int argc, char *argv[])
  atomic_bool a;
  atomic_char b;
  atomic_schar c;
  atomic_uchar d;
  atomic_short e;
  atomic_ushort f;
  atomic_int g;
  atomic_uint h;
  atomic_long i;
  atomic_ulong j;
  atomic_llong k;
  atomic_ullong l;
  atomic_char16_t m;
  atomic_char32_t n;
  atomic_wchar_t o;
  atomic_int_least8_t p;
  atomic_uint_least8_t q;
  atomic_int_least16_t r;
  atomic_uint_least16_t s;
  atomic_int_least32_t t;
  atomic_uint_least32_t u;
  atomic_int_least64_t v;
  atomic_uint_least64_t w;
  atomic_int_fast8_t x;
  atomic_uint_fast8_t y;
  atomic_int_fast16_t z;
  atomic_uint_fast16_t aa;
  atomic_int_fast32_t ab;
  atomic_uint_fast32_t ac;
  atomic_int_fast64_t ad;
  atomic_uint_fast64_t ae;
  atomic_intptr_t af;
  atomic_uintptr_t ag;
  atomic_size_t ah;
  atomic_ptrdiff_t ai;
  atomic_intmax_t aj;
  atomic_uintmax_t ak;
  return 0;

The missing types are:

  • atomic_char16_t
  • atomic_char32_t
  • atomic_int_least8_t
  • atomic_uint_least8_t
  • atomic_int_least16_t
  • atomic_uint_least16_t
  • atomic_int_least32_t
  • atomic_uint_least32_t
  • atomic_int_least64_t
  • atomic_uint_least64_t
  • atomic_int_fast8_t
  • atomic_uint_fast8_t
  • atomic_int_fast16_t
  • atomic_uint_fast16_t
  • atomic_int_fast32_t
  • atomic_uint_fast32_t
  • atomic_int_fast64_t
  • atomic_uint_fast64_t
  • atomic_intptr_t
  • atomic_uintptr_t
  • atomic_size_t
  • atomic_ptrdiff_t
  • atomic_intmax_t
  • atomic_uintmax_t
0 Kudos
6 Replies
New Contributor I

Additional fun: ICC doesn't support the atomic type specifier (_Atomic), so I can't just do something like typedef _Atomic int_fast32_t atomic_fast32_t myself.

C11 atomics seem to be a bit of a mess in ICC :(

Black Belt

Did you invoke icc with -std=c11 and with valid GCC on path?

New Contributor I

Yes, I've tried in C11 mode.  That was my first thought, too…  Sorry, I should have mentioned that it didn't make a difference.

I'm not sure what you mean by "with valid GCC on path"; I have gcc and clang installed and working properly (this is on Fedora 24, and they are packages installed from the official repos), and ICC picks up system headers fine.  I'm not sure what that has to do with anything, though.  stdatomic.h is provided by each compiler in compiler-specific directories and not used with other compilers.  For ICC, it's in ${icc_install_prefix}/compilers_and_libraries_2016.3.210/linux/compiler/include/stdatomic.h.  Also, the error isn't about the compiler not being able to find stdatomic.h, it's about stdatomic.h being found but not including the information required by C11.

Even if ICC were using GCC or clang's stdatomic.h it wouldn't work because they both define their atomic types using the _Atomic type qualifier, which ICC doesn't seem to support.  The _Atomic type qualifier doesn't require you to include stdatomic.h… the only time it needn't be available (in C11 mode at least, though AFAIK all compilers which support it make it available in all modes) is if the compiler defined __STDC_NO_ATOMICS__ (see § of the C11 standard).

Black Belt

I confirm the same problem with the 2017 beta compiler also.  I'm not having any luck finding any reference on the degree to which c11 support is planned, beyond this:

.  You may need to submit the question on your support account if you don't get an answer from the compiler team after the holiday tomorrow is over.

New Contributor I

Tim P. wrote:
I confirm the same problem with the 2017 beta compiler also.

D'oh.  I was wondering about that.  Thanks for checking… the result wasn't what I was hoping for, but it's good to know.

Tim P. wrote:

Nice, I hadn't seen that.  Intel should really be defining __STDC_NO_ATOMICS__ if they don't fully support C11 atomics.  Right now, code like

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 201112L) && !defined(__STDC_NO_ATOMICS__)
/* Do C11 atomics stuff which ICC doesn't support */

Doesn't work with ICC, and it really should.  I now have a "!defined(__INTEL_COMPILER)" in that list of conditions, but it's really not fair to ask people to do that.

However, this also brings up the issue of GCC compatibility.  With GCC (and clang) I am free to use C11 atomics in C99 mode, so I have a test to see if GCC is ≥ 4.9 (first version which actually included stdatomic.h) and, if so, use C11 atomics even in c99/c89/gnu99/gnu89 mode.  Since icc masquerades as a version of GCC ≥ 4.9 (mine pretends to be GCC 6.1.1) it should accept the same superset of C that GCC does, which puts icc in a pretty tough spot.

Clang works around this by masquerading as an older version of GCC (4.2.1, at least for clang 3.8.0) but implementing feature detection macros (__has_builtin, __has_attribute, __has_extension, __has_feature, __has_warning, __has_include, __has_include_next, and __has_declspec_attribute).  I would really like to see ICC add support for those macros (or something similar), and only increment the version of GCC it masquerades as when it supports 100% of what that version of GCC supports (modulo bugs, of course).

Tim P. wrote:
You may need to submit the question on your support account if you don't get an answer from the compiler team after the holiday tomorrow is over.

I don't have access.  I have a free license for open source development (which is the context I'm running into this issue in).  That said, I've reported issues here in the past with success, I'm confident someone at Intel will notice it soon.



What version of the compiler are you using? As you surmised C11 _Atomic support is missing from our compiler as documented here

This also means we have implemented our own version of stdatomic.h which as you noted may not have all of the functionality of the GNU/Clang ones.

We cannot comment on plans for upcoming releases.

We do define the appropriate feature macros to indicate the feature is missing, i.e. in 16.0 I see the following:

sptxl15-168> cat tt.c

#if defined(__STDC_NO_ATOMICS__)
HERE __STDC_NO_ATOMICS__ is defined

sptxl15-169> icc -E tt.c
# 1 "tt.c"

HERE 1 is defined

sptxl15-170> icc -V
Intel(R) C Compiler for applications running on IA-32, Version 16.0 Beta Build x
Built Jul 14 2016 11:28:06 by jward4 on sptxl15 in /home/nsl/jward4/d/workspaces/16_0cfe/dev
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.


When you say the feature macro doesn't work with ICC can you give more info such as the version of ICC, the version of GNU or Clang, and what compiler flags you are using?