https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104601
--- Comment #14 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d29a0b50687dc42e17dc4a4fe335afafefeada4e
commit r11-9718-gd29a0b50687dc42e17dc4a4fe335afafefeada4e
Author: Jakub Jelinek
Date: Thu Feb 24 15:29:02 2022 +0100
sccvn: Fix visit_reference_op_call value numbering of vdefs [PR104601]
The following testcase is miscompiled, because -fipa-pure-const discovers
that bar is const, but when sccvn during fre3 sees
# .MEM_140 = VDEF <.MEM_96>
*__pred$__d_43 = _50 (_49);
where _50 value numbers to , it value numbers .MEM_140 to
vuse_ssa_val (gimple_vuse (stmt)). For const/pure calls that return
a SSA_NAME (or don't have lhs) that is fine, those calls don't store
anything, but if the lhs is present and not an SSA_NAME, value numbering
the vdef to anything but itself means that e.g. walk_non_aliased_vuses
won't consider the call, but the call acts as a store to its lhs.
When it is ignored, sccvn will return whatever has been stored to the
lhs earlier.
I've bootstrapped/regtested an earlier version of this patch, which did the
if (!lhs && gimple_call_lhs (stmt))
changed |= set_ssa_val_to (vdef, vdef);
part before else if (vnresult->result_vdef), and that regressed
+FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo (" 1
+FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo2 (" 1
so this updated patch uses result_vdef there as before and only otherwise
(which I think must be the const/pure case) decides based on whether the
lhs is non-SSA_NAME.
2022-02-24 Jakub Jelinek
PR tree-optimization/104601
* tree-ssa-sccvn.c (visit_reference_op_call): For calls with
non-SSA_NAME lhs value number vdef to itself instead of e.g. the
vuse value number.
* g++.dg/torture/pr104601.C: New test.
(cherry picked from commit 9251b457eb8df912f2e8203d0ee8ab300c041520)
