[cfe-dev] Representing the allocation in CXXNewExpr

Jordan Rose jediknil at belkadan.com
Sat Mar 31 18:51:22 PDT 2012


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?


>> - 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 clients.

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.

Jordy



More information about the cfe-dev mailing list