https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Chung-Lin Tang from comment #3) > (In reply to Sebastian Huber from comment #2) > > (In reply to Chung-Lin Tang from comment #1) > > > Sebastian, I'm not sure what your problem is. The atomics in nios2 are > > > implemented by __sync_* functions placed in libgcc. The built-in function > > > expansion inside GCC is aware of this, and __atomic_* functions get mapped > > > to those. Is there anything affecting your use? > > > > I think this mapping of __atomic_* functions to __sync_* functions is > > wrong/outdated. Is this a speciality of the Nios II support? I am not > > aware of a second target support in GCC which does this. The __sync_* > > builtins are a legacy API: > > > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins. > > html#g_t_005f_005fsync-Builtins > > Nios II is not the only target which implements __sync_*, see the libgcc > source code for details. The libgcc is not relevant for code generation as far as I know. 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. > > In the current GCC code expansion paths, the __atomic_* functions are meant > to expand to hardware instruction sequences. In cases where we need to > generate library calls for atomics, GCC only generates __sync_* calls. Only on Nios II it seems, the other targets emit __atomic_* calls. > > > > > > > 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): /* Locking for a "small" operation. In the bare-metal single processor cases this could be implemented by disabling interrupts. Thus the extra word passed between the two functions, saving the interrupt level. It is assumed that the object being locked does not cross the locking granularity. Not actually declared here so that they can be defined static inline in a target-specfic <host-config.h>. UWORD protect_start (void *ptr); void protect_end (void *ptr, UWORD); */ /* Locking for a "large' operation. This should always be some sort of test-and-set operation, as we assume that the interrupt latency would be unreasonably large. */ void libat_lock_n (void *ptr, size_t n); void libat_unlock_n (void *ptr, size_t n);
