Daniel Berlin wrote: >> It's a field in the class$ structure. class$ is initialized by creating a >> CONSTRUCTOR tree and calling CONSTRUCTOR_APPEND_ELT for each field. The >> DECL_INITIAL of class$ points to the CONSTRUCTOR tree. >> >> _CD_pp is an array of void*. These are initialized by DECL_INITIAL too. >> >> InitClass is passed class$$ (not class$) and that has a DECL_INITIAL >> that points to class$. As far as I can tell all the types are correct. >> > > If class$$ has an initial of &class$ which has an initial (in it > somewhere) of CD_ppp it should definitely be noticing. > It used to walk these all and get it right, AFAIK, by disqualifying > all variables with their addresses taken (or escaping the function > unit). > Maybe the walking broke when we moved to tuples or something?
I found it. It's a bug in the Java FE that has been around for many years. Turns out that we were creating more than one global decl called "_CD_pp". One decl was used in the load, the other decl is initialized global static data. Of course, the assembler quite happily resolves these, and the code works just fine. I presume there's some sort of rule which says that symbols and symbol_refs always must use the same decl, not just another decl with the same name. It's a bit frightening to think that there may be more errors like this in the FE, but I can't see any. Thanks to everyone who helped. Andrew.
