aboutsummaryrefslogtreecommitdiff
path: root/libjava/javax/swing/plaf/basic/BasicDefaults.java
diff options
context:
space:
mode:
authorMaciej W. Rozycki <macro@orcam.me.uk>2025-04-19 14:10:25 +0100
committerMaciej W. Rozycki <macro@orcam.me.uk>2025-04-19 14:10:25 +0100
commit1dd769b3d0d9251649dcb645d7ed6c4ba2202306 (patch)
tree9feb33d0559566298354906a88ba92424398f597 /libjava/javax/swing/plaf/basic/BasicDefaults.java
parentf9ea46d946887a05d7ecbca5aeeb99fd868f6e70 (diff)
downloadgcc-1dd769b3d0d9251649dcb645d7ed6c4ba2202306.zip
gcc-1dd769b3d0d9251649dcb645d7ed6c4ba2202306.tar.gz
gcc-1dd769b3d0d9251649dcb645d7ed6c4ba2202306.tar.bz2
Alpha: Fix base block alignment calculation regression
In determination of base block alignment we only examine a COMPONENT_REF tree node at hand without ever checking if its ultimate alignment has been reduced by the combined offset going back to the outermost object. Consequently cases have been observed where quadword accesses have been produced for a memory location referring a nested struct member only aligned to the longword boundary, causing emulation to trigger. Address this issue by recursing into COMPONENT_REF tree nodes until the outermost one has been reached, which is supposed to be a MEM_REF one, accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: Also use tree information to get base block alignment") regression. Bail out and refrain from using tree information for alignment if we end up at something different or we are unable to calculate the offset at any point. gcc/ * config/alpha/alpha.cc (alpha_get_mem_rtx_alignment_and_offset): Recurse into COMPONENT_REF nodes. gcc/testsuite/ * gcc.target/alpha/memcpy-nested-offset-long.c: New file. * gcc.target/alpha/memcpy-nested-offset-quad.c: New file.
Diffstat (limited to 'libjava/javax/swing/plaf/basic/BasicDefaults.java')
0 files changed, 0 insertions, 0 deletions