Re: [Gc] Win64 GCC support
ivmai at mail.ru
Thu Jun 18 15:53:02 PDT 2009
NightStrike <nightstrike at gmail.com> wrote:
> 2009/6/18 Ivan Maidanski <ivmai at mail.ru>:
> > 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:
> > -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
> > ...
> 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