search for: constructcompileunit

...th dbgstoppoint() functions. However, when I use llc to compile the bc file to .s file (llc -f -o httpd.s httpd.bc), I met this error (the httpd.bc file will be attached at the next email): llc: /home/heming/defens/llvm-2.5/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1235: void llvm::DwarfDebug::ConstructCompileUnit(llvm::GlobalVariable*): Assertion `!MainCU && "Multiple main compile units are found!"' failed. 0 llc 0x00000000011c0f6c 1 llc 0x00000000011c148a 2 libpthread.so.0 0x00007fa91db297d0 3 libc.so.6 0x00007fa91cc3a095 gsignal + 53 4 libc.s...

...this might not belong here. See if we can factor this better. > if (DirName == CompilationDir) > DirName = ""; The last snippet weirds me out and breaks Rust debug information generation. Specifically, when creating a new compile unit, we see this: >CompileUnit *DwarfDebug::constructCompileUnit(const MDNode *N) { > DICompileUnit DIUnit(N); > StringRef FN = DIUnit.getFilename(); > CompilationDir = DIUnit.getDirectory(); > unsigned ID = GetOrCreateSourceID(FN, CompilationDir); Note how CompilationDir is passed to GetOrCreateSourceID as DirName? That means that the map of co...

...that if I compile either if them, I would get the same failure as I did with foo.bc. That is not the case. I get a different assertion failure when I compile either of them with llc which is as follows: llc: <llvm-src>/llvm/lib/CodeGen/AsmPrinter/DwarfWriter.cpp:2808: void llvm::DwarfDebug::ConstructCompileUnits(): Assertion `Root->hasLinkOnceLinkage() && Root->hasOneUse() && "Malformed compile unit descriptor anchor type"' failed. This makes it hard for me to easily create a test case and submit a bug report. Hence, I thought I should take this opportunity to delve d...

...e out and breaks Rust debug information > generation. Specifically, when creating a new compile unit, we see > this: In DWARF, if the directory index is zero then it's assumed to be the contents of AT_compilation_dir. This implements that optimization. >> CompileUnit *DwarfDebug::constructCompileUnit(const MDNode *N) { >> DICompileUnit DIUnit(N); >> StringRef FN = DIUnit.getFilename(); >> CompilationDir = DIUnit.getDirectory(); >> unsigned ID = GetOrCreateSourceID(FN, CompilationDir); > > Note how CompilationDir is passed to GetOrCreateSourceID as DirName?...

...hem, I would get the same failure as I did with > foo.bc. That is not the case. I get a different assertion failure > when I compile either of them with llc which is as follows: > > llc: <llvm-src>/llvm/lib/CodeGen/AsmPrinter/DwarfWriter.cpp:2808: > void llvm::DwarfDebug::ConstructCompileUnits(): Assertion `Root- > >hasLinkOnceLinkage() && Root->hasOneUse() && "Malformed compile > unit descriptor anchor type"' failed. This is because bugpoint tool does not understand debug info intrinsics. To avoid this, when you generate foo.bc with -emit-l...

Hi Bharadwaj, > I get the following error during compilation using the LLVM cross-compiler > (x86_64->arm). > > error: nested functions are disabled, use -fnested-functions to re-enable yes, nested functions are disabled by default in llvm-gcc (not sure why - maybe a historical hang over from the days when they were not supported?). > With -fnested-functions switch, I get the

Hi Olaf, This patch looks good to me. I just have a few minor comments: > + inline df_iterator() { CurrentTopNode = 0; /* End is when stack is empty */ } Should the comment here be updated to say that the End is reached when the stack is empty and when CurrentTopNode is null? > + inline void toNext() > + { LLVM style puts the open brace on the same line as the function name.

I get the following error during compilation using the LLVM cross-compiler (x86_64->arm). error: nested functions are disabled, use -fnested-functions to re-enable With -fnested-functions switch, I get the following error: <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&):

Hi @clang and @llvm, attached you'll find a patch dealing with some iterator issues I already mentioned in both lists. Since there was no reaction I cross-post again - now IMHO production-ready code. The patch is considered to get checked-in out of the box. It should not affect the behavior of existing and working code. I really need it for clang AST processing. Changes: 1. Both