From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 792BA3858401; Thu, 26 Jan 2023 16:28:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 792BA3858401 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674750514; bh=XBimqpLfdERwvz0ki/wgfd0nF2LgBhNPVTJqLDY9nLU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YKz7SYQoRIACuRsESut27lko4/l8/bn3qTUFD2rbzjZTESkSREYbCITgFPFoiICeL S+Yy40Aet49wQmbyf0G4iNWzNo3+L9jFxt8L/D6MfdFoC/xt1lIxxuibgl3T18SaE2 1/HPqfHq7KFcPJsmXsgQ9sx6Jctj5mYrYu06GvW0= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/108540] [13 Regression] Frange miscompilation of ruby since r13-3261 Date: Thu, 26 Jan 2023 16:28:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108540 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:09176201ec6a21c25b1edb07f19f83be22a123f9 commit r13-5397-g09176201ec6a21c25b1edb07f19f83be22a123f9 Author: Jakub Jelinek Date: Thu Jan 26 17:21:22 2023 +0100 frange: Fix up foperator_{,not_}equal::fold_range for signed zeros [PR108540] The following testcases are miscompiled, because threader sees some SSA_NAME would have -0.0 value and when computing range of SSA_NAME =3D= =3D 0.0 foperator_equal::fold_range sees one operand has [-0.0, -0.0] singleton range, the other [0.0, 0.0], they aren't equal (frange operator=3D=3D u= ses real_identical etc. rather than real comparisons) and so it thinks they compare unequal. With signed zeros -0.0 =3D=3D 0.0 is true though, so = we need to special case the both ranges singleton code. Similarly, if we see op1 range being say [-42.0, -0.0] and op2 range [0.0, 42.0], we'd check that the intersection of the two ranges is empty (that is correct) and fold the result of =3D=3D between such operands to [0, 0] which is wrong, because -0.0 =3D=3D 0.0, it needs to be [0, 1]. Similarly for foperator_not_equal::fold_range. 2023-01-26 Jakub Jelinek PR tree-optimization/108540 * range-op-float.cc (foperator_equal::fold_range): If both op1 = and op2 are singletons, use range_true even if op1 !=3D op2 when one range is [-0.0, -0.0] and another [0.0, 0.0]. Similar= ly, even if intersection of the ranges is empty and one has zero low bound and another zero high bound, use range_true_and_false rather than range_false. (foperator_not_equal::fold_range): If both op1 and op2 are singletons, use range_false even if op1 !=3D op2 when one range is [-0.0, -0.0] and another [0.0, 0.0]. Similar= ly, even if intersection of the ranges is empty and one has zero low bound and another zero high bound, use range_true_and_false rather than range_true. * gcc.c-torture/execute/ieee/pr108540-1.c: New test. * gcc.c-torture/execute/ieee/pr108540-2.c: New test.=