similar to: [LLVMdev] Exception Problems

On 9/5/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Bill, > > > When I try to compile on Darwin now, I get this: > Could you please provide LLVM bytecode, where bug is reproducible with > llc? > Attached. Thanks! -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: EH.bc Type: application/octet-stream Size: 872 bytes Desc: not

bugzilla plz. Thx, Evan On Sep 5, 2007, at 2:15 PM, Bill Wendling wrote: > On 9/5/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Bill, >> >>> When I try to compile on Darwin now, I get this: >> Could you please provide LLVM bytecode, where bug is reproducible >> with >> llc? >> > Attached. Thanks! > > -bw >

Hello, Bill > It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled. Oh, no. They are always compiled. > They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During

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

Hi Anton, Is the patch going to be uploaded to the CVS source? Ashwin On 5/24/06, Evan Cheng <evan.cheng at apple.com> wrote: > > > On May 24, 2006, at 5:03 AM, Anton Korobeynikov wrote: > > > Hello, Ashwin. > > > > You wrote Wednesday, May 24, 2006, 11:25:11 AM: > > > > AC> "Pass::getClassPassInfo<PassClass>() "Pass class

On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Bill > > > It may be my lack of understanding, but it appears that having -- > > enable-eh set during compilation of llvm-gcc is causing extra files > > to be compiled. > Oh, no. They are always compiled. > > > They do. However, it doesn't seem to stop it from failing during > >

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, Aaron. > /usr/src/llvm-gcc4/gcc/libgcc2.c: In function '__eprintf': > /usr/src/llvm-gcc4/gcc/libgcc2.c:1832: internal compiler error: > Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://llvm.org/bugs> for instructions. You should: 1. Try to emit bytecode with --emit-llvm compiler switch. 1.1

Hi Evan, I updated cvs and recompilled llvm. Still getting some unrecognized commas in the compilation of the assembly file after using llc. I guess this is still future work... Ashwin On 5/25/06, Evan Cheng <evan.cheng at apple.com> wrote: > > The patch is now in. Sorry about the delay! > > Evan > > On May 25, 2006, at 10:20 AM, Ashwin Chandra wrote: > > Hi

Hello, Bill. > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > source server lately? No. It's still at rev 319 (as of 29.04). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

On May 24, 2006, at 5:03 AM, Anton Korobeynikov wrote: > 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

Hi all, This is a (very) rough patch to fix building LLVM with exceptions on PPC Darwin. Basically, it puts the burden of adding the "--enable-eh" on the specific target, which is where I think it should go. If this is okay, then I can clean the patch up and submit it. -bw Index: gcc/llvm-backend.cpp =================================================================== ---

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

The patch is now in. Sorry about the delay! Evan On May 25, 2006, at 10:20 AM, Ashwin Chandra wrote: > Hi Anton, > Is the patch going to be uploaded to the CVS source? > > Ashwin > > > On 5/24/06, Evan Cheng <evan.cheng at apple.com> wrote: > > On May 24, 2006, at 5:03 AM, Anton Korobeynikov wrote: > > > Hello, Ashwin. > > > > You wrote

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

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

The llvm-gcc source can be download from: http://jolt-lang.org/llvm-gcc.tar.bz2 31mb ~7 minute download http://jolt-lang.org/llvm-gcc.tar.gz 40mb ~8.5 minute download Download times assume you are the only person downloading. Please download the bz2 version if possible. I currently have no unexpected failures. Bill wrote: > On 5/4/07, Anton Korobeynikov <asl at

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

I am getting an "--emit-llvm is not supported in this configuration" error on a release build on Cygwin, the debug build is fine. make[3]: Entering directory `/usr/build/llvm/runtime/GCCLibraries/libc' llvm[3]: Compiling atox.c for Release build (bytecode) llvm-gcc: --emit-llvm is not supported in this configuration. make[3]: ***

> How can having an MSVC compatible compiler be to the detriment of clang and > llvm? No one is trying to break mingw here, merely add support for something Just to make stuff clear: I just wanted proper naming which will be non-confusing. Right now we have: - isTargetWindows() which really means "msvc-compabile" - isTargetWin32() which means "everything on windows", so