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.
