Re: [Gc] Win64 GCC support
ivmai at mail.ru
Thu Jun 18 14:09:27 PDT 2009
Remember me? ;) I'm continuously testing your thing with this one.
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.
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)).
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).
My mingw build is: mingw-w64-bin_i686-mingw_20090420.
> > Working off of HEAD, I can see two initial problems. First, this from gc.h:
> > /* Define word and signed_word to be unsigned and signed types of the */
> > /* size as char * or void *. There seems to be no way to do this */
> > /* even semi-portably. The following is probably no better/worse */
> > /* than almost anything else. */
> > /* The ANSI standard suggests that size_t and ptrdiff_t might be */
> > /* better choices. But those had incorrect definitions on some older */
> > /* systems. Notably "typedef int size_t" is WRONG. */
> > 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).
> > 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:
> > It appears that certain things are being initialized by variables, and
> > this is not AFAIK supported.
> Can you expand that with gcc -E ? Then we'll see what's wrong with the
Any more questions?
More information about the Gc