TREE_READONLY in lookup_tmp_var
Richard Kenner
kenner@vlsi1.ultra.nyu.edu
Fri Aug 20 14:21:00 GMT 2004
You removed the setting of TREE_READONLY there. That caused 14 ACATS
regressions!
The reason is somewhat of a kludgely situation.
In an elaboration routine, we often set a field of a global variable to
the address of a CONSTRUCTOR that just has integer constants. There's an
implicit assumption that this will be done by putting the constants in
static memory and pointing to it. If that's done, all is OK. But if they
are formed on the stack and pointed to, you'll have a global pointing to
the stack area of a long-exited function.
Relying on this is *somewhat* bogus, but on the other hand, it's never
more efficient to build such a CONSTRUCTOR on the stack if you're going
to be taking the address of it.
If the variable for the CONSTRUCTOR is readonly, the gimplification code does
the right thing. There are probably ways of fixing it without that (such
as by setting TREE_ADDRESSABLE for the CONSTRUCTOR in that case), but
it's not clear it's worth the effort unless setting TREE_READONLY can't be
done in lookup_tmp_var.
When I put that back and comment out the clearing of DECL_GIMPLE_FORMAL_TEMP_P,
I get exactly *one* remaining ACATS failure (c974007), which I'll
investigate soon.
More information about the Gcc
mailing list