The atomic builtins won't be present on architectures that lack atomic instructions (ie superh, 32 bit sparc, arm v5)
In some cases Linux fakes the presence of atomic instructions with kernel assistance, so people can fall into the trap of thinking the atomic builtins are always available. On Mon, Dec 03, 2012 at 12:29:33AM -0600, Richard Allen wrote: > I'm trying to benchmark my MicroSPARC (Sparc Classic Lunchbox). > However, one of the tests I wrote cannot be linked. > > The arch is: > bash-4.2$ uname -a > OpenBSD sparky.Grr_Not_Open_No_Mores 5.1 GENERIC#36 sparc > > The code is here: https://github.com/rsaxvc/monte-carlo-benchmark > The SHA hash I used was: cb7d5aae08d1f52aed5dcbd25719a32999887d77 > The compile flags were: -O4 -D MODE_ATOMIC_OPERATORS > I also used gmake > > The GCC version is: > bash-4.2$ g++ --version > g++ (GCC) 4.2.1 20070719 > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > The result was: > ^C$ gmake mc_atomics > g++ -O4 -c -o mc_atomics.o main.cpp -D MODE_ATOMIC_OPERATORS > g++ -lpthread mc_atomics.o -o mc_atomics > mc_atomics.o(.text+0x118): In function `montecarlo_pi(void*)': > : undefined reference to `__sync_fetch_and_add_4' > collect2: ld returned 1 exit status > gmake: *** [mc_atomics] Error 1 > $ > > > It appears that my code > "__sync_fetch_and_add( <ptr_to_a_size_t_which_is_effectively_uint32_here>, 1 > )" > gets converted to a call to __sync_fetch_and_add_4 ( meaning 4-byte ). > This is normal > for platforms where the CPU does not have the needed atomic operations. > However, > what is supposed to happen is that the libraries provided by GCC > supply those functions > and do it themselves. Those functions appear to be missing. See: > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html > > "Not all operations are supported by all target processors. If a > particular operation cannot be implemented on the target processor, a > warning will be generated and a call an external function will be > generated. The external function will carry the same name as the > builtin, with an additional suffix `_n' where n is the size of the > data type." > > > This bug could be because the platform does support the needed atomic > operations, but the compiler doesn't know that, and the library does > know it, so it doesn't build the functions. > > Or it could be because the platform doesn't support the needed atomic > operations, and the library is just missing the functions. > > > > I realize this bug falls under #4 - Repeatable problems specific to > your hardware layout, so it won't bother me if you don't get around to > it. Thanks a lot for publishing a current operating system even for my > old 50MHz workstation. > > -Richard
