search for: machinedebuginfo

...k/llvm-cvs/lib/VMCore/Constants.cpp:624 #6 0x087aa821 in llvm::ConstantStruct::get (Ty=0x8b25730, V=@0xbf8adef0) at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:994 #7 0x08714182 in llvm::DISerializer::Serialize (this=0x8b17834, DD=0x8b54480) at /home/ghost/Work/llvm-cvs/lib/CodeGen/MachineDebugInfo.cpp:1204 The real problem is this: #7 0x08714182 in llvm::DISerializer::Serialize (this=0x8b17834, DD=0x8b54480) at /home/ghost/Work/llvm-cvs/lib/CodeGen/MachineDebugInfo.cpp:1204 1204 GV->setInitializer(ConstantStruct::get(Ty, Elements)); (gdb) p Elements[2] $7 = (class llvm::Consta...

Hi, Here is the follow on patch for this problem. Please apply this from the top of the tree and rebuild. -------------- next part -------------- A non-text attachment was scrubbed... Name: op Type: application/octet-stream Size: 2548 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060315/eee8a766/attachment.obj> -------------- next part

...> on quickly fixing this, so I've applied the third attached patch to LLVM, > which "fixes" this issue completely. Ah, hell, as soon as I've send this email I've updated from CVS to find that the issue was fixed by Jim several hours after I reported the crash, by making MachineDebugInfo don't check for empty name of type. > After that, the frontend itself builds (the gcc directory), and "llvm-g++ > -emit-llvm -S some_file.cpp") works. I did not do deep testing. > > On the other hand, I still get segfaults when building libstdc++. I'll > look at t...

On Thu, 16 Mar 2006, Vladimir Prus wrote: > Ah, hell, as soon as I've send this email I've updated from CVS to find that > the issue was fixed by Jim several hours after I reported the crash, by > making MachineDebugInfo don't check for empty name of type. :) > Here's what I get now: > > /space/p2/ghost/build/llvm-frontend/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/compatibility.h:42: > internal compiler error: in make_decl_rtl, at varasm.c:1018 > (gdb) where > Preproc...

On Wed, 15 Mar 2006, Vladimir Prus wrote: >> Please give it a try and let me know if it works any better for you! > > Here we go: Wow, you are good at finding problems! Thanks! > -fvisibility=hidden -DHIDE_EXPORTS > -c ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_fixunsxfdi.o > cc1: /space/p2/ghost/build/llvm-cvs/include/llvm/Instructions.h:72: void >

...n the IR as well, so that transformation passes would > properly > preserve them (and, just like debug info, sometimes be prevented from > modifying some annotated global values unless they are taught how to > preserve > the annotations). Makes sense. This is similar to how the MachineDebugInfo stuff deserializes debug info out of the LLVM IR and presents it for easy consumption of the code generator. > By using a subclass of Annotation (say, GlobalAnnotation) we can > distinguish > between annotations that are (or should be) in the IR and (the > existing) > annota...

Chris Lattner wrote: > On Thu, 16 Mar 2006, Vladimir Prus wrote: >> Ah, hell, as soon as I've send this email I've updated from CVS to find >> that the issue was fixed by Jim several hours after I reported the crash, >> by making MachineDebugInfo don't check for empty name of type. > > :) > >> Here's what I get now: >> >> /space/p2/ghost/build/llvm-frontend/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/compatibility.h:42: >> internal compiler error: in make_decl_rtl, at varasm.c:101...

...GLowering SDL(DAG, TLI, getAnalysis<AliasAnalysis>(), FuncInfo); std::vector<SDOperand> UnorderedChains; @@ -4191,7 +4363,7 @@ assert(SwitchCases.empty() && "Cannot have jump table and lowered switch"); SelectionDAG SDAG(TLI, MF, getAnalysisToUpdate<MachineDebugInfo>()); CurDAG = &SDAG; - SelectionDAGLowering SDL(SDAG, TLI, FuncInfo); + SelectionDAGLowering SDL(SDAG, TLI, getAnalysis<AliasAnalysis>(), FuncInfo); MachineBasicBlock *RangeBB = BB; // Set the current basic block to the mbb we wish to insert the code into BB =...

Hi all, I've also been developing an interest in using IR annotations for my compiler. Some discussion with Bart turns out that he has implemented some code to parse the llvm.globals.annotations array, but in no way integrated or reusable. We've spent some thought about how this could be done properly, which I will share here. Firstly, however, I was wondering about the format of the

Hi, I'm trying to annotate certain functions in C code, and do something with these functions in my LLVM pass. I annotate the C code like this: int __attribute__((annotate("annot"))) function() { This nicely gets added to the LLVM bitcode in an @llvm.global.annotations global. Now I had hoped that it'd be easy to extract a list of functions annotated with my annotation