similar to: [LLVMdev] # operands < # args

I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt? Ryan M. Lefever wrote: > I also tried iterating

On Fri, 2007-04-06 at 14:27 -0500, Ryan M. Lefever wrote: > Is a PR a bug report on the bugzilla database? Yes, so named because of the URL translation. I.e. http://llvm.org/PR123 takes you to bugzilla bug 123. PR == Problem Report. > I am also running > bugpoint to see if that yields anything. Okay, good. That might turn up something useful. If you suspect its a bug, please file

Is a PR a bug report on the bugzilla database? I am also running bugpoint to see if that yields anything. Reid Spencer wrote: > Hi Ryan, > > On Fri, 2007-04-06 at 13:34 -0500, Ryan M. Lefever wrote: > >>I am running the following llvm-ld command to produce native code: >> >>llvm-ld -native -o code.exe code.bc -lm >> >>However, I am getting the

This has been reported. http://llvm.org/bugs/show_bug.cgi?id=1317 On 4/10/07, Ryan M. Lefever <lefever at crhc.uiuc.edu> wrote: > > I checked out llvm from cvs & llvm-gcc from svn last night and again > tonight. Each time they compiled and installed fine. After installing > them, I recompiled compiler transforms I had written for opt. opt seems > to load the my

How do I acquire that version of DSA that you've updated to mainline cvs? Do I still check out llvm-poolalloc, or is there a way to only check out DSA? Patrick Meredith wrote: > I updated dsa to mainline cvs. Poolalloc is broken, however. > > On Mar 6, 2007, at 3:39 AM, Ryan M. Lefever wrote: > >> What versions of llvm and llvm-poolalloc should I check out of cvs, in

Thanks for the help Reid! I frequently look at the online doxygen, but sometimes its difficult to determine the correct replacement when a method is removed from LLVM. In this particular case, I knew which new CallInst constructor to use, I just couldn't figure out the proper syntax. At any rate, I really appreciate your help!! Reid Spencer wrote: > On Tue, 2007-03-06 at 22:44 -0600,

I didn't see anything on http://llvm.org/SVNMigration.html, but I'm assuming that llvm/projects has moved to llvm/examples. Is that correct? If so the documentation in http://llvm.org/docs/GettingStarted.html will need to be updated. In particular, the getting started doc talks about checking out llvm-test to llvm/projects. Also, I'm curious why the llvm/projects/sample

I get a similar error when I try to disassemble a bytecode file generated by llvm-gcc released for llvm 1.9. Do I need to upgrade to a new llvm-gcc? Ryan M. Lefever wrote: > I am trying to use llvm-ld but when I try to link several bytecode files > into a single bytecode file, it gives me the following error: > > llvm-ld -o benchmarks/bc-1.06/src/bc.c.bc

Is there a conversion tool to convert llvm bytecode into c code? Regards, Ryan -- Ryan M. Lefever [217.333.7231] [http://www.ews.uiuc.edu/~lefever]

I don't follow what you mean - gcc doesn't ignore const and llvm doesn't deviate from gcc nor from the relevant language standards. Note that if you declare a global as const that we do capture this in the ir - what specifically do you want? Please provide an example. -Chris http://nondot.org/sabre http://llvm.org On Aug 14, 2007, at 11:58 PM, "Ryan M. Lefever"

I am writing a pass where I need to make a function deceleration for printf. Below is the code I'm trying to use. ----- bool MyPass::runOnModule(Module &m) { vector<const Type*> args; args.push_back(PointerType::get(Type::SByteTy)); Function* f = m.getOrInsertFunction("printf", FunctionType::get(Type::IntTy, args, true)); ----- When I insert a call

I also tried iterating through the functions of the module and calling verifyFunction(), which also returns false, but does not cause an abort or report anything to stderr about what caused the verification to fail. From the doxygen for verifyFunction() and verifyModule(), it seems like they both should print information to stderr if the verification fails and should abort opt if

The reason I didn't use Xcode 2.4 is because I'm running OS X 10.3.9 (Panther). I have not upgraded the OS to 10.4. Xcode 2.4 requires OS X 10.4, according to Apple's website. Do you know otherwise? I think the highest Xcode I can get is 1.5. By the way what does FSF mean? I also tried compiling llvm with the gcc 3.3 that comes with OS X 10.3, and it gave the exact same error

I am trying to disassemble some bytecode using llvm-dis: llvm-dis -f -o llvmtest/sliceme2.cbc.ll llvmtest/sliceme2.cbc However, I am getting the following error. llvm-dis: Invalid bytecode signature: 464C457F (Vers=0, Pos=4) How do I go about figuring out what the problem is? llvmtest/sliceme2.cbc is newly compiled using the same version of llvm-gcc as llvm-dis. -- Ryan M. Lefever

I need to create a cast instruction that casts an sbyte* to another pointer type. Previously I was using the CastInst::createInferredCast() function to do that; however, that function has been removed. Which of the create() functions from CastInst should I use to do that? It seems like the obdvious answer should be createPointerCast(). However, the documentation for createPointerCast

I am still diagnosing the cause of the assertion failure and will submit a bug when I better understand the problem. Reid Spencer wrote: > Ryan, > > This looks like a bug. Could you file it, please? > > Reid. > > On Thu, 2007-02-22 at 19:47 -0600, Ryan M. Lefever wrote: > >>I have a compiler transform that I have been working on that produces >>bytecode

I don't mean to be a pain, but I was thinking about this a bit more. Does gcc ignore the const keyword? If not, why has LLVM chosen to deviate from gcc with respect to the const keyword? If so, then why do we bother using const in LLVM API code? I'm just curious and wanted to understand the thinking behind not preserving const. Thanks, Ryan Chris Lattner wrote: > This property

I was able to correct this problem by checking out the latest version of llvm-gcc4 from svn and compiling it from source. One note, in order to get llvm-gcc4 to compile, I had to add #include "llvm/Analysis/LoopPass.h" to gcc/llvm-backend.cpp Ryan M. Lefever wrote: > I get a similar error when I try to disassemble a bytecode file > generated by llvm-gcc released for llvm

Ok, I think I figured it out. I talked to someone, and we figured out that when I make a call to printf with a constant string, I need to make a global variable and use getElementPtr to reference it. The modified call for accessing the printf is: /* m is Module*, f is Function*, i is Instruction* */ Constant* constStr = ConstantArray::get("test\n"); GlobalVariable* gv =

Thank you for the help. There seem to be several things in my makefiles that are messed up as a result of switching from the gcc3.4 front end to the gcc4 frontend. Is there any documentation listing the things that have changed? Thanks, Ryan Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever] On Fri, 1 Dec 2006, Reid Spencer wrote: > Hi Ryan, > > On Fri, 2006-12-01 at 18:06