Displaying 4 results from an estimated 4 matches for "mycatch".
Did you mean:
maycatch
2010 Jul 12
1
[LLVMdev] clang/g++ frontend: can __cxa_end_catch throw?
...ang++'s code is correct (and better) because
> __cxa_end_catch won't throw for a caught exception of that type. That
> said,
Which type? There are two pending exceptions at the moment when
__cxa_end_catch is called, both with invisible destructors: E* and
unknown type thrown from mycatching(). __cxa_end_catch attempts to
delete E* and proceed to rethrow the unknown one when the other unknown
exception is thrown by E::~E(). Isn't this the condition for terminate()?
Yuri
2010 Jul 12
2
[LLVMdev] clang/g++ frontend: can __cxa_end_catch throw?
...on in case of exception. clang++
always just calls __cxa_end_catch with 'call' instruction.
Which way is correct?
--- c.cpp ---
#include <stdio.h>
#include <stdlib.h>
struct C {
C();
~C();
};
struct E {
E();
~E();
};
void mythrowing1();
void mythrowing2();
void mycatching(E *e);
void myfunc() {
try {
C c;
mythrowing1();
mythrowing2();
} catch (E *e) {
mycatching(e);
}
}
--- commands ---
/usr/local/llvm/2.7/bin/c++ -O3 -fexceptions -emit-llvm -S -o c-gcc.ll c.cpp
/usr/local/llvm/2.7/bin/clang++ -O3 -fexceptions -emit-llvm -S -o
c-clan...
2010 Jul 12
0
[LLVMdev] clang/g++ frontend: can __cxa_end_catch throw?
On Jul 12, 2010, at 3:00 AM, Yuri wrote:
> On 07/12/2010 00:23, Duncan Sands wrote:
>> IIRC, __cxa_end_catch may throw an exception because it runs the destructor
>> for the exception object, which can execute arbitrary user code and thus may
>> throw an exception. This is why it is sometimes correct to use invoke for it.
>> However in the case of your example it seems
2010 Jul 12
3
[LLVMdev] clang/g++ frontend: can __cxa_end_catch throw?
On 07/12/2010 00:23, Duncan Sands wrote:
> IIRC, __cxa_end_catch may throw an exception because it runs the destructor
> for the exception object, which can execute arbitrary user code and thus may
> throw an exception. This is why it is sometimes correct to use invoke for it.
> However in the case of your example it seems that llvm-gcc didn't optimize the
> code as well as it