[cfe-dev] Representing the allocation in CXXNewExpr

[John McCall]

On Mar 31, 2012, at 6:51 PM, Jordan Rose wrote:
> 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?

The size operand of an array allocation can fail to instantiate at particular template arguments, causing the template to be ignored by SFINAE.

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

Yeah, I think when you're adding new AST nodes which cannot conceivably be generalized, you're not actually improving the abstraction.

And even though I implemented it in clang, I've always been a bit skeptical of the "passing -1 to operator new[]" trick, because it's not actually sanctioned by the standard.  I would treat that as an ABI-specific implementation detail rather than something that should necessarily be modeled by the CFG.  The language just says that overflow causes an exception to be thrown.

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

It's interesting, because I can understand the desire to catch bugs involving the allocation and deallocation operators.  On the other hand, there is a *lot* of situation-specific special case logic for this stuff.

John.