https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99648
--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:c0f772894b6b3cd8ed5c5dd09d0c7917f51cf70f commit r11-8146-gc0f772894b6b3cd8ed5c5dd09d0c7917f51cf70f Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Apr 13 09:41:20 2021 +0200 simplify-rtx: Punt on simplify_{,gen_}subreg to IBM double double if bits are lost [PR99648] Similarly to PR95450 done on GIMPLE, this patch punts if we try to simplify_{gen_,}subreg from some constant into the IBM double double IFmode (or sometimes TFmode) if the double double format wouldn't preserve the bits. Not all values are valid in IBM double double, e.g. the format requires that the upper double is the whole value rounded to double, and if in some cases such as in the pr71522.c testcase with -m32 -Os -mcpu=power7 some non-floating data is copied through long double variable, we can simplify a subreg into something that has different value. Fixed by punting if the planned simplify_immed_subreg result doesn't encode to bitwise identical values compared to what we were decoding. As for the simplify_gen_subreg change, I think it would be desirable to just avoid creating SUBREGs of constants on all targets and for all constants, if simplify_immed_subreg simplified, fine, otherwise punt, but as we are late in GCC11 development, the patch instead guards this behavior on MODE_COMPOSITE_P (outermode) - i.e. only conversions to powerpc{,64,64le} double double long double - and only for the cases where simplify_immed_subreg was called. 2021-04-13 Jakub Jelinek <ja...@redhat.com> PR target/99648 * simplify-rtx.c (simplify_immed_subreg): For MODE_COMPOSITE_P outermode, return NULL if the result doesn't encode back to the original byte sequence. (simplify_gen_subreg): Don't create SUBREGs from constants to MODE_COMPOSITE_P outermode.
