From patchwork Tue Dec 12 22:48:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 1875386 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=gPF5Ux5n; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4SqYh24vzCz20H6 for ; Wed, 13 Dec 2023 09:49:06 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A7A45385C310 for ; Tue, 12 Dec 2023 22:49:04 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 842073858019 for ; Tue, 12 Dec 2023 22:48:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 842073858019 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 842073858019 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702421334; cv=none; b=BSqhT9sCo25xDjJw9QGZpSp85kNq3BbO6TTG8zA/lIYOVUuu4pbFXRFhmmbPOBc3f//4Y9e0/bx60gT47cbnpNvCsRnW2Jn1E2JVYZ+GqPOs+tnn0ygfJ5DgS4IoiARur08ZStFz/XgWO1OiPmDPEupToKEgeegT8jM5WWAeqb0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702421334; c=relaxed/simple; bh=krK4h6G1DCoycvrjIVMeuJdYSdzLFLzNu4pBX4WaGoM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=E98WoBq+91NxGMTazpEutxbEb9qUjxJDdS0njxHTptJ96iio365jvdjQIMIw6NVwQbXu2mOATn997+Bi9JrZFwRWIccrucLe7wW21qrHhY3LV19wcX5AcNaezgGe1VPgC4Zy4A9yxHXRNjl5amF7FSAxYrgowTv+f+Z82K2Gnc0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702421332; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qicgBLPlSm+qMwxNWR0mosKJw6/vZxSm/lx23QxsCrs=; b=gPF5Ux5nmS338o4Unwz06MsLCshtysG8J1vvlzU0kPUJ3zF+65dPAdL1pgPjiMnUJXsgYG n1D86BT8Pp3TmnN248gZ0EBYimW5vNiK5DKyuQeoSB+Kcebw0PkO699oagw5FUiglc4GJE 85SaBxF8GD7fpbnRehm71xA8otwDSMY= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-375-rFMs1KZ9N8SWQRTCSCkTRA-1; Tue, 12 Dec 2023 17:48:50 -0500 X-MC-Unique: rFMs1KZ9N8SWQRTCSCkTRA-1 Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-4257662f905so80441241cf.0 for ; Tue, 12 Dec 2023 14:48:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702421330; x=1703026130; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qicgBLPlSm+qMwxNWR0mosKJw6/vZxSm/lx23QxsCrs=; b=oFjcQ9ryB8lM+NMjqACLurSkjMSxIv/csWhgHEp6H2JvaDSgX9ScW/7B0f92mAF/B/ VHFsbVCs893AbxHtmsoylZJdR8cZ/8kAusZPcbwPwlMISAojJJMsStsS1C7D88veG5jV odNCwQeFK8TABc4EieexIrNkIemHT98tsj/3QmGkx19TKovHFpGWXKZ7I5mncKhWzRAv F1LBbCPAPbbsxdwCX88SZUEpyLtO1AV8HcSabDT4OJzMuO8v3sBuKMEYtR5t6g3sk5jR 3NNSs38/6henbP0pzjPFPdu1UEN98yCGqFOHHEm9j21DIxCrPd+hmFTCf/T91T+MaFp3 AmyQ== X-Gm-Message-State: AOJu0YziFiUUxFixT0rBn9DQrqKhurfV9X+XGYcll9TQ7uE4mhC3Tbar k+PS98uQFgWRBowNT1pjeLHGZmeNUk0agSQRAkK++H85ORmxBfZEhQQgxR9zP5zamndvEpbpGNn 2CPEQu0wou2GwOvYo49h+6lREWg== X-Received: by 2002:ac8:5745:0:b0:425:4043:50be with SMTP id 5-20020ac85745000000b00425404350bemr11162267qtx.77.1702421329973; Tue, 12 Dec 2023 14:48:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IHZDCZ/0RDkXQDrD0nDnQPqydmUoB2KKU1czEwsJdVB9Fss0I9oqFPYTC3nsA5rkg5lUOR67A== X-Received: by 2002:ac8:5745:0:b0:425:4043:50be with SMTP id 5-20020ac85745000000b00425404350bemr11162256qtx.77.1702421329562; Tue, 12 Dec 2023 14:48:49 -0800 (PST) Received: from redhat.com (2603-7000-9500-34a5-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:34a5::1db4]) by smtp.gmail.com with ESMTPSA id h26-20020ac8549a000000b004254304015csm4406444qtq.85.2023.12.12.14.48.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 14:48:49 -0800 (PST) Date: Tue, 12 Dec 2023 17:48:47 -0500 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: [PATCH v3] c++: fix ICE with sizeof in a template [PR112869] Message-ID: References: <20231205203136.94832-1-polacek@redhat.com> <9c08e101-0392-4c01-b336-6558e80a4193@redhat.com> <9ca5d651-17ce-464a-8cc3-e8f5ab27c61a@redhat.com> MIME-Version: 1.0 In-Reply-To: <9ca5d651-17ce-464a-8cc3-e8f5ab27c61a@redhat.com> User-Agent: Mutt/2.2.10 (2023-03-25) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote: > On 12/8/23 16:15, Marek Polacek wrote: > > On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: > > > On 12/5/23 15:31, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > > > -- >8 -- > > > > This test shows that we cannot clear *walk_subtrees in > > > > cp_fold_immediate_r when we're in_immediate_context, because that, > > > > as the comment says, affects cp_fold_r as well. Here we had an > > > > expression with > > > > > > > > min ((long int) VIEW_CONVERT_EXPR(bytecount), (long int) <<< Unknown tree: sizeof_expr > > > > (int) <<< error >>> >>>) > > > > > > > > as its sub-expression, and we never evaluated that into > > > > > > > > min ((long int) bytecount, 4) > > > > > > > > so the SIZEOF_EXPR leaked into the middle end. > > > > > > > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > > > > one should be OK.) > > > > > > > > PR c++/112869 > > > > > > > > gcc/cp/ChangeLog: > > > > > > > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > > > > for unevaluated operands. > > > > > > I agree that we want this change for in_immediate_context (), but I don't > > > see why we want it for TYPE_P or unevaluated_p (code) or > > > cp_unevaluated_operand? > > > > No particular reason, just paranoia. How's this? > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > This test shows that we cannot clear *walk_subtrees in > > cp_fold_immediate_r when we're in_immediate_context, because that, > > as the comment says, affects cp_fold_r as well. Here we had an > > expression with > > > > min ((long int) VIEW_CONVERT_EXPR(bytecount), (long int) <<< Unknown tree: sizeof_expr > > (int) <<< error >>> >>>) > > > > as its sub-expression, and we never evaluated that into > > > > min ((long int) bytecount, 4) > > > > so the SIZEOF_EXPR leaked into the middle end. > > > > (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that > > one should be OK.) > > > > PR c++/112869 > > > > gcc/cp/ChangeLog: > > > > * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees > > for in_immediate_context. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/template/sizeof18.C: New test. > > --- > > gcc/cp/cp-gimplify.cc | 6 +++++- > > gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ > > 2 files changed, 13 insertions(+), 1 deletion(-) > > create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C > > > > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc > > index 5abb91bbdd3..6af7c787372 100644 > > --- a/gcc/cp/cp-gimplify.cc > > +++ b/gcc/cp/cp-gimplify.cc > > @@ -1179,11 +1179,15 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) > > /* No need to look into types or unevaluated operands. > > NB: This affects cp_fold_r as well. */ > > - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) > > + if (TYPE_P (stmt) || unevaluated_p (code)) > > { > > *walk_subtrees = 0; > > return NULL_TREE; > > } > > + else if (in_immediate_context ()) > > + /* Don't clear *walk_subtrees here: we still need to walk the subtrees > > + of SIZEOF_EXPR and similar. */ > > + return NULL_TREE; > > tree decl = NULL_TREE; > > bool call_p = false; > > diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C > > new file mode 100644 > > index 00000000000..afba9946258 > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/template/sizeof18.C > > @@ -0,0 +1,8 @@ > > +// PR c++/112869 > > +// { dg-do compile } > > + > > +void min(long, long); > > +template void Binaryread(int &, T, unsigned long); > > +template <> void Binaryread(int &, float, unsigned long bytecount) { > > + min(bytecount, sizeof(int)); > > +} > > Hmm, actually, why does the above make a difference for this testcase? > > ... > > It seems that in_immediate_context always returns true in cp_fold_function > because current_binding_level->kind == sk_template_parms. That seems like a > problem. Maybe for cp_fold_immediate_r we only want to check > cp_unevaluated_operand or DECL_IMMEDIATE_CONTEXT (current_function_decl)? Yeah, I suppose that could become an issue. How about this, then? Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This test shows that we cannot clear *walk_subtrees in cp_fold_immediate_r when we're in_immediate_context, because that, as the comment says, affects cp_fold_r as well. Here we had an expression with min ((long int) VIEW_CONVERT_EXPR(bytecount), (long int) <<< Unknown tree: sizeof_expr (int) <<< error >>> >>>) as its sub-expression, and we never evaluated that into min ((long int) bytecount, 4) so the SIZEOF_EXPR leaked into the middle end. (There's still one *walk_subtrees = 0; in cp_fold_immediate_r, but that one should be OK.) PR c++/112869 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_immediate_r): Don't clear *walk_subtrees in an unevaluated operand or immediate function. gcc/testsuite/ChangeLog: * g++.dg/template/sizeof18.C: New test. --- gcc/cp/cp-gimplify.cc | 8 +++++++- gcc/testsuite/g++.dg/template/sizeof18.C | 8 ++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/template/sizeof18.C base-commit: cd7d0b4cf789264cd75ab7df5df232dc58061ed7 diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc index c307e1b62db..413ebafbd1a 100644 --- a/gcc/cp/cp-gimplify.cc +++ b/gcc/cp/cp-gimplify.cc @@ -1179,11 +1179,17 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) /* No need to look into types or unevaluated operands. NB: This affects cp_fold_r as well. */ - if (TYPE_P (stmt) || unevaluated_p (code) || in_immediate_context ()) + if (TYPE_P (stmt) || unevaluated_p (code)) { *walk_subtrees = 0; return NULL_TREE; } + else if (cp_unevaluated_operand + || (current_function_decl + && DECL_IMMEDIATE_FUNCTION_P (current_function_decl))) + /* Don't clear *walk_subtrees here: we still need to walk the subtrees + of SIZEOF_EXPR and similar. */ + return NULL_TREE; tree decl = NULL_TREE; bool call_p = false; diff --git a/gcc/testsuite/g++.dg/template/sizeof18.C b/gcc/testsuite/g++.dg/template/sizeof18.C new file mode 100644 index 00000000000..afba9946258 --- /dev/null +++ b/gcc/testsuite/g++.dg/template/sizeof18.C @@ -0,0 +1,8 @@ +// PR c++/112869 +// { dg-do compile } + +void min(long, long); +template void Binaryread(int &, T, unsigned long); +template <> void Binaryread(int &, float, unsigned long bytecount) { + min(bytecount, sizeof(int)); +}