https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #5 from Chung-Lin Tang <cltang at gcc dot gnu.org> --- > 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. > > > > > > > > libatomic is usually supported by those targets with more "rich" atomic > > > > instructions, and nios2 in its current form is obviously not one of > > > > them. > > > > > > The libatomic is for architectures which lack atomic instructions. > > > > To clarify/correct my above statement, we do build libatomic like other > > targets, but the basic __atomic_* functions used inside it is also generated > > as __sync_* calls. > > > > libatomic does NOT directly "implement" the basic __atomic_* operations, > > that's supposed to be done inside the compiler. > > > > Can you more specifically describe what you're trying to do? Or is this just > > a general query? > > I don't find any Nios II specific parts in libatomic. > > 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.
