From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-395740-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 112533 invoked by alias); 22 Apr 2015 09:51:02 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 112518 invoked by uid 89); 22 Apr 2015 09:51:01 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-wi0-f173.google.com
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 22 Apr 2015 09:51:00 +0000
Received: by widdi4 with SMTP id di4so50736575wid.0        for <gcc-patches@gcc.gnu.org>; Wed, 22 Apr 2015 02:50:57 -0700 (PDT)
X-Received: by 10.194.60.173 with SMTP id i13mr48688448wjr.124.1429696257916; Wed, 22 Apr 2015 02:50:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.103.70 with HTTP; Wed, 22 Apr 2015 02:50:17 -0700 (PDT)
In-Reply-To: <20150422085924.GE28950@redhat.com>
References: <20150421111638.GB28950@redhat.com> <55365C6E.1080100@gmail.com> <20150422085924.GE28950@redhat.com>
From: =?ISO-8859-1?Q?Manuel_L=F3pez=2DIb=E1=F1ez?= <lopezibanez@gmail.com>
Date: Wed, 22 Apr 2015 09:51:00 -0000
Message-ID: <CAESRpQBZbcDyHvdwRYm3AezZZoJLOiHP9JYAK5Tif-nQFZPSYw@mail.gmail.com>
Subject: Re: [C/C++ PATCH] Improve -Wlogical-op (PR c/63357)
To: Marek Polacek <polacek@redhat.com>
Cc: Gcc Patch List <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset=ISO-8859-1
X-SW-Source: 2015-04/txt/msg01280.txt.bz2

On 22 April 2015 at 10:59, Marek Polacek <polacek@redhat.com> wrote:
> So the bug really must be solved first :(.  I see I proposed a solution in the
> PR, I wonder whether that works...

It will work for

extern int xxx;
#define XXX !xxx
int test (void)
{
  if (XXX && xxx)
    return 4;
  else
    return 0;
}

because the location of '!' is virtual. However, it won't work for:

extern int xxx;
#define XXX xxx
int test (void)
{
  if (!XXX && xxx)
    return 4;
  else
    return 0;
}

So, I think your proposal is an improvement, however, it does not
fully fix the problem. For that, we need to have locations for the
operands of expressions (PR43486), so we can check if they are also
come from macro expansion.

Cheers,

Manuel.