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


> On Sat, Jan 24, 2004 at 11:14:57PM +0100, Jan Hubicka wrote:
> > The problem is the trick:
> > 
> > #define SAVE_EXT_FLAGS()			\
> > 	size_int (pedantic			\
> > 		  | (warn_pointer_arith << 1)	\
> > 		  | (warn_traditional << 2)	\
> > 		  | (flag_iso << 3))
> 
> I don't believe in this at all.  We don't mark the rest of the
> bison stack either.  It's not supposed to matter.  We're not
> supposed to be gc'ing while trees are on the parse stack.  More,
> how are we gc'ing in the *middle* of parsing a function, which
> is the only time __extension__ should be able to be live?

Hmm, I have no idea - the gcing happent from rule I quoted out.
There is some way to get debug output from bison parser, i will try to
debug it then, but at least my trick with making this GGC root solved
the problem partly.
> 
> My debugging of this pointed to the memory already having been
> reused at least once before we got here.  And that the memory
> had initially been allocated to the parameter list of a builtin
> function.  Which of course should never have gone away.

Yes, this sounds wrong....

Honza
> 
> I'd not tracked it any farther.
> 
> 
> r~


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