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.

Reply via email to