The functions for atomic operations described above are either implemented via compiler intrinsics (if the underlying host is capable) or by library fallbacks.
Compiler intrinsics (builtins) are always preferred. However, as
the compiler builtins for atomics are not universally implemented,
using them directly is problematic, and can result in undefined
function calls. (An example of an undefined symbol from the use
of __sync_fetch_and_add on an unsupported host is a
missing reference to __sync_fetch_and_add_4.)
In addition, on some hosts the compiler intrinsics are enabled
conditionally, via the -march command line flag. This makes
usage vary depending on the target hardware and the flags used during
compile.
Incomplete/inconsistent. This is only C++11.
If builtins are possible for bool-sized integral types,
ATOMIC_BOOL_LOCK_FREE will be defined.
If builtins are possible for int-sized integral types,
ATOMIC_INT_LOCK_FREE will be defined.
For the following hosts, intrinsics are enabled by default.
alpha
ia64
powerpc
s390
For others, some form of -march may work. On
non-ancient x86 hardware, -march=native usually does the
trick.
For hosts without compiler intrinsics, but with capable hardware, hand-crafted assembly is selected. This is the case for the following hosts:
cris
hppa
i386
i486
m48k
mips
sparc
And for the rest, a simulated atomic lock via pthreads.
Detailed information about compiler intrinsics for atomic operations can be found in the GCC documentation.
More details on the library fallbacks from the porting section.
A thin layer above IEEE 1003.1 (i.e. pthreads) is used to abstract the thread interface for GCC. This layer is called "gthread," and is comprised of one header file that wraps the host's default thread layer with a POSIX-like interface.
The file <gthr-default.h> points to the deduced wrapper for the current host. In libstdc++ implementation files, <bits/gthr.h> is used to select the proper gthreads file.
Within libstdc++ sources, all calls to underlying thread functionality use this layer. More detail as to the specific interface can be found in the source documentation.
By design, the gthread layer is interoperable with the types,
functions, and usage found in the usual <pthread.h> file,
including pthread_t, pthread_once_t, pthread_create,
etc.
The functions for atomic operations described above are either d7 1 a7 3 function calls.
Prior to GCC 4.7 the older __sync intrinsics were used.
An example of an undefined symbol from the use
d9 1
a9 7
missing reference to __sync_fetch_and_add_4.
Current releases use the newer __atomic intrinsics,
which are implemented by library calls if the hardware doesn't support them.
Undefined references to functions like
__atomic_is_lock_free should be resolved by linking to
libatomic, which is usually
installed alongside libstdc++.
d29 1
a29 1
Detailed information about compiler intrinsics for atomic operations can be found in the GCC documentation. @ 1.1.1.2.16.1 log @Sync with HEAD @ text @d2 1 a2 1
The functions for atomic operations described above are either @ 1.1.1.2.14.1 log @Sync with HEAD, resolve a couple of conflicts @ text @d2 1 a2 1
The functions for atomic operations described above are either @ 1.1.1.3 log @import GCC 6.5.0. this is largely a maint release with no particularly features listed here: http://gcc.gnu.org/gcc-6/changes.html this fixes over 250 PRs in the GCC bugzilla: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.5 @ text @d2 1 a2 1
The functions for atomic operations described above are either @ 1.1.1.4 log @initial import of GCC 9.3.0. changes include: - live patching support - shell completion help - generally better diagnostic output (less verbose/more useful) - diagnostics and optimisation choices can be emitted in json - asan memory usage reduction - many general, and specific to switch, inter-procedure, profile and link-time optimisations. from the release notes: "Overall compile time of Firefox 66 and LibreOffice 6.2.3 on an 8-core machine was reduced by about 5% compared to GCC 8.3" - OpenMP 5.0 support - better spell-guesser - partial experimental support for c2x and c++2a - c++17 is no longer experimental - arm AAPCS GCC 6-8 structure passing bug fixed, may cause incompatibility (restored compat with GCC 5 and earlier.) - openrisc support @ text @d47 1 a47 1 use this layer. More detail as to the specific interface can be found in the source documentation. @ 1.1.1.5 log @initial import of GCC 10.3.0. main changes include: caveats: - ABI issue between c++14 and c++17 fixed - profile mode is removed from libstdc++ - -fno-common is now the default new features: - new flags -fallocation-dce, -fprofile-partial-training, -fprofile-reproducible, -fprofile-prefix-path, and -fanalyzer - many new compile and link time optimisations - enhanced drive optimisations - openacc 2.6 support - openmp 5.0 features - new warnings: -Wstring-compare and -Wzero-length-bounds - extended warnings: -Warray-bounds, -Wformat-overflow, -Wrestrict, -Wreturn-local-addr, -Wstringop-overflow, -Warith-conversion, -Wmismatched-tags, and -Wredundant-tags - some likely C2X features implemented - more C++20 implemented - many new arm & intel CPUs known hundreds of reported bugs are fixed. full list of changes can be found at: https://gcc.gnu.org/gcc-10/changes.html @ text @d2 1 a2 1
Detailed information about compiler intrinsics for atomic operations can be found in the GCC documentation. d47 1 a47 1 use this layer. More detail as to the specific interface can be found in the source documentation. @ 1.1.1.1.8.1 log @file ext_concurrency_impl.html was added on branch tls-maxphys on 2014-08-19 23:54:46 +0000 @ text @d1 44 @ 1.1.1.1.8.2 log @Rebase to HEAD as of a few days ago. @ text @a0 44
The functions for atomic operations described above are either implemented via compiler intrinsics (if the underlying host is capable) or by library fallbacks.
Compiler intrinsics (builtins) are always preferred. However, as
the compiler builtins for atomics are not universally implemented,
using them directly is problematic, and can result in undefined
function calls. (An example of an undefined symbol from the use
of __sync_fetch_and_add on an unsupported host is a
missing reference to __sync_fetch_and_add_4.)
In addition, on some hosts the compiler intrinsics are enabled
conditionally, via the -march command line flag. This makes
usage vary depending on the target hardware and the flags used during
compile.
Incomplete/inconsistent. This is only C++11.
If builtins are possible for bool-sized integral types,
ATOMIC_BOOL_LOCK_FREE will be defined.
If builtins are possible for int-sized integral types,
ATOMIC_INT_LOCK_FREE will be defined.
For the following hosts, intrinsics are enabled by default.
alpha
ia64
powerpc
s390
For others, some form of -march may work. On
non-ancient x86 hardware, -march=native usually does the
trick.
For hosts without compiler intrinsics, but with capable hardware, hand-crafted assembly is selected. This is the case for the following hosts:
cris
hppa
i386
i486
m48k
mips
sparc
And for the rest, a simulated atomic lock via pthreads.
Detailed information about compiler intrinsics for atomic operations can be found in the GCC documentation.
More details on the library fallbacks from the porting section.
A thin layer above IEEE 1003.1 (i.e. pthreads) is used to abstract the thread interface for GCC. This layer is called "gthread," and is comprised of one header file that wraps the host's default thread layer with a POSIX-like interface.
The file <gthr-default.h> points to the deduced wrapper for the current host. In libstdc++ implementation files, <bits/gthr.h> is used to select the proper gthreads file.
Within libstdc++ sources, all calls to underlying thread functionality use this layer. More detail as to the specific interface can be found in the source documentation.
By design, the gthread layer is interoperable with the types,
functions, and usage found in the usual <pthread.h> file,
including pthread_t, pthread_once_t, pthread_create,
etc.
The functions for atomic operations described above are either implemented via compiler intrinsics (if the underlying host is capable) or by library fallbacks.
Compiler intrinsics (builtins) are always preferred. However, as
the compiler builtins for atomics are not universally implemented,
using them directly is problematic, and can result in undefined
function calls. (An example of an undefined symbol from the use
of __sync_fetch_and_add on an unsupported host is a
missing reference to __sync_fetch_and_add_4.)
In addition, on some hosts the compiler intrinsics are enabled
conditionally, via the -march command line flag. This makes
usage vary depending on the target hardware and the flags used during
compile.
Incomplete/inconsistent. This is only C++11.
If builtins are possible for bool-sized integral types,
ATOMIC_BOOL_LOCK_FREE will be defined.
If builtins are possible for int-sized integral types,
ATOMIC_INT_LOCK_FREE will be defined.
For the following hosts, intrinsics are enabled by default.
alpha
ia64
powerpc
s390
For others, some form of -march may work. On
non-ancient x86 hardware, -march=native usually does the
trick.
For hosts without compiler intrinsics, but with capable hardware, hand-crafted assembly is selected. This is the case for the following hosts:
cris
hppa
i386
i486
m48k
mips
sparc
And for the rest, a simulated atomic lock via pthreads.
Detailed information about compiler intrinsics for atomic operations can be found in the GCC documentation.
More details on the library fallbacks from the porting section.
A thin layer above IEEE 1003.1 (i.e. pthreads) is used to abstract the thread interface for GCC. This layer is called "gthread," and is comprised of one header file that wraps the host's default thread layer with a POSIX-like interface.
The file <gthr-default.h> points to the deduced wrapper for the current host. In libstdc++ implementation files, <bits/gthr.h> is used to select the proper gthreads file.
Within libstdc++ sources, all calls to underlying thread functionality use this layer. More detail as to the specific interface can be found in the source documentation.
By design, the gthread layer is interoperable with the types,
functions, and usage found in the usual <pthread.h> file,
including pthread_t, pthread_once_t, pthread_create,
etc.