On Fri, 2013-08-30 at 09:12 -0500, Gabriel Dos Reis wrote:
> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> > On Fri, Aug 30, 2013 at 08:58:43AM -0500, Gabriel Dos Reis wrote:
> >> On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz <m...@suse.de> wrote:
> >>
> >> > And the manual GTY markers are so not maintainable in the long run,
> >> > gengtype or something else really needs to be taught to create them
> >> > automatically.
> >>
> >> I thought the principle that was acquired was that gengtype shouldn't
> >> be improved to support more than what it does now….
> >
> > If it means that we'll need to write and maintain tons of hand written code
> > that could otherwise be generated and maintained by a tool for us, that
> > principle doesn't look very good.
> >
> > Jakub
>
> Back in March 2013, I asked about gengtype support for inheritance.
>
> http://gcc.gnu.org/ml/gcc/2013-03/msg00273.html
>
> This
>
> http://gcc.gnu.org/ml/gcc/2013-03/msg00295.html
>
> was the definitive answer that appeared to be the consensus.
[adding Diego to the CC]
I get the impression from the responses so far to this and to the symtab
patches [1] that people would prefer that gengtype be somehow expanded
to cope with single-inheritance.
Handwaving over syntax (borrowing from the union-marking syntax),
perhaps something like this:
struct
GTY((chain_next ("%h.next")),
desc ("gimple_statement_structure (&%h)"))
gimple_statement_base {
/* as before */
};
struct GTY((subclass_tag ("GSS_PHI"))) gimple_statement_phi : public
gimple_statement_base {
}
and then have gengtype recognize the inheritance hierarchy below
gimple_statement_base, and "do the right thing" (again I'm handwaving).
Also, perhaps we could use a new GTY flag: "never_in_pch" or somesuch,
so that we can mark e.g. gimple and rtx as never appearing in pch, and
thus only the GC hooks need to exist; the PCH either don't need to be
generated, or could be stubs containing just gcc_unreachable? That
would be an independent feature from the subclass support, of course.
That said, for this particular patch series, for the hand-maintained
route, there would just be one big GTY-related function to maintain,
rather than 3, given the lack of need for PCH support.
Dave
[1] http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01152.html
