[cfe-commits] r154640 - in /cfe/trunk: include/clang/Basic/Builtins.def lib/AST/ExprConstant.cpp lib/CodeGen/CGBuiltin.cpp lib/CodeGen/CGExpr.cpp lib/Frontend/InitPreprocessor.cpp test/CodeGen/atomic-ops.c test/Sema/atomic-ops.c

[Richard Smith]

On Fri, Apr 13, 2012 at 2:53 AM, Sebastian Redl <
sebastian.redl at getdesigned.at> wrote:

> On 13.04.2012 02:45, Richard Smith wrote:
> > Author: rsmith
> > Date: Thu Apr 12 19:45:38 2012
> > New Revision: 154640
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=154640&view=rev
> > Log:
> > Implement the missing pieces needed to support libstdc++4.7's<atomic>:
> > __atomic_test_and_set, __atomic_clear, plus a pile of undocumented
> __GCC_*
> > predefined macros.
> >
> > Implement library fallback for __atomic_is_lock_free and
> > __c11_atomic_is_lock_free, and implement __atomic_always_lock_free.
> >
> > Contrary to their documentation, GCC's __atomic_fetch_add family don't
> > multiply the operand by sizeof(T) when operating on a pointer type.
> > libstdc++ relies on this quirk. Remove this handling for all but the
> > __c11_atomic_fetch_add and __c11_atomic_fetch_sub builtins.
> >
> This is scary. Do we have any idea how to handle it if GCC 4.8 fixes
> this? They can, since they just fix libstdc++ at the same time, but it
> will be a problem for us.


I don't have a good answer for this (suggestions welcome!). I've pinged
someone on the gcc side to find if this is intentional or a bug, but
haven't heard back yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120414/7f7b9a09/attachment.html>