This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC - Alternatives to gengtype
- From: Lawrence Crowl <crowl at google dot com>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: Diego Novillo <dnovillo at google dot com>, gcc at gcc dot gnu dot org, Ian Lance Taylor <iant at google dot com>, Laurynas Biveinis <laurynas dot biveinis at gmail dot com>
- Date: Mon, 19 Nov 2012 16:56:45 -0800
- Subject: Re: RFC - Alternatives to gengtype
- References: <20121116005936.GA16988@google.com> <alpine.BSF.2.02.1211170550300.76197@dair.pair.com>
On 11/17/12, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> On Thu, 15 Nov 2012, Diego Novillo wrote:
> > === Approach: Move GTY to cc1plus.
> >
> > Instead of a separate weak parser, we would make cc1plus
> > understand GTY attributes. The compiler would emit IL in the
> > object files instead of generating source.
> >
> > This solution would require a first boot stage that did not
> > support PCH, because we cannot rely on the seed compiler
> > supporting GTY. We would probably need to use the Boehm
> > collector during the first stage as well.
> >
> > Because the first stage would be fundamentally different from the
> > second stage, we may need to add an additional pass for correct
> > object file comparisons.
>
> It sounds like this would, for cross-compilers, require a native
> GTY-savvy g++? Please no.
We cannot require a GTY savy seed compiler. In part, at least,
because we do not have one now. :-)
So, the GTY annotations would need to be invisible to the seed
compiler. The implication is that the first built compiler does
not have GGC and PCH. The first built compiler would, however,
recognize GTY, and the second (and subsequent) built compiler would
have these features.
Because the first built compiler would not have GGC, we need some
other memory management, and the Boehm collector is the nearest
handy tool.
--
Lawrence Crowl