[cfe-dev] Why the argument of `delete' is converted to void* ?

Enea Zaffanella zaffanella at cs.unipr.it
Sun Jul 8 10:46:20 PDT 2012


On 07/05/2012 11:53 PM, John McCall wrote:
> On Jul 4, 2012, at 10:13 AM, Enea Zaffanella wrote:
>> On 07/04/2012 05:07 PM, Jean-Daniel Dupas wrote:
>>> Le 4 juil. 2012 à 15:57, Enea Zaffanella a écrit :
>> [...]
>>>> Sorry for the misunderstanding, but the original question was not
>>>> really meant to be restricted to classes having a trivial destructor
>>>> (if you add a non-trivial destructor to class S then "delete ps" will
>>>> call it, whereas "operator delete(ps)" will not).
>>>>
>>>> To rephrase my question: since in the general case "delete ps" may
>>>> also call the destructor, why is its argument (always) converted to void*?
>>>>
>>>> Cheers,
>>>> Enea.
>>>
>>>
>>> AFAIK, even with a non trivial destructor, the code always end up
>>> calling the operator delete(void *) to free the memory.
>>
>> Yes, the argument of "operator delete" has to be converted to a void*.
>>
>> But this, afaict, is an inner implementation detail that should not be
>> exposed in the AST (or it should be exposed elsewhere, e.g., in a method
>> named getOperatorDeleteArg).
>>
>> The argument of the CXXDeleteExpr is *not* subject to such an implicit
>> conversion; as a matter of fact, the implicit conversion (if made
>> explicit by the user) would change the semantics of the delete
>> expression by killing the call of the destructor.
>
> It's a bug in the AST;  Sema is doing an implicit conversion to void* in order
> to not have to implement custom logic for deleting values of record type, but
> it should at least be dropping the extra ICE when it does so.  IR-generation
> has to awkwardly work around this.
>
> John.

Can you please review the attached patch?
(It passes all tests in clang.)

Thanks,
Enea.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CXXDeleteExpr.patch
Type: text/x-diff
Size: 2682 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120708/3d62d49e/attachment.patch>


More information about the cfe-dev mailing list