https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119131
--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The trunk branch has been updated by Andrew Pinski <pins...@gcc.gnu.org>: https://gcc.gnu.org/g:0bbdffc5d4f723f6a41b713519b156ea46ce5fc8 commit r15-7974-g0bbdffc5d4f723f6a41b713519b156ea46ce5fc8 Author: Andrew Pinski <quic_apin...@quicinc.com> Date: Mon Mar 10 23:10:01 2025 -0700 aarch64: Fix DFP constants [PR119131] After r15-6660-g45d306a835cb3f865, in some cases DFP constants would cause an ICE. This is due to do a mismatch of a few things. The predicate of the move uses aarch64_valid_fp_move to say if the constant is valid or not. But after reload/LRA when can_create_pseudo_p returns false; aarch64_valid_fp_move would return false for constants that were valid for the constraints of the instruction. A strictor predicate compared to the constraint is wrong. In this case `Uvi` is the constraint while aarch64_valid_fp_move allows it via aarch64_can_const_movi_rtx_p for !DECIMAL_FLOAT_MODE_P, there is no such check for DECIMAL_FLOAT_MODE_P. The fix is to remove the check !DECIMAL_FLOAT_MODE_P in aarch64_valid_fp_move and in the define_expand. As now the predicate allows a superset of what is allowed by the constraints. aarch64_float_const_representable_p should be rejecting DFP modes as they can't be used with instructions like `mov s0, 1.0`. Changes since v1: * v2: Add check to aarch64_float_const_representable_p for DFP. Built and tested on aarch64-linux-gnu with no regressions. PR target/119131 gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_valid_fp_move): Remove check for !DECIMAL_FLOAT_MODE_P. (aarch64_float_const_representable_p): Reject decimal floating modes. * config/aarch64/aarch64.md (mov<mode>): Likewise. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr119131-1.c: New test. Signed-off-by: Andrew Pinski <quic_apin...@quicinc.com>
