similar to: [LLVMdev] LLVM build failures

I'm seeing a lot of build failures recently: (1) on x86-64 linux, gcc 4.1.2: ... llvm[3]: Compiling Hello.cpp for Debug build (PIC) llvm[3]: Linking Debug Loadable Module LLVMHello.so /usr/bin/ld: .../llvm/build/llvm/lib/Transforms/Hello/Debug/.libs/Hello.o: relocation R_X86_64_PC32 against `std::basic_string<char, std::char_traits<char>, std::allocator<char>

Hello, Scott. > Checking the assembly from llc, the first alloca call is to allocate > local vars in _main. Is this just the state of the code at 2.0 when > built with vs.net, or is there something that I've managed to > mis-build locally? _alloca is used to probe the stack, if you asks for locals of size more that 4k. This is pretty ugly, but the names of this functions differs

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 Thanks for the info, it led to the source of the error I was having. I was using llvm-gcc binaries (built with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack

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

The alloca hook is in lib\System\Win32\DynamicLibrary.inc all the way at the bottom. You'll see a __MING32__ #ifdef around the definition. You just have to implement those methods and it'll work just fine. Jake On 6/24/07, Scott Graham <scott.llvm at h4ck3r.net> wrote: > > Hi > > Thanks for the info, it led to the source of the error I was having. > > I was using

Dear llvmdev, I am new to LLVM , but have a task on writing a LLVM backend to generate some architecture specific assembly file. Here is my cygwin build setting: GCC 3.4.4 , BIN UTILITY 2.15 ,and all other packages of the right version listed on the LLVM Getting Started doc. I have successfully built Release 1.6 LLVM. All the tools has been installed there /usr/local/bin . But I

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

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, 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

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

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

Just a quick question on LLVM, signals, and the lli interpreter. A sample program is included at the end. Platform is x86, Linux, 32-bit, GCC 4.2.4. Does lli -force-interpreter support signals, or is it only the JIT that does? The following sample program crashes with lli 2.5 and lli top-of-tree. Thanks and regards, Matt ============================= #include <stdio.h> #include

Hello, Ashwin. You wrote Wednesday, May 24, 2006, 11:25:11 AM: AC> "Pass::getClassPassInfo<PassClass>() "Pass class not AC> registered!"" failed: file AC> "/cygdrive/c/llvm/llvm/include/llvm/PassAnalysisSupport.h", line 76 AC> Aborted Same for me. AC> Wihtout the -march specified (using native x86 assembly) it does AC> convert it into

Hello Matt, The interpreter doesn't support external functions at all. This includes the printf function from the glibc library. That's why the signal causes a segfault. If you're interested in bringing the interpreter up-to-date with the JIT compiler, I would welcome it since JIT compilation isn't supported on all platforms. --Sam ----- Original Message ---- > From:

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

Chuck, > It is dying trying to store a our working vector into one of the LLVM > vectors created on the stack. Despite the align-16 directive on the > alloca instruction, it is not always aligning to a 16-byte boundary. The stack is not necessary 16 bytes aligned on linux/windows. The vector is really sotred aligned relative to %esp, but %esp value is not good. This is known problem