This is the mail archive of the
mailing list for the GCC project.
Re: GSoc-2015: Modular GCC (RFC on refactoring)
- From: Jeff Law <law at redhat dot com>
- To: Trevor Saunders <tbsaunde at tbsaunde dot org>, gcc at gcc dot gnu dot org
- Date: Tue, 17 Mar 2015 22:36:05 -0600
- Subject: Re: GSoc-2015: Modular GCC (RFC on refactoring)
- Authentication-results: sourceware.org; auth=none
- References: <CAA_ASpVFs7LXS4Pw1Mxo5VCxtEncvYXjYgnULGoRAWnbM3PkYw at mail dot gmail dot com> <54F87A48 dot 6070803 at redhat dot com> <54FA52CD dot 2080003 at gmail dot com> <54FB1C2B dot 7010108 at redhat dot com> <5508F5F3 dot 500 at gmail dot com> <20150318042427 dot GA5533 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com>
On 03/17/2015 10:32 PM, Trevor Saunders wrote:
Sigh. We could just use a vec then... That would still be better in
various ways than chaining things via EXPR_LIST or INSN_LIST.
2. Lists, list nodes and list iterators should be objects of distinct
types. In this case, header file function.h gets additional dependency,
because struct rtldata contains insn/expr lists as members; currently
they are pointers, so a forward declaration is sufficient. A possible
workaround is to create an opaque type like it's done with struct
initial_value_struct (at a cost of one additional level of indirection).
Which is better?
given std::forward_list isn't available in c++98 I expect you'll write
your own version of it. It seems pretty reasonable to me function.h
would depend on the hypothetical header containing that list template,
and presumably more stuff than just rtx_insn_list's could be made to use