[Gc] Win64 GCC support

NightStrike 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.

> Tips:
> 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[64].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
(hopefully soon).

> 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:
> http://sourceforge.net/tracker/?func=detail&aid=2364034&group_id=202880&atid=983354

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 mailing list