From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119507 invoked by alias); 28 Sep 2016 14:42:28 -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 119494 invoked by uid 89); 28 Sep 2016 14:42:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=Hx-languages-length:1412 X-HELO: mail-yw0-f174.google.com Received: from mail-yw0-f174.google.com (HELO mail-yw0-f174.google.com) (209.85.161.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Sep 2016 14:42:17 +0000 Received: by mail-yw0-f174.google.com with SMTP id i129so28993748ywe.2 for ; Wed, 28 Sep 2016 07:42:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aB1X/0Wj5AkpqeCgfvZ49n4ZZCbxPnOI5NCcWUxufJM=; b=EDc+npc5vVQOYPChSs/jH56DpILtiMTnFBfuhoS2LC80kjeCZzLtWGFGvEfXMt6vg/ Smj/t6UoIoG1a+i/s8+kp+drHac3Q6tnPepTmrr9mRTs4JRyQmK1rcFGg0Af8C2hlEOX zaYV3x5oKEyOrAIgQcjHeOHDTFQhWl+lm60OP4NmCf1StuW5slQpCLyLHpZixJr68SZ1 XVm6DvOY/nfwl0JTgg4wfILXYzLL0ngNlVjJ0hWiaWuhKGRy5kNebM1Z9rh9MhUpdYB6 sGGjZ9Ks2CXsqyA94XdHKi/s7tsXWiGt282cyiTPMlVVr4ALK/j/VkkLJEJ4b7Hg0HOi mNgQ== X-Gm-Message-State: AA6/9RnECHaVmC1rNLmmG7ZLEIfAR9LcglwuFEGiLMM3MfZzvMzfuRezPTsOoFYaBlB0RDET7N8/f02a9+p4tF/Z X-Received: by 10.157.37.24 with SMTP id k24mr3001314otb.28.1475073735774; Wed, 28 Sep 2016 07:42:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.105.167 with HTTP; Wed, 28 Sep 2016 07:41:54 -0700 (PDT) In-Reply-To: References: <87shslv769.fsf@mid.deneb.enyo.de> <87fuol77ri.fsf@mid.deneb.enyo.de> From: Jason Merrill Date: Wed, 28 Sep 2016 14:44:00 -0000 Message-ID: Subject: Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops To: Bernd Edlinger Cc: Florian Weimer , "gcc-patches@gcc.gnu.org" , Jeff Law Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg02136.txt.bz2 On Tue, Sep 27, 2016 at 11:10 AM, Bernd Edlinger wrote: > On 09/27/16 16:42, Jason Merrill wrote: >> On Tue, Sep 27, 2016 at 10:28 AM, Bernd Edlinger >> wrote: >>> On 09/27/16 16:10, Florian Weimer wrote: >>>> * Bernd Edlinger: >>>> >>>>>> =E2=80=9C0 << 0=E2=80=9D is used in a similar context, to create a z= ero constant 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); >>>>>> >>>>> >>>>> Of course that is not a boolean context, and will not get a warning. >>>>> >>>>> Question is if "if (1 << 0)" is possibly a miss-spelled "if (1 < 0)". >>>>> >>>>> Maybe 1 and 0 come from macro expansion.... >>>> >>>> But what's the intent of treating 1 << 0 and 0 << 0 differently in the >>>> patch, then? >>> >>> I am not sure if it was a good idea. >>> >>> I saw, we had code of the form >>> bool flag =3D 1 << 2; >>> >>> another value LOOKUP_PROTECT is 1 << 0, and >>> bool flag =3D 1 << 0; >>> >>> would at least not overflow the allowed value range of a boolean. >> >> Assigning a bit mask to a bool variable is still probably not what was >> intended, even if it doesn't change the value. > > That works for me too. > I can simply remove that exception. Sounds good. Jason