[PATCH 5/5] add libcc1

[Richard Biener]

On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law <law@redhat.com> wrote:
> On 06/19/14 14:52, Tom Tromey wrote:
>>
>> Tom> I've edited this one down by removing the auto-generated stuff , and
>> Tom> then compressed it.
>>
>> Here's a new version of patch #5.
>> I've removed the generated code; let's see if it gets through without
>> compression.
>>
>> I think this addresses all the reviews:
>>
>> * It uses gcc-plugin.m4 to disable the plugin
>> * It does some configure checks for needed functionality, and disables
>>    the plugin if they are not found
>> * libcc1 and the plugin now do a protocol version handshake at
>>    startup
>> * The diagnostic overriding code is now in the plugin, not in gcc proper
>> * gdb now tells libcc1 about the target triplet, and libcc1 uses
>>    this to invoke the proper GCC.  This is done by (ewww) searching $PATH.
>>
>> Tom
>>
>> 2014-06-19  Phil Muldoon  <pmuldoon@redhat.com>
>>             Tom Tromey  <tromey@redhat.com>
>>
>>         * Makefile.def: Add libcc1 to host_modules.
>>         * configure.ac (host_tools): Add libcc1.
>>         * Makefile.in, configure: Rebuild.
>>
>> 2014-06-19  Phil Muldoon  <pmuldoon@redhat.com>
>>             Jan Kratochvil  <jan.kratochvil@redhat.com>
>>             Tom Tromey  <tromey@redhat.com>
>>
>>         * aclocal.m4: New file.
>>         * callbacks.cc: New file.
>>         * callbacks.hh: New file.
>>         * cc1plugin-config.h.in: New file.
>>         * configure: New file.
>>         * configure.ac: New file.
>>         * connection.cc: New file.
>>         * connection.hh: New file.
>>         * findcomp.cc: New file.
>>         * findcomp.hh: New file.
>>         * libcc1.cc: New file.
>>         * libcc1plugin.sym: New file.
>>         * libcc1.sym: New file.
>>         * Makefile.am: New file.
>>         * Makefile.in: New file.
>>         * marshall.cc: New file.
>>         * marshall.hh: New file.
>>         * names.cc: New file.
>>         * names.hh: New file.
>>         * plugin.cc: New file.
>>         * rpc.hh: New file.
>>         * status.hh: New file.
>
> So my biggest concern here is long term maintenance -- who's going to own
> care and feeding of these bits over time.
>
> My inclination is to go ahead and approve, but explicitly note that if the
> bits do start to rot that we'll be fairly aggressive at disabling/removing
> them.
>
> Now that my position is out there for everyone to see, give the other
> maintainers a few days (say until Monday) to chime in with any objections.
>
> Obviously if there are no objections and you check in the change, please be
> on the lookout for any fallout.  I'm particularly concerned about AIX,
> Solaris and other non-linux platforms.
>
> Does this deserve a mention in the news file?

Can you briefly elaborate on how this relates to the JIT work from
David Malcom?

Also during the GCC Summit we talked about JIT and plugins and
I mentioned that the JIT API is actually a kind of "stable plugin API"
for IL creation.

We've also elaborated on why the JIT cannot be a "plugin" at the
moment - which is at least partly because we cannot have
"frontend plugins".  This is because compilation is currently
driven by the frontend which "owns" main() even though it immediately
calls into the middle-end and only gets control back via langhooks.
So a quite obvious cleanup of the program flow of GCC would be
to drive things from a middle-end main() - which would allow
a plugin to take over the frontend parts (and which would allow
making all frontends shared objects, aka "plugins" to a common
middle-end "driver").

Just throwing in my mental notes from the Summit here.  I really
wonder how libcc1 falls in into this picture and if it would stand
in the way of re-organizing main program flow and/or making
frontends shared objects.

[ideally both frontends and targets would be shared objects, but of
course even frontends have target dependencies pulled in via
target macros at the moment...]

Richard.

> Jeff
>