This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH PING] unreviewed tree-slimming patches
- From: Nathan Froyd <froydnj at codesourcery dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 25 May 2011 22:21:03 -0400
- Subject: Re: [PATCH PING] unreviewed tree-slimming patches
- References: <4DDD0B95.40308@codesourcery.com> <4DDD0F9F.5000409@redhat.com>
On 05/25/2011 10:18 AM, Jason Merrill wrote:
> On 05/25/2011 10:00 AM, Nathan Froyd wrote:
>> Jason commented on the TS_STATEMENT_LIST patch, but
>> the discussion didn't come to a resolution.
>
> Right, from your last mail I thought that you were investigating my question
> about add_stmt and your suggestion about dropping the NULL checking in
> append_to_statement_list_1.
Ah, OK. That was not clear to me.
I stand by what I said about add_stmt. Before, if we weren't
building_stmt_tree (i.e. cur_stmt_list was NULL), we'd just pass a pointer to
NULL into append_to_statement_list and append_to_statement_list would DTRT.
Now if we have a NULL stack, then passing a pointer to the stack doesn't work,
because it's not typed correctly and we'd be clobbering the VEC, not pushing
onto the stack.
An alternative solution would be to initialize cur_stmt_list somewhere with an
actual 1-element VEC; the check in add_stmt would then be unnecessary, as we'd
always be assured of having someplace in the stack to store it. I don't trust
myself to write a patch like that tonight; I'll twiddle with that tomorrow.
As to the NULL checking in append_to_statement_list_1, I was being hasty and
naive. There are scores of places throughout the compiler that depend on this
behavior; I don't think it's worthwhile to change all the callers to ensure
the pointer-to-statement_list points to a non-NULL thing.
-Nathan