similar to: [LLVMdev] emitting dwarf debug info on mach fails with assert

Hi, What is the best way to debug an llc crash using bugpoint? I am getting the following crash that I would like to reduce llc: /home/vadve/aggarwa4/llvm29/llvm-2.9/lib/MC/MCAsmStreamer.cpp:273: virtual void<unnamed>::MCAsmStreamer::EmitLabel(llvm::MCSymbol*): Assertion `Symbol->isUndefined() && "Cannot define a symbol twice!"' failed. 0 llc

Do something like this: bugpoint -run-llc <bitcode file> --tool-args -- <llc arguments> Cameron On May 23, 2011, at 1:33 PM, Arushi Aggarwal wrote: > Hi, > > What is the best way to debug an llc crash using bugpoint? > > I am getting the following crash that I would like to reduce > > llc: /home/vadve/aggarwa4/llvm29/llvm-2.9/lib/MC/MCAsmStreamer.cpp:273:

DwarfDebug::emitDebugInfo() always appends four zero bytes to the tail of the debug info section: emitDIE(Die); // FIXME - extra padding for gdb bug. Asm->OutStreamer.AddComment("4 extra padding bytes for GDB"); Asm->EmitInt8(0); Asm->EmitInt8(0); Asm->EmitInt8(0); Asm->EmitInt8(0);

On Fri, Jul 16, 2010 at 11:25 AM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi Michael, > > Overall patch looks good. I do have a few comments below. My main > comment is please try to make the style match that used in the > MCMachOStreamer more closely. I intend to refactor more functionality > into the base MCObjectStreamer class, and having them use consistent >

Hi Erick, Thanks, this looks good. Can you please resubmit this patch, and the others, as an attachment? On Mar 4, 2008, at 03:19, Erick Tryzelaar wrote: > --- > bindings/ocaml/llvm/llvm.ml | 2 +- > bindings/ocaml/llvm/llvm.mli | 2 +- > bindings/ocaml/llvm/llvm_ocaml.c | 2 +- > include/llvm-c/Core.h | 32 ++++++++++++++++++ > +-------------

--- bindings/ocaml/llvm/llvm.ml | 2 +- bindings/ocaml/llvm/llvm.mli | 2 +- bindings/ocaml/llvm/llvm_ocaml.c | 2 +- include/llvm-c/Core.h | 32 +++++++++++++++++++------------- 4 files changed, 22 insertions(+), 16 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 316a84e85ed2363551149e65a227c8e7c8192624.diff Type:

Hi there, I am a student considering a compiler design based dissertation with llvm. I am having problems building llvm on OpenBSD-current. I hope to make a port of llvm for OpenBSD once I have figured out how to build it. Observe: llvm[3]: Compiling Deserialize.cpp for Release build In file included from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitstreamRead er.h:18, from

As part of our work on LLD for Mach-O, we’ve observed that the object files produced by LLVM don’t always have aligned nlist_64 entries. For context, nlist_64 is the 64-bit symbol table entry structure for Mach-O, and the symbol table is an array of nlist_64 entries. nlist_64 has an 8 byte member, so it should be 8-byte aligned, but we’ve seen object files where the symbol table only has a 4-byte

On Mar 4, 2008, at 09:18, Gordon Henriksen wrote: > Hi Erick, > > Thanks, this looks good. Can you please resubmit this patch, and the > others, as an attachment? > > On Mar 4, 2008, at 03:19, Erick Tryzelaar wrote: > >> diff --git include/llvm-c/Core.h include/llvm-c/Core.h >> index 9b11df5..3676377 100644 >> --- include/llvm-c/Core.h >> +++

On 2008-06-10, at 09:19, Edd Barrett wrote: > I am a student considering a compiler design based dissertation with > llvm. I am having problems building llvm on OpenBSD-current. I hope > to make a port of llvm for OpenBSD once I have figured out how to > build it. Hi Edd, Could you please update to r52213 or later in svn and check whether this error is resolved with your

I looked into this further. ld64 has a macho_nlist abstraction over the various underlying nlist structures [1]. On x86-64, the P::getP referenced in n_value will resolve to [2], which in turn goes to [3], which calls OSReadLittleInt64. On a little endian machine, OSReadLittleEndian just calls _OSReadInt64 [4], which in turn does a pointer arithmetic and cast and then dereferences the pointer [5].

(switching list from llvm-commits to llvm-dev, which seems more appropriate here) From: llvm-commits <llvm-commits-bounces at lists.llvm.org> on behalf of Rui Ueyama via llvm-commits <llvm-commits at lists.llvm.org> Reply-To: Rui Ueyama <ruiu at google.com> Date: Friday, October 13, 2017 at 4:22 PM To: Rafael Avila de Espindola <rafael.espindola at gmail.com> Cc:

Hello, Recently Jonathan Blow posted a short screencast discussing build time of his compiler with when no optimizations are run on the user's code. Part 1: https://www.youtube.com/watch?v=HLk4eiGUic8 Part 2: https://www.youtube.com/watch?v=mIjGYbol0O4 He discusses what parts are taking the longest to compile, and the ultimately shows this: http://i.imgur.com/BkbKcJK.png ...which shows that

Dear Community, The ponyc<https://github.com/CausalityLtd/ponyc/tree/llvm37> (llvm37 branch) project is facing an issue on Windows: When optimizations are turned on (llvm 3.7.0-final and more specifically<https://github.com/CausalityLtd/ponyc/blob/llvm37/src/libponyc/codegen/genopt.cc>, opt-level 3, BBVectorize, LoopVectorize, SLPVectorize, RerollLoops, LoadCombine + a custom heap

Hi Michael, Overall patch looks good. I do have a few comments below. My main comment is please try to make the style match that used in the MCMachOStreamer more closely. I intend to refactor more functionality into the base MCObjectStreamer class, and having them use consistent idioms makes this easier; specific instances are included in the comments: -- > diff --git

Just got started and stuck at the same time. Working with the C-Api, i have come to the point where i want to emit a binary file for my module. I queried the X86-Target and called LLVMCreateTargetMachine this way: > LTarget := LLVMGetTargetFromName('x86'); > LMachine := LLVMCreateTargetMachine(LTarget, 'i386-win32-msvc', nil, > nil, LLVMCodeGenLevelDefault,

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

I noticed that the ocaml compilation isn't using the .opt executables if they're available. We might gain a slight optimization in ocaml compile time by optionally using them with this patch. --- autoconf/configure.ac | 18 +++++ configure | 195 ++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 188 insertions(+), 25 deletions(-) -------------- next part

Hi, :If I compile this file with debugging enabled (clang/LLVM TOT) int main() { } I get the error Error: inconsistent uses of .cfi_sections From the 2.27 binutils assemblers. It seems that 2.27 doesn't like the .cfi_sections .debug_frame directive following previous .cfi directives. The assemblers seem to be happy if the .cfi_sections directive precedes any other .cfi directive. Is

Hi, I've run Clang Static Analyzer checker alpha.cplusplus.NewDeleteLeaks over LLVM codebase to detect false-positives and at the same time eliminate memory leaks. The majority of leaks were detected in lib/Target/* and lib/MC/*. In all cases the similar trick was detected as a leak (example from lib/Target/Sparc/MCTargetDesc/SparcMCTargetDesc.cpp) : static MCStreamer