This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: g77 garbage collection work


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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]