On Fri, Jul 11, 2008 at 6:49 PM, Olivier Hainque <[EMAIL PROTECTED]> wrote: > 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).
That would work. > Clear TREE_RO in gimplify_decl_expr. We could leave > DECL_INITIAL there in this case as well. This 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. So what happened? The code in tree-sra looking at DECL_INITIAL looks fine. Richard.
