Skip to content

Order of destructor call of temporary and __cxa_throw #62062

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
strimo378 opened this issue Apr 11, 2023 · 4 comments
Closed

Order of destructor call of temporary and __cxa_throw #62062

strimo378 opened this issue Apr 11, 2023 · 4 comments
Labels
clang:codegen IR generation bugs: mangling, exceptions, etc. question A question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead!

Comments

@strimo378
Copy link
Contributor

strimo378 commented Apr 11, 2023

I might have found an issue with the order of destructor call of a temporary and the call to the __cxa_throw function within a throw statement.

In the following code, the Clang frontend first calls __cxa_throw and afterwards a::~a. See https://godbolt.org/z/jbx74s1Ge

struct a {
  ~a() noexcept;
};
struct b {
  b(a) noexcept;
};
void c() {throw b(a()); }

GCC generates it in opposite order which is more logical to me. ICC generates it in the same order as Clang. I don't know what is correct from the C++ standard, maybe it is undefined.

@strimo378
Copy link
Contributor Author

Maybe the problem is related to #50865

@strimo378
Copy link
Contributor Author

strimo378 commented Apr 11, 2023

Okey, it looks like that clang is correct and GCC not. I found the following text in the C++ standard [class.temporary]:

When an implementation introduces a temporary object of a class that has a non-trivial constructor (15.1,
15.8) , it shall ensure that a constructor is called for the temporary object. Similarly, the destructor shall be
called for a temporary with a non-trivial destructor (15.4) . Temporary objects are destroyed as the last step
in evaluating the full-expression (4.6) that (lexically) contains the point where they were created. This is true
even if that evaluation ends in throwing an exception.
The value computations and side effects of destroying
a temporary object are associated only with the full-expression, not with any specific subexpression.

@EugeneZelenko EugeneZelenko added clang:codegen IR generation bugs: mangling, exceptions, etc. and removed new issue labels Apr 11, 2023
@llvmbot
Copy link
Member

llvmbot commented Apr 11, 2023

@llvm/issue-subscribers-clang-codegen

@shafik
Copy link
Collaborator

shafik commented Apr 11, 2023

It does look like that is what the standard says

CC @MaskRay who might be able to give some insights here as well.

@EugeneZelenko EugeneZelenko added the question A question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead! label Aug 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:codegen IR generation bugs: mangling, exceptions, etc. question A question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead!
Projects
None yet
Development

No branches or pull requests

4 participants