Re[4]: [Gc] Win64 GCC support

Ivan Maidanski ivmai at
Thu Jun 18 15:53:02 PDT 2009


NightStrike <nightstrike at> wrote:
> 2009/6/18 Ivan Maidanski <ivmai at>:
> > Hi, NightStrike!
>> ....
> 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.

These aren't happen on every test.c run.

> > The build scripts may be not up to date (this is out of my scope).
> > I'm personally using these options:
> > ...
> 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).

It's better You provide the options gcc is executed with.

> > My mingw build is: mingw-w64-bin_i686-mingw_20090420.
> That's way old.  Can you try the latest?

Ok. I'll use the latest one (but for mingw i686 devel host).

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

VC++ 2008 is not ancient but lacks inttypes.h (but intptr_t is present since 2003, I guess (guarded with _INTPTR_T_DEFINED)).

And, AFAIK, it's typically defined in stdint.h (not inttypes.h).

The idea with autoconf isn't good as config.h is not used in bdwgc (unlike gcc boehm-gc), not only for public gc.h but in the whole project.

Ok. I'll think about [u]intptr_t... (this, in fact, matters only for non-Windows LLP64 systems but I've never heard these are supported by GC, so this question is of little practical importance).

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

See my prev post.

Also, as I can see, gcj is not under development for 2 years.


More information about the Gc mailing list