search for: const_casts

Hi, how do I compile c code from a char array in clang? Im using code from the interpreter example. Thanks. char *cCode; // the char array // fill array with code goes here... // Initialize a compiler invocation object from the clang (-cc1) arguments. const driver::ArgStringList &CCArgs = Cmd->getArguments(); llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation);

no, does not help, ive already looked at it. none none-17 wrote: > > This thread may help: > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-June/009507.html > > On Sun, Aug 15, 2010 at 2:50 AM, gafferuk <gafferuk at gmail.com> wrote: > >> >> Hi, how do I compile c code from a char array in clang? >> >> Im using code from the interpreter

Currently, member functions like File::defined() return an iterator for const atoms. But we don't actually treat atoms as consts -- we updates atoms in many places including the core resolver. We have too many const_casts in our code. It just doesn't make sense. I'm making a change to make atoms non-const. Please hit reply if you have any concerns. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150407/a1de5102/attach...

This thread may help: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-June/009507.html On Sun, Aug 15, 2010 at 2:50 AM, gafferuk <gafferuk at gmail.com> wrote: > > Hi, how do I compile c code from a char array in clang? > > Im using code from the interpreter example. > Thanks. > > char *cCode; // the char array > // fill array with code goes here... > > >

Hello, I wonder if someone would know what is going on below. All of a sudden I’m getting this assertion thrown: Assertion failed: (New->getType() == getType() && "replaceAllUses of value with new value of different type!"), function replaceAllUsesWith, file /Users/meister/Development/externals-clasp/llvm36/lib/IR/Value.cpp, line 345. It’s happening when

I don't know how ccons works, but it may do what you need. http://code.google.com/p/ccons/ Le 15 août 2010 à 14:48, gafferuk a écrit : > > no, does not help, ive already looked at it. > > > > none none-17 wrote: >> >> This thread may help: >> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-June/009507.html >> >> On Sun, Aug 15, 2010 at

On Monday 25 April 2005 14:43, Vladimir Prus wrote: > The 'i' variable is never modified in the program, however, all analyses > except for -globalsmodref-aa report that the > > %tmp.3 = call int %_Z3bari( int %p ) ; <int> [#uses=1] > > instruction can modify 'i'. I'm somewhat surprised, because it looks like > -globalsmodref-aa is the simplest

Hi, I'm working on a bug somewhere between SCEV and IndVarSimplify, which tacks an unwanted "nuw" onto an "add i32 %whatever, -1" (which actually almost certainly will overflow), leading ultimately to an infinite loop. A fuller description and test-case is at the end for anyone interested. The issue seems to be with ScalarEvolution's attempts to cache SCEV objects,

To context was , Basic requirement was to append extra string to the decl name and update all his references to the updated name. , So we are constructing the DeclarationName instance as stated below code snap. and from DeclarationName instance ,we are constructing the DeclarationNameInfo and same info used to create decl spec with FunctionDecl::Create () . Question is , How do ,someone

Heres my full code listing, im totally stuck. // Whistle.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include "clang/CodeGen/CodeGenAction.h" #include "clang/Driver/Compilation.h" #include "clang/Driver/Driver.h" #include "clang/Driver/Tool.h" #include

Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

Hello, I'm playing with alias analysis, using the following program: %i = external global int ; <int*> [#uses=2] implementation ; Functions: int %_Z3bari(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0, 10 ; <bool> [#uses=1] br bool %tmp.1, label %then, label %UnifiedReturnBlock then:

> 1. Callers are expected to not engage in speculation. ScalarEvolution > itself must only create expressions it knows hold in all cases. This is correct. There is some more relevant text in ScalarEvolution::isSCEVExprNeverPoison. And you're right, this is quite restrictive. > Long term, I think that it would be cleaner to rework this so that all of the SCEV's are immutable

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedestkop.org> --- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp index b8d0d3e..d566c99

On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote: > Hi all, > > I have reported more than enough about the space savings achieved > and the associated costs, here comes the current patch for review. > > Since this one is substantially smaller than the previous one, I did > not cut it in pieces. The front part is about headers and the rest > the .cpp and other files. Hi

Thanks Daniel! I think you've cleared up some of my misconceptions, but I still am a bit confused about some of the corner cases. Suppose we had something like this std::vector<int> A(100); > int* x,y; > x=&A[0]; > for(int i=0; i<100; i++) { > y=&A[i]; > *y=*x; > x=&A[i+1]; > } > Would the load and store instructions be MustAlias? I

I forgot to mention this in my initial email. The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c The date on the commit is: Date: Fri Sep 26 12:34:06 2014 Also: Today I grabbed the ToT llvm/clang/clang-extra-tools and I’m working on getting my code to be compatible with it. I can switch back and forth between the current ToT llvm and the old one. Thanks,

Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8 into v16i32, what should happen is that the return type of the BUILD_VECTOR continues to be v16i8, but the type of the operands changes to i32, so you end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8. The target then has all the info it needs to produce the best code, but needs to be careful

Hello all, I've read the documentation on alias analysis, and I think I understand it literally, but I just want to be sure, because it seems a bit strange. As it says on this web page <http://llvm.org/docs/AliasAnalysis.html>, The MayAlias response is used whenever the two pointers might refer to the > same object. > > The PartialAlias response is used when the two memory

Hi all, at the moment I am trying to fix an unnecessary iterator dereferencing in Casting.h and am uncovering several ugly things. For example, look at this code: > // dyn_cast_or_null<X> - Functionally identical to dyn_cast, except that a null > // value is accepted. > // > template <class X, class Y> > inline typename cast_retty<X, Y>::ret_type