public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails. Date: Thu, 08 Dec 2022 09:36:53 +0000 [thread overview] Message-ID: <bug-107967-4-UhFwPUnzy3@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-107967-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967 --- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:2f187e9893916796992b60b278e743ec865f7418 commit r13-4549-g2f187e9893916796992b60b278e743ec865f7418 Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Dec 8 10:34:26 2022 +0100 range-op-float: Fix up frange_arithmetic [PR107967] The addition of PLUS/MINUS/MULT/RDIV_EXPR frange handlers causes miscompilation of some of the libm routines, resulting in lots of glibc test failures. A part of them is purely PR107608 fold-overflow-1.c etc. issues, say when the code does return -0.5 / 0.0; and expects division by zero to be emitted, but we propagate -Inf and avoid the operation. But there are also various tests where we end up with different computed value from the expected ones. All those cases are like: is: inf inf should be: 1.18973149535723176502e+4932 0xf.fffffffffffffff0p+16380 is: inf inf should be: 1.18973149535723176508575932662800701e+4932 0x1.ffffffffffffffffffffffffffffp+16383 is: inf inf should be: 1.7976931348623157e+308 0x1.fffffffffffffp+1023 is: inf inf should be: 3.40282346e+38 0x1.fffffep+127 and the corresponding source looks like: static const double huge = 1.0e+300; double whatever (...) { ... return huge * huge; ... } which for rounding to nearest or +inf should and does return +inf, but for rounding to -inf or 0 should instead return nextafter (inf, -inf); The rules IEEE754 has are that operations on +-Inf operands are exact and produce +-Inf (except for the invalid ones that produce NaN) regardless of rounding mode, while overflows: "a) roundTiesToEven and roundTiesToAway carry all overflows to â with the sign of the intermediate result. b) roundTowardZero carries all overflows to the formatâs largest finite number with the sign of the intermediate result. c) roundTowardNegative carries positive overflows to the formatâs largest finite number, and carries negative overflows to ââ. d) roundTowardPositive carries negative overflows to the formatâs most negative finite number, and carries positive overflows to +â." The behavior around overflows to -Inf or nextafter (-inf, inf) was actually handled correctly, we'd construct [-INF, -MAX] ranges in those cases because !real_less (&value, &result) in that case - value is finite but larger in magnitude than what the format can represent (but GCC internal's format can), while result is -INF in that case. But for the overflows to +Inf or nextafter (inf, -inf) was handled incorrectly, it tested real_less (&result, &value) rather than !real_less (&result, &value), the former test is true when already the rounding value -> result rounded down and in that case we shouldn't round again, we should round down when it didn't. So, in theory this could be fixed just by adding one ! character, - if ((mode_composite || (real_isneg (&inf) ? real_less (&result, &value) + if ((mode_composite || (real_isneg (&inf) ? !real_less (&result, &value) : !real_less (&value, &result))) but the following patch goes further. The distance between nextafter (inf, -inf) and inf is large (infinite) and expressions like 1.0e+300 * 1.0e+300 always produce +inf in round to nearest mode by far, so I think having low bound of nextafter (inf, -inf) in that case is unnecessary. But if it isn't multiplication but say addition and we are inexact and very close to the boundary between rounding to nearest maximum representable vs. rounding to nearest +inf, still using [MAX, +INF] etc. ranges seems safer because we don't know exactly what we lost in the inexact computation. The following patch implements that. 2022-12-08 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/107967 * range-op-float.cc (frange_arithmetic): Fix a thinko - if inf is negative, use nextafter if !real_less (&result, &value) rather than if real_less (&result, &value). If result is +-INF while value is finite and -fno-rounding-math, don't do rounding if !inexact or if result is significantly above max representable value or below min representable value. * gcc.dg/pr107967-1.c: New test. * gcc.dg/pr107967-2.c: New test. * gcc.dg/pr107967-3.c: New test.
next prev parent reply other threads:[~2022-12-08 9:37 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-05 2:51 [Bug c/107967] New: The gcc commit 2f7f9edd28d " caiyinyu at loongson dot cn 2022-12-05 8:24 ` [Bug tree-optimization/107967] " rguenth at gcc dot gnu.org 2022-12-05 9:08 ` caiyinyu at loongson dot cn 2022-12-05 9:56 ` [Bug tree-optimization/107967] [13 regression] " pinskia at gcc dot gnu.org 2022-12-05 10:35 ` [Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 " jakub at gcc dot gnu.org 2022-12-05 10:55 ` aldyh at gcc dot gnu.org 2022-12-05 14:29 ` marxin at gcc dot gnu.org 2022-12-05 16:40 ` jakub at gcc dot gnu.org 2022-12-06 1:32 ` caiyinyu at loongson dot cn 2022-12-06 15:59 ` jakub at gcc dot gnu.org 2022-12-06 17:16 ` jakub at gcc dot gnu.org 2022-12-06 20:06 ` jakub at gcc dot gnu.org 2022-12-07 1:34 ` caiyinyu at loongson dot cn 2022-12-07 16:59 ` amacleod at redhat dot com 2022-12-08 9:36 ` cvs-commit at gcc dot gnu.org [this message] 2022-12-08 10:24 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-107967-4-UhFwPUnzy3@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).