From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8BAB33858404; Tue, 10 Jan 2023 14:25:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8BAB33858404 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1673360731; bh=pCV0aEVTBWz8dXaOg1C38l3qH+Ozy58ntKR4Iwj/kSU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FXOcMDOpMjtgJ9N+QbiavMXib8avf2muWAPUv9kxHCg1RBRlKT0moXCoMtgL8YdGY YfUMeDhFSq4BoFPK9caH6WAu9rHrK0E5h2bIO4AV5zb3BL1xe8QNAmudMO+IXZzktb /8PWrcsQ7SC7uVh6atWVQP3bmz/G8X6C6MqdyEZ4= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c Date: Tue, 10 Jan 2023 14:25:30 +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: missed-optimization, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com 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=3D107608 --- Comment #21 from Andrew Macleod --- (In reply to Richard Biener from comment #13) > Yes, the fact that ranger doesn't operate as a usual propagator with a > lattice > makes things very difficult here. Note that my comment referred to code > optimality, not correctness. >=20 > > It really looks like the problem here is DCE (and the gimplifier as you > > point out in comment #2), which is removing a needed statement. Can't = this > > be fixed there? >=20 > Sure it can, but the expense is that we'd do constant folding all the way > down and not remove dead code which will result in _tons_ of unnecessary > constant pool entries and loads. >=20 I think I'm missing something, or not understanding what you are saying. Why is the propagation or lack of lattice a problem? Its DCE that is remo= ving that potentially trapping stmt because its no longer used in the IL? THe change would be to not kill off dead statements that may trap? I guess this may leave a bunch of feeding statements that are not dead.. but I fail to s= ee how thats different than not propagating and then not being able to delete those stmts either?=20=20 > The issue is also that -ftrapping-math is default on so we'd have to > do this by default. Ugh. >=20 > Note that the constant folding routines generally refrain from folding > when that loses exceptions, it's just ranger when producing singleton > ranges and propagating from them that doesn't adhere to that implicit rul= e. I'm also not sure what this means. I don't think ranger itself propagates singleton constants.. VRP is still using the substitute_and_fold engine, so= any folding/propagation is still going through the same mechanisms we always did when a singleton result is produced. We just produce more of them now, especially with floats. I don't think ranger is doing anything different t= han VRP ever did regarding propagation. Its possible GCCs infrastructure for dealing with float propagation isn't mature enough perhaps?=