From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28530 invoked by alias); 21 Jul 2004 06:44:09 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 28521 invoked from network); 21 Jul 2004 06:44:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 21 Jul 2004 06:44:08 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6L6i4e1021008; Wed, 21 Jul 2004 02:44:04 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6L6i4a13209; Wed, 21 Jul 2004 02:44:04 -0400 Received: from livre.redhat.lsd.ic.unicamp.br (vpn64-14.boston.redhat.com [172.16.66.14]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i6L6i2Nf019269; Wed, 21 Jul 2004 02:44:03 -0400 Received: from livre.redhat.lsd.ic.unicamp.br (livre.redhat.lsd.ic.unicamp.br [127.0.0.1]) by livre.redhat.lsd.ic.unicamp.br (8.13.0/8.13.0) with ESMTP id i6L6i20U017113; Wed, 21 Jul 2004 03:44:02 -0300 Received: (from aoliva@localhost) by livre.redhat.lsd.ic.unicamp.br (8.13.0/8.13.0/Submit) id i6L6i1RR017110; Wed, 21 Jul 2004 03:44:01 -0300 To: Archie Cobbs Cc: gcc-help@gcc.gnu.org Subject: Re: Null pointer dereference and side effects References: <200407201512.i6KFCXrx001516@arch20m.dellroad.org> From: Alexandre Oliva Organization: Red Hat Global Engineering Services Compiler Team Date: Wed, 21 Jul 2004 06:44:00 -0000 In-Reply-To: <200407201512.i6KFCXrx001516@arch20m.dellroad.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-07/txt/msg00204.txt.bz2 On Jul 20, 2004, Archie Cobbs wrote: > It appears gcc is completely ignoring the possibility of > "side effects" when it optimizes away the comparison. Oh, rats. That's because the reasoning about dereferencing NULL invoking undefined behavior still applies. Since both arms of the if return the same value, the compare is optimized away, and the dereference of the pointer can be removed because, if it was NULL or any other bad pointer, it would invoke undefined behavior, and otherwise, the dereference would be safe and unused. I think you really need to make the pointer volatile to prevent the dereference from being optimized out. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}