[Bug tree-optimization/121493] Another missing Fre from a copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121493 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |16.0 Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/121493] Another missing Fre from a copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121493 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5294840e3c7bf9bd98016dec07f54ee8dc71714a commit r16-3156-g5294840e3c7bf9bd98016dec07f54ee8dc71714a Author: Richard Biener Date: Mon Aug 11 10:42:47 2025 +0200 tree-optimization/121493 - another missed VN with aggregate copy This is another case where opportunistically handling a first aggregate copy where we failed to match up the refs exactly (as we don't insert missing handling components) yields to a failure in the second aggregate copy that we visit. Add another fixup to deal with such situations, in-line with that present opportunistic handling. PR tree-optimization/121493 * tree-ssa-sccvn.cc (vn_reference_lookup_3): Opportunistically strip components with known offset. * gcc.dg/tree-ssa/ssa-fre-109.c: New testcase.
[Bug tree-optimization/121493] Another missing Fre from a copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121493
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2025-08-11
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
Confirmed. So what happens is that we do not handle inserting fake refs that
are missing here. For the first aggregate copy we thus run into
/* When the LHS is already at the outermost level simply
adjust for any offset difference. Further lookups
will fail when there's too gross of a type compatibility
issue. */
if (!found && j == 0)
{
extra_off = vr->operands[i].off - lhs_ops[j].off;
i--, j--;
but there's now a "gross type compatibility issue", we have
tt.t and tt.t with once a FIELD_DECL for struct s1 and once for int.
So when visiting the earlier aggregate copy tt.t = t but with the
lookup RHS of tt.t (with the int field) we go past the MEM_REFs which
match up exactly but then we fail to process further (we don't allow
for even more gross type compatibility issues).
One could argue that for components we can handle by offset we should
simply go ahead, hoping for the best. That helps in this case.
I will test this.
[Bug tree-optimization/121493] Another missing Fre from a copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121493 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
