similar to: [LLVMdev] Register allocation problems with TLS unit test.

Running the SingleSource tests with llc while debugging my PBQP allocator I noticed that test-suite/SingleSource/UnitTests/Threads/tls.c has some issues with register allocators other than linear scan: Local, simple & bigblock regalloc all cause the following ld assertion failures: bash-3.2$ gcc tls.foo.s -o tls.foo.debug -lm -lpthread /usr/bin/ld: BFD version 2.17.50.0.18-1 20070731

2008/9/21 Anton Korobeynikov <asl at math.spbu.ru>: > Hello, > >> If anybody has an idea of how to fix this (other than using another >> version of gcc because I am sick of compiling), I would appreciate. I >> can offer backtraces or shell access if anybody is interested, just >> ask me what you need. > This was fixed couple of months ago. Please consider

Hello, > If anybody has an idea of how to fix this (other than using another > version of gcc because I am sick of compiling), I would appreciate. I > can offer backtraces or shell access if anybody is interested, just > ask me what you need. This was fixed couple of months ago. Please consider using current svn top of tree, not 2.3 release. -- WBR, Anton Korobeynikov

Hi, Oscar > at all, it would be great if you reflect your changes on the file list > inside the corresponding CMakeLists.txt when you add, remove or rename a > .cpp file. Isn't is possible for cmake just to glob everything in the corresponding directory? -- WBR, Anton Korobeynikov

Hello Philipp, > Does that mean that I will have to configure llvm as a cross-compiler > even when using the C backend? Not llvm, but llvm-gcc only. I've successfully used llvm-gcc for crosscompiling with host=linux and target=mingw32 platform. So, you have just to supply host, build and target triples to llvm-gcc configure and be also sure, that configure will find target headers,

Hi, Chris > If the assembler is a limitation, the best solution would be to add a > direct PECOFF writer. There is a start of direct ELF and Macho writers > already in the tree. They are not production quality, but could be a > useful place to start looking. Well, maybe. But in any case I doubt there will be 'open' support for CV debug format :) -- WBR, Anton

Hello everyone. The bug in ld prevented release build of LLVM on Mingw & Cygwin is fixed by now. You might get the patch for binutils sources at http://sourceware.org/bugzilla/show_bug.cgi?id=2659 Hope, this fix will be included in the next binutils release. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Chuck > I've had a look at the stubs before and I think I'm circumventing them > in the example program since I populate the table and compile the > functions in the order so that things never need to be done lazily, but > I'll look further. Well, anyway stubs are definitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to

Hello, Kevin > build process I described in my original message. So the difference is > more subtle; maybe a difference in the layout of structs or something. Also, there can be another ABI differences. > llvmoutput.c:17976: warning: pointer targets in passing argument 1 of > 'longjmp' differ in signedness Hrm, are you using setjmp/longjmp stuff? They're definitely not

Hello, Kevin. > Well, I already use custom includes with these options: "-nostdlib > -nostdinc -Ipsptoolchain/psp/include > -Ipsptoolchain/lib/gcc/psp/4.1.0/include". But that seems not enough. > GCC has some target-specific behaviour compiled in? Well, in general - yes. However, I'm not sure up to which margin. -- WBR, Anton Korobeynikov

Hello, Bill > This merge should go *much* more smoothly than the last merge -- it > could hardly be worse, right? ;-) I already did a test compile of > llvm-test with the patch and it compiled the programs without a > problem. Devang is currently testing it as well so that I have a > second opinion. One thing, which we already saw: please carefully check, that you won't

Hello, Oscar > Anyways, if there is no Mercurial or Bazaar mirrors available, I will > try git. Recommendations on which one to use welcomed. There is git mirror at repo.or.cz: http://repo.or.cz/w/llvm.git, llvm-gcc & clang mirrors are available there as well. I'm updating it 'by hands' currently due to some reasons, so sometimes it will need 2-3 days for changes in llvm

Hi, > (2) on alpha, gcc 4.2.4. The "unknown component name: alphacodegen" > didn't use to occur. My fault, I'll fix it. The problem is that lli wants to link in JIT module, which does not exist for these targets. -- WBR, Anton Korobeynikov

On Mon, Sep 29, 2008 at 12:05 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Mon, Sep 29, 2008 at 9:01 AM, Duncan Sands <baldrick at free.fr> wrote: >> libgcc is also available for windows. > Really? What license? What restrictions? Any speed impact over the > VC runtimes? Don't mix VC runtime and libgcc. These are totally different libraries for doing

Yes, you are right. During my testings, I tried the llvm produced .S files with the gcc frontend and it compiled and linked them to the final executable. The problem is with the gcc and binutils licence. This is GPL and while this is ok for open source or for academic purposes, it can't be used on commercial projects. In fact one of the strong points of llvm (and clang) is its BSD like

Razvan, You're somewhat misinterpreting the GPL license. Using binutils as a dependency of LLVM does not require that they be linked into any distributable that might contain proprietary code. They can be shipped as separate, purely-GPL'd executables that are called via the command line, thereby avoiding the whole "infection" problem. This is, for instance, how

Hello, Everyone > Hmm. It is "ld -r" that seems to be doing this. > If I use the sub-objects on their own I don't get any warning. This can be bug in the linker, when it tries to optimize EH tables. What's you binutils version? PS: We already faced with linker bugs during LLVM compilation (I think it was in pre 2.17 ages) -- WBR, Anton Korobeynikov

Sam, > Am I supposed to install MinGW (maybe MSYS) and extract prebuilt > packages ( llvm-2.1-x86-mingw32.tar.bz2 and > llvm-gcc4.0-2.1-x86-mingw32.tar.bz2) to C:\MinGW ?? llvm-as != as. You'll need to have binutils installed in order to compile & link. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Everyone > On this specific case, IIRC, MinGW chokes if asmprinter is not on the > list of components. This may be another consequence of the malfunctoning > of llvm-config/GenLibDeps.pl on MinGW/MSYS. This works for me without any problems on mingw32. What are the problems you're seeing? -- WBR, Anton Korobeynikov

Hello, Razvan > after that I use only the Windows interface to it (like any other > proprietary Windows software does) , GPL forbids me to do that. That's due to nature of the interface. Binary interface to codec make the proprietary application 'derived work'. > - I didn't find any commercial projects (not Operating Systems or > dual-licensed but simple