Re[4]: [Gc] Win64 GCC support

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


Hi!

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.

Bye.


More information about the Gc mailing list