[cfe-dev] [Bug] Wrong Exception Handling : Destructor not called immediately

suyog sarda sardask01 at gmail.com
Fri Apr 4 09:39:20 PDT 2014


Gentle Ping !! Please help to verify if this is a bug and if my analysis is
correct.


On Tue, Apr 1, 2014 at 10:18 PM, suyog sarda <sardask01 at gmail.com> wrote:

> Hi all,
>
> This is a test g++ test case for checking correct exception handling.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *#ifdef __GXX_EXPERIMENTAL_CXX0X__#define NOEXCEPT_FALSE noexcept
> (false)#else #define NOEXCEPT_FALSE#endifextern "C" void abort (); int
> thrown;int as;struct a {  a () { ++as; }  ~a () NOEXCEPT_FALSE { --as; if
> (thrown++ == 0) throw 42; }};  int f (a const&) { return 1; }int f (a
> const&, a const&) { return 1; }int bs;int as_sav;struct b {  b (...) {
> ++bs; }  ~b ()   { --bs; as_sav = as; }};bool p;void g() {  if (p) throw
> 42;}int main () {  thrown = 0;  try {    b tmp(f (a(), a()));    g();  }
> catch (...) {}  // We throw when the first a is destroyed, which should
> destroy b before   // the other a.  if (as_sav != 1)    abort ();  thrown =
> 0;  try {    b tmp(f (a()));    g();  }    catch (...) {}   if (bs != 0)
> abort ();} *
>
> This Test Case aborts on ARM as well as X86 with clang latest trunk while
> with g++ no aborts are seen .
>
> Here, when first temporary object '*a'* gets destroyed, its destructor is
> called where we throw an exception. This should immediately call destructor
> of *'b'* and before calling constructor of second temporary object *'a'*.
> Instead, with clang, it is waiting for second temporary object *'a'* to
> get destroyed and then calling its own destructor.
>
> In my opinion, the compiler is not generating correct landing pad for the
> exception. Can someone please help in validating this reason? If it is a
> genuine bug then i will file a bug and try to work out solution for it.
>
> --
> With regards,
> Suyog Sarda
>



-- 
With regards,
Suyog Sarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140404/b0019f37/attachment.html>


More information about the cfe-dev mailing list