From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3F0913858D20; Tue, 15 Feb 2022 11:12:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F0913858D20 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double Date: Tue, 15 Feb 2022 11:12:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2022 11:12:32 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104522 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2801f23fb82a5ef51c8b460a500786797943e1e9 commit r12-7240-g2801f23fb82a5ef51c8b460a500786797943e1e9 Author: Jakub Jelinek 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 th= at 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 va= lues 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-16843= 010 5 because it decides to use a pattern that has non-zero bits in the paddi= ng 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 wor= se 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 allocat= ed to memory at expansion time, I'd say much better would be to do the sto= res 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 initiali= zed (or expand __builtin_clear_padding, but then you initialize separately = the value bits and padding bits). 2022-02-15 Jakub Jelinek 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) : But perform it here instead for all modes. * gimple-fold.cc (clear_padding_type): Call native_interpret_re= al 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.=