From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 17BB5389041B; Tue, 5 May 2020 17:54:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 17BB5389041B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1588701275; bh=4Ui6z4jbrZUf+593RR3wn/PmBLd/NgAl5Fa/eHKJrFQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dZciQGePu6ImZ4Mul7xEQ6uf/l211a8+ORD1XOEbwmiOgXWMfa42HaVNs7rIcWBxW ybH0ewFSkX44e9/mrQw21CYo5w9nHQ0xiwwj/+4w8YNl686g12Rra4rdHGJHgXBkgY DQp7To06WRNWr1Y2qgUmQFV6/Cgun9Hq6qWkP1Dk= From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/4210] should not warn in dead code Date: Tue, 05 May 2020 17:54:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 3.0.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: manu at gcc dot gnu.org 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: Tue, 05 May 2020 17:54:35 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D4210 --- Comment #35 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Niels M=C3=B6ller from comment #32) > 1. There's similar code in c_fully_fold_internal, in gcc/c/c-fold.c, close > to line 400. But that code does *not* emit any warning for the example > above, which surprised me a bit. Maybe that's only for the case that both > operands to the shift operator are constants? In general, front-ends should avoid emitting warnings while folding (simplifying) expressions. I think there is an open bug about this but I ca= nnot find it now. Of course, if the code is doing the same, it should be factored out into a common function. A good first patch to submit: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_e= asy_steps > 2. More importantly, if the warning is deleted from build_binary_op, we n= eed > to add a check for this case, and an appropriate warning, somewhere later= in > the compilation process. It has to be done after dead code is identified, > i.e., in a phase processing only non-dead code. And preferably as early as > possibly, when we're still working close to the parse-tree representation. > Is there such a place? Some other functions traversing the tree are > c_gimplify_expr (gcc/c-family/c-gimplify.c) and verify_tree > (gcc/c-family/c-common.c), are any of those called after elimination of d= ead > code? There is no such place. Dead code is identified in the middle-end and by th= en, there is no parse tree, only GIMPLE and SSA: https://gcc.gnu.org/onlinedocs/gccint/Passes.html#Passes Of course, you could add some kind of unreachable code pass to the FE, but = that would require a lot of work from your side. Clang has something similar that you could use as an inspiration:=20 https://github.com/llvm/llvm-project/blob/2946cd701067404b99c39fb29dc9c74bd= 7193eb3/clang/include/clang/Analysis/Analyses/ReachableCode.h > 3. Alternatively, if there's no place after dead code elimination where t= he > parse tree is still easily available, a different alternative could be to > leave the check for invalid shift counts in c-typeck.c, but instead of > emitting a warning, construct a special tree object representing an > expression with invalid/undefined behavior, and any meta data needed to e= mit > a warning or error to describe it? Then emission of the warning could be > postponed to later, say, close to the conversion to SSA form? That is still too early, since the dead code elimination happens after SSA.=