From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F34B63858C52; Fri, 3 Feb 2023 12:46:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F34B63858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675428393; bh=2dsM0kRg9vSfOE06H95KO9NRL4PtTwYxVKpdZ7yrafs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=J8PCn6Ie7xpd17dW0pksHXkXOms/gvNDwa7DL1KzXzgaY1bQHT5b+m116JyJFaDuc DAgHtSZbRILeF8ZVVk2yAKR5oryPOrBjH1W54iKH4SXgIxqKce4RwHMZn7ReYz6Jxx oocd0fW4hr1aaNcswQ8LnKd5GSsvc27a4AGKkMLc= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef Date: Fri, 03 Feb 2023 12:46:32 +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: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned 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=3D108647 --- Comment #5 from Aldy Hernandez --- > Perhaps just adding if (op2.undefined_p ()) return false; above most of t= he > switch (get_bool_state (r, lhs, type)) lines (in methods that refer to op= 2; > and similarly for op1) for the comparison operators. This feels like the right approach. We also do something similar in some of the binary operators. For example, plus/minus_expr do: if (lhs.undefined_p ()) return false; For this testcase we have: [0,0] =3D UNDEFINED < op2 I don't think we can determine anything for op2 in this situation, so the r= ight thing would be to return false, which amounts to returning VARYING. The binary operators would also have to handle operators of undefined, but those seem to all have gates on singleton_p() or go through the fold_range() routine for the inverse operation, so they'd be handled correctly. So yeah, it looks like just handling the op[12]_range operators above the get_bool_state would do the trick. Hmmm, it seems like there are 2 operators that have possible problematic handling of op2.undefined_p(): 1. operator_cast::op1_range (irange &r, tree type, The assert looks at the op2 type. That will ICE with an UNDEFINED. The truncating_cast_p path will also look at op2's type blindly. 2. operator_bitwise_xor::op1_range Imagine: [0,0] =3D x ^ UNDEFINED op1_range won't ICE, but it will do: case BRS_FALSE: r =3D op2; I don't think we know anything about x in this case. Though if, op2 is UNDEFINED, I guess it wouldn't hurt to assume op1 is also UNDEFINED. Also earlier in the function, for: UNDEFINED =3D x ^ op2 will return x =3D UNDEFINED for any op2.=20=20 So at least #1 would also have to be handled because it could ICE. Also, range-op-float.cc needs the same treatment prior all the get_bool_sta= te calls. As you mention, another alternative would be to always call empty_range_varying, as we're doing for abs::op[12]_range: if (empty_range_varying (r, type, lhs, op2)) return true; Thoughts? Andrew? Hmmm, I wonder why we haven't tripped over this scenario in past releases (= LHS being defined, but op2 being UNDEFINED).=