[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