From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17323 invoked by alias); 22 May 2011 15:27:47 -0000 Received: (qmail 17315 invoked by uid 22791); 22 May 2011 15:27:46 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_JMF_BL X-Spam-Check-By: sourceware.org Received: from smtp-100-sunday.noc.nerim.net (HELO mallaury.nerim.net) (62.4.17.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 22 May 2011 15:27:31 +0000 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by mallaury.nerim.net (Postfix) with ESMTPS id EC269153418; Sun, 22 May 2011 17:27:29 +0200 (CEST) Received: from glinka.lesours ([192.168.0.1]) by hector.lesours with smtp (Exim 4.76) (envelope-from ) id 1QOAYa-0003jB-SW; Sun, 22 May 2011 17:27:04 +0200 Date: Sun, 22 May 2011 18:49:00 -0000 From: Basile Starynkevitch To: Gerald Pfeifer Cc: Pierre Vittet , gcc-patches@gcc.gnu.org Subject: Re: [PATCH, MELT] add dominance functions Message-Id: <20110522172649.67506486.basile@starynkevitch.net> In-Reply-To: References: <4DD41847.1040801@pvittet.com> <20110519073238.35a156ca.basile@starynkevitch.net> <4DD638CD.5020106@pvittet.com> <20110520151332.7bcbfeb6.basile@starynkevitch.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2011-05/txt/msg01559.txt.bz2 On Sun, 22 May 2011 15:24:30 +0200 (CEST) Gerald Pfeifer wrote: > On Fri, 20 May 2011, Basile Starynkevitch wrote: > > By the way, I am quite happy of Pierre patches to the MELT branch. Is > > this enough to get him a write access to GCC SVN (all legalese is done)? > > I fear that to really get that write access, Pierre would also need to > > have accepted patches to the trunk (i.e. that writing good patches to a > > branch is not enough)... I still don't understand the criteria to admit > > Pierre to the Write After Approval list of maintainers with a write > > access to GCC SVN... > > This indeed is a bit of an unusual situation. Are you planning to, > realistically, merge the MELT branch into mainline at one point? I am dreaming of either merging MELT into mainline, or at least having it be an essential GCC plugin distributed with GCC.... (ideally, I would prefer MELT to be merged, because that would give it more visibility). But I don't know how realistic is that dream. And I even don't know how to make it happen. (The main issue being: who will review a 60KLOC patch, most of it being in a "bizarre" language, MELT itself??) As I told in informal discussions at some GCC Summits, I feel that MELT is or may become a bit like the tree-browser.c : something useful enough to some people to be integrated into mainline, even if most GCC users don't even know about that functionality, and don't care or use it when compiling their software. I am quite sure that 99% of GCC users don't need or know about tree-browser.c and could use GCC with the tree-browser disabled! I believe it could be the same for MELT: it would be useful to a small fraction of users, but to them it would bring enough value. I am believing that Pierre's work can indeed attract much more attention to MELT, because it shows very well MELT's interest: providing a higher-level formalism which makes possible extra features (e.g. specific warnings, in Pierre's GSOC work case) which would not be realistically or economically possible without MELT. The point is that MELT is usually quite near to the mainline: we carefully avoid adding things into MELT which make MELT incompatible with the mainline (unless we believe it shows a feature which should be accepted), because we strongly want MELT to be either compilable as a branch or as a plugin (to the next GCC release). To be more specific, the difference between MELT (as a branch) and the trunk are two lines in gengtype.c, a few lines in toplevel.c, some additional options & parameters (common.opt, params.def), and the whole MELT infrastructure (melt-runtime.[ch], melt/generated/*, melt/*) which is by default disabled. So the behavior of the MELT branch when no MELT specific program options are given is exactly the behavior of the trunk (which was last merged into MELT). This is done on purpose, because MELT can also be built and used as a GCC plugin, so its behavior is "plugin-like": unless enabled (by options -fmelt*), MELT branch does exactly what the trunk do. And even when required by -fmelt* arguments to cc1, MELT branch behavior is exactly that of the melt.so plugin (except that arguments which are -fmelt* to the MELT branch becomes -fplugin-arg-melt-* arguments for -fplugin=melt). Internally, the MELT branch registers a pseudo builtin/MELT plugin and uses the plugin hooks (only when enabled). The distributed MELT plugin is made of files extracted from the MELT branch: the melt.so plugin is obtained by compiling melt-runtime.c as a plugin... Regards. PS. I surely don't want to start a useless flamewar... -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***