From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19240 invoked by alias); 12 Nov 2007 01:10:13 -0000 Received: (qmail 19230 invoked by uid 22791); 12 Nov 2007 01:10:12 -0000 X-Spam-Check-By: sourceware.org Received: from mail.gnu.org (HELO mx10.gnu.org) (199.232.76.166) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 12 Nov 2007 01:10:09 +0000 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IrNoV-0000VT-Kt for gcc-patches@gcc.gnu.org; Sun, 11 Nov 2007 20:10:07 -0500 Received: (qmail 3093 invoked from network); 12 Nov 2007 01:09:04 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Nov 2007 01:09:04 -0000 Message-ID: <4737A7A4.90107@codesourcery.com> Date: Mon, 12 Nov 2007 01:43:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Manuel_L=F3pez-Ib=E1=F1ez?= CC: GCC Patches Subject: Re: PR c++/33160: wrong "NULL used in arithmetic" warning References: <6c33472e0711101053v788b66f3ud16a845130b4ab3d@mail.gmail.com> <47378DFC.7080102@codesourcery.com> <6c33472e0711111605l2e2e6a33q3a671a357810362@mail.gmail.com> In-Reply-To: <6c33472e0711111605l2e2e6a33q3a671a357810362@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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: 2007-11/txt/msg00593.txt.bz2 Manuel López-Ibáñez wrote: > On 12/11/2007, Mark Mitchell wrote: >> if ((orig_op0 == null_node || orig_op1 == null_node) >> >> should be false. >> >> The bug might be that something is thinking that (intptr_t)__null is a >> no-op cast and is throwing away the cast -- even though it is important, >> for exactly the reason shown here. It would be OK to replace the cast >> with a zero of the correct type (rather than leaving the cast itself >> explicit). >> > That is exactly what I was thinking. Any hints where this may be happening? No, sorry, I have no idea; you'll just have to step through the code that handles casts... -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713