[cfe-dev] ___atomic_XXX operations in libcxx for Sparc

Vladimir Voskresensky - Oracle via cfe-dev cfe-dev at lists.llvm.org
Tue Dec 22 00:59:41 PST 2015

Hello Chris,

I've asked an engineer from Oracle to answer:
but reply is not propagated back to this list, so here you are:


I'm assuming you are talking about porting LLVM to Solaris SPARC.

The library support for C++11 atomics feature is already available on Solaris 
11. It is in a separate library called libatomic.so in /usr/lib though. You 
could try if this solves your immediate problem.

This library is not a Solaris system library, it comes from GCC 4.8. So you may 
need to install some GCC runtime library packages. If LLVM depends on this 
library, it is vulnerable to an ABI change, is it why you think there could be 
resistance? There is some effort going to to standardize the ABI of this 
library, not sure if you are interested?

The sized version (with a _n suffix) can also be implemented by back-end 
generating inlined code because all of them can be implemented with lock-free 
instructions, so it does not need locks or other meta data supported by a 
runtime library.

- Bin


Hope it helps,

On 12/17/15 03:28 PM, Chris.Dewhurst via cfe-dev wrote:
> Hi,
> I am further developing the compiler back-end for Sparc for LLVM and I have 
> some tests which the requirements of my project need to pass. They are using 
> __atomic__XXX operations in libcxx, 
> e.g. __atomic_compare_exchange_1, __atomic_fetch_xor_2 (among others).
> These are not implemented currently for Sparc and if I 
> understand http://libcxx.llvm.org/docs/http://libcxx.llvm.org/docs/ correctly, 
> the relevant library containing these inbuilt functions are only implemented 
> for i386 and x86_64.
> However, I still need to get these working. There could be some resistance if 
> I suggest using the GCC libraries to solve this problem, but I assume that 
> it's a very non-trivial task to port this library to Sparc.
> Would my assumption be correct here? Could anyone give me an estimate for the 
> amount of time it might take to port this? Even a scientific wild-ass guess 
> (SWAG) would be better than what I could currently make.
> What options do I have?
> If I'm reading this situation incorrectly and it's potentially trivial to 
> implement these for Sparc, how might I go about this easily? If not, is it 
> possible to use the GCC libraries to support this behaviour? Are there any 
> other options?
> Best Regards,
> Chris Dewhurst,
> University of Limerick.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151222/8603a276/attachment.html>

More information about the cfe-dev mailing list