From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4521 invoked by alias); 15 Sep 2015 10:34:02 -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 4502 invoked by uid 89); 15 Sep 2015 10:34:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f174.google.com Received: from mail-yk0-f174.google.com (HELO mail-yk0-f174.google.com) (209.85.160.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 15 Sep 2015 10:34:00 +0000 Received: by ykft14 with SMTP id t14so28645031ykf.0 for ; Tue, 15 Sep 2015 03:33:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.57.80 with SMTP id 77mr19455901ykz.59.1442313238713; Tue, 15 Sep 2015 03:33:58 -0700 (PDT) Received: by 10.37.93.136 with HTTP; Tue, 15 Sep 2015 03:33:58 -0700 (PDT) In-Reply-To: <20150915102045.GB1847@tucnak.redhat.com> References: <1441916913-11547-1-git-send-email-dmalcolm@redhat.com> <1441916913-11547-8-git-send-email-dmalcolm@redhat.com> <20150915102045.GB1847@tucnak.redhat.com> Date: Tue, 15 Sep 2015 10:48:00 -0000 Message-ID: Subject: Re: [PATCH 07/22] Implement token range tracking within libcpp and C/C++ FEs From: Richard Biener To: Jakub Jelinek Cc: David Malcolm , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01045.txt.bz2 On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek wrote: > On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote: >> > diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h >> > index 760467c..c7558a0 100644 >> > --- a/gcc/cp/parser.h >> > +++ b/gcc/cp/parser.h >> > @@ -61,6 +61,8 @@ struct GTY (()) cp_token { >> > BOOL_BITFIELD purged_p : 1; >> > /* The location at which this token was found. */ >> > location_t location; >> > + /* The source range at which this token was found. */ >> > + source_range range; >> >> Is it just me or does location now feel somewhat redundant with range? Can't we >> compress that somehow? > > For a token I'd expect it is redundant, I don't see how it would be useful > for a single preprocessing token to have more than start and end locations. > But generally, for expressions, 3 locations make sense. > If you have > abc + def > ~~~~^~~~~ > then having a range is useful. In any case, I'm surprised that the ranges aren't encoded in > location_t (the data structures behind it, where we already stick also > BLOCK pointer). Probably lack of encoding space ... I suppose upping location_t to 64bits coud solve some of that (with its own drawback on increasing size of core structures). Richard. > Jakub