On Thu, Jul 31, 2014 at 10:01:15AM +0200, Richard Biener wrote: > On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law <l...@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 <pmuld...@redhat.com> > >> Tom Tromey <tro...@redhat.com> > >> > >> * Makefile.def: Add libcc1 to host_modules. > >> * configure.ac (host_tools): Add libcc1. > >> * Makefile.in, configure: Rebuild. > >> > >> 2014-06-19 Phil Muldoon <pmuld...@redhat.com> > >> Jan Kratochvil <jan.kratoch...@redhat.com> > >> Tom Tromey <tro...@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 > >
