This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: refinements to definition of TREE_READONLY ?
Richard Guenther wrote:
> A doc extension is ok.
Understood, as soon as we agree on what it should say :)
> > We'd also like to get to an agreement on what TREE_READONLY means on a
> > decl with non static storage, if anything at all.
>
> Good question...
> > Ada front-end sets TREE_RO and DECL_INITIAL on a stack decl with
> > initializer but never assigned later on,
> > gimplify_decl_expr turns this into an explicit assignment,
> > clears DECL_INITIAL and leaves TREE_RO set (creating an
> > unexpected assignment with TREE_RO on the lhs).
>
> ... I suggest to not clear DECL_INITIAL here.
Leaving an assignment with TREE_RO on the lhs ?
Other options we thought of were
Don't set TREE_RO on the decl if !TREE_STATIC, in gigi (we might
decide it doesn't make sense and document accordingly).
Clear TREE_RO in gimplify_decl_expr. We could leave
DECL_INITIAL there in this case as well.
> > later middle-end passes (e.g. tree-sra) turn this into an
> > assignment from 0 (null DECL_INITIAL).
> But in the end tree-sra shouldn't try to look at DECL_INITIAL from
> non-static storage.
Sorry, this part was confused on my side: the issue we had with
sra was with a static rhs (global Ada constant integer), of value 1,
marked TREE_RO and without DECL_INITIAL.