search for: cfa_offset

Hi all, Here's a potential patch for LLVM-GCC: Index: llvm-convert.cpp =================================================================== --- llvm-convert.cpp (revision 41260) +++ llvm-convert.cpp (working copy) @@ -4240,11 +4240,12 @@ return false; int cfa_offset = ARG_POINTER_CFA_OFFSET(0); - - Result = Builder.CreateCall(Intrinsic::getDeclaration(TheModule, - Intrinsic::eh_dwarf_cfa), - ConstantInt::get(Type::Int32Ty, cfa_offset)); - + Result = + Builder.CreateCall(Intr...

Bill, > The reason for it: when going to calculate the CFA in LLVM, the > original code was adding an offset of type i32 to a pointer. This is > fine if pointers are 32-bits, but we get an assert if the types are > different. By converting the cfa_offset to a pointer, we get it to be > that size. Please ignore my prev. e-mail. The code breaks at least 32-bit stuff. The arg of eh_dwarf_cfa is i32, how it can be pointer? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Bill > The reason for it: when going to calculate the CFA in LLVM, the > original code was adding an offset of type i32 to a pointer. This is > fine if pointers are 32-bits, but we get an assert if the types are > different. By converting the cfa_offset to a pointer, we get it to be > that size. How do you like the one attached? It seems to be much more clear to fix codegen :) Only slightly tested. If this looks ok to you - I'll commit tomorrow. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Peter...

...er argument; handle remember/restore. (lookup_cfa): Pass remember argument. (cfa_remember): New. (compute_barrier_args_size_1): Remove sibcall check. (dwarf2out_frame_debug_def_cfa): New. (dwarf2out_frame_debug_adjust_cfa): New. (dwarf2out_frame_debug_cfa_offset): New. (dwarf2out_frame_debug_cfa_register): New. (dwarf2out_frame_debug_cfa_restore): New. (dwarf2out_frame_debug): Handle REG_CFA_* notes. (dwarf2out_begin_epilogue): New. (dwarf2out_frame_debug_restore_state): New. (dw_cfi_oprnd1_desc): Handle DW_C...

On Sep 18, 2009, at 10:43 AM, Jack Howarth wrote: > On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote: >> So, when these test cases are run, is the binary linked against /usr/ >> lib/libgcc_s.10.5.dylib? or against some just built libgcc_s. >> 10.5.dylib? >> or against some just build libgcc_s.dylib? If either of the >> latter, then >> if you

On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote: > So, when these test cases are run, is the binary linked against /usr/ > lib/libgcc_s.10.5.dylib? or against some just built libgcc_s.10.5.dylib? > or against some just build libgcc_s.dylib? If either of the latter, then > if you changed the FSF build of libgcc_s for darwin to have the right > magic symbols, then