[cfe-dev] Trying to add __atomic_load_x support to a sparc-gaisler-elf-clang++ project

Pete Blacker via cfe-dev cfe-dev at lists.llvm.org
Tue Aug 7 08:48:22 PDT 2018


Since I'm working in a single threaded environment I created a stub which
always returned true. I'm stuck with the atomic dependencies from
tensorflow even though it's a single core target.

The project now builds successfully, although I'm back at the run time
error now! Definitely getting closer though,

Thanks for the help.

On Tue, Aug 7, 2018 at 2:20 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:

> On 7 Aug 2018, at 14:10, Pete Blacker <pete.blacker at gmail.com> wrote:
> >
> > atomic.c now compiles without warning but it's failing to link with a
> lot of undefined reference to `__atomic_is_lock_free' errors. This is
> definitely progress!
> >
> > Is this simply a case of adding another source file from the llvm
> builtins?
>
> This one is harder.  These are all meant to be compiler-provided builtins
> that tell the system whether it can do atomic operations of a particular
> size or whether it needs to do a library call (or, in the case of the stuff
> in atomic.c, use a lock).
>
> You might be able to get away with providing a stub definition of
> __atomic_is_lock_free that always returns false.  This should then cause
> the library functions to use a mutex.  You will need a compiler that can at
> least provide a simple compare and swap to implement a spinlock though… (or
> you’ll need to add a new locking implementation in atomic.c that uses some
> assembly for your target).
>
> David
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180807/565ecd0c/attachment.html>


More information about the cfe-dev mailing list