This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 5/5] add libcc1


On Thu, Jul 31, 2014 at 10:01:15AM +0200, Richard Biener wrote:
> 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?

I don't think the JIT work helps much here because this library wants to
feed gcc source not IL, so it needs a front end not just the back.

> 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.

good point.

> 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").

sounds nice

> 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.

so the interesting bit of libcc1 is just a plugin, which means it won't
add any extra work past making plugins work.  On the other hand if you
could load a library that included the driver and front ends then you'd
basically have a much simpler libcc1, so I think that work would make
libcc1 a bit nicer.

Trev

> 
> [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
> >


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]