This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: refinements to definition of TREE_READONLY ?
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Olivier Hainque" <hainque at adacore dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 11 Jul 2008 18:21:02 +0200
- Subject: Re: refinements to definition of TREE_READONLY ?
- References: <20080711161512.GA24187@cardhu.act-europe.fr>
On Fri, Jul 11, 2008 at 6:15 PM, Olivier Hainque <hainque@adacore.com> wrote:
> Hello,
>
> According to comments in PR/35493, when DECL_INITIAL is null on a
> TREE_READONLY decl, the middle-end may assume the value to be zero.
>
> This is not explicit from the current definitions in tree.h, we'd
> like to understand if this is actually the case and to suggest a doc
> extension to this effect.
A doc extension is ok.
> 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...
> The kind of issues we're seeing is ...
>
> 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.
> 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.
So it looks like there are multiple issues here and a bug in tree-sra.
Richard.
> Thanks in advance for your feedback,
>
> Olivier
>
>
>
>
>
>
>
>
>
>