From patchwork Thu Jul 15 08:03:21 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1505575 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces+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.a=rsa-sha256 header.s=default header.b=Le96CxNy; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4GQRhx70Lvz9sCD for ; Thu, 15 Jul 2021 18:04:01 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7E2423AA9822 for ; Thu, 15 Jul 2021 08:03:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7E2423AA9822 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1626336237; bh=q58l2SjqTjr4+aibaJSX9fjnNvDeMe8HEaUFdq4qr0M=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=Le96CxNyMGw0XCN5POEqIH+9MiIKgXINDxKXjPOS7FbDe/AL3i1N8Qh7l57ELn1m5 SpD+otZG3piXlOtaLDqyZ+2sA02Fz9YiNCkM08xNY8EC7crXHJ4bVz2FY2H2vwLlsr z7TNMs6RTakj79Qfbq4B0EduFja7OrUYTNGRr4u0= 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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 78EFE3861800 for ; Thu, 15 Jul 2021 08:03:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 78EFE3861800 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-269-qXC1sPDkNc6Exw3cla_ZQg-1; Thu, 15 Jul 2021 04:03:28 -0400 X-MC-Unique: qXC1sPDkNc6Exw3cla_ZQg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 34A795074C; Thu, 15 Jul 2021 08:03:27 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-143.ams2.redhat.com [10.36.112.143]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4E17A5D6AB; Thu, 15 Jul 2021 08:03:26 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 16F83Nsq2319643 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 10:03:23 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 16F83LPo2319642; Thu, 15 Jul 2021 10:03:21 +0200 Date: Thu, 15 Jul 2021 10:03:21 +0200 To: Richard Biener , "Joseph S. Myers" Subject: [PATCH] gimplify: Fix endless recursion on volatile empty type reads/writes [PR101437] Message-ID: <20210715080321.GY2380545@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" Hi! Andrew's recent change to optimize away during gimplification not just assignments of zero sized types, but also assignments of empty types, caused infinite recursion in the gimplifier. If such assignment is optimized away, we gimplify separately the to_p and from_p operands and throw away the result. When gimplifying the operand that is volatile, we run into the gimplifier code below, which has different handling for types with non-BLKmode mode, tries to gimplify those as vol.N = expr, and for BLKmode just throws those away. Zero sized types will always have BLKmode and so are fine, but for the non-BLKmode ones like struct S in the testcase, the vol.N = expr gimplification will reach again the gimplify_modify_expr code, see it is assignment of empty type and will gimplify again vol.N separately (non-volatile, so ok) and expr, on which it will recurse again. The following patch breaks that infinite recursion by ignoring bare volatile loads from empty types. If a volatile load or store for aggregates are supposed to be member-wise loads or stores, then there are no non-padding members in the empty types that should be copied and so it is probably ok. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2021-07-15 Jakub Jelinek PR middle-end/101437 * gimplify.c (gimplify_expr): Throw away volatile reads from empty types even if they have non-BLKmode TYPE_MODE. * gcc.c-torture/compile/pr101437.c: New test. Jakub --- gcc/gimplify.c.jj 2021-06-25 10:36:22.232019090 +0200 +++ gcc/gimplify.c 2021-07-14 13:24:28.860486677 +0200 @@ -15060,7 +15060,8 @@ gimplify_expr (tree *expr_p, gimple_seq *expr_p = NULL; } else if (COMPLETE_TYPE_P (TREE_TYPE (*expr_p)) - && TYPE_MODE (TREE_TYPE (*expr_p)) != BLKmode) + && TYPE_MODE (TREE_TYPE (*expr_p)) != BLKmode + && !is_empty_type (TREE_TYPE (*expr_p))) { /* Historically, the compiler has treated a bare reference to a non-BLKmode volatile lvalue as forcing a load. */ --- gcc/testsuite/gcc.c-torture/compile/pr101437.c.jj 2021-07-14 13:35:57.155100700 +0200 +++ gcc/testsuite/gcc.c-torture/compile/pr101437.c 2021-07-14 13:35:41.430314232 +0200 @@ -0,0 +1,29 @@ +/* PR middle-end/101437 */ + +struct S { int : 1; }; + +void +foo (volatile struct S *p) +{ + struct S s = {}; + *p = s; +} + +void +bar (volatile struct S *p) +{ + *p; +} + +void +baz (volatile struct S *p) +{ + struct S s; + s = *p; +} + +void +qux (volatile struct S *p, volatile struct S *q) +{ + *p = *q; +}