diff options
author | Maciej W. Rozycki <macro@orcam.me.uk> | 2025-04-19 14:10:25 +0100 |
---|---|---|
committer | Maciej W. Rozycki <macro@orcam.me.uk> | 2025-04-19 14:10:25 +0100 |
commit | 1dd769b3d0d9251649dcb645d7ed6c4ba2202306 (patch) | |
tree | 9feb33d0559566298354906a88ba92424398f597 /libjava/javax/swing/plaf/basic/BasicDefaults.java | |
parent | f9ea46d946887a05d7ecbca5aeeb99fd868f6e70 (diff) | |
download | gcc-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