search for: lang_eh_catch_all

...es > > not causes the unwinder to go into a loop. this is the bit I don't understand. Why does it go into a loop? How can the unwinder possibly know that the original code did not have a catch-all, since we tell it which catches there are and we say: there is a catch-all! > > - lang_eh_catch_all = return_null_tree; > > +/* lang_eh_catch_all = return_null_tree;*/ > Ok, cool :) Duncan, Anton, what do you guys think about this? This is wrong - it breaks the semantics of invoke and causes eh to not work properly in some cases (see my email to Dale). Ciao, Duncan.

...============================================ > --- cp/except.c (revision 44663) > +++ cp/except.c (working copy) > @@ -104,7 +104,7 @@ > lang_eh_runtime_type = build_eh_type_type; > lang_protect_cleanup_actions = &cp_protect_cleanup_actions; > /* LLVM local */ > - lang_eh_catch_all = return_null_tree; > +/* lang_eh_catch_all = return_null_tree;*/ > } > > /* Returns an expression to be executed if an unhandled exception is > > and that works well for me; i.e., the gcc tests that exercise > exceptions work as well with the > two patches above (on x8...

...the IP because the IP of the throw and Unwind_Resume call were different, but when caching the CFA they are the same, which confuses Unwind_Resume. (This is darwin's unwinder but I think the patch I quoted is the only relevant change to generic gcc code. Could be wrong.) >>> - lang_eh_catch_all = return_null_tree; >>> +/* lang_eh_catch_all = return_null_tree;*/ > >> Ok, cool :) Duncan, Anton, what do you guys think about this? > > This is wrong - it breaks the semantics of invoke and causes > eh to not work properly in some cases (see my email to Dale). Well,...

...except.c =================================================================== --- cp/except.c (revision 44663) +++ cp/except.c (working copy) @@ -104,7 +104,7 @@ lang_eh_runtime_type = build_eh_type_type; lang_protect_cleanup_actions = &cp_protect_cleanup_actions; /* LLVM local */ - lang_eh_catch_all = return_null_tree; +/* lang_eh_catch_all = return_null_tree;*/ } /* Returns an expression to be executed if an unhandled exception is and that works well for me; i.e., the gcc tests that exercise exceptions work as well with the two patches above (on x86) as they did before. Now I need s...

...Are you sure that this isn't simply a bug in where labels are placed etc, the frame info or the exception table setup etc? > (This is darwin's unwinder but I think the patch I quoted is the only > relevant change to generic gcc code. > Could be wrong.) > > >>> - lang_eh_catch_all = return_null_tree; > >>> +/* lang_eh_catch_all = return_null_tree;*/ > > > >> Ok, cool :) Duncan, Anton, what do you guys think about this? > > > > This is wrong - it breaks the semantics of invoke and causes > > eh to not work properly in some cases...

...ptions a lot. > I guess an easy but undesirable fallback position is to tell the > inliner not to inline anything that invokes Unwind_Resume. If you push a "cleanup" instead of a catch-all on Darwin, does everything work? This is exactly what you get if you apply your patch - lang_eh_catch_all = return_null_tree; +/* lang_eh_catch_all = return_null_tree;*/ Ciao, Duncan.

Hi Anatoly, > any ideas what library has these symbols > > lang_eh_catch_all > get_pointer_alignment > validate_arglist it sounds like you are trying to build a version of llvm-gcc without LLVM enabled. Did you specify --enable-llvm=path_to_llvm_build_directory when configuring llvm-gcc? These symbols are all defined in llvm-gcc itself, but only when ENABLE_LLVM is...

On Dec 9, 2007, at 1:01 PM, Duncan Sands wrote: > Hi Dale, > >> #include <cstdio> >> class A { >> public: >> A() {} >> ~A() {} >> }; >> void f() { >> A a; >> throw 5.0; >> } >> main() { >> try { >> f(); >> } catch(...) { printf("caught\n"); } >> } > > this example

any ideas what library has these symbols lang_eh_catch_all get_pointer_alignment validate_arglist i get these linker errors when trying to link llvm-gcc: make[1]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' make[2]: Entering directory `/home/anatolyy/qctp406/pakman/depot...

...vm-gcc-4.2-2.7.source/gcc/config/arm/lib1funcs.asm:1004: Error: backward ref to unknown label "8:" Thanks, Anatoly On Mon, May 24, 2010 at 12:52 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Anatoly, > >> any ideas what library has these symbols >> >> lang_eh_catch_all >> get_pointer_alignment >> validate_arglist > > it sounds like you are trying to build a version of llvm-gcc without LLVM > enabled.  Did you specify --enable-llvm=path_to_llvm_build_directory when > configuring llvm-gcc?  These symbols are all defined in llvm-gcc itself, &...

...easy but undesirable fallback position is to tell the >> inliner not to inline anything that invokes Unwind_Resume. > > If you push a "cleanup" instead of a catch-all on Darwin, does > everything work? This is exactly what you get if you apply your > patch > > - lang_eh_catch_all = return_null_tree; > +/* lang_eh_catch_all = return_null_tree;*/ No, things are much better than there were, but inlining functions that call Unwind_Resume still causes the problem we've been talking about. Disabling that as well makes everything work.