refinements to definition of TREE_READONLY ?

[Richard Guenther]

On Fri, Jul 11, 2008 at 6:49 PM, Olivier Hainque <hainque@adacore.com> 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.