aboutsummaryrefslogtreecommitdiff
path: root/gcc/expr.cc
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2025-01-30 08:59:30 +0000
committerRichard Sandiford <richard.sandiford@arm.com>2025-01-30 08:59:30 +0000
commitf559ac896942ffe0e2315d0a4d8b8b517a16d607 (patch)
treecb3ee0d9a67e3e725f5ef30935f43c2ae6666c68 /gcc/expr.cc
parent15dba7dfba8b7800ac7b74213171e4df9bc32bb9 (diff)
downloadgcc-f559ac896942ffe0e2315d0a4d8b8b517a16d607.zip
gcc-f559ac896942ffe0e2315d0a4d8b8b517a16d607.tar.gz
gcc-f559ac896942ffe0e2315d0a4d8b8b517a16d607.tar.bz2
pair-fusion: Check for invalid use arrays [PR118320]
As Andrew says in the bugzilla comments, this PR is about a case where we tried to fuse two stores of x0, one in which x0 was defined and one in which it was undefined. merge_access_arrays failed on the conflict, but the failure wasn't caught. Normally the hazard detection code would fail if the instructions had incompatible uses. However, an undefined use doesn't impose many restrictions on movements. I think this is likely to be the only case where hazard detection isn't enough. As Andrew notes in bugzilla, it might be possible to allow uses of defined and undefined values to be merged to the defined value. But that sounds dangerous in the general case, as an rtl-ssa-level decision. We might run the risk of turning conditional UB into unconditional UB. And LLVM proves that the definition of "undef" isn't simple. gcc/ PR rtl-optimization/118320 * pair-fusion.cc (pair_fusion_bb_info::fuse_pair): Commonize the merge of input_uses and return early if it fails. gcc/testsuite/ PR rtl-optimization/118320 * g++.dg/torture/pr118320.C: New test.
Diffstat (limited to 'gcc/expr.cc')
0 files changed, 0 insertions, 0 deletions