This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: g77 garbage collection work
- To: gcc-patches at gcc dot gnu dot org
- Subject: Re: g77 garbage collection work
- From: Geoff Keating <geoffk at envy dot cygnus dot com>
- Date: 26 Dec 1999 14:47:23 -0800
- CC: grahams <grahams at rcp dot co dot uk>
- Newsgroups: cygnus.egcs.patches
- Posted-To: cygnus.egcs.patches
- References: <38664602.957ED467@rcp.co.uk>
The following message is a courtesy copy of an article
that has been posted to cygnus.egcs.patches as well.
grahams <grahams@rcp.co.uk> writes:
> Hi
>
> There's approx. 32 local "static tree" variables which
> are not handled by this patch which need to be registered
> as GC tree roots.
>
> You can find them easily by running (grep -n " static tree" *.c")
> there are about 9 in com.c and the rest are in ste.c
As it turns out, there are somewhat fewer than that (many of the
static variables are just fields of some record which is referenced by
some other static variable), but that's not the real problem.
com.h also does
typedef tree ffecomConstant;
#define FFECOM_constantHOOK
typedef tree ffecomNonter;
#define FFECOM_nonterHOOK
typedef tree ffecomLabel;
#define FFECOM_globalHOOK
typedef tree ffecomGlobal;
#define FFECOM_labelHOOK
typedef tree ffecomStorage;
#define FFECOM_storageHOOK
typedef struct _ffecom_symbol_ ffecomSymbol;
#define FFECOM_symbolHOOK
and _this_ is tricky, because of course the 'ffecomGlobal' and so on
must be preserved between procedures. Rather than have GC understand
_all_ of the dozen or so structures in the Fortran parser, I think
what I'll do is write a little hack which just keeps track of all
these trees, and prevents the garbage collector from collecting them
until the right time (which, in some of these cases, is 'never').
--
- Geoffrey Keating <geoffk@cygnus.com>