From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101817 invoked by alias); 27 Sep 2016 12:50:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 101802 invoked by uid 89); 27 Sep 2016 12:50:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Signal X-HELO: albireo.enyo.de Received: from albireo.enyo.de (HELO albireo.enyo.de) (5.158.152.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Sep 2016 12:49:58 +0000 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1borpX-0004t1-6t; Tue, 27 Sep 2016 14:49:51 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.84_2) (envelope-from ) id 1borpX-0004sF-1G; Tue, 27 Sep 2016 14:49:51 +0200 From: Florian Weimer To: Jason Merrill Cc: Bernd Edlinger , "gcc-patches\@gcc.gnu.org" , Jeff Law Subject: Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops References: Date: Tue, 27 Sep 2016 12:58:00 -0000 In-Reply-To: (Jason Merrill's message of "Tue, 27 Sep 2016 08:42:18 -0400") Message-ID: <87shslv769.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg01968.txt.bz2 * Jason Merrill: > On Sun, Sep 25, 2016 at 3:46 AM, Bernd Edlinger > wrote: >> This patch makes -Wint-in-bool-context warn on suspicious integer left >> shifts, when the integer is signed, which is most likely some kind of >> programming error, for instance using "<<" instead of "<". >> >> The warning is motivated by the fact, that an overflow on integer shift >> left is undefined behavior, even if gcc won't optimize the shift based >> on the undefined behavior. >> >> So in absence of undefined behavior the boolean result does not depend >> on the shift value, thus the whole shifting is pointless. > > It's pointless for unsigned integers, too; why not warn for them as > well? And why not warn for 0 << 0 and 1 << 0, which are just as > pointless? =E2=80=9C1 << 0=E2=80=9C is often used in a sequence of flag mask definitio= ns. This example is from : | /* Terminal control structure. */ | struct termios | { | /* Input modes. */ | tcflag_t c_iflag; | #define IGNBRK (1 << 0) /* Ignore break condition. */ | #define BRKINT (1 << 1) /* Signal interrupt on break. */ | #define IGNPAR (1 << 2) /* Ignore characters with parity errors. = */ | #define PARMRK (1 << 3) /* Mark parity and framing errors. */ =E2=80=9C0 << 0=E2=80=9D is used in a similar context, to create a zero con= stant for a multi-bit subfield of an integer. This example comes from GDB, in bfd/elf64-alpha.c: | insn =3D INSN_ADDQ | (16 << 21) | (0 << 16) | (0 << 0);