On Sep 21, 2011, at 5:53 PM, Eli Friedman wrote: > On Wed, Sep 21, 2011 at 11:34 AM, John McCall <[email protected]> wrote: >> On Sep 21, 2011, at 11:30 AM, Eli Friedman wrote: >>> On Wed, Sep 21, 2011 at 10:39 AM, John McCall <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
