[cfe-commits] [PATCH] Initial clang support for C++0x atomic operations

John McCall rjmccall at apple.com
Wed Sep 21 21:53:40 PDT 2011


On Sep 21, 2011, at 5:53 PM, Eli Friedman wrote:

> On Wed, Sep 21, 2011 at 11:34 AM, John McCall <rjmccall at apple.com> wrote:
>> On Sep 21, 2011, at 11:30 AM, Eli Friedman wrote:
>>> On Wed, Sep 21, 2011 at 10:39 AM, John McCall <rjmccall at apple.com> wrote:
>>>> On Sep 20, 2011, at 7:02 PM, Eli Friedman wrote:
>>>>> Attached.  Adds AtomicExpr nodes, creates them in Sema, and lowers
>>>>> them in IRGen.
>>>> 
>>>> Why is this a new expression node instead of a builtin call with custom
>>>> typechecking?
>>> 
>>> The return type of (most of) the builtins depends on the type of the
>>> first argument... can we model that without a new expression node?
>> 
>> Yes.  All the GCC atomic builtins are overloaded like this.  Just mark the
>> builtin as requiring custom type-checking.
>> 
>> There are also several builtins which take l-value operands, if that's important.
> 
> Hmm... the issue here, which the GCC atomic builtins don't face, is
> that we need arbitrary return types.  And I'm not sure if the AST will
> be completely happy with a call where the return type of the callee is
> different from the return type of the call?

Hmm, I see what you mean;  I had forgotten how the GCC atomics were
done.  I'm not actually very happy with how the GCC atomics are done,
actually. :)

My thinking was that the usual AST invariants should not be guaranteed
in the presence of a builtin call, and I still think that's abstractly
reasonable, but it looks like it'd force some new complexity into
the system.  Let's talk about this off-line tomorrow when Doug is
around to weigh in.

John.



More information about the cfe-commits mailing list