From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69183 invoked by alias); 5 Jun 2017 11:22:20 -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 68848 invoked by uid 89); 5 Jun 2017 11:22:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=meet X-HELO: mail-yb0-f172.google.com Received: from mail-yb0-f172.google.com (HELO mail-yb0-f172.google.com) (209.85.213.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Jun 2017 11:22:18 +0000 Received: by mail-yb0-f172.google.com with SMTP id r66so31998698yba.2 for ; Mon, 05 Jun 2017 04:22:22 -0700 (PDT) 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=MmfY3YKTRj07f0vhfktjmp+4x5qeQsnCe3cBfrwVl44=; b=Q2Jy6qxldAIaYBpT4snxCOnaTQjdu7wZslKkdlM6tkl2qjEeaESZePKb/4dhZgMRYW zyqMkmRCg1XztNJ8e8DVIWa4LoyDTCZC4/PCgqB8Y+kWCYrrs9gu0uPH1uKkqQzCC3oe pkNQ/Vm3/cCYJxnklxMBF8OC8JAD3o9geAEW6C4decNz/pWVHWI3FgZlV3lcegAP4jdF suG0Lm1tg3WxmGIRcRpm6ZgLmyY17WyPGsFiBbUVZL4nj3pC7GizlNEaSiXXdkBLlKxB +ChXzn+M/MoOGXmw/jJTSQjcsVloEgj7i5F09QDHn4GyNHWpXJ9yjRIcGnjbk+I0lp9v el3g== X-Gm-Message-State: AODbwcAedixfj+Y/0t5W1qAccsmagirSZR41BaXTX1U0b8s06kh+apXx 9bFkpQ+VQgIQSw== X-Received: by 10.37.178.9 with SMTP id i9mr9429881ybj.168.1496661740858; Mon, 05 Jun 2017 04:22:20 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a3:20fb:7500:e7fb:4a6f:2254? ([2620:10d:c091:200::7:3f92]) by smtp.googlemail.com with ESMTPSA id o63sm13687604ywc.12.2017.06.05.04.22.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 04:22:20 -0700 (PDT) Subject: Re: [C++ PATCH] lang_decl selector & decomposition To: Jakub Jelinek Cc: GCC Patches References: <21a65173-8939-e6d8-0fa5-278d7a64ec3d@acm.org> <20170531170545.GC24023@tucnak> <1dae7652-350f-fdc1-fa12-270c83644dac@acm.org> <20170605102826.GC2154@tucnak> From: Nathan Sidwell Message-ID: <8506e680-f06d-d906-1917-65ba3ab13326@acm.org> Date: Mon, 05 Jun 2017 11:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170605102826.GC2154@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00216.txt.bz2 On 06/05/2017 06:28 AM, Jakub Jelinek wrote: > So unless cxx_dup_lang_specific_decl or copy_decl or tsubst_decl > clears the DECL_DECOMP_BASE for the short time before cp_finish_decomp > is called, DECL_DECOMP_BASE will be "wrong" for a short time, but it > shouldn't matter, nothing should be querying it in between. Setting > it to NULL wouldn't be correct either anyway. Ok, thanks for checking. That also explains why we can meet VAR_DECLs that already have a decomp_lang_decl extension. nathan -- Nathan Sidwell