From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12987 invoked by alias); 31 Jul 2014 10:46:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 12964 invoked by uid 89); 31 Jul 2014 10:46:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.mozilla.org Received: from mx1.corp.phx1.mozilla.com (HELO smtp.mozilla.org) (63.245.216.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 31 Jul 2014 10:46:47 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (69-165-234-187.cable.teksavvy.com [69.165.234.187]) (Authenticated sender: tsaunders@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id DA305F2055; Thu, 31 Jul 2014 03:46:44 -0700 (PDT) Date: Thu, 31 Jul 2014 10:53:00 -0000 From: Trevor Saunders To: Richard Biener Cc: Jeff Law , Tom Tromey , GCC Patches Subject: Re: [PATCH 5/5] add libcc1 Message-ID: <20140731104455.GA29240@tsaunders-iceball.corp.tor1.mozilla.com> References: <1400254001-12038-1-git-send-email-tromey@redhat.com> <87oayx4l0x.fsf@fleche.redhat.com> <87bntobp1f.fsf@fleche.redhat.com> <53D9CA7B.3040709@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg02183.txt.bz2 On Thu, Jul 31, 2014 at 10:01:15AM +0200, Richard Biener wrote: > On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law 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 > >> Tom Tromey > >> > >> * Makefile.def: Add libcc1 to host_modules. > >> * configure.ac (host_tools): Add libcc1. > >> * Makefile.in, configure: Rebuild. > >> > >> 2014-06-19 Phil Muldoon > >> Jan Kratochvil > >> Tom Tromey > >> > >> * 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 > >