From patchwork Tue Sep 26 08:28:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 818492 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-462932-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="gy4rV4lh"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3y1Yxl4JQ7z9tXc for ; Tue, 26 Sep 2017 18:28:27 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to:cc :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=o3NufolceF/dRduCOTKXPn5DUknOnFFriP8wFzSlgjsSXEh9JB kHZar2J/Xfn41iqIP976xyUwxkpH1UkA7+8nMQ7c42EfHv3QX82FlPfQC20k5PEj vvFLyJNJjWqkJZukv+bgcAmnUdXjlc7/eEsx9xTDkZKH1HO7FshJGMkK4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to:cc :from:subject:message-id:date:mime-version:content-type; s= default; bh=D/NOZWe54GNvneUKUybyOmESfVE=; b=gy4rV4lhkxHTjYNcng/e Giu+ZkZEFCBFXd+xp8HARraHaM1gpx52FVinDutQhUDlWE9CmC4SJ1Gjdz1jbXMq iT6jypARw+WShObaneZjeMQo0quYj3y8J8Vcy4J2qk1lHx4o1IuSGV+RrxPhLVTj 1cUaRKgTg+dNsgSpkOxTWB8= Received: (qmail 14733 invoked by alias); 26 Sep 2017 08:28:20 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 14720 invoked by uid 89); 26 Sep 2017 08:28:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.1 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=completing, straightforward, H*MI:8054, paolo X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Sep 2017 08:28:18 +0000 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8Q8SDIo000361 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Sep 2017 08:28:14 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v8Q8SDPG026169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Sep 2017 08:28:13 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8Q8SDoE011724; Tue, 26 Sep 2017 08:28:13 GMT Received: from [192.168.1.4] (/79.46.212.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Sep 2017 08:28:13 +0000 To: "gcc-patches@gcc.gnu.org" Cc: Jason Merrill From: Paolo Carlini Subject: [C++ Patch] PR 65579 ("gcc requires definition of a static constexpr member...") Message-ID: Date: Tue, 26 Sep 2017 10:28:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 X-IsSubscribed: yes Hi, this is a relatively old bug already analyzed by Martin last year. He also proposed a patch: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00593.html After a short exchange Jason proposed a different approach based on simply completing the involved vars: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01420.html Having verified that Martin wasn't actively working on the bug, I decided to try a very straightforward implementation of Jason's suggestion - see the attached, tested x86_64-linux - which appears to work fine as-is. Naturally, one could imagine restricting/enlarging the set of decls to complete: some choices don't seem good, like extending to non-constepr vars too (the corresponding snippet is ill formed anyway due to the initialization). I didn't try to test all the possible variants... Thanks, Paolo. /////////////////// /cp 2017-09-26 Paolo Carlini PR c++/65579 * decl.c (grokdeclarator): Before calling cp_apply_type_quals_to_decl on constexpr VAR_DECLs complete their type. /testsuite 2017-09-26 Paolo Carlini PR c++/65579 * g++.dg/cpp0x/constexpr-template11.C: New. Index: cp/decl.c =================================================================== --- cp/decl.c (revision 253134) +++ cp/decl.c (working copy) @@ -12348,7 +12348,11 @@ grokdeclarator (const cp_declarator *declarator, /* Set constexpr flag on vars (functions got it in grokfndecl). */ if (constexpr_p && VAR_P (decl)) - DECL_DECLARED_CONSTEXPR_P (decl) = true; + { + DECL_DECLARED_CONSTEXPR_P (decl) = true; + if (!processing_template_decl) + TREE_TYPE (decl) = complete_type (TREE_TYPE (decl)); + } /* Record constancy and volatility on the DECL itself . There's no need to do this when processing a template; we'll do this Index: testsuite/g++.dg/cpp0x/constexpr-template11.C =================================================================== --- testsuite/g++.dg/cpp0x/constexpr-template11.C (revision 0) +++ testsuite/g++.dg/cpp0x/constexpr-template11.C (working copy) @@ -0,0 +1,16 @@ +// PR c++/65579 +// { dg-do link { target c++11 } } + +template +struct S { + int i; +}; + +struct T { + static constexpr S s = { 1 }; +}; + +int main() +{ + return T::s.i; +}