similar to: [LLVMdev] Linkage error in simple call graph pass?

Hey All, I’m working with Mac OS X 10.10, and everything seems generally fine but when I started working on a FunctionPass I get the following: error: call to deleted constructor of 'Function::ArgumentListType' (aka 'iplist<llvm::Argument>') Function::ArgumentListType argList = f.getArgumentList(); Any pointers as to the correct way access the Arguments of a

Hi, I've written a CallGraphSCCPass that compiles successfully, but when I try to run it with opt, it fails: Symbol not found: __ZTIN4llvm16CallGraphSCCPassE If I simply change the pass to be a FunctionPass or a ModulePass, opt can run it just fine. I'm on Mac OS X, so I thought perhaps I was running into bug #2771 [1], but I'm getting the same error on Ubuntu Linux:

Hi, I'm using macports to install nut on a MAC OS X (10.7) I get the following error messages when I try running: sudo blazer_usb -a zigor -DDDDDDDDDD 0.944590 Checking device (0001/0000) (250/005) 2.785449 - VendorID: 0001 2.785465 - ProductID: 0000 2.785468 - Manufacturer: unknown 2.785472 - Product: STD UPS MON V1.0 2.785475 - Serial Number: unknown

Does anybody know how to do a intermediate linkage clustering in R? Is there a command allready developed? Which package do I have to load? Thanks in advance yvo -- View this message in context: http://www.nabble.com/intermediate-linkage-clustering-tp15736379p15736379.html Sent from the R help mailing list archive at Nabble.com.

Dear R community, I am trying to understand how the ward linkage works from a quantitative point of view. To test it I have devised a simple 3-members set: G = c(0,2,10) The distances between all couples are: d(0,2) = 2 d(0,10) = 10 d(2,10) = 8 The smallest distance corresponds to merging 0 and 2. The corresponding ESS are: ESS(0,2) = 2*var(c(0,2)) = 4 ESS(0,10)

My understanding is that single linkage clustering is equivalent to finding the minimum spanning tree. Hclust works very nicely for finding the clusters but I am unable to find enough information in its output to construct the minimum spanning tree. In particular, I want to find a minimum spanning tree path between two items in the tree. Is this possible with hclust or is there another

Hi all, I am trying to run a cluster analysis using Sorenson (Bray-Curtis) distance measure with flexible beta linkage method. However, I can't seem to find flexible beta in any of the functions/packages I have looked at. Any help would be appreciated. [[alternative HTML version deleted]]

Author: pwernau Repository: /hg/zfs-crypto/gate Revision: ba16e4a9c5255b467f2d29663976000f863c3b71 Log message: PSARC 2005/501 ikecert PKCS#11 object migration and linkage 6219636 ikecert(1m) needs to tie IKE certificate slots to existing PKCS#11 objects 6220119 ikecert certlocal migrate disk key to PKCS#11 token 6232671 Can''t add a certificate to a keystore with ikecert(1m) 6303764 IKE

> Currently what debugger has to do is to demangle RTTI name and try to > match it to DW_AT_name attribute to find type. As you can see it does > not work for any of 3 examples. > > I've asked about the problem on G++ maillist, and one of the proposed > solutions is to emit DW_AT_linkage_name for types.  > > Can this solution be also implemented in LLVM?  It could, but

Hi, I have a pass that creates a GlobalVariable, when I ran it get the following error: Global is external, but doesn't have external or weak linkage! i8** @myvar This is how I create the GlobalVariable: ------------------------------------------------ new llvm::GlobalVariable(*M, IRB.getInt8PtrTy(), false, llvm::GlobalValue::CommonLinkage, nullptr, "myvar", NULL,

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 ;

Hi, Before I go ahead and remove the generation of stubs for external functions, is there any good reason why they get generated? I can understand that the JIT wants to make stubs for the functions it compiles itself - it enables selective recompilation and replacement - but functions which are defined in a library (or in my case by the application using the JIT) can't be changed anyway.

I am implementing weak linkage support on the ARM backend and I noticed this code on the X86 and PPC backends: ------------------------------------------------ // If the initializer is a extern weak symbol, remember to emit the weak // reference! if (const GlobalValue *GV = dyn_cast<GlobalValue>(C)) if (GV->hasExternalWeakLinkage()) ExtWeakSymbols.insert(Mang->getValueName(GV));

On Wed, 6 Dec 2006, [UTF-8] Rafael Esp?ndola wrote: > I am implementing weak linkage support on the ARM backend and I > noticed this code on the X86 and PPC backends: > ------------------------------------------------ > // If the initializer is a extern weak symbol, remember to emit the weak > // reference! > if (const GlobalValue *GV = dyn_cast<GlobalValue>(C)) > if

Hi, I've been able to link ioquake, but not without a small modification to lib/Linker/LinkModules.cpp:427 where I had to add: } else if (Dest->hasExternalLinkage() && Src->hasExternalLinkage()){ LinkFromSrc = true;//overwrite old value LT = Src->getLinkage();//use src linkage The reason is that two files both had a global function pointer variable (due

Hello, Bram. > My question: does this change break certain design decisions, > optimisations, ...? This is bug in the source code. You have two symbols with the same name in the different object files, which is definite redefinition. At least one of them should be declared with "extern". -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint

On Fri, 25 May 2007, Anton Korobeynikov wrote: >> My question: does this change break certain design decisions, >> optimisations, ...? > This is bug in the source code. You have two symbols with the same name > in the different object files, which is definite redefinition. At least > one of them should be declared with "extern". Shouldn't these symbols get

Hi, Op 26-mei-07, om 23:14 heeft Chris Lattner het volgende geschreven: > Shouldn't these symbols get "common" linkage, aka llvm weak linkage? > > Are you building the source with -fno-common? Yes. What does this mean? Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium)

On Sat, 26 May 2007, Bram Adams wrote: > >> Shouldn't these symbols get "common" linkage, aka llvm weak linkage? >> >> Are you building the source with -fno-common? > > Yes. What does this mean? -fno-common is a performance win on some targets, but it disallows merging of global variables that are defined with no initializers (like your example). Please

Hi all, I was looking at the StructRetPromotion pass this morning and noticed it doesn't look at a function's linkage at all. Since it changes the signature of the function, I would say it should only change internal functions, like ArgumentPromotion does for example. Is there some implicit check I'm missing, or should an explicit check really be added? Gr. Matthijs --------------