Re: gcc moving memory reference across call

[Andrew Haley <aph at redhat dot com>]

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.