Re: [PATCH, libbacktrace] SPU does not support __sync or __atomic

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Ian Lance Taylor wrote:
> On Fri, Aug 28, 2015 at 9:54 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> >
> > this is the (hopefully) last compatibility problem with libbacktrace on SPU:
> > we do not have either the __sync or the __atomic routines (since the SPU
> > is a fundamentally single-threaded target).
> 
> I guess I don't understand.  These are GCC intrinsic functions that
> ought to be supported on every target.  There are many processors
> other than the SPU that are fundamentally single-threaded.  That
> doesn't mean they can't support these functions; it just means that
> their implementation is trivial.
> 
> When I look at the docs for the __sync and __atomic functions I don't
> see anything saying "these functions are only available on some
> targets."

Well, I had always understood that those routines are only available on
some processors.  The __sync builtin docs say:

  Not all operations are supported by all target processors.  If a particular
  operation cannot be implemented on the target processor, a warning is
  generated and a call to an external function is generated.

And the __atomic builtin docs say:

  If there is no pattern or mechanism to provide a lock-free instruction
  sequence, a call is made to an external routine with the same parameters
  to be resolved at run time.

And then there's a bunch of predefined macros to check:

  @item __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1
  @itemx __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
  @itemx __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
  @itemx __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
  @itemx __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
  These macros are defined when the target processor supports atomic compare
  and swap operations on operands 1, 2, 4, 8 or 16 bytes in length, respectively.

Now, I guess you might say that this is about processors that *cannot*
implement an atomic operation.  On the SPU, we could implement the trivial
single-threaded version; on the other hand, I don't see any other target
do so, so I thought we're supposed to do so.

If the intent is that single-threaded targets are supposed to implement
trivial atomic operations, I guess I can do that for SPU.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com