diff options
author | Jakub Jelinek <jakub@redhat.com> | 2025-04-14 19:34:22 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@gcc.gnu.org> | 2025-04-14 19:34:22 +0200 |
commit | f96a54350afcf7f3c90d0ecb51d7683d826acc00 (patch) | |
tree | d6dbdac55917d567f523034fc9d9745a93ece505 /libjava/include/default-signal.h | |
parent | e0b57c75e6daa1664bea03ce96733bf1ebb38ced (diff) | |
download | gcc-f96a54350afcf7f3c90d0ecb51d7683d826acc00.zip gcc-f96a54350afcf7f3c90d0ecb51d7683d826acc00.tar.gz gcc-f96a54350afcf7f3c90d0ecb51d7683d826acc00.tar.bz2 |
expmed: Always use QImode for init_expmed set_zero_cost [PR119785]
This is a regression on some targets introduced I believe by r6-2055
which added mode argument to set_src_cost.
The problem here is that in the first iteration, mode is always QImode
and we get as -Os zero cost set_src_cost (const0_rtx, QImode, false).
But then we use the mode variable for iterating over int, partial int
and vector int modes, so for the second iteration we call set_src_cost
with mode which is at that time (machine_mode) (MAX_MODE_VECTOR_INT + 1).
In the x86 case that happens to be V2HFmode and we don't crash (and
compute the same 0 cost as we would for QImode).
But e.g. in the SPARC case (machine_mode) (MAX_MODE_VECTOR_INT + 1) is
MAX_MACHINE_MODE and that does all kinds of weird things especially
when doing ubsan bootstrap.
Fixed by always using QImode.
2025-04-14 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/119785
* expmed.cc (init_expmed): Always pass QImode rather than mode to
set_src_cost passed to set_zero_cost.
Diffstat (limited to 'libjava/include/default-signal.h')
0 files changed, 0 insertions, 0 deletions