similar to: [LLVMdev] More llvm-gcc build breakage

On Wed, Jul 30, 2008 at 03:06:54PM -0700, Julien Lerouge wrote: > On Wed, Jul 30, 2008 at 11:32:18AM -0700, Bill Wendling wrote: > > On Jul 30, 2008, at 11:17 AM, Julien Lerouge wrote: > >> ../../../llvm-gcc4.2-src/gcc/libgcc2.c:2095: error: conflicting types > >> for 'VirtualProtect' > >> > >>

On Wed, Jul 30, 2008 at 11:32:18AM -0700, Bill Wendling wrote: > On Jul 30, 2008, at 11:17 AM, Julien Lerouge wrote: >> ../../../llvm-gcc4.2-src/gcc/libgcc2.c:2095: error: conflicting types >> for 'VirtualProtect' >> >> c:/cygwin/home/jlerouge/buildbot/llvm/lib/../include/winbase.h:1998: >> error: previous declaration of 'VirtualProtect' was here

On Jul 30, 2008, at 11:17 AM, Julien Lerouge wrote: > Not sure if that's related, but we had two failures last night as > well: > > MacOS/Universal build failed on rev 54197, when building the x86->ppc > cross: > > cc1: warnings being treated as errors > /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: > no > previous prototype for

Not sure if that's related, but we had two failures last night as well: MacOS/Universal build failed on rev 54197, when building the x86->ppc cross: cc1: warnings being treated as errors /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: no previous prototype for 'outermost_tinst_level' make[2]: *** [cp/pt.o] Error 1 MingW failed on rev 54208:

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, Arnold. Only quick comments, I'll try to make a full review a little bit later. > 0.)a fast calling convention (maybe use the current > CallingConv::Fast, or create a CallingConv::TailCall) > 1.) lowering of formal arguments > like for example x86_LowerCCCArguments in stdcall mode > we need to make sure that later mentioned CALL_CLOBBERED_REG is >

Hi Bill, This is probably due to the llvm-gcc merge. Please take a look. Thanks, Evan On Jul 30, 2008, at 10:04 AM, Duncan Sands wrote: > x86-64 linux, during stage3: > > xgcc -B/home/duncan/LLVM/gcc-4.2.llvm-objects/./gcc/ -B/usr/local/ > gnat-llvm/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gnat-llvm/ > x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gnat-llvm/x86_64-

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

x86-64 linux, during stage3: xgcc -B/home/duncan/LLVM/gcc-4.2.llvm-objects/./gcc/ -B/usr/local/gnat-llvm/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gnat-llvm/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gnat-llvm/x86_64-unknown-linux-gnu/include -isystem /usr/local/gnat-llvm/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.2.llvm/libgomp -I.

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/

Here is my thought process on why the application crashes with a protection violation reading a section of memory. I used IDA to disassemble the app. Here's the section where it reads from memory and crashes because of a protection violation: 00760D4A sub_760D4A proc near ; CODE XREF: sub_75FCB0+159^Xp 00760D4A push ebp 00760D4B mov

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

Hello, David. > After hacking around in the CBE output I managed to compile it with > gcc, only to discover that gcc 4.1.2 has the SAME bug LLVM does with > respect to alignment. Automatic stack realignment was atted to X86 backend ~3 months ago. Everything should work with LLVM. If not - please fill out a PR. AFAIR, automatic stack realignment still does not land into gcc mainline

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

Hi Arnold and Anton, Sorry I have been ignoring your emails on this topic. It's an important task and I really need sometime to think about it (and talk to Chris about it!) But this has been an especially hectic week. I am also going to vacation soon so I am not sure when I would get around to it. If Chris has time, I am sure he has lots to say on this topic. :-) Otherwise, please

Okay so i implemented an(other :) initial version for X86-32 backend, this time based on TOT: It is not very generic at the moment. Only functions with callingconv::fastcc and the tail call attribute will be optimized. Maybe the next step should be to integrate the code into the other calling convention lowering. Here is what i have at the moment: If callingconv::fastcc is used the

When attempting to compile this simple testing tool http://github.com/oneclick/rubyinstaller/blob/fake/resources/tools/fakeruby.c I get the following: C:\Users\Jon\Documents\CDev\sandbox>llvm-gcc -Wall -o fakeruby.exe fakeruby.c Warning: resolving _GetModuleHandleA by linking to _GetModuleHandleA at 4 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=us-ascii" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <b>Reid,<br> <br> I followed the steps but got stuck as described

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

I've blown a couple of weekends trying to build under MinGW. I can build the llvm tools with only a couple of minor hassles, but can't seem to make any headway with the C Front End Most errors I run into involve not being able to find header files. The most frustrating part is that the error messages report that the file can't be found, and then proceed to give a path to where the