similar to: [LLVMdev] Linking two external linkage GlobalValues

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)

The sound file is played correctly for the first time, then when rewind to the initial position. then copy PCM to buffer, the OpenAL report an error. It seems like the OpenAL doesn't recognize the PCM data. The OpenAL error number : AL_INVALID_VALUE 0xA003 void Buffer::PCMData (ALuint id, ALenum eFormat, ALvoid *data, ALsizei size, ALsizei freq) { // Copy

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

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

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

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

On Jan 12, 2009, at 8:24 AM, Dan Gohman wrote: > > On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: > >>>> There is no good reason for malloc to be an instruction anymore. >>>> I'd >>>> be very happy if it got removed. Even if we keep it, malloc/alloca >>>> should be extended to optionally take 64-bit sizes. >>> >>>

Sorry if it comes out a bit pushy bumping my own question, but it's been really difficult to find any info regarding this functionality in the mailing list archives. Just some emails i've found from people working on NaCl: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-December/046055.html  is there a branch where this is being work on, or is internal chromium project so far? Also

On Fri, Nov 11, 2011 at 11:00 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > A CallInst in one module can't reference a Function in another module. > Build a declaration of foo in the module where you're building the > call, and call that. > > -Eli > Hmm, before emitting any code i've added this:

Hi All, I need to call global variable by its name from the following code for(Function::iterator i=F->begin();i!=F->end();++i) { BasicBlock*Bb =&*i; GlobalVariable* GV = new GlobalVariable(type,false, F->getLinkage(),0, "F$"+Bb->getName()); GV->setInitializer(Constant::getNullValue (typ)); GList.push_back(GV); } Could I solve that by

Hi, I want to execute functions in a module, this module will have dependencies resolved in other modules. the modules might change (dynamic compilation environment) so i would prefer not not link all the dependencies in a single monolithic module, that is, if it can be avoided I hope to use Linker::linkModules but this is always destructive. That is ok for one module depending on a single one,

2011/2/28 John Criswell <criswell at illinois.edu>: > On 2/28/11 6:31 AM, Gabriel Rodríguez wrote: > > Hi all, > > I am trying to extend a FunctionType to include new parameters. In > particular, I want to > ensure that the main function has been declared with both argsc and argsv. > However > there seems to be no easy way to accomplish this: >

Hi all, I had a look at the interprocedural optimizer. In my opinion the routine 'GlobalOpt::ProcessInternalGlobal' is a little bit to conservative. It removes global variables if the only routine using this variable is main. Typically this condition is valid only for very few global variables. Here is a code snippet containing the test before the transformation: file:

The problem is that ThinLTO is not dropping the non-prevailing definitions, and they end up being emitted into the object file for b.o. $ ../ra/bin/llvm-dis -o - b.o0.0.preopt.bc | grep __llvm_prof $__llvm_profile_raw_version = comdat any $__llvm_profile_filename = comdat any @__llvm_profile_raw_version = constant i64 72057594037927940, comdat @__llvm_profile_filename = constant [19 x i8]

Chris Lattner wrote: > On Jan 12, 2009, at 8:24 AM, Dan Gohman wrote: > >> On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: >> >>>>> There is no good reason for malloc to be an instruction anymore. >>>>> I'd >>>>> be very happy if it got removed. Even if we keep it, malloc/alloca >>>>> should be extended to

Hello, GlobalOpt has an interesting special-case optimization for globals that are only accessed within "main". These globals are replaced by allocas within the "main" function (and the GV itself is deleted). The full condition for this happening is: // If this is a first class global and has only one accessing function // and this function is main (which we know is not

Hello LLVM, To reduce the code-size cost of relocations, I'm trying to hoist GlobalValues that are used many times. A new pass hides each hoisted GV behind a BITCAST in the dominating BB. The pass then updates users with the output of the BITCAST. This pass works properly AFAICT. The problems come in instruction selection. SelectionDAGBuilder::visitBitCast() treats the BITCAST as a no-op

Hey there, I'm having trouble getting speex working with a project that uses it. For some quick background, the game Quake 3 was GPL'ed a while ago. Some programmers decided to throw it into a public svn and improve on it, called it ioquake3. One of the blokes integrated speex into ioquake3 and it works, but I have troubles getting it to compile/link properly with Visual Studio 2005. I

Thanks Peter, your patch does fix the reproducer. I filed https://bugs.llvm.org/show_bug.cgi?id=37422 to track this bug. I have no clue on how to resolve the tests - whether further cleanup is required in the code or in the tests. But if Teresa or you cannot get to it, I can, with some help, take a crack at fixing the tests. On Wed, May 9, 2018 at 11:26 AM Peter Collingbourne <peter at