https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112679
--- Comment #2 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:31669ec1d01c93fb0a63a7053ad314c17fa5a416 commit r14-5818-g31669ec1d01c93fb0a63a7053ad314c17fa5a416 Author: Jakub Jelinek <ja...@redhat.com> Date: Fri Nov 24 11:30:30 2023 +0100 lower-bitint: Lower FLOAT_EXPR from BITINT_TYPE INTEGER_CST [PR112679] The bitint lowering pass only does something if it sees BITINT_TYPE (medium, large, huge) SSA_NAMEs. In the past I've already ran into one special case where the above doesn't work well, if there is a store of medium/large/huge BITINT_TYPE INTEGER_CST into memory, there might not be any BITINT_TYPE SSA_NAMEs in the function, yet we need to lower. This has been solved by also checking for SSA_NAME_IS_VIRTUAL_OPERAND if at the vdef there isn't such a store (the whole intent is make the pass as cheap as possible in the currently very likely case that the IL doesn't have any BITINT_TYPEs at all). And the following testcase shows a similar problem. With -frounding-math we don't fold some of FLOAT_EXPRs with INTEGER_CST operands, and if those INTEGER_CSTs are medium/large/huge BITINT_TYPEs, we need to either cast the INTEGER_CST to corresponding INTEGER_TYPE (for medium) or lower to internal fn call which is later turned into libgcc call (for large/huge). The following patch does that, but of course admittedly this discovery of stores and FLOAT_EXPRs means we already look through quite a few SSA_NAME_DEF_STMTs even when BITINT_TYPEs never appear. 2023-11-23 Jakub Jelinek <ja...@redhat.com> PR middle-end/112679 * gimple-lower-bitint.cc (gimple_lower_bitint): Also stop first loop on floating point SSA_NAME set in FLOAT_EXPR assignment from BITINT_TYPE INTEGER_CST. Set has_large_huge for those if that BITINT_TYPE is large or huge. Set kind to such FLOAT_EXPR assignment rhs1 BITINT_TYPE's kind. * gcc.dg/bitint-42.c: New test.
