From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2153) id 495253861810; Tue, 30 Mar 2021 22:41:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 495253861810 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" From: Jakub Jelinek To: gcc-cvs@gcc.gnu.org Subject: [gcc r10-9626] c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790] X-Act-Checkin: gcc X-Git-Author: Jakub Jelinek X-Git-Refname: refs/heads/releases/gcc-10 X-Git-Oldrev: afe9a630eae114665e77402ea083201c9d406e99 X-Git-Newrev: 7cdd30b43a63832d6f908b2dd64bd19a0817cd7b Message-Id: <20210330224159.495253861810@sourceware.org> Date: Tue, 30 Mar 2021 22:41:59 +0000 (GMT) X-BeenThere: gcc-cvs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-cvs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 22:41:59 -0000 https://gcc.gnu.org/g:7cdd30b43a63832d6f908b2dd64bd19a0817cd7b commit r10-9626-g7cdd30b43a63832d6f908b2dd64bd19a0817cd7b Author: Jakub Jelinek Date: Tue Mar 30 18:15:32 2021 +0200 c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790] The following testcase ICEs (since the addition of inline var support), because the lambda contains PTRMEM_CST but finish_function is called for the lambda quite early during parsing it (from finish_lambda_function) when the containing class is still incomplete. That means that during genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but later nothing lowers it when the class is finalized. Using sizeof etc. on the class in such contexts is rejected by both g++ and clang++, and when the PTRMEM_CST appears e.g. in static var initializers rather than in functions, we handle it correctly because c_parse_final_cleanups -> lower_var_init will handle those cplus_expand_constant when all classes are already finalized. The following patch fixes it by calling cplus_expand_constant again during gimplification, as we are now unconditionally unit at a time, I'd think everything that could be completed will be before we start gimplification. 2021-03-30 Jakub Jelinek PR c++/99790 * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST. * g++.dg/cpp1z/pr99790.C: New test. Diff: --- gcc/cp/cp-gimplify.c | 8 ++++++++ gcc/testsuite/g++.dg/cpp1z/pr99790.C | 9 +++++++++ 2 files changed, 17 insertions(+) diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c index 8553f18f845..d5415f116a6 100644 --- a/gcc/cp/cp-gimplify.c +++ b/gcc/cp/cp-gimplify.c @@ -941,6 +941,14 @@ cp_gimplify_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p) ret = GS_UNHANDLED; break; + case PTRMEM_CST: + *expr_p = cplus_expand_constant (*expr_p); + if (TREE_CODE (*expr_p) == PTRMEM_CST) + ret = GS_ERROR; + else + ret = GS_OK; + break; + case RETURN_EXPR: if (TREE_OPERAND (*expr_p, 0) && (TREE_CODE (TREE_OPERAND (*expr_p, 0)) == INIT_EXPR diff --git a/gcc/testsuite/g++.dg/cpp1z/pr99790.C b/gcc/testsuite/g++.dg/cpp1z/pr99790.C new file mode 100644 index 00000000000..99961f5a4ee --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1z/pr99790.C @@ -0,0 +1,9 @@ +// PR c++/99790 +// { dg-do compile { target c++17 } } + +struct A; +struct B { void (*fn) (A *); }; +template +int foo (const T &); +struct A { int a; static constexpr B b{[] (A *n) { n->*&A::a = 2; }}; }; +int a = foo (A::b);