https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
--- Comment #10 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:2801f23fb82a5ef51c8b460a500786797943e1e9 commit r12-7240-g2801f23fb82a5ef51c8b460a500786797943e1e9 Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Feb 15 12:11:31 2022 +0100 fold, simplify-rtx: Punt on non-representable floating point constants [PR104522] For IBM double double I've added in PR95450 and PR99648 verification that when we at the tree/GIMPLE or RTL level interpret target bytes as a REAL_CST or CONST_DOUBLE constant, we try to encode it back to target bytes and verify it is the same. This is because our real.c support isn't able to represent all valid values of IBM double double which has variable precision. In PR104522, it has been noted that we have similar problem with the Intel/Motorola extended XFmode formats, our internal representation isn't able to record pseudo denormals, pseudo infinities, pseudo NaNs and unnormal values. So, the following patch is an attempt to extend that verification to all floats. Unfortunately, it wasn't that straightforward, because the __builtin_clear_padding code exactly for the XFmode long doubles needs to discover what bits are padding and does that by interpreting memory of all 1s. That is actually a valid supported value, a qNaN with negative sign with all mantissa bits set, but the verification includes also the padding bits (exactly what __builtin_clear_padding wants to figure out) and so fails the comparison check and so we ICE. The patch fixes that case by moving that verification from native_interpret_real to its caller, so that clear_padding_type can call native_interpret_real and avoid that extra check. With this, the only thing that regresses in the testsuite is +FAIL: gcc.target/i386/auto-init-4.c scan-assembler-times long\\t-16843010 5 because it decides to use a pattern that has non-zero bits in the padding bits of the long double, so the simplify-rtx.cc change prevents folding a SUBREG into a constant. We emit (the testcase is -O0 but we emit worse code at all opt levels) something like: movabsq $-72340172838076674, %rax movabsq $-72340172838076674, %rdx movq %rax, -48(%rbp) movq %rdx, -40(%rbp) fldt -48(%rbp) fstpt -32(%rbp) instead of fldt .LC2(%rip) fstpt -32(%rbp) ... .LC2: .long -16843010 .long -16843010 .long 65278 .long 0 Note, neither of those sequences actually stores the padding bits, fstpt simply doesn't touch them. For vars with clear_padding_real_needs_padding_p types that are allocated to memory at expansion time, I'd say much better would be to do the stores using integral modes rather than XFmode, so do that: movabsq $-72340172838076674, %rax movq %rax, -32(%rbp) movq %rax, -24(%rbp) directly. That is the only way to ensure the padding bits are initialized (or expand __builtin_clear_padding, but then you initialize separately the value bits and padding bits). 2022-02-15 Jakub Jelinek <ja...@redhat.com> PR middle-end/104522 * fold-const.h (native_interpret_real): Declare. * fold-const.cc (native_interpret_real): No longer static. Don't perform MODE_COMPOSITE_P verification here. (native_interpret_expr) <case REAL_TYPE>: But perform it here instead for all modes. * gimple-fold.cc (clear_padding_type): Call native_interpret_real instead of native_interpret_expr. * simplify-rtx.cc (simplify_immed_subreg): Perform the native_encode_rtx and comparison verification for all FLOAT_MODE_P modes, not just MODE_COMPOSITE_P. * gcc.dg/pr104522.c: New test.
