From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98812 invoked by alias); 11 Mar 2019 09:14:57 -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 98059 invoked by uid 89); 11 Mar 2019 09:14:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=promoted, C11, singlediff, SingleDiff X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Mar 2019 09:14:56 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 35DA9C057F42; Mon, 11 Mar 2019 09:14:55 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-64.ams2.redhat.com [10.36.117.64]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D08475D705; Mon, 11 Mar 2019 09:14:54 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x2B9EpSg018004; Mon, 11 Mar 2019 10:14:52 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x2B9EneM018003; Mon, 11 Mar 2019 10:14:49 +0100 Date: Mon, 11 Mar 2019 09:14:00 -0000 From: Jakub Jelinek To: Moritz =?iso-8859-1?Q?Str=FCbe?= Cc: "gcc@gcc.gnu.org" , Nicolai Steinkamp Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning Message-ID: <20190311091449.GB7611@tucnak> Reply-To: Jakub Jelinek References: <4af9e251-f4c3-a5a4-e33d-fb8750c87e36@redheads.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4af9e251-f4c3-a5a4-e33d-fb8750c87e36@redheads.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00077.txt.bz2 On Mon, Mar 11, 2019 at 08:49:30AM +0000, Moritz Strübe wrote: > Considering that C11 6.5.7#3 ("If  the  value  of  the  right operand  > is  negative  or  is greater than or equal to the width of the promoted > left operand, the behavior is undefined.") is not very widely known, as > it "normally" just works, inverting the intent is quite unexpected. > > Is there any option that would have helped me with this? You could build with -fsanitize=undefined, that would tell you at runtime you have undefined behavior in your code (if the SingleDiff has bit ever 0x20 set). The fact that negative or >= bit precision shifts are UB is widely known, and even if it wouldn't, for the compiler all the UBs are just UBs, the compiler optimizes on the assumption that UB does not happen, so when it sees 32-bit int << (x & 32), it can assume x must be 0 at that point, anything else is UB. GCC has warnings for the simple cases, where one uses negative or too large constant shift, warning in cases like you have would be a false positive for many people, there is nothing wrong with that (if x & 32 always results in 0). Jakub