From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3034 invoked by alias); 10 Dec 2010 17:55:30 -0000 Received: (qmail 3015 invoked by uid 22791); 10 Dec 2010 17:55:29 -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; Fri, 10 Dec 2010 17:55:24 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBAHtGW5004785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Dec 2010 12:55:17 -0500 Received: from adjoa.redhat.com (ovpn-113-34.phx2.redhat.com [10.3.113.34]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oBAHtDCk027270; Fri, 10 Dec 2010 12:55:14 -0500 From: Dodji Seketeli To: Gabriel Dos Reis Cc: 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> X-URL: http://www.redhat.com Date: Fri, 10 Dec 2010 18:22:00 -0000 In-Reply-To: (Gabriel Dos Reis's message of "Fri, 10 Dec 2010 06:33:55 -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=us-ascii 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/msg00902.txt.bz2 Gabriel Dos Reis writes: > On Fri, Dec 10, 2010 at 5:11 AM, Dodji Seketeli wrote: >> * Problem statement >> >> Let's consider the diagnostic GCC emits when an error occurs on an >> expression that was defined in a macro that is later expanded: > > I like the general idea of the patch. Thanks. > Ideally, we should avoid introduction of yet another flag for this. I agree. > I understand the concern about memory consumption, and I share it. > But, it would be great we could limit that without introducing > new flags -- because it seems the flags would be there only to > expose implementation inefficiency, not fundamental user-level > functionality. > > I suspect that for many reasonably well written C++ programs, all those > loci are the same. Very few would have all three loci (and actually there > is at least a fourth) different. I would suggest exploring functional > interface where there are different location implementations, corresponding > to the different sensible combinations of location kind. This way, only > tokens that are actually macro expanded or created through macro > expansion or strnigification get additional necessary slots. Actually that's what the second patch does. Only tokens resulting from macro expansion have the new virtual location. Other tokens just have the plain old spelling location and thus don't incur any cost. -- Dodji