similar to: [LLVMdev] hello.bc & binary code

I'm another new person to LLVM. I can't successfully compile and execute a simple C++ program. The compiler seems to work, as it produces a.out and a.out.bc files, but I get a whole bunch of warnings: WARNING: Found global types that are not compatible: "struct.std::messages<wchar_t>"* %_ZN9__gnu_cxx10messages_cE [16 x sbyte]*

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

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

Hello! I get some odd behaviour using my structs: "myKernelMap" = type {int (sbyte*)*, int ()*} "Kernel" = type {"myKernelMap"*} The second member ( int()* ) is a pointer to the %getchar() function. I want to call getchar using this function: int "callmyKernelgetchar_kernel"("Kernel"* "myKernel") { "PTRMAP" =

I have an objective-c file, bar.m, that I try to process in the following way generating the error shown below. Any help would be appreciated. I suspect the error is in the first few lines of output. thanks, Todd > cfrontend-g++ -o bar.bc bar.m > llvm2cpp -o bar.cpp bar.bc > g++ -c bar.o bar.cpp > ld -o bar bar.o -l objc -l LLVMCore -l LLVMSupport -l LLVMSystem > ./bar Global

On May 4, 2004, at 10:36 PM, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: >> I suspect that a large reason that LLVM does worst than a native C >> compiler with the CBE+GCC is that LLVM generates very low-level C >> code, >> and I'm not convinced that GCC is doing a very good job (ie, without >> syntactic loops). > > Yup, this is

Anders Alexandersson wrote: > Hello! > > I get some odd behaviour using my structs: > > "myKernelMap" = type {int (sbyte*)*, int ()*} > "Kernel" = type {"myKernelMap"*} > > The second member ( int()* ) is a pointer to the %getchar() function. > > I want to call getchar using this function: > > int

On Wednesday 15 August 2007 13:10, Reid Spencer wrote: > > It really depends on what you mean. I've found that iostreams are > > extremely slow, much slower than C stdio streams. Eventually I'd like to > > move them to stdio, not to more complex streambufs :) > > Eventually I'd like to move them to native syscalls adapted by > lib/System and suited to the

hi, I want to know what is exact meaning in the following code. target endian-- %struct..TorRec-- %struct.TorRec-- implementation-- ;<sbyte>[#uses=1/0]-- how to explain them in details? Does anyone give me a guide? thanks yueqiang -------------------------------------------------------------- target endian = little target pointersize = 32 %struct..TorRec = type { int, void ()* }

Hi When I compiled sendmail v8.11.6 with LLVM 1.2, I found some variables with strange type, such as: %sys_errlist = external constant [0 x sbyte*] ; <[0 x sbyte*]*> [#uses=3] %tmp.24 = getelementptr [0 x sbyte*]* %sys_errlist, long 0, long %tmp.23 ; <sbyte**> [#uses=1] The process of getting these is: 1. entry sendmail-8.11.6 directory 2. make

> Okay, I took a closer look at your output. > > I was correct in that gccas is attempting to assemble a native PPC > assembly language file. However, this appears to be happening because > the assembly file is generated by the GCC Makefiles for libgcc2 (in > llvm-gcc/gcc/config/rs6000/t-ppccomm, I think). > > The first thing I would try is Marco's suggestion: add

When I increased COLS to the point where the loop could no longer be unrolled, the selection dag code generator generated effectively the same code as the default X86 code generator. Lots of redundant imul/movl/addl sequences. It can't clean it up either. Only unrolling all nested loops permits it to be optimized away, regardless of code generator. Jeff Cohen wrote: > I noticed

Hi, Is there a way to modify the string such as char a or char b? Could I use the way like "Replace an instruction with another Value" in Programm Manual? In fact, what I am interested in is string with visible expression, not all string, and I am trying to hide the orignal string by using simple way like XOR.. Is there a way to reorder the basic blocks? Thanks. Qiuyu C Source

I noticed that fourinarow is one of the programs in which LLVM is much slower than GCC, so I decided to take a look and see why that is so. The program has many loops that look like this: #define ROWS 6 #define COLS 7 void init_board(char b[COLS][ROWS+1]) { int i,j; for (i=0;i<COLS;i++) for (j=0;j<ROWS;j++) b[i][j]='.';

hi, i also have problems compiling llvm-gcc (current svn version). llvm is current llvm svn. i tried to use every gcc version from 4.0 to 4.3 to compile llvm-gcc. i configured llvm-gcc like this (and tried every other combination of disable-shared, disable-multilib and bootstrap) : ../llvm-gcc/configure --prefix=/usr --enable-llvm=/usr --enable-languages=c,c++ --disable-shared

>Right. This looks like it's just a simple bug in llvm2cpp. >CppWriter.cpp:698 contains: > > if (CA->isString() && CA->getType()->getElementType() == >Type::SByteTy) { > Out << "Constant* " << constName << " = ConstantArray::get(\""; > printEscapedString(CA->getAsString()); > //

On Wed, Mar 09, 2005 at 04:05:32PM +0300, Vladimir Merzliakov wrote: > >>Is assert(!NewSTy->isAbstract()) must pass after this line? > > > >In this case, yup. > > > I create test program and assert failed in it: > > { \2 *, sbyte * } How do I decode the \2 in this? I am creating types through this interface and I get quite a mess seen below. And this is

After looking at this problem longer, I believe that there is something wrong with the disassembler. When I run my transformation and then disassemble the output, I get bytecode that looks like: ----- int %main(int %argc, sbyte** %argv) { entry: alloca int ; <int*>:0 [#uses=3] alloca sbyte** ; <sbyte***>:0 [#uses=3] store int %argc,

Hi, I'm working on a CS326 compiler project, and I'm having some problems using string functions. Some LLVM programs produced are either aborting or giving incorrect results; however, if I disassemble the LLVM bytecode and recompile with GCC, everything works fine. I encountered the following error when running lli with '-force-interpreter' option: "Tried to execute an

On Tue, 2004-11-30 at 08:58, Chris Lattner wrote: > On Tue, 30 Nov 2004, Tanu Sharma wrote: > > > I have trouble using the llvm tools.Some of the errors are : > > > > $ llvm-dis prog.bc > > $ llvm-dis: Invalid Top Level Block Length! Type:1, Size:456 (Vers=0, Pos=12) > > Can you explain how you generated this bytecode file? It looks corrupted > or