[cfe-dev] Representing the allocation in CXXNewExpr
matthieu.monrocq at gmail.com
Sun Apr 1 02:28:29 PDT 2012
Le 1 avril 2012 03:51, Jordan Rose <jediknil at belkadan.com> a écrit :
> On Mar 30, 2012, at 18:46, John McCall wrote:
> > On Mar 30, 2012, at 2:34 PM, Jordan Rose wrote:
> >> - Itanium name-mangling, which currently skips the size argument. The
> Itanium spec does seem to imply that this is correct (the size is skipped
> for the expression but not for the allocator function's name), but there's
> no clause dealing specifically with new and new.
> > This is actually a bug, since the size operand of a new could be
> instantiation-dependent and therefore affect overload resolution. I'll
> raise that with the ABI list.
> I think this is actually not an issue:
> C++11[basic.std.dynamic.allocation]p1 says "The first parameter shall have
> type std::size_t". So it can't affect overload resolution, right?
Is not `std::size_t` a typedef though ? I think the underlying type could
vary, especially between 32 bits and 64 bits platform.
> >> - CodeGen: We need to know the array+cookie size for the call to the
> allocator and the array size alone for the call to the initializer.
> >> That last one is the killer. Teaching CXXOperatorCallExpr to just skip
> its first argument for printing and mangling wouldn't be so bad, but I'm
> not so happy about computing the array size again for the initializer call.
> And if we extract it from the arguments list, we just have to subtract the
> cookie size off again.
> > And the fact that IR-gen has to give special treatment to the fact that
> the computation can overflow. I assume that's been covered elsewhere here.
> Right, this behavior is already correct now, and we'd wrap it up in the
> handling of "CXXAllocSizeExpr" or whatever. Still doesn't solve the
> double-calculation problem, though. (We don't /really/ need to handle the
> overflow case for the second calculation, though, because our recovery is
> just to make the allocation fail by passing an all-ones value.)
> > To be perfectly honest, it sounds like this proposal is just
> complicating the representation of CXXNewExpr without significantly
> reducing the amount of special-case work that needs to be done in the
> I'm still on the fence myself; the original impetus for this (for me) was
> to improve the analyzer's model of new-expressions. If everyone agrees
> CXXOperatorCallExpr is the wrong way to go, we'll make up a new CFG node to
> represent the allocation instead.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev