From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31723 invoked by alias); 14 Dec 2010 08:31:43 -0000 Received: (qmail 31702 invoked by uid 22791); 14 Dec 2010 08:31:41 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Dec 2010 08:31:35 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBE8VQBt030647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 03:31:26 -0500 Received: from adjoa.redhat.com (ovpn-113-36.phx2.redhat.com [10.3.113.36]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oBE8VMZr012190; Tue, 14 Dec 2010 03:31:23 -0500 From: Dodji Seketeli To: Gabriel Dos Reis Cc: Jeff Law , gcc-patches@gcc.gnu.org, tromey@redhat.com, joseph@codesourcery.com, lopezibanez@gmail.com Subject: Re: [PATCH 0/6] Tracking locations of tokens resulting from macro expansion References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <4D025930.6020000@redhat.com> <4D062D34.1050606@redhat.com> X-URL: http://www.redhat.com Date: Tue, 14 Dec 2010 09:24:00 -0000 In-Reply-To: (Gabriel Dos Reis's message of "Mon, 13 Dec 2010 09:38:36 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: 2010-12/txt/msg01075.txt.bz2 Gabriel Dos Reis writes: > On Mon, Dec 13, 2010 at 8:27 AM, Jeff Law wrote: [...] >> I'm not sure either. =C2=A0I wouldn't be terribly surprised if we end up= changing >> our minds (whatever they may be) after a period of time with access to m= ore >> thorough diagnostic information. =C2=A0ie, we may not know what the right >> interface should be until after we've used the info for a while. =C2=A0S= o I guess >> we should keep our options open for the UI issues. > > Agreed. One thing we should also keep in mind though: GCC has already > way too many flags. Having dedicated flags to control every single > aspect does not necessarily make for good design. > Sure. I am not a flag-soup fan myself. My intent was just to provide a way for people to opt in and out for experimentation purposes during, say, stage 1. When we know what we want and come to an acceptable implementation then of course the flag will go away. If we are sure about what we want in advance as to avoid the flag in the first place, even better. --=20 Dodji