> 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
>
