similar to: compile problem on solaris10 x86

Thank you for any pointers. Windows XP ** *# as -version GNU assembler (GNU Binutils) 2.19.1 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `mingw32'.* ** ** *as -o crc32_x86.o

Ok, I got home so I have more details. Here's the sample C program: ----------------- C program --------------- #include <stdio.h> int main() { printf("hello world\n"); return 0; } ------------- end C program ------------- This is compiled using llvm online demo into the following llvm code (target removed): ----------------- LLVM code -------------- deplibs

On Mon, 7 Mar 2005, Vyacheslav Akhmechet wrote: > Ok, I just tried the patch with some modifications (added msvc target > and used WIN32 instead of __MINGW32__ for preprocessor) and everything > worked beautifully. Thanks for the help! Did you actually try the previous patch? If you compiled llvm-gcc with mingw, it should work, regardless of the compiler you use to compile the LLVM

My first patch was a little premature, please use this one. On Mon, 2005-03-07 at 17:19, Reid Spencer wrote: > Vyacheslav, > > This is the same problem that I had with Cygwin .. nearly identical. > The issue was documented in PR492 if you want some background. I'm > currently trying to dig up what I did to fix this in December for Cygwin > and see if I can apply the same

Ok, I just tried the patch with some modifications (added msvc target and used WIN32 instead of __MINGW32__ for preprocessor) and everything worked beautifully. Thanks for the help! On Mon, 7 Mar 2005 20:45:40 -0500, Vyacheslav Akhmechet <coffeemug at gmail.com> wrote: > Reid, > > This patch won't work for me. I compile llvm toolset with MSVC Express > (hence __MINGW32__

Vyacheslav, This is the same problem that I had with Cygwin .. nearly identical. The issue was documented in PR492 if you want some background. I'm currently trying to dig up what I did to fix this in December for Cygwin and see if I can apply the same change for mingw. Reid. On Mon, 2005-03-07 at 16:39, Vyacheslav Akhmechet wrote: > Ok, I got home so I have more details. Here's the

Yes, but it won't work in the future because the VC++ build will use Intel syntax, not AT&T. If you have mingw installed, why not use it to build LLVM? It's a lot more functional. Mixing and matching Microsoft and GNU tool chains is not good for your sanity. Vyacheslav Akhmechet wrote: >Reid, > >This patch won't work for me. I compile llvm toolset with MSVC Express

Reid, This patch won't work for me. I compile llvm toolset with MSVC Express (hence __MINGW32__ won't be defined for me at compile time). I only try to feed the generated assembly into gcc (pretty much gnu assembler, I suppose). I don't use mingw tools at the earlier stage. However it's obvious for me how to modify the code now (just add MSVC at that line), thanks! I'll try it

Vyacheslav, I've tracked down the change and I have a fix for you to test. The attached patch should be applied to the CVS head (version 1.132) of X86AsmPrinter.cpp in llvm/lib/Target/X86. The patch just includes MINGW targets in the same set of choices that it makes for Cygwin. Could you please try the patch and let me know if it solves your problem? If it does, I'll commit the patch.

Hello, Sorry if this has been addressed elsewhere, if so please let me know where! I'd like to compile 64-bit Wine 1.3.0 via GCC 4.5.1 (I use GCC 4.5.1 according to the instructions here: http://wiki.winehq.org/Wine64) on my Mac running Mac OS X 10.6.4 with a goal of taking advantage of the 8.0 GB of RAM I've got. I set CFLAGS="-march=native -m64", CXXFLAGS="-march=native

Hello, I'm trying to do the following and encountering problems with the generated arm assembly code: I've got an application in two parts that i've compiled into llvm bitcode using: llvm-gcc -emit-llvm -c part1.c -o part1.bc llvm-gcc -emit-llvm -c part2.c -o part2.bc Then I link them together: llvm-ld part1.bc part2.bc -o combined.bc Now I use the ARM backend via llc to

Hello all, I have been having problems building wine on debian for ppc. I continuously get an error from winegcc when building ddraw.dll.so. Something like: ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ddraw.spec convert.o dclipper/main.o ddraw/hal.o ddraw/main.o ddraw/thunks.o ddraw/user.o dpalette/hal.o dpalette/main.o dsurface/dib.o dsurface/fakezbuffer.o

Dear all I use arm-linux-gcc 2.95.2, because the code generated by version 3.X and 4.X can not run on SimpleScalar. So I use the arm-linux-gcc 2.95.2 *only*, the version is recommended by SimpleScalar. The code generated by arm-linux-gcc 2.95.2 can run on SimpleScalar. Now I want to use llvm/clang to generate ARM assembly code and arm-linux-gcc 2.95.2 to be assembler. Unfortunately, I got some

Simplescalar is not compatible with llvm because the binutils simplescalar is based on is ancient. Jim On Sep 26, 2012, at 12:21 AM, 陳奕梅 <ymchen at sslab.cs.nctu.edu.tw> wrote: > Dear all > > I use arm-linux-gcc 2.95.2, because the code generated by version 3.X and 4.X can not run on SimpleScalar. > So I use the arm-linux-gcc 2.95.2 *only*, the version is recommended by

Dear All, I'm getting the following error on Mac OS X when compiling C++ code in the LLVM test suite: g++ Output/minisat.llc.s -o Output/minisat.llc -lm -m64 -fomit-frame-pointer -mdynamic-no-pic -lstdc++ -lm Output/minisat.llc.s:5:Unknown pseudo-op: .cfi_startproc Output/minisat.llc.s:8:Unknown pseudo-op: .cfi_def_cfa_offset Output/minisat.llc.s:8:Rest of line ignored. 1st junk

Hello WINE Users: I am trying to build WINE on Snow Leopard with 64-bit support enabled (actually for my particular purpose I need to build a version of WINE with both 32-bit and 64-bit libraries supported). I am using the 1.1.29 source version.. I have been following the guide for building on Mac and 64-bit WINE at: http://wiki.winehq.org/MacOSX/Building http://wiki.winehq.org/Wine64 I get

R Version 2.1.1 (2005-06-20); R Cocoa GUI 1.12 (1622); Mac OS X 10.4.2 (8C46) For nlme, the R package installer for CRAN (binaries) gives 3.1-60 as Repository Version as well as Installed Version. For CRAN (sources) it gives 3.1-62 as Repository Version and 3.1-60 as Installed Version. When I try to update nlme, I get * Installing *source* package 'nlme' ... ** libs gcc-3.3

On Wed, Oct 31, 2012 at 5:01 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > On Wed, Oct 31, 2012 at 04:43:42PM -0700, Eli Friedman wrote: >> On Wed, Oct 31, 2012 at 4:33 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: >> > On Wed, Oct 31, 2012 at 03:53:50PM -0700, Eli Friedman wrote: >> >> On Wed, Oct 31, 2012 at 8:43 AM, Jack Howarth

Hi, I have got GCC 3.4.3 and binutils 2.15 installed on Cygwin. Had to copy as.exe to gccas.exe to get llvm-gcc to get this far. I am getting the following error message(s) :- /usr/build/llvm-gcc/gcc/xgcc -B/usr/build/llvm-gcc/gcc/ -B/usr/llvm-gcc/i686-pc- cygwin/bin/ -B/usr/llvm-gcc/i686-pc-cygwin/lib/ -isystem /usr/llvm-gcc/i686-pc-c ygwin/include -isystem

> > I volunteer. As soon as I get everything to work. > > > > Next problem: I now have the hello.bc file compiled. But how do I get an executable from this? I tried: > > > > C:\Eigenes\compiler\llvm-2.0\win32\release>llvm-ld -o=hellow.exe hellow.bc > > llvm-ld: Could not find llvm-stub.exe executable! > > > > So, I don't have