[cfe-dev] [LLVMdev] [LLVMDev] Object in a try-catch block not being destroyed even after an exception

John McCall rjmccall at apple.com
Tue Jun 19 14:15:24 PDT 2012

On Jun 19, 2012, at 12:19 PM, Joshua Cranmer wrote:
> What clang is generating can be approximated by the following pseudocode:
> atmp1, atmp2, btmp = alloca space for temporaries
> call a::a on atmp1
> try {
>   call a::a on atmp2
>   try {
>     call f(atmp1, atmp2)
>     call b::b on btmp
>   } catch {
>   } finally {
>     call a::~a on atmp2
>   }
> } catch {
> } finally {
>   call a::~a on atmp1
> }
> // NOW b is "constructed"
> Looking at the output IR, the best interpretation I can give is that Clang is cleaning up the temporary arguments before calling the new variable constructed. The question, of course, is whether or not this is legal per the C++ spec. C++11 section 12.2, par 3 states that
>> Temporary objects are destroyed as the last step
>> in evaluating the full-expression (1.9) that (lexically) contains the point where they were created.
> Section 1.9, par 10 has an example which states that the full expression associated with the call to the constructor in this case is indeed the actual constructor call.
> Section 15.2, par 1 states:
>> As control passes from a throw-expression to a handler, destructors are invoked for all automatic objects
>> constructed since the try block was entered. The automatic objects are destroyed in the reverse order of the
>> completion of their construction.
> I'm not 100% what the correct interpretation is in this case. It comes down to whether b should be considered constructed before or after the full expression of the declarator is completed.

b should be considered constructed as soon as its constructor completes.  This is a bug in clang.


More information about the cfe-dev mailing list