From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58064 invoked by alias); 3 Dec 2015 21:43:24 -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 58051 invoked by uid 89); 3 Dec 2015 21:43:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 03 Dec 2015 21:43:23 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id EDDB0915A3 for ; Thu, 3 Dec 2015 21:43:21 +0000 (UTC) Received: from [10.3.235.63] (vpn-235-63.phx2.redhat.com [10.3.235.63]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB3LhLEG020474; Thu, 3 Dec 2015 16:43:21 -0500 Message-ID: <1449179000.8490.35.camel@surprise> Subject: Re: [PATCH 02/10] Fix g++.dg/cpp0x/nsdmi-template14.C From: David Malcolm To: Jason Merrill Cc: gcc-patches@gcc.gnu.org Date: Thu, 03 Dec 2015 21:43:00 -0000 In-Reply-To: <5660A710.7040607@redhat.com> References: <565627A0.6040107@redhat.com> <1449154548-43964-1-git-send-email-dmalcolm@redhat.com> <1449154548-43964-3-git-send-email-dmalcolm@redhat.com> <5660A710.7040607@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00498.txt.bz2 On Thu, 2015-12-03 at 15:33 -0500, Jason Merrill wrote: > On 12/03/2015 09:55 AM, David Malcolm wrote: > > This patch adds bulletproofing to detect purged tokens, and avoid using > > them. > > > > Alternatively, is it OK to access purged tokens for this kind of thing? > > If so, would it make more sense to instead leave their locations untouched > > when purging them? > > I think cp_lexer_previous_token should skip past purged tokens. Sorry if this is a silly question, but should I limit the iteration e.g. by detecting a sentinel value? e.g. parser->lexer->buffer->address () ? Or is there guaranteed to be an unpurged token somewhere beforehand? Out of interest, the prior tokens here are: (gdb) p end_tok[0] $25 = {type = CPP_GREATER, keyword = RID_MAX, flags = 0 '\000', pragma_kind = PRAGMA_NONE, implicit_extern_c = 0, error_reported = 0, purged_p = 1, location = 0, u = {tree_check_value = 0x0, value = }} (gdb) p end_tok[-1] $26 = {type = CPP_NAME, keyword = RID_MAX, flags = 0 '\000', pragma_kind = PRAGMA_NONE, implicit_extern_c = 0, error_reported = 0, purged_p = 1, location = 0, u = {tree_check_value = 0x0, value = }} (gdb) p end_tok[-2] $27 = {type = CPP_LESS, keyword = RID_MAX, flags = 0 '\000', pragma_kind = PRAGMA_NONE, implicit_extern_c = 0, error_reported = 0, purged_p = 1, location = 0, u = {tree_check_value = 0x0, value = }} (gdb) p end_tok[-3] $28 = {type = 86, keyword = RID_MAX, flags = 1 '\001', pragma_kind = PRAGMA_NONE, implicit_extern_c = 0, error_reported = 0, purged_p = 0, location = 202016, u = {tree_check_value = 0x7ffff19dfd98, value = }} (gdb) p end_tok[-4] $29 = {type = CPP_KEYWORD, keyword = RID_NEW, flags = 1 '\001', pragma_kind = PRAGMA_NONE, implicit_extern_c = 0, error_reported = 0, purged_p = 0, location = 201890, u = {tree_check_value = 0x7ffff18a8318, value = }} where the previous unpurged token is: (gdb) p end_tok[-3].purged_p $31 = 0 (gdb) call inform (end_tok[-3].location, "") ../../src/gcc/testsuite/g++.dg/cpp0x/nsdmi-template14.C:11:14: note: B* p = new B; ^ which would give a range of: B* p = new B; ^~~~~ for the erroneous new expression, rather than: B* p = new B; ^~~~~~~~ if we used the location of the purged token (the CPP_GREATER). I prefer the latter, hence my suggestion about not zero-ing out the locations of tokens when purging them.