[Gc] Win64 GCC support
nightstrike at gmail.com
Thu Jun 18 14:17:22 PDT 2009
2009/6/18 Ivan Maidanski <ivmai at mail.ru>:
> Hi, NightStrike!
> Remember me? ;) I'm continuously testing your thing with this one.
Ah, I do now! Hahah.. I did forget, though. Thanks for the constant testing!
> Andrew Haley <aph at redhat.com> wrote:
>> NightStrike wrote:
>> > Hello,
>> > I am an admin of the mingw-w64.sf.net project. We have ported GCC to
>> > Win64 along with all of the required parts. We are now on to get all
>> > the languages worked. So far, the only remaining two are ada and
>> > java. Java for GCC requires, among other things, boehm-gc. That is
>> > now next in the list of things to get working. Is there anyone here
>> > that can help out with this?
> You are using gc v7.2 (alpha) or CVS, right? (If not You're on the wrong way.)
> It works fine with mingw-64 (at least for me, same as with VC++ 2008 x64) including parallel mark and memory unmapping.
I'm using CVS HEAD as of right now.
> 1. ignore failure on "Unexpected heap growth - collector may be broken" (the condition that trigs it should be IMHO refined).
> 2. ignore possible "GC_gww_read_dirty unexpectedly failed" (this is known problem of incremental collection (may be it's been solved by the latest Boehm's patch)).
I haven't gotten that far, I don't think.
> The build scripts may be not up to date (this is out of my scope).
> I'm personally using these options:
> -O2 -fno-strict-aliasing -Wall -DALL_INTERIOR_POINTERS -DGC_GCJ_SUPPORT -DNO_DEBUGGING -DGC_NOT_DLL -DLARGE_CONFIG -DUSE_MUNMAP -DGC_THREADS -DTHREAD_LOCAL_ALLOC -DPARALLEL_MARK -DNDEBUG -I include -I libatomic_ops-1.2\src
> DLL version can be built with: -DGC_DLL -DGC_BUILD -s -shared -o gc.dll
> But it (unlike VC++) does not export some semi-private things (for now) used by test.c (I've already fixed it - patches pending)
> (On other hand, the DLL could be created by VC++ and imported by mingw - it works ok).
I'm using configure, with host=x86_64-w64-mingw32 and no other
options. I'm cross compiling from linux to win64. This is the same
way that gcc will build it in-tree once we merge everything back over
> My mingw build is: mingw-w64-bin_i686-mingw_20090420.
That's way old. Can you try the latest?
>> > The type you want is intptr_t from inttypes.h
>> In a perfect world that might be true.
> Since the world isn't perfect everywhere, we are using __int64 and "long long" (either works for mingw-64).
Wouldn't it be better to special case out the oddball ancient systems
and use intptr_t elsewhere? There's an autoconf test just for this
purpose, AC_TYPE_INTPTR_T. It might be worth looking into.
>> > Second, compiling yields this failure:
>> > ../mallocx.c:32:1: error: initializer element is not constant
>> > ../mallocx.c:33:1: error: initializer element is not constant
>> > ../mallocx.c:34:1: error: initializer element is not constant
>> > ../mallocx.c:36:5: error: initializer element is not constant
> Hmm... Never seen this. The bad thing with mingw64 that I know is:
Wow, that's embarrassing :)
I'll ping on Kai for that. Luckily, he's CC'd on this email :)
> Any more questions?
Yes, actually. Can you get the boehm-gc in the gcc tree updated to be
in synch with the current upstream? We will need this to get a
working gcj out the door.
More information about the Gc