This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Joern Rennecke <amylaar at spamcop dot net>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Ian Lance Taylor <iant at google dot com>
- Date: Tue, 14 Jun 2011 13:29:22 +0200
- Subject: Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated)
- References: <20101116234626.u7kpzzukn34kogkk-nzlynne@webmail.spamcop.net> <20101118223203.muhg2uba8gww48co-nzlynne@webmail.spamcop.net> <20110507114245.8rcb4f6n0gggwggk-nzlynne@webmail.spamcop.net> <Pine.LNX.4.64.1105071546350.24964@digraph.polyomino.org.uk> <Pine.LNX.4.64.1105071559200.24964@digraph.polyomino.org.uk> <20110507151225.qsxqm0ltokc4sw0k-nzlynne@webmail.spamcop.net> <20110514103611.vpdb6r7wcgo8wkg0-nzlynne@webmail.spamcop.net> <20110521153014.mkzu2c9qsc808k4g-nzlynne@webmail.spamcop.net> <20110529232655.0ria73pgzkwo008g-nzlynne@webmail.spamcop.net> <20110604092242.4aaut664f4kcsws4-nzlynne@webmail.spamcop.net> <20110614054034.i5n9pysdoo0gsg4-nzlynne@webmail.spamcop.net> <BANLkTikvJyYfh+WV4kuE7WC6Xy2ftiwCyQ@mail.gmail.com> <20110614071614.upci7rx74scwg4ws-nzlynne@webmail.spamcop.net>
On Tue, Jun 14, 2011 at 1:16 PM, Joern Rennecke <amylaar@spamcop.net> wrote:
> Quoting Richard Guenther <richard.guenther@gmail.com>:
>
>> On Tue, Jun 14, 2011 at 11:40 AM, Joern Rennecke <amylaar@spamcop.net>
>> wrote:
>>>
>>> Except or the fortran/java bits (committed), this patch hasn't been
>>> reviewed for five weeks:
>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html
>>
>> A patch doing s/CUMULATIVE_ARGS*/cumulative_args_t/ only
>> is ok.
>
> It's not quite that simple. ?The patch makes a distinction between pointers
> to the target specific types CUMULATIVE_ARGS, and the target-independent
> cumulative_args_t.
>
> Is it still OK if I selectively do the replacement where the
> target-independent type is meant, and add a provisional
> typedef CUMULATIVE_ARGS *cumulative_args_t to tie it together?
>
>> Posting compressed attached patches makes it too easy
>> to not review things btw ...
>
> The mailing list size limits did't allow this patch to be posted
> without compression.
>
>> After that patch the "meat" of the patch should be much much smaller
>> and easier to review (if there is anything left besides the renaming?).
>
> It should be somewhat smaller, but there are lots of places where we have
> to convert between cumulative_args_t and CUMULATIVE_ARGS *.
> Were a target-independent interface is required, we need cumulative_args_t .
> Where a target accesses struct components, it needs CUMULATIVE_ARGS *.
> There are some places that just pass CUMULATIVE_ARGS * around, both in
> rtl-centric middle-end/ rtl-optimizer code and in target code, which
> could be electively converted. ?In general, I haven't done such optional
> conversions. ?They could be added according to taste once the interface
> has been straightened out. ?There is also a judgement call in each place
> how closely the code is tied to the cumulative_args_t side or the
> CUMULATIVE_ARGS * side.
Hmm, I see. Maybe a GWP wants to ack your patch in whole then.
Ian?
Thanks,
Richard.