arg..well, I had replaced xmalloc with alloca, leading to some of the garbage
below, but
I am indeed still running afoul of the garbage collector.
I don't know if that is my original problem but I should probably fix this
first.
ie: now that I'm using -enable-checking, and I think it collects earlier/more
often.
I need to "map" my internal unsigned long arbitrary integers, to trees.
So I just have an array of struct {unsigned id; tree t };
I put GTY on the struct, on the field, and on the VEC of them.
When I append I mark it dirty.
When I search I qsort if dirty, then bsearch.
typedef struct GTY(()) m3type_t
{
unsigned long id;
tree GTY (()) t;
} m3type_t;
static GTY (()) VEC (m3type_t,gc)* m3type_table;
seems reasonable eh?
The files are in gtfiles. When I put the GTY in the wrong place I get compile
errors.
I guess I can try rolling my own "VEC" or even use a fixed size and see what
happens..
Thanks,
- Jay
----------------------------------------
> From: jay.kr...@cornell.edu
> To: i...@google.com
> CC: gcc@gcc.gnu.org
> Subject: RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
> Date: Sat, 11 Sep 2010 08:48:08 +0000
>
>
> > I kind of suspect it might be a type mismatch, overwriting part of a tree
> > node
>
> configure -enable-checking:
>
> ?"Bmr?: In function 'FPrint__xCombine':
> `?"Bmr?:13:0: internal compiler error: tree check: expected ssa_name, have
> var_decl in copy_phis_for_bb, at tree-inline.c:1950
>
> and some other problems..I really need to fix those...
>
> - Jay
>
> ----------------------------------------
> > From: jay.kr...@cornell.edu
> > To: i...@google.com
> > CC: gcc@gcc.gnu.org
> > Subject: RE: internal compiler error: in referenced_var_lookup, at
> > tree-dfa.c
> > Date: Fri, 10 Sep 2010 20:38:58 +0000
> >
> >
> > [licensing dealt with separately]
> >
> >
> >
> > > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def
> > > > 0x412130a8 1093058884
> > > This is clearly wrong, though I have no idea what caused it.
> > > > Is it valid for uids to be so high?
> > > No.
> >
> > Thanks, that helps.
> >
> >
> > > From your description, you've implemented some sort of customized tree
> > > reader.
> >
> >
> > Not exactly, by my understanding of terminology.
> > We do end up making gcc trees but we serialize something that is separately
> > specified and not really the same, though some level of resemblance is
> > unavoidable since they both are involved with compilation, i.e. they both
> > have operations like "add" and notions of locals, parameters, functions,
> > etc.
> > Ours is stack-based though for example (not my preference, but it was
> > already there).
> >
> >
> > > Does it play nicely with the garbage collector?
> >
> >
> > I think so.
> > We have the GTY annotations, I've managed to crash things when I got them
> > wrong/missing. I haven't moved all targets from 4.3.x to 4.5.x so I even
> > have
> > to hack on the code a bit because GTY has to be in a different place.
> > I put the type declarations in seperate .h files, maintain both, and copy
> > one
> > over the other before compilation.
> >
> >
> > We do have an open bug report about causing the gcc garbage collector
> > consuming infinite memory, maybe due to a cycle in our data.
> > But really the system works a ton. I can compile and run tens of thousands
> > of lines
> > of code, for multiple architectures. I "just" have to turn off inlining, and
> > a small number of other optimizations. Clearly we are pretty good, and
> > flawed.
> >
> >
> > Notice that the gcc middle end seemed to have created this variable with
> > the high uid.
> > I checked the globals that guide uid assignment, found them after sending
> > the
> > first mail. They aren't so high.
> > I haven't yet found where this uid comes from.
> > I kind of suspect it might be a type mismatch, overwriting part of a tree
> > node
> > with the wrong type or such.
> > I'll have to dig more.
> >
> > I know it comes from here:
> > copy_phis_for_bb:
> > ...
> > SSA_NAME_DEF_STMT (new_res)
> > = new_phi = create_phi_node (new_res, new_bb);
> >
> >
> >
> > Thanks,
> > - Jay
> >
>
