[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
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
Hope it helps,
On 12/17/15 03:28 PM, Chris.Dewhurst via cfe-dev wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev