This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Diego Novillo <dnovillo at google dot com>, Michael Matz <matz at suse dot de>, David Malcolm <dmalcolm at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 30 Aug 2013 10:52:15 -0500
- Subject: Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
- Authentication-results: sourceware.org; auth=none
- References: <1377793216-22549-1-git-send-email-dmalcolm at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1308301532490 dot 9949 at wotan dot suse dot de> <CAAiZkiB-Z7GfDGNuWys+d6JW+ynbtfC_Yc5YHfN9M-to5uABXg at mail dot gmail dot com> <20130830140253 dot GO21876 at tucnak dot zalov dot cz> <CAAiZkiB=iJ7dwFEe7OKhMBXccMsu6950fE6Cy=h-a6JF0h=FTA at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1308301712450 dot 9949 at wotan dot suse dot de> <CAD_=9DRK4htu8jefZehb0Q4JDCozbCA2pr0Sq6rhX4JcW7QEDw at mail dot gmail dot com> <20130830153727 dot GQ21876 at tucnak dot zalov dot cz>
On Fri, Aug 30, 2013 at 10:37 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
>> > Well, it was a wrong decision then. For some smaller types writing manual
>> > marker might be a sensible thing, or for some extra complicated
>> > constructs. But here we're talking about the most simple struct hierarchy
>> > imaginable. Having to write manual markers for that one is absurd IMO.
>>
>> I want to discourage extending gengtype more than necessary. Long
>> term, I would like to see memory pools replacing GC. However, that is
>> likely a long road so we should find an interim solution.
>
> I have doubts that, still somewhat remember the obstack era and memory pools
> would again bring all the issues back, but let's put that aside.
We didn't have the automation of RAII with obstacle, back then.
We do have evidence of widely use industrial
C and C++ compilers that are built around the idea of memory pools.
>> I vaguely remember thinking about what would be needed to have
>> gengtype deal with inheritance. It needed some pretty ugly
>> annotations. This made gengtype even more magic. That's very bad for
>> maintenance.
>
> Teaching the gengtype parser about
> {struct,class} name : public {struct,class} someothername { … }
I would suggest NOT to allow the {struct, class} part in the base-class clause.
> as opposed to current
> {struct,class} name { ... }
> shouldn't be that hard. And, if the complaint is that we'd need to write
> whole C++ parser for it, then the response could be that we already have
> one C++ parser (and, even have plugin support and/or emit dwarf etc.).
We should not need one. At most the base classes would have the form
optional-typename optional-qualifying-scope identifier
optional-template-argument-list
that should cover most of what we want.
> So, gengtype could very well use a g++ plugin to emit the stuff it needs,
> or parse DWARF, etc. And, we even could not require everybody actually
> emitting those themselves, we could check some text form of that
> (gengtype.state?) into the tree, so only people actually changing the
> compiler would need to run the plugin.
>
>> One thing I liked is a suggestion that went something along the lines
>> of creating some base templates that could be used to facilitate
>> writing the manual markers.
>
> Even if you have some stuff that helps you writing those, still it will be a
> big source of bugs (very hard to debug) and a maintainance nightmare.
>
> Jakub