From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12222 invoked by alias); 12 Mar 2019 15:40:19 -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 11985 invoked by uid 89); 12 Mar 2019 15:40:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=sk:wshift, sk:wshift-, Lefevre, lefevre X-HELO: cventin.lip.ens-lyon.fr Received: from cventin.lip.ens-lyon.fr (HELO cventin.lip.ens-lyon.fr) (140.77.13.17) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Mar 2019 15:40:16 +0000 Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.92) (envelope-from ) id 1h3jVm-0002ib-01; Tue, 12 Mar 2019 16:40:14 +0100 Date: Tue, 12 Mar 2019 15:40:00 -0000 From: Vincent Lefevre To: gcc@gcc.gnu.org Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning Message-ID: <20190312154013.GA9898@cventin.lip.ens-lyon.fr> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0474f7ad-1e8d-e545-ff36-1f5c122aabfd@westcontrol.com> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.11.3+113 (67bdfa31) vl-114617 (2019-03-04) X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00096.txt.bz2 On 2019-03-11 13:51:21 +0100, David Brown wrote: > On 11/03/2019 12:24, Vincent Lefevre wrote: > > It already does by default: > > > > -Wshift-count-negative > > Warn if shift count is negative. This warning is enabled > > by default. > > > > -Wshift-count-overflow > > Warn if shift count >= width of type. This warning is > > enabled by default. > > > > Of course, if the compiler cannot guess that there will be such > > an issue, it will not emit the warning. You certainly don't want > > a warning for each non-trivial shift just because the compiler > > cannot know whether the constraint on the shift count will be > > satisfied. > > While the compiler clearly can't give a warning on calculated shifts > without massive amounts of false positives, it is able to give warnings > when there is a shift by a compile-time known constant value that is > invalid. In the case of the OP's test function, inlining and constant > propagation means that the shift value /is/ known to the compiler - it > uses it for optimisation (in this case, it uses the undefined behaviour > to "simplify" the calculations). > > Am I right in thinking that this is because the pass that checks the > shift sizes for warnings here comes before the relevant inlining or > constant propagation passes? And if so, would it be possible to change > the ordering here? To generate a warning, the compiler would also have to make sure that the inlined code with an out-of-range shift is actually not dead code. In practice, it may happen that constraints are not satisfied on some platforms, but the reason is that on such platforms the code will never be executed (this is code written to take care of other platforms). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)