similar to: [LLVMdev] How do you determine whether a function is defined externally to a module ?

On Sun, 3 Jul 2005, Aaron Gray wrote: > How do you determine whether a function is defined externally ? > Basically I want a list of external functions but cannot seem to get one. > > e.g. I want to create the following list for a module > > EXTERN _printf : NEAR > EXTERN _malloc : NEAR > EXTERN _an_external_fn : NEAR > > I have tried all the obvious permutations but

> 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

I have tried the following :- if (!M.empty()) for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I) if ( !I->getIntrinsicID() && I->getEntryBlock().empty()) O << "EXTERN " << Mang->getValueName(I) << " : NEAR" << "\n"; Based upon :- virtual bool Function::isExternal() const { return

On Sun, 3 Jul 2005, Aaron Gray wrote: >> 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 ! Which functions in particular are you

>> If you take a look at the PowerPC asm printer, it has to do some special >> things for external functions as well, it might give you some ideas. > > I will have a look at this then. AFAICS there is nothing special here (PowerPCAsmPrinter.cpp). Aaron

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]

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

On Oct 20, 2009, at 5:49 AM, Jay Foad wrote: >> To test clang: >> 1) Compile llvm and clang from source. > > LLVM fails to build for me on Cygwin. I get: > Does TOT build? If not, please file a bug. Unfortunately Cygwin is not in our release criteria. I'd like to have a buildbot running (if there is not one already) and then get someone to qualify it for the

> To test clang: > 1) Compile llvm and clang from source. LLVM fails to build for me on Cygwin. I get: make[1]: Entering directory `/home/foad/llvm/objdir-2.6/runtime' make[2]: Entering directory `/home/foad/llvm/objdir-2.6/runtime/libprofile' llvm[2]: Compiling BasicBlockTracing.c for Release build (PIC) llvm[2]: Compiling BlockProfiling.c for Release build (PIC) llvm[2]:

I am getting the following on 'make install' on Cygwin both on debug and release builds :- llvm[3]: Installing Release /home/ang/llvm-coff/bin/llvmc.exe make[3]: Leaving directory `/home/ang/build/llvm-coff/tools/llvmc/driver' make[2]: Leaving directory `/home/ang/build/llvm-coff/tools/llvmc' make[1]: Leaving directory `/home/ang/build/llvm-coff/tools' make[1]: Entering

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

2009/10/20 Tanya Lattner <lattner at apple.com>: > > On Oct 20, 2009, at 5:49 AM, Jay Foad wrote: > >>> To test clang: >>> 1) Compile llvm and clang from source. >> >> LLVM fails to build for me on Cygwin. I get: >> > > Does TOT build? If not, please file a bug. No. Theres the runtime install bug (below), and llvm-gcc has a bug that I

This is a continuation of my previous posts about improving write perf when trapping millions of small writes to a gluster filesystem. I was able to improve write perf by ~30x by running STDOUT thru gzip to consolidate and reduce the output stream. Today, another similar problem, having to do with yet another bioinformatics program (which these days typically handle the 'short reads' that

I noticed that folding a cast of a global address to boolean doesn't work like I expected - there is a comment in the code that casts of external symbols should not happen, but I don't understand the rationale for this. // FIXME: When we support 'external weak' references, we have to prevent // this transformation from happening. In the meantime we avoid folding // any cast of

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

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

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 >

On Oct 20, 2009, at 12:05 PM, Aaron Gray wrote: > 2009/10/20 Tanya Lattner <lattner at apple.com>: >> >> On Oct 20, 2009, at 5:49 AM, Jay Foad wrote: >> >>>> To test clang: >>>> 1) Compile llvm and clang from source. >>> >>> LLVM fails to build for me on Cygwin. I get: >>> >> >> Does TOT build? If not,

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