similar to: [LLVMdev] llvm-gcc4 1.8 mingw32 prerelease

I'm looking forward to your patches and bug reports. I really want to get this going myself. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Anton Korobeynikov Sent: Wednesday, May 10, 2006 1:22 PM To: LLVM Developers Mailing List Subject: [LLVMdev] Successfulyl bootsrapped llvm-gcc4 on mingw32 Hello, Everyone. Today

Hello, Everyone. Today I've finished digging into llvm-gcc4 in order to build in under mingw32. The most trickiest was to make libstdc++ build, since its configure & makefiles are not so perfect as main gcc ones. There are several problems with inline assemler (in two places at least), but both of them are easily seen. Also, there are some compiler crashes while compiling libiberty (with

Hello, Everyone. All blackmagic (playing with pwd, etc) in my build description has gone with patched bash (pwd builtin was just hardly disabled). It's not good, I myself prefer modifying libstdc++ configure script to use PWD_CMD environmental variable as main gcc ones. I'm working on this feature. -- With best regards, Anton mailto:asl at math.spbu.ru

Hello, Henrik. You wrote Thursday, May 11, 2006, 5:13:06 AM: HB> Thanks Anton. Nice Job. There was at least one thing I miss in the description: In the step 3 you should unpack runtime libraries from mingw32 distribution into "prefix" (say, w32api and mingw-runtime) before starting configure for GCC. BTW, maybe it will be better just use patched bash (with "pwd" builtin

Hello, Greg. You wrote Sunday, May 14, 2006, 5:21:49 PM: GP> Do I still need to do the "black magic"? In fact, yes. GP> What is this patched version of bash (do you have a patch, where do I get GP> it?) What does "pwd builtin was just hardly disabled" mean? There are some set of built-in commands in bash (they are called "builtins"). For example

Hello, Everyone. This is just brief description on building llvm-gcc4 with mingw32. It's definitely non error-free and contains many "hacks", which should be eliminated in the future. 1. Prerequisites We're building in the folowing configuration: 1.1 GCC 3.4.5: gcc -v Reading specs from f:/research/mingw/bin/../lib/gcc/mingw32/3.4.5/specs Configured with:

Hello, Everyone. I'm currently trying to bootstrap llvm-gcc4 on mingw32 platform. Everything (except some small fixes) seems to be fine: stage1 finished successfully. I'm linking with debug variant of LLVM, since linker bug prevents release builds. Unfortunately, stage2 failes immediately with this cryptic message: $/f/tmp/llvm/gccbuild/gcc/xgcc -B/f/tmp/llvm/gccbuild/gcc/

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

Reid & Aaron > > This is the same error that appears alot of times on the 'make check' > > of the debug build. > > > > What is going on here please ? > > Sounds to me like the llvm-gcc being used wasn't configured using > --with-llvm=. That message occurs when llvm-gcc is built > "normally" (without using llvm). Yes. llvm-gcc4

Hello Hendrik Mon, 07 Aug 2006 14:35:25 -0400 you wrote: > (1) To install llvm, do I really need the llvm version of the gcc > front end? I have no special interest in yet another c/c++ conmpiler. No. This will only need, if you want to turn your C\C++ sources to LLVM bytecode. > (4) The page http://llvm.org/docs/GettingStarted.html#checkout says > to get the gcc 3.4 source code.

Hello, Greg. You wrote Saturday, May 6, 2006, 10:24:16 PM: GP> If anyone has any insight I'd love to hear it. GP> Meanwhile, I'll continue to investigate... Currently I'm working on bootstrapping llvm-gcc4 on mingw32 platform. There are some serious miscompartibilities preventing build. I'll let know the results. Anyway, it's common knowledge, that msys itself have

Hello Anton Thu, 3 Aug 2006 12:38:54 +0400 you wrote: > I've updated it yesterday and rebuilt - llvm built fine. But when > building llvm-gcc4 (also updated yesterday from new /trunk > directory) it fails with the same error. You might easily get llvm-gcc4-mingw32 binaries from "prerelease" directory. Since stdcall, fastcall & dllimport stuff is unsupported right now,

First, thanks for testing this! > Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5) > > HIGH LEVEL COMMENTS > * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't > that be llvm-1.9? We have always labeled the dir just llvm which is fine. If you build llvm it will know its version 1.9. > * LLVM was built in Release mode

Hello Anton Thu, 3 Aug 2006 23:13:52 +0400 you wrote: > I won't be available for the next 10-12 hours if you'll need some more > files. Well. I have one idea. Could you please execute "sort --version" from your cygwin shell and let me know, whether it's GNU one (it should reply with the words "textutils") or windows-supplied one (it should just give you and

On Thu, 16 Nov 2006, Tanya M. Lattner wrote: >> * I don't think this is ready for release. In particular the llvm-gcc4 >> binary >> seg faults on FC 5 for most of llvm-test programs. >> * I'm going to re-try without using the binaries and building >> everything from scratch. > > Does llvm-gcc4 seg fault for make check? I've done extensive

Hello, Duncan. > 3-fortran.diff > Get fortran to compile: use the common stubs and rip out > the incomplete collection of dummy routines someone already put in. > With this patch, the fortran build dies at this point: > > cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void llvm::ScheduleDAG::AddOperand(llvm: > :MachineInstr*, llvm::SDOperand, unsigned int, const

Hello, Stefan > my suggestion: > add in README.LLVM for the linux-section that in the case one sees the error > with GCC4.2.0 the switch "--disable-shared" should be added to the configure > command. It's already there. At least on HEAD. Probably, it was missed in 1.9 release, sorry. It's PR1017. -- With best regards, Anton Korobeynikov. Faculty of Mathematics

Hello, Jay. > the resulting bitcode doesn't use LLVM's exception handling > intrinsics, it just has a call to a function called "_setjmp". And > there doesn't seem to be any provision for returning the current value > of the volatile variable v if setjmp returns non-zero - the bitcode > always returns zero, whereas the spec for setjmp() says that f() >

Hello, Torvald > is there documentation about what happens to setjmp() et al, and how one > should handle the setjmp intrinsics? You shouldn't use them at all. > Are setjmp() function calls transformed to intrinsics, or are > the intrinsics only used for EH? Intrisincs are used for representing necessary EH code flow. User's setjmp() are just function calls. We fixed

I have successfully built LLVM and LLVM-GCC4 on GCC-4.2.0-20070501 on Linux x86 32bit. GCC 4.2.0 RC3 is availiable from :- ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070505/5535bb23/attachment.html>