https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #7 from Chung-Lin Tang <cltang at gcc dot gnu.org> --- (In reply to Sebastian Huber from comment #6) > (In reply to Chung-Lin Tang from comment #5) > > > I checked the code generation on some targets for the test case above. The > > > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets > > > generated all __atomic_* functions. > > > > > Only on Nios II it seems, the other targets emit __atomic_* calls. > > > > Many of those target archs use __sync_* by default on Linux, although you > > might generate __atomic_* on bare metal. > > That's the case on nios2; we should be generating __atomic_* calls if you're > > using nios2 ELF (bare metal), for Linux the compiler will generate __sync_* > > calls, unless the architecture has hardware instructions. > > This sounds reasonable. Which magic switch in GCC leads to the generation > of __sync_* functions instead of __atomic_* functions? You can use -fno-sync-libcalls to force OFF __sync_* and generate __atomic_* calls, if that's really what you want (although we have not implemented that kind of runtime support). > > > Implementing __atomic_* functions via __sync_* in libatomic makes no sense > > > to me. The host specific implementation should provide (libatomic_i.h): > > > > Most architectures don't have library implementations of __atomic_* > > operations, especially if we already have __sync_*. The major difference is > > the consistency model arguments in __atomic_* APIs, which is useless for > > simpler architectures like nios2. > > The __sync_* stuff is deprecated. A user can always use the __atomic_* API, the compiler will take care of the rest.
