search for: longti

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: > There is still one unneeded LongTy in LowerInvoke.cpp - something like this > pseudo-diff should probably get applied. What does this impact? -Chris > Index: LowerInvoke.cpp > =================================================================== > RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/LowerInvoke.cpp,v >

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: >> >>> There is still one unneeded LongTy in LowerInvoke.cpp - something like >>> this pseudo-diff should probably get applied. >> >> >> What does this impact? > > This causes code like > > write(2,

Hi, I have this call instruction to printf inserted which is causing an assertion failure. Any pointers to where I am wrong : Code Dump : Function *printFn=M.getNamedFunction(std::string("printf")); Constant *str=ConstantArray::get("Value : %d\n"); std::vector<Value *> Args(2); std::vector<Constant *> GEPIndices(2);

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: >> Ah ok, in that case, the CBE should be fixed. There are other cases that >> could cause long arguments to exist on 32-bit systems. If the C compiler >> takes issue with this, it would be best to tell the CBE to emit casts to C >> (long) or something. > > Actually that's the only case I stumbled over this

>>> >>> >>> The reason for the difference is that e.g "long" in >>> >>>> bool GOMP_loop_runtime_next(long, long) >>> >>> has a different size on different architectures. >>> >>> Currently we generate the prototypes and functions ourselves: >>>> declare i8 @GOMP_loop_runtime_next(i64*,

On 12/22/2010 03:12 PM, Peter Collingbourne wrote: > On Wed, Dec 22, 2010 at 01:38:06PM -0500, Tobias Grosser wrote: >> Hi, >> >> raghesh and I are working in Polly on automatically generating OpenMP >> calls. This works nicely on a 64bit architecture, >> however the functions we need to generate are slightly different on >> different platforms. >>

On Fri, 2005-05-13 at 08:06 +0200, Markus F.X.J. Oberhumer wrote: > Actually that's the only case I stumbled over this problem in a somewhat > larger C++ program, and it's clearly the wrong type in LowerInvoke.cpp - > it really should be IntPtrTy. But maybe we could use just IntTy here to > avoid target dependencies. Wait a minute. You want to lower a 64 bit thing to a 32

On Tue, Dec 21, 2004 at 03:45:33PM -0700, Sriraman Tallam wrote: > I have this call instruction to printf inserted which is causing > an assertion failure. Any pointers to where I am wrong : > > Function *printFn=M.getNamedFunction(std::string("printf")); std::string() is unnecessary here as it's implicit. > Constant *str=ConstantArray::get("Value :

On 12/26/2010 01:31 AM, Eric Christopher wrote: >>>> >>>> >>>> The reason for the difference is that e.g "long" in >>>> >>>>> bool GOMP_loop_runtime_next(long, long) >>>> >>>> has a different size on different architectures. >>>> >>>> Currently we generate the prototypes and

Constant *strcon==ConstantArray::get("Value : %d\n"); Sorry Typo. On Tue, 21 Dec 2004, Misha Brukman wrote: > On Tue, Dec 21, 2004 at 03:45:33PM -0700, Sriraman Tallam wrote: > > I have this call instruction to printf inserted which is causing > > an assertion failure. Any pointers to where I am wrong : > > > > Function

[Reposted from llvm-bugs mailing list. Also has an updated, hopefully better, patch associated with it.] Hi, The following program causes the LLVM GCC4 front end to ICE: struct A { virtual ~A(); }; template <typename Ty> struct B : public A { ~B () { delete [] val; } private: Ty* val; }; template <typename Ty> struct C : public A { C (); ~C (); }; template

Okay, I'm past the GEP "have to dereference pointer first" problem of my last post. I now have a linkage error (I get undefined symbol when I try to assemble the program). gcc -o test.o test.s says: > /tmp/cczhiFk7.o(.text+0x7): In function `a': > : undefined reference to `_index_' _index_ is defined like this: > %_index_ = external global long ;

Right now I am trying to capture the function name and the number of arguments , so this following is the pass I wrote . ------------------------------------------------------------- struct pass06a : public ModulePass { virtual bool runOnModule(Module &M) { std::vector<const Type*> pList; pList.push_back( PointerType::get(Type::SByteTy) ); pList.push_back(

While it is great that LLVM has an IR Verifier, its a little troublesome to use because it separates the point of detection from the source of the problem. That is, the verifier gets run on a module or function after its been built. By that point, the compiler's state has moved past the point at which the error was placed into the module or function. Trying to track down the source of the

HI , I understand that the standard C library functions are executed using the native library of the host machine. ( for example when we execute a bytecode to extract the profile info ) Is it possible to extract for each standard library function that is executed , the arguments that the function is called with. For example if printf ("%d", some_int ) when called during runtime

On Fri, 1 Sep 2006, Michael McCracken wrote: > Here's what works now, and I have a separate test case for each of these: > > statement functions > intrinsic functions (print, cos, etc) > loops, goto statments > scalarized array operations > function calls with *no arguments* > simple common blocks Great! > Function calls with more than one argument don't work.

The NIST F77 test suite doesn't seem to be compatible with gfortran at all, so I had to work from my own sample codes, and generate test cases from them. Here's what works now, and I have a separate test case for each of these: statement functions intrinsic functions (print, cos, etc) loops, goto statments scalarized array operations function calls with *no arguments* simple common

Hi , I am using LLVM for my Post Graduate course project on Optimization. I am trying to do some insrtumentation to the bytecode.I 've been going through your Instrumentation code for the past few days in /llvm/lib/Transforms/Instrumentation folder and finally found two ways of instrumentation : 1) injecting LLVM bytecode instructions 2) calling an external C function. I am trying both and