From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98377 invoked by alias); 26 Mar 2019 22:51:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 98286 invoked by uid 89); 26 Mar 2019 22:51:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT autolearn=ham version=3.3.1 spammy=Blog, smarter, detect, wish X-HELO: joooj.vinc17.net Received: from joooj.vinc17.net (HELO joooj.vinc17.net) (155.133.131.76) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Mar 2019 22:51:31 +0000 Received: from smtp-zira.vinc17.net (2a02-8429-80cd-3101-328d-99ff-fe25-ad3f.rev.sfr.net [IPv6:2a02:8429:80cd:3101:328d:99ff:fe25:ad3f]) by joooj.vinc17.net (Postfix) with ESMTPSA id BF608B2; Tue, 26 Mar 2019 23:51:26 +0100 (CET) Received: by zira.vinc17.org (Postfix, from userid 1000) id 4E6A9C208A1; Tue, 26 Mar 2019 23:51:26 +0100 (CET) Date: Tue, 26 Mar 2019 22:51:00 -0000 From: Vincent Lefevre To: gcc@gcc.gnu.org Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning Message-ID: <20190326225126.GA18723@zira.vinc17.org> Mail-Followup-To: gcc@gcc.gnu.org References: <4af9e251-f4c3-a5a4-e33d-fb8750c87e36@redheads.de> <20190311091449.GB7611@tucnak> <9085342b-41a6-851c-28e3-08a40cc30103@redheads.de> <20190311112429.GA377@cventin.lip.ens-lyon.fr> <0474f7ad-1e8d-e545-ff36-1f5c122aabfd@westcontrol.com> <20190312154013.GA9898@cventin.lip.ens-lyon.fr> <20190313022539.GA28438@zira.vinc17.org> <5aeec750-d820-ce56-bd27-6271dc23ac4d@westcontrol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5aeec750-d820-ce56-bd27-6271dc23ac4d@westcontrol.com> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.11.4+135 (aae3e555) vl-114617 (2019-03-21) X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00225.txt.bz2 On 2019-03-13 11:18:02 +0100, David Brown wrote: > On 13/03/2019 03:25, Vincent Lefevre wrote: > > On 2019-03-12 21:56:59 +0100, David Brown wrote: > >> I disagree. To generate an unconditional error (rejecting the > >> program), the compiler would need such proof - such as by tracing > >> execution from main(). But to generate a warning activated > >> specifically by the user, there is no such requirement. It's fine > >> to give a warning based on the code written, rather than on code > >> that the compiler knows without doubt will be executed. > > > > There's already a bug about spurious warnings on shift counts: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 > > > > You can divide code into three groups (with the exact divisions varying > by compiler switches and version): > > 1. Code that the compiler knows for sure will run in every execution of > the program, generally because it can track the code flow from main(). > > 2. Code that the compiler knows will /not/ run, due to things like > constant propagation, inlining, etc. > > 3. Code that the compiler does not know if it will run or not. Actually more than the fact whether the code will be run or not, what is important is the concept of reachability. This will give: 1. Code that the compiler knows for sure will run under some conditions (e.g. particular values of inputs). 2. Code that the compiler knows will never run (what I called dead code). 3. Code for which the compile can't decide. > Code in group 1 here is usually quite small. Code in group 2 can be > large, especially with C++ header libraries, templates, etc. The > compiler will often eliminate such code and avoid generating any object > code. gcc used to have a warning for when it found "group 2" code and > eliminated it - that warning was removed as gcc got smarter, and the > false positives were overwhelming. > > Most code is in group 3. It depends on how the code is written. The programmer could try to avoid group 3 by giving hints to the compiler, e.g. with __builtin_unreachable(). I wish this were standardized in C. > I am arguing here that a warning like this should be applied to group 3 > code - you are suggesting it should only apply to group 1. No, I was just suggesting that the compiler should be smart enough to detect dead code (when possible). In the past, there was a similar issue with -Wmaybe-uninitialized, which was rather useless (too many false positives in complex code). Fortunetaly, this has improved a lot. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)