similar to: [LLVMdev] Folding cast of a global address to boolean

Chris Lattner wrote: >>The four leaks are caused by the ConstantBool::True >>and ConstantBool::False (1 for each object + 1 for the use list dummy) - >> unfortunately they are not so easy to wrap with accessor functions >>since they are public member variables of the ConstantBool class... If >>only everyone used the ConstantBool::get() there would be no problem,

Hi, I finally took the time to track down the remaining memory leaks beside the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It turns out almost all of them came from the command line options module, so I cleaned up the patch for LeakDetector and made a new patch for CommandLine. The patches are attached to this message. That got rid of all but 4 leaks I'm getting,

Is there are reason why ConstantInt::getRawValue method can't be moved one step into class hierarchy, into ConstantIntegral::getRawValue The reason I'd like this is that to handle both ConstantInt and ConstantBool, I need the following: if (ConstantInt* CI = dyn_cast<ConstantInt>(V)) { BuildMI(*MBB, IPt, NM::MOVE, 1, Reg).addImm(CI->getRawValue()); } if

On Fri, 19 Nov 2004, Morten Ofstad wrote: > I finally took the time to track down the remaining memory leaks beside > the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It > turns out almost all of them came from the command line options module, > so I cleaned up the patch for LeakDetector and made a new patch for > CommandLine. The patches are attached to this

Morten Ofstad wrote: } Chris Lattner wrote: } >>The four leaks are caused by the ConstantBool::True } >>and ConstantBool::False (1 for each object + 1 for the use list dummy) - } >> unfortunately they are not so easy to wrap with accessor functions } >>since they are public member variables of the ConstantBool class... If } >>only everyone used the ConstantBool::get()

On Thu, 17 Jun 2004, Vladimir Prus wrote: > Is there are reason why ConstantInt::getRawValue method can't be moved one > step into class hierarchy, into ConstantIntegral::getRawValue > > The reason I'd like this is that to handle both ConstantInt and ConstantBool, > I need the following: > > if (ConstantInt* CI = dyn_cast<ConstantInt>(V)) { >

On Feb 20, 2005, at 11:12, Evan Jones wrote: > I can "fix" it by changing JITResolver::getFunctionStub to use > F->isExternal() instead of F->hasExternalLinkage(). However, this then > breaks when calling *real* external functions (native code). I obviously should not post to mailing lists before I've eaten. With my "fix" I get an assertion when taking an

Chris Lattner wrote: > > If getRawValue is moved to ConstantIntegral, I'd simply write > > > > if (ConstantIntegral* CI = dyn_cast<ConstantInt>(V)) { > > BuildMI(*MBB, IPt, NM::MOVE, 1, Reg).addImm(CI->getRawValue()); > > } ... > > > > which is a bit nicer. Of course, if you think it's a good idea, I can > > send a patch.

I just got the CVS version of LLVM running tonight. On my PowerBook, one of the examples (HowToUseJIT) has an assertion error when I try and run it: Running foo: JIT.cpp:217: failed assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' However, when I compile and run the same program on x86 Linux, it runs fine (Running foo: Result: 11). I

There used to be a method in Function called isExternal() that you could call to check if a function is external. That method seems to be removed. What method should now be called to check if a function isExternal? Regards, Ryan -- Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever]

Hi, here I am again with "why is this so" kind of a question. Among different types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. For MO_GlobalAddress, we can get usefull information from the getGlobal() method, which returns GlobalValue*. Wouldn'it it be better is MO_GlobalAddress be called MO_GlobalValue, for consistency? Second, MO_ExternalSymbol is used

> Something like this should work: > > for (Module::iterator F = M->begin(), E = M->end(); F != E; ++F) > if (F->isExternal()) > ... Function* F is external! ... This is not working. For some reason there is a BasicBlock present on undefined functions ! I am compiling the examples from llvm/test/feature, about 28 out of 34 assemble fine. Just cannot seem to get

On Tue, Nov 19, 2013 at 10:20 PM, David Chisnall < David.Chisnall at cl.cam.ac.uk> wrote: > On 19 Nov 2013, at 17:58, Kostya Serebryany <kcc at google.com> wrote: > > > On Tue, Nov 19, 2013 at 9:56 PM, Kuperstein, Michael M < > michael.m.kuperstein at intel.com> wrote: > >> What I’m trying to say is that according to my understanding of the > C++11

I encountered a segfault when using lld to cross-compile for Windows (+MinGW) from Linux. The problem happens with objects built by gcc. The problem is that ObjFile::CreateRegular considers a PendingComdat to be valid (and later causes an illegal pointer dereference). The following patch fixes the crash: diff --git a/COFF/InputFiles.cpp b/COFF/InputFiles.cpp index 9e2345b0a..f47d612df 100644

----- Original Message ----- > From: "Kostya Serebryany" <kcc at google.com> > To: "David Chisnall" <David.Chisnall at cl.cam.ac.uk> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday, November 19, 2013 11:01:12 PM > Subject: Re: [LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH]

On Thu, 17 Jun 2004, Vladimir Prus wrote: > > Hi, > here I am again with "why is this so" kind of a question. Among different > types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. > > For MO_GlobalAddress, we can get usefull information from the getGlobal() > method, which returns GlobalValue*. Wouldn'it it be better is >

Ok, after thinking about it a bit, I decided to go ahead and make the changes required to use a better name than "uninitialized" for global variables that are external. I went ahead and made the following changes: 1. The parser now accepts both "uninitialized" and "external" global variables, they both mean the exact same thing. 2. The LLVM writer now emits

I wonder in what cases FunctionPass is better that Pass. For example, addPassesToEmitAssembly takes PassManger and addPassesToJITCompile takes FunctionPassManager. Another question is about FunctionPassManager::run(Function&) and FunctionPass(Function&). The former calls the later, which is fine, but the latter looks like this: bool FunctionPass::run(Function &F) { if

Can you upload a reproducer? You can create it using the /linkrepro flag. Peter On Thu, Jun 7, 2018 at 2:50 PM, Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > GCC does comdats completely differently from the spec. Since you contacted > me about this off of the mailing list, I started investigating what they > do, and it is completely different. It's

On 19 Nov 2013, at 17:58, Kostya Serebryany <kcc at google.com> wrote: > On Tue, Nov 19, 2013 at 9:56 PM, Kuperstein, Michael M <michael.m.kuperstein at intel.com> wrote: >> What I’m trying to say is that according to my understanding of the C++11 memory model, even in that small reproducer, the store to g and the load from g are in fact a data race. >> >> (This