[PATCH] D16614: Use "long long int" when checking whether atomics are supported.

[Daniel Sanders via llvm-commits]

> -----Original Message-----
> From: Joerg Sonnenberger [mailto:joerg at britannica.bec.de]
> Sent: 28 January 2016 00:35
> To: Daniel Sanders
> Cc: Vasileios Kalintiris; llvm-commits at lists.llvm.org
> Subject: Re: [PATCH] D16614: Use "long long int" when checking whether
> atomics are supported.
> 
> On Wed, Jan 27, 2016 at 03:23:52PM +0000, Daniel Sanders wrote:
> > > Yes, but emulations larging the native register width tend to be
> > > significantly slower and raise questions about signal safety and the
> > > like. That makes them quite important to avoid for a lot of "production"
> > > code.
> >
> > It's true that users may want to avoid them for performance reasons but
> > this doesn't mean we should fail to compile code that contains emulated
> atomics.
> 
> As I said, I believe that LLVM *should* fail to build when 64bit atomics
> are used on 32bit platforms.

I disagree with this argument on the grounds that code containing std::atomic<long long> is valid C++ and support for it is required by the C++ standard. If LLVM ever has a legitimate need for std::atomic<long long> then it should be usable even though it's less efficient on some targets.
However, I do agree that we currently don't use them in LLVM and should continue to avoid using them where better alternatives exist.

Should LLVM successfully build on a target that requires libatomic to support std::atomic<int>? I would say 'yes', do you agree?

> Nothing in the change indicates that its
> impact is limited to the libc++ test suite and.
> 
> Joerg

> Nothing in the change indicates that its impact is limited to the libc++ test suite and.

(This sentence seems to stop halfway through. Am I missing part of it?)

This patch potentially adds -latomic to the link command for the libLLVMSupport library but I see no problem with this for the reasons given above.