From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14033 invoked by alias); 4 Oct 2011 20:28:36 -0000 Received: (qmail 14024 invoked by uid 22791); 4 Oct 2011 20:28:35 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 04 Oct 2011 20:28:20 +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.14.4/8.14.4) with ESMTP id p94KRtX8006404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Oct 2011 16:27:55 -0400 Received: from localhost (ovpn-113-20.phx2.redhat.com [10.3.113.20]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p94KRrhv025060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Oct 2011 16:27:54 -0400 Received: by localhost (Postfix, from userid 500) id D343629C129; Tue, 4 Oct 2011 22:27:52 +0200 (CEST) From: Dodji Seketeli To: Jason Merrill Cc: gcc-patches@gcc.gnu.org, tromey@redhat.com, gdr@integrable-solutions.net, joseph@codesourcery.com, burnus@net-b.de, charlet@act-europe.fr, bonzini@gnu.org Subject: Re: [PATCH 3/7] Emit macro expansion related diagnostics References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <4E778A26.1000707@redhat.com> <4E77ACA1.80205@redhat.com> <4E789C5B.20509@redhat.com> <4E793BF4.4010103@redhat.com> <4E7B497F.8060301@redhat.com> <4E80E47C.305@redhat.com> <4E83B6D5.5030907@redhat.com> <4E84C9FA.30604@redhat.com> <4E85E004.2030706@redhat.com> <4E862966.6080801@redhat.com> <4E8B658A.1020809@redhat.com> X-URL: http://www.redhat.com Date: Tue, 04 Oct 2011 20:35:00 -0000 In-Reply-To: <4E8B658A.1020809@redhat.com> (Jason Merrill's message of "Tue, 04 Oct 2011 15:59:06 -0400") 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 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-10/txt/msg00266.txt.bz2 Jason Merrill writes: > On 10/03/2011 06:49 PM, Dodji Seketeli wrote: >> Good question. Is the below better? > >> + if (linemap_location_from_macro_expansion_p (set, pre)) >> + pre = linemap_resolve_location (set, pre, >> + LRK_MACRO_EXPANSION_POINT, NULL); >> + >> + if (linemap_location_from_macro_expansion_p (set, post)) >> + post = linemap_resolve_location (set, post, >> + LRK_MACRO_EXPANSION_POINT, >> + NULL); > > This looks like two different virtual locations from the same macro > expansion will compare equal. Yes. I thought this was enough to not regress compared to the current situation where two tokens from the same macro expansion have the spelling location of macro expansion point anyway. This is used for #pragma disagnostic changes in diagnostic_report_diagnostic. Otherwise, I am not sure how this should behave wrt nested macro expansions. -- Dodji