From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 97E42386EC77; Mon, 20 Apr 2020 09:06:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 97E42386EC77 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1587373588; bh=f8yiazCHJSRDWbJy0w53N6X+diuh6Tg4V9NJnHuUSJ4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RFkSxf9PQoXIHDablLf4ZMSgcg6mU08fMcNcmaNCm5gU4wTCFH0r1aEWUbyislD0z rin5ER7vwvkFl3M2YzZeG+4cRE9leEajJVxNNbmI+UsXJkjxk1qra+WyseXYv6XYrP oM/3Do847tfuHeOgLuc2kIy6DD6/lvb7IuZiJU+A= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce Date: Mon, 20 Apr 2020 09:06:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: diagnostic, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: jamborm at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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 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, 20 Apr 2020 09:06:28 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D93385 --- Comment #29 from Jakub Jelinek --- (In reply to rguenther@suse.de from comment #28) > On Fri, 17 Apr 2020, jakub at gcc dot gnu.org wrote: >=20 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D93385 > >=20 > > --- Comment #26 from Jakub Jelinek --- > > For debug stmts, it would be best if we could use those > > DEBUG D#Y s=3D> parm > > DEBUG var =3D> D#Y > > added in if (param_body_adjs && MAY_HAVE_DEBUG_BIND_STMTS). > > Though, if we remove already during the copy_bb by not actually creatin= g the > > stmt, I'm afraid that will mean the debug info is lost (debug stmts wil= l be > > reset), unless we for the lhs of to be dced stmts manually create debug > > temporaries and debug stmts when we remap_gimple_stmt those stmts (for > > SSA_NAMEs that are directly (or indirectly!) used in debug stmts). > > If we do what Martin was proposing instead, i.e. copy the stmts and the= n DCE > > them afterwards, it might work properly (perhaps only if we DCE them in= the > > right order). >=20 > It's true that copying everything and then DCEing is easier for debug > stmt generation. I didn't consider this. That also argues for not > remapping anything to error_mark_node. Of course this leaves us with > no automagic verification if we really DCEd everything required > (esp. his handling of call arguments looks expensive and odd to me). We could remap those to error_mark_node for -g0 and for -g to the DEBUG_EXPR_DECLs we'd create and then just during verification make sure we diagnose DEBUG_EXPR_DECLs in non-debug stmts (and error_mark_node). Though, I think even right now the debug side of things even without the DC= E is not perfect, we do create a bind to cover the optimized out parameters at t= he start of the function, but don't do this remapping of the SSA_NAME to that DEBUG_EXPR_DECL, which means that e.g. debug stmts that used to use that SSA_NAME in some expressions are reset. So, I think if Martin comes up with something that just doesn't handle the debug stmts for GCC10, I can try to improve the debug side later.=