From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27319 invoked by alias); 31 Oct 2011 16:52:29 -0000 Received: (qmail 27150 invoked by uid 22791); 31 Oct 2011 16:52:25 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Oct 2011 16:52:07 +0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9VGq5g4016800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2011 16:52:06 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9VGq4M5008292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2011 16:52:05 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9VGpw9I006334; Mon, 31 Oct 2011 11:51:59 -0500 Received: from [192.168.1.4] (/79.47.194.71) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 31 Oct 2011 09:51:58 -0700 Message-ID: <4EAED224.50502@oracle.com> Date: Mon, 31 Oct 2011 18:09:00 -0000 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jason Merrill CC: "gcc-patches@gcc.gnu.org" Subject: Re: [C++ preview patch] PR 44277 References: <4EAD9AE8.7070703@oracle.com> <4EAEB18C.7000306@redhat.com> In-Reply-To: <4EAEB18C.7000306@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2011-10/txt/msg02862.txt.bz2 Hi, > How does it work to warn in convert_like_real instead? the problem is that (expr, totype) can be a lot of different things for which we want to warn, can be a zero and a pointer for assignments, but, when totype is a BOOLEAN_TYPE expr can be an EQ_EXPR or NEQ_EXPR and then the operands various things depending on whether we are looking for pointer, data member pointer, etc, on the left or on the right of the == or != sign. In other terms, the pattern matching doesn't seem matter of a few lines. I'm annoyed by this. Also, for the assignment case, I'm getting duplicate warnings, maybe can be fixed. Do you think there is no neat way to implement my idea of avoiding generating those implicit 0s in the first place? The internals of the front-end, seem very c++98-ish for null pointers ;) Paolo.