From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 25EC6389900F; Tue, 15 Nov 2022 16:26:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 25EC6389900F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668529576; bh=hqR2NvmH4CMzB+5n2BglkWSTgtQFJq5o2BGTCkBe64E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jqBxAAzdLVIMkPX1khBqRuKQ7lQ1fyWw/xPUsEidT7UMEvFHkvlsy+/uBWcX6Wv0o X0SdSzBfZR1mGw+nzRUQAs7iGtbMrQYbAvCC4Bdwkm4KN6T8gR8ZPLpLXGBYKQ2vu4 glQyaZpDBjEuFkDBoGfkvrdNL6RhOBtQSbrxuH0I= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int Date: Tue, 15 Nov 2022 16:26:14 +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: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh 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=3D107668 --- Comment #10 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #8) > While the patch passed bootstrap/regtest, I'm afraid it is not correct. >=20 > What we have is lhs =3D op1 * 0.0; with range of lhs [-0.0, 0.0] and rang= e of > op2 [0.0, 0.0] and we call fop_mult.op1_range to determine range of op1. > Now, if it would be HONOR_NANS, the division lhs / op2 aka [-0.0, 0.0] / > [0.0, 0.0] would compute NAN and float_binary_op_range_finish would take = the: > // If we get a known NAN from reverse op, it means either that > // the other operand was known NAN (in that case we know nothing), > // or the reverse operation introduced a known NAN. > // Say for lhs =3D op1 * op2 if lhs is [-0, +0] and op2 is too, > // 0 / 0 is known NAN. Just punt in that case. > // Or if lhs is a known NAN, we also don't know anything. > if (r.known_isnan () || lhs.known_isnan ()) > { > r.set_varying (type); > return true; > } > path. VARYING is the range we want in this case btw, because anything ti= mes > 0.0 > is 0.0 or -0.0 (well, if INF/NANs are honored, we could make it [-MAX, MA= X], > or > if honoring signed zeros and lhs range would be just [0.0, 0.0] or [-0.0, > -0.0] > or op2 one of these it could be even [-MAX, -0.0] or [0.0, MAX]. > But because NANs aren't honored and INFs neither, we get from [-0.0, 0.0]= / > [0.0, 0.0] division UNDEFINED range (NAN with NAN removed). > So, a safe fix would be to handle r.undefined_p () the same as r.known_is= nan > () or lhs.known_isnan () and if we want to eventually improve the > op[12]_range > calls for individual ops for some special cases, we can. >=20 > Aldy, thoughts on this? OMG, head hurts on this one. Yeah, op1 could have been anything so varying seems like the right thing to= do. I was curious if we were doing something in operator_div::op1_range for integers, but we haven't even thought that far :). OK for trunk btw.=