search for: __cxa_end_catch

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 opti...

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 that llvm-gcc did...

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 attempts to delete E* and proceed to r...

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. Which way is correct? --- c.cpp --- #include <stdio.h> #include <stdlib.h> struct C { C(); ~C(); };...

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 the exception object, which can e...

...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 the IR prior to the CodeGen prepare passes. For the majority of platforms the intrinsics will be directly mapped to the existing function calls during one of the CodeGen prepare passes. For MSVC-environment Windows targets there is no equivalent function call to be made, but these intrinsics w...

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 %lpad121 Something thinks that this invoke will always take the unwind path, which isn't the case, and marks the Unwind block as unreachable. As a consequence of that, the call to _Unwind_SjLj_Resume()...

...appens in the different ABIs when an exception with a non-trivial copy constructor is caught. There’s an entire copy-construction that’s explicit in Itanium but which I believe is done implicitly by the personality equivalent in MSVC (necessarily, if you understand the purpose of __cxa_begin_catch/__cxa_end_catch). I agree that we should be more explicit about modeling the differences in personality-mandated code generation. Perhaps if we did this, people would stop talking about the “Itanium LSDA” when they mean the gcc/g++ LSDA. I just think there is zero benefit in pretending that we can actually mode...

> On Feb 2, 2015, at 4:53 PM, Reid Kleckner <rnk at google.com> wrote: > This seems reasonable to me. Adding John explicitly… Thanks, Reid. Andy, I understand why Windows EH needs custom lowering here, and using intrinsics seems like a fine approach, but I don’t understand why you’re proposing changing the Itanium code generation pattern. There’s no reason for backends to have

...tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*)) ; <i32> [#uses=0] 22 %2 = tail call i8* @__cxa_begin_catch(i8* %eh_ptr) nounwind ; <i8*> [#uses=0] 23 tail call void @__cxa_end_catch() 24 ret i32 0 25 } 26 27 declare i8* @__cxa_allocate_exception(i32) nounwind 28 29 declare void @__cxa_throw(i8*, i8*, void (i8*)*) noreturn 30 31 declare i8* @__cxa_begin_catch(i8*) nounwind 32 33 declare i8* @llvm.eh.exception() nounwind...

...lowing 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 %lpad121 > Something thinks that this invoke will always take the unwind path, > which isn't the case, and marks the Unwind block as unreachable. As a > consequence of that, the call to _Un...

...elementptr ([10 x i8]* @.str, i32 0, i32 0)) 60 to label %bb6 unwind label %lpad10 ; <%"struct.std::basic_ostream<char,std::char_traits<char> >"*> [#uses=0] 61 62 bb6: ; preds = %bb 63 tail call void @__cxa_end_catch() 64 ret i32 0 65 66 lpad: ; preds = %entry 67 %eh_ptr = tail call i8* @llvm.eh.exception() ; <i8*> [#uses=3] 68 %eh_select9 = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personalit...

...quot;<bb 5>": ; preds = %"<L1>" unwind "<L2>": ; preds = %"<L1>" %D.2112_2 = tail call i8* @__cxa_begin_catch(i8* %exc_ptr) nounwind tail call void @__cxa_end_catch() nounwind ret void return: ; preds = %entry ret void } define void @_Z1cv() { entry: invoke void @_Z1bv() to label %return unwind label %"<L1>" personality @__gxx_personality_v0 catches %struct.__fundamental_type_info...

...llvm.eh.resume(i8*, i32) declare void @_ZSt9terminatev() declare i32 @memcmp(i8*, i8*, i64) declare i64 @llvm.expect.i64(i64, i64) nounwind readnone declare void @_ZSt19__throw_logic_errorPKc(i8*) noreturn declare i8* @__cxa_begin_catch(i8*) declare void @__cxa_rethrow() declare void @__cxa_end_catch() declare void @__cxa_call_unexpected(i8*) declare void @_ZdlPv(i8*) nounwind declare void @_ZSt20__throw_length_errorPKc(i8*) noreturn declare void @_ZSt17__throw_bad_allocv() noreturn declare noalias i8* @_Znwm(i64) declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture,...

...) nounwind > %tmp1 = bitcast i8* %tmp0 to i32* > %exn.scalar = load i32* %tmp1, align 4 > %call = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([19 x i8]* @.str, i64 0, i64 0), > i32 %exn.scalar) optsize > tail call void @__cxa_end_catch() nounwind > br label %try.cont > > invoke.cont20: > %tmp2 = tail call i8* @__cxa_begin_catch(i8* %exn) nounwind > %tmp3 = bitcast i8* %tmp2 to double* > %exn.scalar11 = load double* %tmp3, align 8 > %call21 = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds (...

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > Inlining > -------- > > Many a plausible seeming exception handling scheme has fallen by the way-side > because it interacts poorly with inlining. > > Here is how inlining would work with this scheme. It's pretty close to how > it works right now. Suppose you have > > invoke void @foo() > to

...When trying to use a self-built version of Clang, I get an error about libc++ missing when the buildbot slave tries to build LLD. When I build and install libc++, I get unresolved symbols (GNU exception handling support routines) of the form "/usr/local/lib/libc++.so: undefined reference to `__cxa_end_catch'". As far as I am concerned, this build slave is not going be valuable in terms of quickly reporting errors (it is only 1,25 GHz, so it is simply too slow for that), but rather it will serve by testing LLD in a big-endian setting. I do hope that this build slave will reveal a number of i...

...CLANG_DEFAULT_RTLIB=compiler-rt >> LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl >> LLVM_TARGET_ARCH=x86_64 >> LLVM_TARGETS_TO_BUILD=X86 >> >> When linking libc++.so there are a lot of undefined references to __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_guard_abort, __cxa_guard_acquire, __cxa_guard_release, __cxa_pure_virtual, __cxa_rethrow, __cxa_throw, __gxx_personality_v0, _Unwind_Resume, vtable for __cxxabiv1::__class_type_info, vtable for __cxxabiv1::__si_class_type_info, vtable for __cxxabiv1::__vmi_class_type_in...

...begin_catch(i8* %exn) nounwind %tmp1 = bitcast i8* %tmp0 to i32* %exn.scalar = load i32* %tmp1, align 4 %call = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([19 x i8]* @.str, i64 0, i64 0), i32 %exn.scalar) optsize tail call void @__cxa_end_catch() nounwind br label %try.cont invoke.cont20: %tmp2 = tail call i8* @__cxa_begin_catch(i8* %exn) nounwind %tmp3 = bitcast i8* %tmp2 to double* %exn.scalar11 = load double* %tmp3, align 8 %call21 = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([18 x i8]* @.str1, i64 0, i64...

...=libc++ CLANG_DEFAULT_LINKER=lld CLANG_DEFAULT_RTLIB=compiler-rt LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl LLVM_TARGET_ARCH=x86_64 LLVM_TARGETS_TO_BUILD=X86 When linking libc++.so there are a lot of undefined references to __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_guard_abort, __cxa_guard_acquire, __cxa_guard_release, __cxa_pure_virtual, __cxa_rethrow, __cxa_throw, __gxx_personality_v0, _Unwind_Resume, vtable for __cxxabiv1::__class_type_info, vtable for __cxxabiv1::__si_class_type_info, vtable for __cxxabiv1::__vmi_class_type_in...