From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8346 invoked by alias); 31 Jul 2014 15:04:54 -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 8278 invoked by uid 89); 31 Jul 2014 15:04:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 31 Jul 2014 15:04:52 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1XCruQ-0006RI-Vz from joseph_myers@mentor.com ; Thu, 31 Jul 2014 08:04:47 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Jul 2014 08:04:46 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Thu, 31 Jul 2014 16:04:45 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1XCruO-0003f2-3L; Thu, 31 Jul 2014 15:04:44 +0000 Date: Thu, 31 Jul 2014 15:08:00 -0000 From: "Joseph S. Myers" To: Richard Biener CC: Trevor Saunders , Jeff Law , Tom Tromey , GCC Patches Subject: Re: [PATCH 5/5] add libcc1 In-Reply-To: Message-ID: References: <1400254001-12038-1-git-send-email-tromey@redhat.com> <87oayx4l0x.fsf@fleche.redhat.com> <87bntobp1f.fsf@fleche.redhat.com> <53D9CA7B.3040709@redhat.com> <20140731104455.GA29240@tsaunders-iceball.corp.tor1.mozilla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-07/txt/msg02210.txt.bz2 On Thu, 31 Jul 2014, Richard Biener wrote: > Actually after looking again I was wrong. main.c and toplev.c > are the "driver". So if we can make all frontends shared objects > with their only interface being their lang_hooks that would be nice > (of course the middle-end still needs to make gazillions of symbols > available to that "plugin"). As far as I know, the main non-lang-hook interface provided by front ends is the "convert" function (and there aren't that many places outside the front ends that still use it). So it shouldn't be hard to get to the state where each front end is only used by its langhooks. (That's a long way from any sort of independent buildability, though; everything still embeds global information about such things as command-line options for all available front ends, and tree codes likewise.) I don't personally like the relics of other such magic-named functions in the form of langhooks-def.h defaulting to a langhook having a particular name that a front end can provide #define LANG_HOOKS_GLOBAL_BINDINGS_P global_bindings_p #define LANG_HOOKS_PUSHDECL pushdecl #define LANG_HOOKS_GETDECLS getdecls and think it would be better for each front end to have unique names for these, with no such default. I think there are a few more cases where C and C++ provide different implementations of a function with the same name for use by c-family code (and ObjC / ObjC++ issues as well, of course). -- Joseph S. Myers joseph@codesourcery.com