From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7CAF4388A414; Mon, 4 Jan 2021 15:34:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7CAF4388A414 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range Date: Mon, 04 Jan 2021 15:34:52 +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: 9.2.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com 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: --- 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: Mon, 04 Jan 2021 15:34:52 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94021 --- Comment #9 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #6) > CCing Andrew and Aldy to see what the ranger does or can do, talking about > I mean, if we have: > h_1 =3D x_2 / 3600; > if (x_2 <=3D -3599 && x_2 <=3D 89999) > use (h_1); > figure out that h_1 is set to x_2 / 3600 and even when that > SSA_NAME_DEF_STMT is not in a guarded block, its use is in one and so from > the [-3599, 89999] range of x_2 at the point of use derive that h_1 there= is > [0, 24]? > Surely if it is like: > if (x_2 <=3D -3599 && x_2 <=3D 89999) > { > h_1 =3D x_2 / 3600; > use (h_1); > } > I'd expect it to handle it that way. Certainly we get the latter case. The earlier case is currently... inconsistent. Something I hope to address in the next release. if we have precisely: h_1 =3D x_2 / 3600; if (x_2 <=3D -3599 && x_2 <=3D 89999) use (h_1); and if that is calculated in such a way that all of the conditions are evaluated in a single basic block, then the GORI engine well mark h1 and x_2 both as exports and the evaluator will calculate the desired value for h_1. Once we start to pull them further apart, the current implementation loses = the ability to recalculate h_1 when we get new ranges for x_2. I have plans to segregate the def chains from the export lists in blocks, a= nd allow for greater ability to recalculate things like this. When I look at #c4 in EVRP, I see: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D : # x_10 =3D PHI h_15 =3D x_10 / 3600; _1 =3D x_10 % 3600; m_16 =3D _1 / 60; h.0_2 =3D (unsigned int) h_15; _3 =3D h.0_2 > 23; _5 =3D _3; if (_5 !=3D 0) goto ; [INV] else goto ; [INV] _1 : int [0, 3599] h.0_2 : unsigned int [0, 596523] x_10 : int [0, +INF] h_15 : int [0, 596523] m_16 : int [0, 59] 4->6 (T) h.0_2 : unsigned int [0, 596523] 4->6 (T) _5 : _Bool [1, 1] 4->6 (T) x_10 : int [0, +INF] 4->6 (T) h_15 : int [0, 596523] 4->5 (F) h.0_2 : unsigned int [0, 596523] 4->5 (F) _5 : _Bool [0, 0] 4->5 (F) x_10 : int [0, +INF] 4->5 (F) h_15 : int [0, 596523] and then later on: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 8 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D x_10 int [0, +INF] : if (x_10 <=3D 89999) goto ; [INV] else goto ; [INV] 8->9 (T) x_10 : int [0, 89999] 8->10 (F) x_10 : int [90000, +INF] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 9 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D : __builtin_snprintf (&a, 8, "%s%02i%02i", "+", h_15, m_16); The defchains already indicate that h_15 is dependant on the value of x_10,= and I am hoping to enable recalculation of h_15 when a dependant range has changed.. and not just when they are exported from the same block. so in this case, when we ask for the range of h_15 in BB_9, we should be a= ble to see that x_10 has a range of int [0, 89999] and trigger a recalculation = of h_15 using "current" values. and come up with h_15 =3D [0,24]=20 The pieces are all there, but they need to be assembled in a non time consu= ming way :-) It is on the radar for next release.=