Trying to add __atomic_load_x support to a sparc-gaisler-elf-clang++ project

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?

Any ideas would be greatly appreciated.

Pete

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

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

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

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.