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]
Other format: [Raw text]

Re: ggc_free


> Jan, I'm not sure I like the half-dozen old_foo_array patches you've
> been generating, trying to work around varray vs ggc_realloc silliness.
> 
> Seems to me that the proper fix is (1) don't make ggc_realloc so
> stupid, and (2) allow us to use known lifetimes of specific objects.
> Both of which are solved by implementing ggc_free, which we've talked
> about before.
> 
> The following has made it through bootstrap of gcc/, including ada.
> The build is still in the middle of libjava somewhere, but it looks
> promising.
> 
> It has not been tested with gcac because mainline fails gcac with
> or without this patch.  Which is probably Bad News...
The problem is the trick:

#define SAVE_EXT_FLAGS()			\
	size_int (pedantic			\
		  | (warn_pointer_arith << 1)	\
		  | (warn_traditional << 2)	\
		  | (flag_iso << 3))

#define RESTORE_EXT_FLAGS(tval)			\
  do {						\
    int val = tree_low_cst (tval, 0);		\
    pedantic = val & 1;				\
    warn_pointer_arith = (val >> 1) & 1;	\
    warn_traditional = (val >> 2) & 1;		\
    flag_iso = (val >> 3) & 1;			\
  } while (0)
In combination with:
extdefs:
	{$<ttype>$ = NULL_TREE; } extdef
	| extdefs {$<ttype>$ = NULL_TREE; ggc_collect(); } extdef
	;

What happens is that EXT_FLAGS are saved, then ggc is collected and then
resotred in the bad way.
It is probably not related to my changes (that is good news as I would
not be happy to push them to 3.4 if they caysed some involved breakage)
and obvious trick is to add variable incrementing/decrementing in the
macros and check it in ggc_collect, but perhaps someone who has more
insight to parser has better idea?

Honza


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