This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH Re: [ast-optimizer-branch]: Simplify STMT_EXPR's
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Sebastian Pop <m1sp at csc dot liv dot ac dot uk>, Daniel Berlin <dberlin at dberlin dot org>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 19 Jun 2002 09:44:23 -0400
- Subject: Re: PATCH Re: [ast-optimizer-branch]: Simplify STMT_EXPR's
- Organization: Red Hat Canada
- References: <Pine.LNX.4.44.0205021030560.4533-100000@dberlin.org> <20020502161835.A9384@linux18.lxfarm.csc.liv.ac.uk> <1020354525.9564.6.camel@tornado> <wvl1yb31v30.fsf_-_@prospero.cambridge.redhat.com>
On Wed, 19 Jun 2002, Jason Merrill wrote:
> In this patch I haven't tried to preserve source position information for
> inlined functions, because we don't support wrapping _STMTs in
> EXPR_WITH_FILE_LOCATION. One obvious direction would be to support that.
> I don't see a good way to use FILE_STMT to handle this, as we aren't
> tracking source position during simplification. On the other hand, perhaps
> we should be.
>
But we are, after a fashion. When creating new _STMT nodes we
set their line number from the originating statement. Would that
suffice?
> I ran into trouble with bogus TREE_ANN information on statements in inlined
> functions; the annotation info is allocated using the GC code, but is never
> marked, which means that after the inline function has been compiled, all
> the TREE_ANN fields in its tree structure are pointing to freed memory.
> I've worked around this by clearing the aux field in copy_tree_r; a better
> fix would be to mark it properly for GC.
>
Yeah, I've been meaning to fix this for a while now. It's mildly
annoying because we have to start marking a lot of structures
pointed by TREE_ANN (basic blocks, variable references, etc).
With your patch it shouldn't be necessary to guard against false
positives in the warnings we emit in simplyfy_expr_stmt. Cool.
Diego.