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.
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...
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?
I'd mark it as 'closed -> please test'. My changes didn't explicitly try to fix it, but I did find when I started writing test cases that most things were broken.