aboutsummaryrefslogtreecommitdiff
path: root/libjava/gnu/java
diff options
context:
space:
mode:
authorJeff Law <jlaw@ventanamicro.com>2025-04-18 12:19:30 -0600
committerJeff Law <jlaw@ventanamicro.com>2025-04-18 12:21:23 -0600
commit45a1038f3ca6ddceb8d159ccba6d99ed61951472 (patch)
treee696df4f328b8894b91d1bb4dc96b2cef962d1ba /libjava/gnu/java
parentb986ed16c2546674256b8c892541a8fdb6a97202 (diff)
downloadgcc-45a1038f3ca6ddceb8d159ccba6d99ed61951472.zip
gcc-45a1038f3ca6ddceb8d159ccba6d99ed61951472.tar.gz
gcc-45a1038f3ca6ddceb8d159ccba6d99ed61951472.tar.bz2
[RISC-V] Fix missed bext discovery
RISC-V has the ability to extract a single bit out of a register from a fixed or variable position. While looking at 502.gcc a little while ago I realize that we failed to use bext inside bitmap_bit_p for its return value. The core "problem" is that the RISC-V does not define SHIFT_COUNT_TRUNCATED (for good reasons). As a result the target is largely responsible for handling elimination of shift count/bit position masking. There's a follow-up patch I've been working on with an intern to improve detection of bext in more cases. This one stands independently though and is probably the most important of the missed cases. Will push to the trunk assuming pre-commit testing is green. It's already been through my tester as well as Ventana's internal testing. gcc * config/riscv/bitmanip.md (*bext<mode>_mask_pos): New pattern for extracting a single bit at masked bit position. gcc/testsuite * gcc.target/riscv/bext-ext-2.c: New test
Diffstat (limited to 'libjava/gnu/java')
0 files changed, 0 insertions, 0 deletions