search for: asmwriters

I just updated my llvm sources (revision 164794.) and I see the error, "overriding non-deleted function" when building with gcc 4.7.0 and passing -std=c++11. /usr2/sidneym/llvm/tools/install/bin/c++ -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fPIC -fvisibility-inlines-hidden -I/local/scratch/llvm-tmp/build/lib/VMCore

Ryan Taylor wrote: > Nick, > > Unfortunately this doesn't answer my question I don't think. It > seems that -instnamer, as you mention, names the instructions but still > does not name the local variables. What other local variables are you referring to? When AsmWriter prints "%y = add i32 %x, 1", the name of that add instruction is "y" and

Hi guys Is some one able to explain me, why these errors emerge: gmake[2]: Entering directory `/usr/local/src/llvm/lib/VMCore' Compiling AsmWriter.cpp AsmWriter.cpp: In function `void WriteConstantInt(std::ostream&, const llvm::Constant*, bool, std::map<const llvm::Type*, std::string, std::less<const llvm::Type*>, std::allocator<std::pair<const llvm::Type* const,

Hi, Op 18-mei-07, om 10:10 heeft Tanya M. Lattner het volgende geschreven: >> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build >> with the header files using uintptr_t (not recognised as a type). >> Putting "#include <stdint.h>" in include/llvm/BasicBlock.h (llvm) >> and in "include/llvm/ValueSymbolTable.h" (frontend)

I've fixed this specific error in r164813. Please let me know if there are more behind it. On Thu, Sep 27, 2012 at 2:16 PM, Sid Manning <sidneym at codeaurora.org> wrote: > > I just updated my llvm sources (revision 164794.) and I see the error, > "overriding non-deleted function" when building with gcc 4.7.0 and passing > -std=c++11. > >

Nick, Unfortunately this doesn't answer my question I don't think. It seems that -instnamer, as you mention, names the instructions but still does not name the local variables. So there really is no way to do this shy of creating (or basically copying) the API from AsmWriter (seems very dedundant to me)? This seems like a large failing? On Fri, Oct 21, 2011 at 7:03 PM, Nick

It looks like the AsmWriter is generating the local variables (SlotNum)s on the fly in that file (AsmWriter.cpp), so is there any way at all to get this information from the operation itself, via Instruction, Value or Type? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111021/55f4887c/attachment.html>

I am trying to parse LLVM IR from a bit code file. I went through the following steps. hello.cpp #include <iostream> int main() { std::cout << "Hello world!" << "\n"; return 0;} dump.cpp #include <llvm/IR/Module.h>#include <llvm/IRReader/IRReader.h>#include <llvm/IR/LLVMContext.h>#include <llvm/Support/SourceMgr.h> using

Hi I am not a good programmer but for my project i have to use llvm to generate CFG for c programs where i have a mapping from IR instruction in CFG to their respective c instruction. After surfing a in source of llvm i did the following change in printInstruction() function in llvm/lib/VMCore/AsmWriter.cpp file. .....void AssemblyWriter::printInstruction(const Instruction &I) { if

No, Chris, I'm not buying that argument, due to I've tweaked /usr/include/types.h a little bit, so the configuration and compilation of the cfrontend would be correct: /* * 64bit type for BSD compatability */ #ifdef __GNUC__ typedef long long int quad_t; typedef unsigned long long int u_quad_t; typedef long long int int64_t; typedef unsigned long long int u_int64_t;

On Wed, 7 Jul 2004, Henrik Bach wrote: > This tweak seems to work. > > As far as I can see, correct me if I'm wrong, it is the compiler, that can't > figure out which std::basic_ostream to use. Why? What I'm saying is that it appears that your implementation of operator<< is not functional or is missing. You said that you are using GCC on internix. Is it possible

Albert Graef wrote: > One thing I noticed is that writing LLVM assembler code (print() > methods) seems to be horribly slow now (some 4-5 times slower than in > LLVM 2.5). This is a real bummer for me, since Pure's batch compiler > uses those methods to produce output code which then gets fed into llvmc. Let me follow up with some concrete figures. Unfortunately, I don't have

> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build with the > header files using uintptr_t (not recognised as a type). Putting "#include > <stdint.h>" in include/llvm/BasicBlock.h (llvm) and in > "include/llvm/ValueSymbolTable.h" (frontend) resolved this. Ok. This is now fixed on the release branch. Thanks! > Also, I got linking

Here is an excerpt from the config.log: configure:19451: checking for int64_t configure:19476: gcc -c -g -O2 conftest.c >&5 configure:19479: $? = 0 configure:19482: test -s conftest.o configure:19485: $? = 0 configure:19496: result: yes configure:19511: checking for uint64_t configure:19536: gcc -c -g -O2 conftest.c >&5 configure:19539: $? = 0 configure:19542: test -s conftest.o

Good day Nathan, If your using the stock GCC with Solaris, I am sorry to inform you its broken, Please see: http://llvm.org/docs/GettingStarted.html#brokengcc Please be warned as your get miss compiles and things will do strange `stuff`. As can be seen here, the reverse is true for both the GNU binutils and XPG4 versions of `nm' : -bash-3.2$ /usr/xpg4/bin/nm -p -u `find . -name

Before we get too far into this, I'd like to point out that there's a ready solution for the problem of the AsmPrinter being slow: Bitcode. If you want IR reading and writing to be fast, you should consider bitcode files rather than assembly (text) files anyway. Bitcode is smaller and faster. And the API is similar, so it's usually easy to change from assembly to bitcode.

Yes, Chris you're right. It seems that my << operator for int64_t is missing in my '/opt/gcc.3.3/include/c++/3.3/bits/ostream.tcc' file. Which ordinary version of GCC are you working with and how do your definition of the << operator for int64_t look like? /Henrik > >Here is an excerpt from the config.log for LLVM: > >configure:19451: checking for int64_t

I have a "first version" of Stacker up and running. Structurally its a lot like llvm-as. When I run it, I get: Leaked objects found: after running pass 'Function Pass Manager' LLVM Value subclasses leaked: Note that the supposed list of "LLVM Value subclasses leaked" is empty. Its followed up by a SIGSEGV at AsmWriter.cpp:754 presumably because I have a BasicBlock

Dan Gohman wrote: > One other question the occurs to me: is Pure dumping the whole Module > at once, or is it manually writing out the IR in pieces? Well, you hit the nail on the head with that one. ;-) In fact, I just had the same idea. So, instead of selecting and emitting individual globals and functions on the fly, I rewrote the .ll writer in Pure so that it just erases unwanted stuff

On Aug 24, 2009, at 3:05 PM, Ivo wrote: > On Monday 24 August 2009 23:27, Albert Graef wrote: >> Thank you also for the hint about bitcode reading/writing. I'm >> aware of >> this, but I actually prefer the .ll output because it's human- >> readable, >> which is great for debugging purposes. I might add a bitcode writer >> some >> time,