From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24829 invoked by alias); 12 Mar 2019 20:57:06 -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 24821 invoked by uid 89); 12 Mar 2019 20:57:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL autolearn=no version=3.3.1 spammy=H*Ad:D*no, HX-Languages-Length:2438, activated, H*MI:sk:2019031 X-HELO: asav22.altibox.net Received: from asav22.altibox.net (HELO asav22.altibox.net) (109.247.116.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Mar 2019 20:57:02 +0000 Received: from mail.jansenbrown.no (unknown [51.174.108.167]) by asav22.altibox.net (Postfix) with ESMTP id 60FE620088 for ; Tue, 12 Mar 2019 21:57:00 +0100 (CET) Received: from [192.168.4.243] (unicorn.lan [192.168.4.243]) by mail.jansenbrown.no (Postfix) with ESMTPSA id 0E65C19A8FB for ; Tue, 12 Mar 2019 21:57:00 +0100 (CET) Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning 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> From: David Brown Message-ID: Date: Tue, 12 Mar 2019 20:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190312154013.GA9898@cventin.lip.ens-lyon.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=ecATgYMH c=1 sm=1 tr=0 a=U0L3DYRvxOwaPRbtiaGbog==:117 a=U0L3DYRvxOwaPRbtiaGbog==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=NTGMnVQrEZIA:10 a=2Yu4Pk6J0pqpg6PBiH0A:9 a=QEXdDO2ut3YA:10 X-SW-Source: 2019-03/txt/msg00102.txt.bz2 On 12/03/2019 16:40, Vincent Lefevre wrote: > 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). > 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. (The warning here would be on the function "test" which calls the function with the shift, not on that function itself - since it is only when used in "test" that the compiler can see that there is undefined behaviour.)