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)

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

Hi, Op 20-aug-06, om 21:18 heeft Reid Spencer het volgende geschreven: > I looked over your patch and it looks good. I applied a patch based on > yours. The llvm-ld tool now uses the PluginLoader just like the opt > tool. It will also run some cleanup passes after the loaded plugins > run > to ensure cruft is removed. OK, thanks. Your patch seems to work, although I also get

Do you have a verify option in your loaded module? Reid. On Sun, 2006-08-20 at 22:04 +0200, Bram Adams wrote: > Hi, > > Op 20-aug-06, om 21:18 heeft Reid Spencer het volgende geschreven: > > > I looked over your patch and it looks good. I applied a patch based on > > yours. The llvm-ld tool now uses the PluginLoader just like the opt > > tool. It will also run

Hi, Op 18-mei-07, om 10:10 heeft Tanya M. Lattner het volgende geschreven: >> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build >> with the header files using uintptr_t (not recognised as a type). >> Putting "#include <stdint.h>" in include/llvm/BasicBlock.h (llvm) >> and in "include/llvm/ValueSymbolTable.h" (frontend)

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

Hi, There is a typo in $LLVM_SRC/Makefile.rules on line 750 where it says : SharedLibKindMessage := "Lodable Module" instead of SharedLibKindMessage := "Loadable Module" Op 15-nov-06, om 15:54 heeft Bram Adams het volgende geschreven: > Didn't check > LLVM's test suite. Doing the simple LLVM-tests (on Slackware 10.2) gets: === Summary ===

Hi, Op 20-aug-06, om 22:26 heeft Reid Spencer het volgende geschreven: > Do you have a verify option in your loaded module? What exactly do you mean by "verify option"? Anyway, I did a grep on "verify" in my code, but found nothing. Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium)

Hi, Op 15-nov-06, om 03:26 heeft Tanya M. Lattner het volgende geschreven: > I'm able to reproduce this if I skip doing a "make" and directly do a > "make install" after configuring. I believe we require people to do > a full > build before attempting to install. So I don't think its really a bug. > Could you try doing a make first and then install?

Hi, Chris Lattner wrote: > All the non-vastart calls can be anywhere. va_end in particular codegens > to a noop on all targets llvm currently supports, fwiw. > Things go well, except for the following (pathological?) C program: int va_double_sum(int count,...){ int i,sum=0; va_list ap; va_start(ap,count); for(i=0;i<count;i++){ sum+=va_arg(ap,int); } va_end(ap);

Hi, Op 25-sep-06, om 20:07 heeft Chris Lattner het volgende geschreven: > What are you trying to accomplish? Why not use location records from > debug info? You mean the debugging intrinsics? Just discovered them :-), and I guess that's exactly what I need. Haven't tried them extensively yet, so I'm wondering whether the remark in your mail of 09/04/2006 to Nikhil Patil

> When building LLVM 1.9 on OSX 10.4.8, I get (after a while, see attachment): > > make[1]: *** No rule to make target `/path/to/llvm-build/Debug/bin/tblgen', > needed by `/path/to/llvm-build/lib/VMCore/Debug/Intrinsics.gen.tmp'. Stop. > make: *** [install] Error 1 > > when doing: > > $LLVM_SRC/configure --prefix=$LLVM_INSTALL --with-llvmgccdir=$LLVM_FRONT

Hi, Op 30-mei-07, om 06:31 heeft Chris Lattner het volgende geschreven: >> when I do: llc file.bc -march=c -o file.c > > The C backend doesn't support all target-specific intrinsics. OK (http://llvm.org/bugs/show_bug.cgi?id=1481). > Please file a bug with this in a self-contained .c file. Thanks! Has happened: http://llvm.org/bugs/show_bug.cgi?id=1482. > Very strange.

Hi, Today, I've made the transition from LLVM 2.1 to 2.3. I invoke opt with two dynamic libraries to "-load", the first of which contains transformation passes and support code whereas the second one provides extra passes which make use of the first library's support code. In other words, the symbols loaded in for the first library should be available when the second

Hi, Op 14-aug-06, om 09:29 heeft Reid Spencer het volgende geschreven: > >> Apparently, %llvmgccdir% and %llvmcc1% are not recognized as a useful >> variable by the llvmc configuration parser. > > Actually, they are. See tools/llvmc/ConfigurationDriver.cpp around > line > 304. Also, they are recognized by the lexer. Its more likely that when > you configured LLVM

Hi, Today I managed to link ioquake3, but generating a binary does not work yet. 1) On OSX, I get: Error: Code generator does not support intrinsic function 'llvm.ppc.altivec.lvsl'! when I do: llc file.bc -march=c -o file.c 2) On Linux X86, llc does not give any problem, but I get this while compiling the generated .c file: error: unknown register name 'S' in

Hi, Op 2-okt-06, om 21:35 heeft Chris Lattner het volgende geschreven: > I think the easiest way to do this is to do the 'complement' as you > describe, but specially handle the varargs case. Basically you > need to > call va_start in the original function, and pass the valist pointer > down. > This shouldn't be too hard. OK. I've been rethinking my use

Hi, I've written a couple of passes, and I intend to use them using llvm-ld (loading works fine). However, I can't seem to figure out how to put them first, i.e. before all other optimizations (inlining, internalizing, ... should only kick in after my passes). Omitting AnalysisUsage::setPreservesAll() doesn't help and there is no AnalysisUsage::invalidateAll(). Does anybody know

Hi Bram, On Fri, 2007-05-18 at 18:12 +0200, Bram Adams wrote: > Hi, > > Op 18-mei-07, om 10:10 heeft Tanya M. Lattner het volgende geschreven: > > >> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build > >> with the header files using uintptr_t (not recognised as a type). > >> Putting "#include <stdint.h>" in