From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0740A3857821; Tue, 25 Aug 2020 05:18:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0740A3857821 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1598332739; bh=iAqWEpHpFDyJeIujl+Ifozwn3I5qJrsfrejgZo4krpM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jUkahDPqXyGAAWzoXnWvGAf+LYxpkgHisFfnVBUiZXBvPaVc7DaFbBQkSlTjIteVh SC+jaVVFkM5WQNexbeBdwmONoNkcJHCCpfnljwkC5Kifo+f8+/3bTRNLYyyf9lHQjg MPUKc/KPE0wQ128k4VEuWAa2eC9C5l162NPFv7NE= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/95450] [10/11 regression] Wrong long double folding Date: Tue, 25 Aug 2020 05:18:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.1.0 X-Bugzilla-Keywords: wrong-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: 10.3 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, 25 Aug 2020 05:18:59 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95450 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f2f79df19fbfaa1c4be313c2f2b5ce04646433e commit r11-2830-g9f2f79df19fbfaa1c4be313c2f2b5ce04646433e Author: Jakub Jelinek Date: Tue Aug 25 07:17:10 2020 +0200 gimple-fold: Don't optimize wierdo floating point value reads [PR95450] My patch to introduce native_encode_initializer to fold_ctor_reference apparently broke gnulib/m4 on powerpc64. There it uses a const union with two doubles and corresponding IBM doub= le double long double which actually is the largest normalizable long doub= le value (1 ulp higher than __LDBL_MAX__). The reason our __LDBL_MAX__ is smaller is that we internally treat the double double type as one having 106-bit precision, but it actually has a variable 53-bit to 2000-ish bit precision and for the 0x1.fffffffffffff7ffffffffffffc000p+1023L value gnulib uses we need 107-bit precision, therefore for GCC __LDBL_M= AX__ is 0x1.fffffffffffff7ffffffffffff8000p+1023L Before my changes, we wouldn't be able to fold_ctor_reference it and it worked fine at runtime, but with the change we are able to do that, but because it is larger than anything we can handle internally, we treat it weirdly. Similar problem would be if somebody creates this way valid, but much more than 106 bit precision e.g. 1.0 + 1.0e-768. Now, I think similar problem could happen e.g. on i?86/x86_64 with long double there, it also has some weird values in the format, e.g. the unnormals, pseudo infinities and various other magic values. This patch for floating point types (including vector and complex types with such elements) will try to encode the returned value again and punt if it has different memory representation from the original. Note, this is only done in the path where native_encode_initializer was used, in o= rder not to affect e.g. just reading an unpunned long double value; the value should be compiler generated in that case and thus should be properly representable. It will punt also if e.g. the padding bits are initiali= zed to non-zero values. I think the verification that what we encode can be interpreted back woiuld be only an internal consistency check (so perhaps for ENABLE_CHECKING if flag_checking only, but if both directions perform it, then we need to avoid mutual recursion). While for the other direction (interpretation), at least for the broken= by design long doubles we just know we can't represent in GCC all valid values. The other floating point formats are just theoretical case, perhaps we would canonicalize something to a value that wouldn't trigger invalid excepti= on when without canonicalization it would trigger it at runtime, so let's = just ignore those. Adjusted (so far untested) patch to do it in native_interpret_real inst= ead and limit it to the MODE_COMPOSITE_P cases, for which e.g. fold-const.c/simplify-rtx.c punts in several other places too because we just know we can't represent everything. E.g. /* Don't constant fold this floating point operation if the result may dependent upon the run-time rounding mode and flag_rounding_math is set, or if GCC's software emulation is unable to accurately represent the result. */ if ((flag_rounding_math || (MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizatio= ns)) && (inexact || !real_identical (&result, &value))) return NULL_TREE; Or perhaps guard it with MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations too, thus break what gnulib / m4 does with -ffast-math, but not normall= y? 2020-08-25 Jakub Jelinek PR target/95450 * fold-const.c (native_interpret_real): For MODE_COMPOSITE_P mo= des punt if the to be returned REAL_CST does not encode to the bitw= ise same representation. * gcc.target/powerpc/pr95450.c: New test.=