From patchwork Fri Nov 8 09:48:59 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 2008340 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=SEg7H/7H; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; 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 [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 ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4XlDgP5gCgz1xy0 for ; Fri, 8 Nov 2024 20:49:37 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A4F78385840C for ; Fri, 8 Nov 2024 09:49:35 +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.133.124]) by sourceware.org (Postfix) with ESMTP id 9FD613858D20 for ; Fri, 8 Nov 2024 09:49:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9FD613858D20 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 9FD613858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1731059358; cv=none; b=cs8QfzvXng1zxrQp2e/Lb7ogxWSMOBRqIHZyaqYC90Gud7w4TOYun0mm918wsp1GOuiwGPRn8aZ8D6XyeOZSMWZTzgKnSp1nEiynM5PuXpYWLSzO+w6z/SPwf4tfBX6knPdhXbPtEk8hVkE6b73gKnBNd0Pd2wu+R8M1xGkR5bs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1731059358; c=relaxed/simple; bh=q5TdVxVo5IVx01Uef8N/lItvcuS2fMa0V0zKBEc8dCo=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=NoRlMOjmpQs3T2Xjy8AYR9uHcUtBEiSxjJJq/ZFylYu01Zc4gNfp3GmlE0Ubg93ZD7w72/6CZ4uUeDT9v5vMIP44yeaFe/U2sPWJ+5GzgIZrnTe0CnCfnTcVb1XvtXNd2OsGy+Ox+DEZOyOQFUSS8ZoTdK278xKG3DkvPR6gCOM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1731059346; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=rdeO/XLPrisxxcAaBRbkXXaUc5Za7p8R0F3QGGC/ji8=; b=SEg7H/7HJyA6FrmGlS5qgC0AmA0G/uonaoYc+O39VBOYnPWcRHhXWuViLlj4bUKxUyqV44 /OmPWenjYhVQm+5dfbZvvd5YB+z5yTtkRwR2u95kBOsMbO1ddPlV5gzr8nnll+l6HZfRL0 DgXk/Zx97O7bYlZqzEQ4Xu2iwYHF4Cs= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-612-NbPdK5woPcuFfm6AD9GT7w-1; Fri, 08 Nov 2024 04:49:04 -0500 X-MC-Unique: NbPdK5woPcuFfm6AD9GT7w-1 X-Mimecast-MFC-AGG-ID: NbPdK5woPcuFfm6AD9GT7w Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 91C781955F3B; Fri, 8 Nov 2024 09:49:03 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.16]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 89D40195E480; Fri, 8 Nov 2024 09:49:02 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 4A89mxFu2796725 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 8 Nov 2024 10:48:59 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4A89mxe72796724; Fri, 8 Nov 2024 10:48:59 +0100 Date: Fri, 8 Nov 2024 10:48:59 +0100 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] trans-mem: Fix ICE caused by expand_assign_tm Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 1cA9-K8y9wVYQjMXSrf2E0u6TCVEyyk55DE_UclZlj4_1731059343 X-Mimecast-Originator: redhat.com Content-Disposition: inline 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: , Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org Hi! My https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668065.html patch regressed +FAIL: g++.dg/tm/pr45940-3.C -std=gnu++11 (internal compiler error: in create_tmp_var, at gimple-expr.cc:484) +FAIL: g++.dg/tm/pr45940-3.C -std=gnu++11 (test for excess errors) +FAIL: g++.dg/tm/pr45940-3.C -std=gnu++14 (internal compiler error: in create_tmp_var, at gimple-expr.cc:484) +FAIL: g++.dg/tm/pr45940-3.C -std=gnu++14 (test for excess errors) ... +FAIL: g++.dg/tm/pr45940-4.C -std=gnu++26 (internal compiler error: in create_tmp_var, at gimple-expr.cc:484) +FAIL: g++.dg/tm/pr45940-4.C -std=gnu++26 (test for excess errors) +FAIL: g++.dg/tm/pr45940-4.C -std=gnu++98 (internal compiler error: in create_tmp_var, at gimple-expr.cc:484) +FAIL: g++.dg/tm/pr45940-4.C -std=gnu++98 (test for excess errors) tests, but it turns out it is a preexisting bug. If I modify the pr45940-3.C testcase Jakub --- gcc/testsuite/g++.dg/tm/pr45940-3.C 2020-01-12 11:54:37.258400660 +0100 +++ gcc/testsuite/g++.dg/tm/pr45940-3.C 2024-11-08 10:35:11.918390743 +0100 @@ -16,6 +16,7 @@ class sp_counted_base { protected: int use_count_; // #shared + int a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, aa, ab, ac, ad, ae, af; public: __attribute__((transaction_safe)) virtual void dispose() = 0; // nothrow then it ICEs already on vanilla trunk. The problem is that expand_assign_tm just wants to force it into TM memcpy argument, if is_gimple_reg (reg), then it creates a temporary, stores the value there and takes temporary address, otherwise it takes address of rhs. That doesn't work if rhs is an empty CONSTRUCTOR with C++ non-POD type (TREE_ADDRESSABLE type), we ICE trying to create temporary, because we shouldn't be creating a temporary. Now before my patch with the CONSTRUCTOR only having a vtable pointer (64bit) and 32-bit field, we gimplified the zero initialization just as storing of 0s to the 2 fields, but as we are supposed to also clear padding bits, we now gimplify it as MEM[...] = {}; to make sure even the padding bits are cleared. With the adjusted testcase, we gimplified it even before as MEM[...] = {}; because it was simply too large and clearing everything looked beneficial. The following patch fixes this ICE by using TM memset, it is both wasteful to force zero constructor into a temporary just to TM memcpy it into the lhs, and in C++ cases like this invalid. Ok for trunk if it passes bootstrap/regtest? 2024-11-08 Jakub Jelinek * trans-mem.cc (expand_assign_tm): Don't take address of empty CONSTRUCTOR, instead use BUILT_IN_TM_MEMSET to clear lhs in that case. Formatting fixes. --- gcc/trans-mem.cc.jj 2024-10-25 10:00:29.527767013 +0200 +++ gcc/trans-mem.cc 2024-11-08 09:55:08.963557301 +0100 @@ -2442,26 +2442,33 @@ expand_assign_tm (struct tm_region *regi gcall = gimple_build_assign (rtmp, rhs); gsi_insert_before (gsi, gcall, GSI_SAME_STMT); } + else if (TREE_CODE (rhs) == CONSTRUCTOR + && CONSTRUCTOR_NELTS (rhs) == 0) + { + /* Don't take address of an empty CONSTRUCTOR, it might not + work for C++ non-POD constructors at all and otherwise + would be inefficient. Use tm memset to clear lhs. */ + gcc_assert (!load_p && store_p); + rhs_addr = integer_zero_node; + } else rhs_addr = gimplify_addr (gsi, rhs); // Choose the appropriate memory transfer function. - if (load_p && store_p) - { - // ??? Figure out if there's any possible overlap between - // the LHS and the RHS and if not, use MEMCPY. - copy_fn = builtin_decl_explicit (BUILT_IN_TM_MEMMOVE); - } + if (store_p + && TREE_CODE (rhs) == CONSTRUCTOR + && CONSTRUCTOR_NELTS (rhs) == 0) + copy_fn = builtin_decl_explicit (BUILT_IN_TM_MEMSET); + else if (load_p && store_p) + // ??? Figure out if there's any possible overlap between + // the LHS and the RHS and if not, use MEMCPY. + copy_fn = builtin_decl_explicit (BUILT_IN_TM_MEMMOVE); else if (load_p) - { - // Note that the store is non-transactional and cannot overlap. - copy_fn = builtin_decl_explicit (BUILT_IN_TM_MEMCPY_RTWN); - } + // Note that the store is non-transactional and cannot overlap. + copy_fn = builtin_decl_explicit (BUILT_IN_TM_MEMCPY_RTWN); else - { - // Note that the load is non-transactional and cannot overlap. - copy_fn = builtin_decl_explicit (BUILT_IN_TM_MEMCPY_RNWT); - } + // Note that the load is non-transactional and cannot overlap. + copy_fn = builtin_decl_explicit (BUILT_IN_TM_MEMCPY_RNWT); gcall = gimple_build_call (copy_fn, 3, lhs_addr, rhs_addr, TYPE_SIZE_UNIT (TREE_TYPE (lhs)));