diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2023-12-05 13:17:57 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2023-12-05 13:17:57 +0100 |
| commit | e0786ca9a18c50ad08c40936b228e325193664b8 (patch) | |
| tree | b437d5c537622dc1064814efa98725bdef3e82a9 /gcc/function-tests.cc | |
| parent | c1c267dfcdccd53af0d2b2c945794ab3b0d8683f (diff) | |
| download | gcc-e0786ca9a18c50ad08c40936b228e325193664b8.zip gcc-e0786ca9a18c50ad08c40936b228e325193664b8.tar.gz gcc-e0786ca9a18c50ad08c40936b228e325193664b8.tar.bz2 | |
i386: Fix -fcf-protection -Os ICE due to movabsq peephole2 [PR112845]
The following testcase ICEs in the movabsq $(i32 << shift), r64 peephole2
I've added a while back to use smaller code than movabsq if possible.
If i32 is 0xfa1e0ff3 and shift is not divisible by 8, then it creates
an invalid insn (as 0xfa1e0ff3 CONST_INT is not allowed as
x86_64_immediate_operand nor x86_64_zext_immediate_operand), the peephole2
even triggers on it again and again (this time with shift 0) until it gives
up.
The following patch fixes that. As ix86_endbr_immediate_operand needs a
CONST_INT and it is hopefully rare, I chose to use FAIL rather than handling
it in the condition (where I'd probably need to call ctz_hwi again etc.).
2023-12-05 Jakub Jelinek <jakub@redhat.com>
PR target/112845
* config/i386/i386.md (movabsq $(i32 << shift), r64 peephole2): FAIL
if the new immediate is ix86_endbr_immediate_operand.
Diffstat (limited to 'gcc/function-tests.cc')
0 files changed, 0 insertions, 0 deletions