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

[Pete Blacker via cfe-dev]

Hi David,

I spoke too soon it turns out. That was a version control error on my part.

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?

Pete

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

>
> > On 7 Aug 2018, at 13:06, Pete Blacker via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >
> > Hi There,
> >
> > I'm currently trying to setup a build system using the tensorflow XLA
> compiler and the gaisler version of clang which generates code for the LEON
> family of CPU's.
> >
> > The problem I've hit is that the C++11 support in this version of clang
> doesn't appear to be complete, it doesn't support std::atomic. Meanwhile
> the XLA compiler is producing an IR as well as a header file for inclusion
> in the project, when compiled and linked this has a dependency on the
> library call __atomic_load_1. Which then causes a linker error : undefined
> reference to `__atomic_load_1'
> >
> > How would I go about adding these functions into this project so that
> the XLA compiler output can be successfully linked?
> >
> > I've tried adding the compiler-rt/lib/builtins/atomic.c source into the
> project but it produced the following compiler warning and failed to link
> with the same error as above:
> >
> > sparc-gaisler-elf-clang: warning: treating 'c' input as 'c++' when in
> C++ mode, this behavior is deprecated [-Wdeprecated]
> > atomic.c:162:6: warning: #pragma redefine_extname is applicable to
> external C declarations only; not applied to function '__atomic_load_c'
> [-Wpragmas]
> > void __atomic_load_c(int size, void *src, void *dest, int model) {
> >
> > Am I remotely on the right track to add support for atomic operations?
>
> Yes, I believe that the only thing that you’re doing wrong is passing
> atomic.c to clang++ instead of clang.  If you compile it with clang (or, I
> believe, with 'clang++ -x c’) separately and then link the resulting .o
> file, then it is likely to work.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180807/e06c2de0/attachment.html>