aboutsummaryrefslogtreecommitdiff
path: root/gcc/function.cc
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2024-11-09 11:42:30 +0100
committerJakub Jelinek <jakub@gcc.gnu.org>2024-11-09 11:42:30 +0100
commitfe908af7dfc95c22284baf544279743a3389d4de (patch)
tree2eea68be46fb5dba6771d7f90138fd70983798cb /gcc/function.cc
parent114abf075c1e28358173756042049c9992ae6572 (diff)
downloadgcc-fe908af7dfc95c22284baf544279743a3389d4de.zip
gcc-fe908af7dfc95c22284baf544279743a3389d4de.tar.gz
gcc-fe908af7dfc95c22284baf544279743a3389d4de.tar.bz2
trans-mem: Fix ICE caused by expand_assign_tm
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 --- 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. 2024-11-09 Jakub Jelinek <jakub@redhat.com> * 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.
Diffstat (limited to 'gcc/function.cc')
0 files changed, 0 insertions, 0 deletions