diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2024-01-20 12:36:32 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2024-01-20 12:36:32 +0100 |
| commit | efc677f3e78abf02264e4a64c751b4ecdc918ec9 (patch) | |
| tree | fcc803a935710eaf871317d49f47152edf30ddd9 /gcc/fortran/parse.cc | |
| parent | 291e00e2d88a352f46cd539e3c5785982dc3fdd9 (diff) | |
| download | gcc-efc677f3e78abf02264e4a64c751b4ecdc918ec9.zip gcc-efc677f3e78abf02264e4a64c751b4ecdc918ec9.tar.gz gcc-efc677f3e78abf02264e4a64c751b4ecdc918ec9.tar.bz2 | |
lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]
The following patch ICEs because fre3 leaves around unfolded
_1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
statement and in handle_cast I was expecting just SSA_NAMEs for the
large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something
we can handle in that case exactly the same, as the handle_operand recursion
handles those.
Of course, maybe we should also try to fold_stmt such cases somewhere in
bitint lowering preparation.
2024-01-20 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113462
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast):
Handle rhs1 INTEGER_CST like SSA_NAME.
* gcc.dg/bitint-76.c: New test.
Diffstat (limited to 'gcc/fortran/parse.cc')
0 files changed, 0 insertions, 0 deletions