similar to: [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

Hi Yuri, > When I compile a piece of C++ with exceptions into .ll I see that gcc > frontend in some cases calls __cxa_end_catch with 'call' and in other > cases with 'invoke' with termination in case of exception. clang++ > always just calls __cxa_end_catch with 'call' instruction. IIRC, __cxa_end_catch may throw an exception because it runs the destructor for

On 07/12/2010 12:41, John McCall wrote: > For your test case, clang++'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

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

When I try running simple example with exceptions through JIT I get this output: terminate called after throwing an instance of 'E*' Why exceptions don't work in JIT and what it takes to make them work? Yuri --- e.C --- #include <stdio.h> #include <stdlib.h> class E { }; void xmain() { try { throw new E; } catch (E *e) { printf("caught!\n");

On 06/21/2010 11:14, Reid Kleckner wrote: > Yes, I have some version of 7.1 installed on my workstation and it works for me. I repeted what you did step by step and it still doesn't work for me, see log below. Two differences: I am on FreeBSD and it's 32 bit. It's svn revision 105825. Plus I have few unrelated patched applied to it which shouldn't matter. Yuri $ lli

On Sat, Jun 19, 2010 at 8:53 PM, Yuri <yuri at rawbw.com> wrote: > I have followed http://llvm.org/docs/DebuggingJITedCode.html, used the > latest release gdb-7.1 (from March 18, 2010) and got this stack: > > (gdb) bt > #0  0x35532156 in ?? () > #1  0x355320f8 in ?? () > #2  0x35532098 in ?? () > #3  0x3553202e in ?? () > #4  0x34a5661a in ?? () > #5  0x349d9bd9

Here is what I did: I took c.C (attached), compiled it into my.ll code with command 'clang++ -O3 -fexceptions -emit-llvm -S -o my.ll c.C' and added tracing command on every line, see attached my.ll Running my.ll in interpreter with this command 'llvm-as my.ll && lli -jit-enable-eh my.bc', I get this log: TRACE num=20 TRACE num=22 TRACE num=27 TRACE num=29 TRACE num=31

Since FreeBSD is an ELF target, this should work fine. I've also tested that this works in 32-bit by building gdb and llvm in 32-bit mode and testing this stuff while running on a 64-bit OS. I would try setting a breakpoint in gdb on 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being called, and that getELFWriterInfo returns something. If that function actually

Hello, I am trying to install rgl package under R and getting some errors which is below. > install.packages("rgl") Warning in install.packages("rgl") : argument 'lib' is missing: using '/usr/lib/R/library' trying URL 'http://cran.csie.ntu.edu.tw/src/contrib/rgl_0.91.tar.gz' Content type 'application/x-gzip' length 1677498 bytes (1.6 Mb)

Hello, am I wrong or the ARM c++ exceptions handling does not work? See the difference between assembly generated by clang and gcc with the following test code: #include <stdio.h> #include <exception> # test.cpp int main() { try { throw 20; } catch (int e) { printf("Exception Nr %d occurred\n", e); } return 0; }

Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove "junk files" it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, and even more importantly if I can I restore what was lost. Panickingly, Jarrod [jarrod at localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file

Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove "junk files" it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, and even more importantly if I can I restore what was lost. Panickingly, Jarrod [jarrod at localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file

Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove "junk files" it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, and even more importantly if I can I restore what was lost. Panickingly, Jarrod [jarrod at localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file 'MCMCglmm_2.05/DESCRIPTION'

I have C++ project that builds fine with g++. But when I try to replace g++ with clang++ I get such errors (see below) during link. What might be a problem? Yuri --- errors are like this --- local symbol 1: discarded in section `.text.SomeSymbolHere1' local symbol 2: discarded in section `.text.SomeSymbolHere2' ... ...

All, The following relatively simple function is behaving oddly under SJLJ exception handling. Specifically, it's being diagnosed by the optimizer as being a nounwind function, which is obviously incorrect. From what I can tell so far, something is going wrong analyzing the call to __cxa_end_catch() invoke arm_apcscc void @__cxa_end_catch() to label %Unwind unwind label

Dear all, I have tried installing "rgl" with the usual command: R CMD INSTALL rgl_0.67-2.tar.gz Differently from what happened last time I have succesfully installed this package, this time there was a failure: ... ...g++ -I/usr/lib/R/include -I/usr/lib/R/include -I -DHAVE_PNG_H -I/usr/include/libpng12 -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2

I have followed http://llvm.org/docs/DebuggingJITedCode.html, used the latest release gdb-7.1 (from March 18, 2010) and got this stack: (gdb) bt #0 0x35532156 in ?? () #1 0x355320f8 in ?? () #2 0x35532098 in ?? () #3 0x3553202e in ?? () #4 0x34a5661a in ?? () #5 0x349d9bd9 in ?? () #6 0x08052cd9 in main (argc=4, argv=0xbfbfe264, envp=0xbfbfe278) at

Hi all, I brought this up last week in an LLVMDev discussion of C++ EH support on Windows, but I thought I should float it again with a subject that would be less likely to be missed by people who don't have a direct interest in Windows support. I would like to introduce two new intrinsics, llvm.eh.begincatch and llvm.eh.endcatch, to take the place of __cxa_begin_catch and __cxa_end_catch in

On 6 February 2014 19:21, Richard Smith <richard at metafoo.co.uk> wrote: > > if (nounwind) > can't unwind > can't unwind == unwind table + no EH directives + no EH table if (uwtable || (!nounwind && need uwtable to unwind)) > unwind table > "need unwind table to unwind" is probably true in almost all cases. At least in all where