[cfe-dev] [atomic] 32 bit bug fixed recently?
hhinnant at apple.com
Sat Mar 9 08:17:31 PST 2013
Thanks David. On i386, and using tip-of-trunk clang, all of libc++'s atomic tests pass. Would you agree that we should mark:
as fixed by your work?
On Mar 9, 2013, at 4:53 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> Hi Howard,
> I made a number of improvements to the clang C11 atomics support last weekend. I intended to fix some poor performance on MIPS (and ARM, and anything else non-x86), but it turned out that we were generating invalid IR for a number of fairly simple operations. I don't know if this is related. There are almost certainly some more corner cases that don't work, and some fairly major issues:
> 1) We don't yet properly understand that _Atomic(T) and T can have different in-memory representations (in particular, on most non-x86 architectures, we really want to ensure that _Atomic(short) and _Atomic(char) have zeroed padding so that we can do efficient atomic operations on them - this isn't really up to us, but is something that should appear in C11 supplements to various ABIs)
> 2) We don't save and restore the floating point exception state around floating point atomic operations. I'm tempted to say that anyone who thinks that atomic operation on a floating point value should step slowly away from the computer, but the standard does allow this...
> On 8 Mar 2013, at 20:42, Howard Hinnant <hhinnant at apple.com> wrote:
>> Does anyone recognize this bug report as something that's recently been fixed in clang?
>> It is a failure only on 32 bit architecture (I only tested i386). And I can **not** reproduce it with tip-of-trunk clang, only with Apple LLVM version 4.2 (clang-425.1.16) (based on LLVM 3.2svn).
>> I'm hoping someone recognizes another bug report that I can just dup this one to.
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
More information about the cfe-dev