similar to: [LLVMdev] std::remove

ValGrind gives me some info, but I'm not great at memory stuff, and so I'm not sure what to make of it... This is code that worked for someone 8 months ago, and I'm just trying to get it to run on llvm 2.9 instead of 2.8, so the fact that it hasn't been working is frustrating. Anyway, my issues seem to stem from IntervalIterator, as seen below. I have a lot of similar issues

On Saturday 30 April 2005 07:30, Chris Lattner wrote: > > Here's NodeTy is a first order interval and can contain several basic > > blocks, but we add only the first one. I attach the patch which tries to > > fixes that. Also, for convenience, there's output of 2-order interval on > > some test case. 'log' is before the change and 'log_good' is

Hi all, Here the first bunch of patch for compiling part of LLVM under win32 with MSVC 7.1: * Trivial addings (I hope!): - #include <string> at top of: llvm\include\llvm\ExecutionEngine\ExecutionEngine.h(78) : error C2039: 'string' : is not a member of '_STL' - #include <algorithm> at top of: llvm\lib\CodeGen\LiveIntervalAnalysis.cpp(639) : error C2039:

Hi all, I've been investigating a machine verifier failure on the attached testcase, and I'm tempted to say the verifier is wrong and should accept it. Skip the description for the proposed change. On AArch64, the verifier complains with: *** Bad machine code: MBB exits via unconditional branch but doesn't have exactly one CFG successor! *** - function: t4 - basic

Both are working well on VC. Just tested. template<class STy> void set_intersect(STy &S1, const STy &S2) { for(STy::iterator I = S1.begin(), E = S1.end(); I != E; ) if (S2.count(*I)) S1.erase(*I++); else ++I; } template <class S1Ty, class S2Ty> void set_intersect(S1Ty &S1, const S2Ty &S2) { for (typename S1Ty::iterator I = S1.begin(); I !=

On Fri, Feb 3, 2012 at 1:20 PM, Griffin Wright <grwright at umich.edu> wrote: > > Hello, > > I've been stuck with a problem for about a month, and it has stumped > everyone in my lab.  I have a function pass that runs, and when it finishes > and opt goes to return, I get: > > While deleting: void % > An asserting value handle still pointed to this value! >

On Aug 2, 2013, at 1:37 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> I expected that this optimization would be picked >> up in a cse, gvn, machine-cse or even peepholing pass. >> >> Comments? > > > At the LLVM IR level this is represented as > > define i64 @caller() #0 { > entry: > store i64* @val, i64** @p, align 8, !tbaa

Hi all, Well, suggestion for workarounds for the namespace problems are welcome... this is a 7 minutes compile files on a pentium 4 3ghz 700Mb ram... The fatal error at the end MAY depend on the previous... or at least, I hope so. cl /nologo /TP /EHsc /GR /Zi /Yd /D__STDC_LIMIT_MACROS /DHAVE__FINITE_IN_FLOAT_H /DHAVE__ISNAN_IN_FLOAT_H /ISTLport-4.6.2\stlport /Illvm\inc lude

On Tue, 12 Oct 2004 14:01:21 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > On Tue, 12 Oct 2004, Morten Ofstad wrote: > > > This is my first post on this mailing list, so bear with me... My name > > is Morten Ofstad and I work for Hue AS (www.hue.no), a company that > > makes 3D Visualization software. We are looking into using LLVM for JIT > >

struct X86AsmPrinter is in an anonymous namespace, but printInstruction is declared in namespace llvm. try editing the tablegen output to move X86AsmPrinter::printInstruction into an anonymous namespace, not llvm. I suspect this will at least fix the first problem. Then we can figure out the proper longterm fix. Andrew On Tue, 2004-10-12 at 03:56, Paolo Invernizzi wrote: > Hi all, >

Hello, I've been stuck with a problem for about a month, and it has stumped everyone in my lab. I have a function pass that runs, and when it finishes and opt goes to return, I get: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! On a simple test case, the error becomes 'i32 %'

Hi all, among other things, we provide shell access to various unix based platforms for our students and university staff. Recently, there has been increasing number of root login attacks on one particular Tru64 machine running OpenSSH. The host is configured with "PermitRootLogin no" but every once in a while SIA auth with TCB enhanced security locks the root account. I suppose

Hi, it looks like the IntervalPartition does not work as expected when constructed from another interval partition. Say, I have built an interval partition from function, and the first interval has two basic blocks. When I create second order partition and print all intervals, the second basic block of the function is not seen anywhere. Here's what's going on in IntervalIterator.h:

I'll wait for the research. We should try, as much as possible, to make it work with just what the compiler provides and without third party packages. Thanks, reid. On Fri, 2004-09-24 at 07:46, Jeff Cohen wrote: > I added the include of cstudio and it fails with plain VC7.1; the file > does not exist. > > Add it for now. If it is impossible to build with VC7.1 and without

Hi The Dragon book, led my thoughts to "Here be dragons" http://en.wikipedia.org/wiki/Here_be_dragons "In another context, software programmers sometimes use it to indicate especially difficult or obscure sections of code in a program so that others do not tamper with them." Why not some dragon name ? or maybe someone can use this idea to come up with something else. /f

It would be great to avoid STLPort and use plain vanilla VC... as I told, the biggest difference it's how the hash_map and hash_set are implemented, but I'm not so strong in C++ for resolving the iussue. About the build procedure, it's based on scons, and it's still at a very preliminary stage... Right now I'm trying to build TableGen with it, as till now I've always

I checked right now that it compiles also with #include <iostream> Jeff, can you test it with plain VC? --- Paolo Invernizzi On Sep 24, 2004, at 4:52 PM, Reid Spencer wrote: > I'll wait for the research. We should try, as much as possible, to make > it work with just what the compiler provides and without third party > packages. > > Thanks, > > reid. > >

Someone needs to adjudicate on whether I add the #include of <cstdio> or not. I can't test this so, Paolo/Henrik/Jeff, please let me know if I need to add it. Thanks, Reid. On Fri, 2004-09-24 at 07:08, Jeff Cohen wrote: > But I compiled that under vc7.1 as it was! > > On Fri, 24 Sep 2004 15:19:22 +0200 > Paolo Invernizzi <arathorn at fastwebnet.it> wrote: > >

Hi, Has some one committed these patches into CVS? Paolo, thanks for the patches. In the near future I'll try to compile them. I've installed STLport 6.4.2 with vc6. Henrik --- Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/ --- >From: Paolo Invernizzi <arathorn at fastwebnet.it> >Reply-To: LLVM Developers Mailing List

On Sep 23, 2004, at 4:08 PM, Jeff Cohen wrote: > MSVC++ is picky about this. It considers classes and structs to be > different types so you have to be consistent. If you forward declared > a > struct as a class within the same compilation unit, it would complain > about that too. It's not just linking. You are right... BTW, I've just fixed that problem in my checkout