From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15719 invoked by alias); 8 Jan 2018 17:10:57 -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 15705 invoked by uid 89); 8 Jan 2018 17:10:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=gains, H*f:2mPVCyX1izR9d4X, _CharT, VAR_DECL X-HELO: mail-yb0-f182.google.com Received: from mail-yb0-f182.google.com (HELO mail-yb0-f182.google.com) (209.85.213.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Jan 2018 17:10:54 +0000 Received: by mail-yb0-f182.google.com with SMTP id b18so1424998ybn.2 for ; Mon, 08 Jan 2018 09:10:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ltLogzoQawysUi+LqQPjCLmJyCoBT/xuoiSlSeBAg98=; b=EkrSY0c4JygRQbRyobjxiMmMghxohLxCaONM7vo8TR1vTTQFLPJ/JaH3Mq9GBRq1VA OhvTNg3FMVr26tcBqMjDYvVx5MnzS6nmTtddmYJxo3PaHd2YcEmKRive5CE5y+G8kIRv OP6EvccNhMIS4FNP2aYsAze3rY+SkmK1YiNt3Roj3bpvkRNVf5ZY4Jq2XaZ1KmhadeYK XUXhAmlCvG473Lfr9jmRVSxBNC4uSoIUdhsYOPf2cSWsyu0bVIilJTBfy2xT3HkkZ9iL 8ts660XhtZZ9E5jwbxCADeJB3yr52mx7VbtzFcKqdmATCBBSk7VYP28Y7lwrdWpyYFrD 7JZA== X-Gm-Message-State: AKGB3mKzNeySaWs1jvja6+qLOl3jPW9ajxRPpYj0L4YJQcn19UzdbkA1 8avNwgFoB1y6JEo/K2f72ZA= X-Google-Smtp-Source: ACJfBovcEsq5WtOydoKHJnl5R8+AQIYZ1my/jluneysd/yjIlBNkFaQBtGMwiaZBw7cMaebcRNkqJQ== X-Received: by 10.37.112.4 with SMTP id l4mr11522570ybc.503.1515431452785; Mon, 08 Jan 2018 09:10:52 -0800 (PST) Received: from ?IPv6:2620:10d:c0a1:1102:495f:7267:5ff:a250? ([2620:10d:c091:180::1:6c18]) by smtp.googlemail.com with ESMTPSA id w69sm1591313yww.13.2018.01.08.09.10.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jan 2018 09:10:52 -0800 (PST) Subject: Re: Location wrappers vs decls that change type (was Re: [v2 of PATCH 03/14] C++: add location_t wrapper nodes during parsing (minimal impl)) To: David Malcolm , Jason Merrill Cc: Jakub Jelinek , Richard Biener , gcc-patches List References: <1514567206-13093-1-git-send-email-dmalcolm@redhat.com> <1a3db854-830d-516c-61ed-ef503b47b946@redhat.com> <1515190808.24844.23.camel@redhat.com> <1515430963.24844.56.camel@redhat.com> From: Nathan Sidwell Message-ID: Date: Mon, 08 Jan 2018 17:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1515430963.24844.56.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-01/txt/msg00507.txt.bz2 On 01/08/2018 12:02 PM, David Malcolm wrote: > On Fri, 2018-01-05 at 17:20 -0500, David Malcolm wrote: > Doing so uncovered an issue which I'm not sure how to resolve: it's > possible for a decl to change type during parsing, after location > wrappers may have been created, which changes location_wrapper_p on > those wrappers from true to false. > Asserting that the only VIEW_CONVERT_EXPR or NON_LVALUE_EXPR seen in > tsubst_copy and tsubst_copy_and_build are location_wrapper_p leads to > an ICE on the above code. > > What's happening is as follows. First, in the call: > > 6 assign(_S_terminal); > ^~~~~~~~~~~ > > the VAR_DECL "_S_terminal" gains a VIEW_CONVERT_EXPR location wrapper > node to express the underline shown above. > > Later, during parsing of this init-declarator: > > 10 template > 11 const _CharT basic_string<_CharT>::_S_terminal = _CharT(); > ^~~~~~~~~~~ > > > ...cp_parser_init_declarator calls start_decl, which calls > duplicate_decls, merging the "_S_terminal" seen here: ... > Both "_S_terminal" VAR_DECLs have a "_CharT" TEMPLATE_TYPE_PARM, but > these types are different tree nodes. correct. they are not EQ but are EQUAL (same_type_p will be true). > Hence the type of the first VAR_DECL changes in duplicate_decls here: > > 2152 TREE_TYPE (newdecl) = TREE_TYPE (olddecl) = newtype; > > ...changing type to the TEMPLATE_TYPE_PARM of the second VAR_DECL. > 18306 case VIEW_CONVERT_EXPR: > 18307 case NON_LVALUE_EXPR: > 18308 gcc_assert (location_wrapper_p (t)); > 18309 RETURN (RECUR (TREE_OPERAND (t, 0))); > > Assuming I'm correctly understanding the above, I'm not sure what the > best solution is. > > Some ideas: > * don't add location wrappers if processing a template > > * introduce a new tree node for location wrappers (gah) > > * something I haven't thought of Add a flag on the VIEW_CONVERT/NON_LVALUE expr explicitly noting its wrapperness (rather than infer it from TREE_TYPE == TREE_TYPE (TREE_OPERAND)). TREE_LANG_FLAG_0 looks available? nathan -- Nathan Sidwell