[PATCH PING] unreviewed tree-slimming patches

[PATCH PING] unreviewed tree-slimming patches

[Nathan Froyd]

These patches:

  (C, C++, middle-end)
  [PATCH 14/18] move TS_STATEMENT_LIST to be a substructure of TS_TYPED
  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00560.html

  (C, Java, middle-end)
  [PATCH 18/18] make TS_BLOCK a substructure of TS_BASE
  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00564.html

are still pending review.  Jason commented on the TS_STATEMENT_LIST patch, but
the discussion didn't come to a resolution.  I forgot to CC the TS_BLOCK patch
to the Java folks the first time around.

Thanks,
-Nathan

Re: [PATCH PING] unreviewed tree-slimming patches

[Jason Merrill]

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.

Jason

Re: [PATCH PING] unreviewed tree-slimming patches

[Richard Guenther]

On Wed, May 25, 2011 at 4:00 PM, Nathan Froyd <froydnj@codesourcery.com> wrote:
> These patches:
>
>  (C, C++, middle-end)
>  [PATCH 14/18] move TS_STATEMENT_LIST to be a substructure of TS_TYPED
>  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00560.html
>
>  (C, Java, middle-end)
>  [PATCH 18/18] make TS_BLOCK a substructure of TS_BASE
>  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00564.html
>
> are still pending review.  Jason commented on the TS_STATEMENT_LIST patch, but
> the discussion didn't come to a resolution.  I forgot to CC the TS_BLOCK patch
> to the Java folks the first time around.

The middle-end parts of both patches are ok.

Thanks,
Richard.

> Thanks,
> -Nathan
>

Re: [PATCH PING] unreviewed tree-slimming patches

[Joseph S. Myers]

On Wed, 25 May 2011, Nathan Froyd wrote:

> These patches:
> 
>   (C, C++, middle-end)
>   [PATCH 14/18] move TS_STATEMENT_LIST to be a substructure of TS_TYPED
>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00560.html
> 
>   (C, Java, middle-end)
>   [PATCH 18/18] make TS_BLOCK a substructure of TS_BASE
>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00564.html
> 
> are still pending review.  Jason commented on the TS_STATEMENT_LIST patch, but

The C changes are OK.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH PING] unreviewed tree-slimming patches

[Tom Tromey]

>>>>> "Nathan" == Nathan Froyd <froydnj@codesourcery.com> writes:

Nathan>   (C, Java, middle-end)
Nathan>   [PATCH 18/18] make TS_BLOCK a substructure of TS_BASE
Nathan>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00564.html

The Java parts are ok.

I think these sorts of changes should be obvious once approved from a
middle-end perspective, at least assuming that there are no regressions.
I say this because I think that once the core change has been decided
on, there is often just one way to go about fixing up the users; at
least, in a case like this where the consequence amounts to deleting
assignments.

I mentioned this idea before but I didn't see any discussion of it.  I
am happy to continue looking at patches like this if that is what the
more active maintainers would prefer.

Tom

Re: [PATCH PING] unreviewed tree-slimming patches

[Nathan Froyd]

On 05/25/2011 02:06 PM, Tom Tromey wrote:
>>>>>> "Nathan" == Nathan Froyd <froydnj@codesourcery.com> writes:
> 
> Nathan>   (C, Java, middle-end)
> Nathan>   [PATCH 18/18] make TS_BLOCK a substructure of TS_BASE
> Nathan>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00564.html
> 
> The Java parts are ok.
> 
> I think these sorts of changes should be obvious once approved from a
> middle-end perspective, at least assuming that there are no regressions.
> 
> I mentioned this idea before but I didn't see any discussion of it.  I
> am happy to continue looking at patches like this if that is what the
> more active maintainers would prefer.

I think Jason mentioned considering them approved after waiting a week.  If we
want to enshrine that as policy, I think that'd be reasonable.  All in favor...?

-Nathan