From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7667 invoked by alias); 1 Nov 2012 21:43:36 -0000 Received: (qmail 7658 invoked by uid 22791); 1 Nov 2012 21:43:36 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-qc0-f175.google.com (HELO mail-qc0-f175.google.com) (209.85.216.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Nov 2012 21:43:32 +0000 Received: by mail-qc0-f175.google.com with SMTP id j3so2212519qcs.20 for ; Thu, 01 Nov 2012 14:43:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=v4NuF3feu6elic6URA+mkAZqKK6wD7TFPPrMt2DifVo=; b=R3/XINV8oA+tYkcbABonopJwYBkBOn6fG31ZDw02LCluybkWVlKNadrr6jnENMMUWy 4t6hw1k78c25diNBbsl30GDIwWYSqYZTZReZ0e4ef29JSvMFKJVKNUmmtHVVkOrkQoXd N/VOG4pH/sPFYB7CYumPGmFAxXW/F5zfDDd9hfsRuE7m32lC1tSjAnlg2CeeXP2e7pH8 +WRbtk9XMqEmUHpqvc+4Ej38/MjtkpBLhY4lz1znBr4F6D6uLsAEkGeAaHbEnrIGNN8e gtnQKTvUcW59gFpCyBssoAXPTdqCCCE0N0hDWb7bOAOTV56oU/j7lCOesIWgYVzbUCuA 7M8Q== MIME-Version: 1.0 Received: by 10.49.71.71 with SMTP id s7mr34761280qeu.33.1351806211910; Thu, 01 Nov 2012 14:43:31 -0700 (PDT) Received: by 10.49.104.142 with HTTP; Thu, 1 Nov 2012 14:43:31 -0700 (PDT) In-Reply-To: <20121101212416.GQ1891@tucnak.redhat.com> References: <20121101204750.GM1891@tucnak.redhat.com> <20121101210742.GP1891@tucnak.redhat.com> <20121101212416.GQ1891@tucnak.redhat.com> Date: Thu, 01 Nov 2012 21:43:00 -0000 Message-ID: Subject: Re: [tsan] ThreadSanitizer instrumentation part From: Xinliang David Li To: Jakub Jelinek Cc: Dmitry Vyukov , Wei Mi , GCC Patches , Diego Novillo , Dodji Seketeli Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlUbKAysNz4GYshlw04oxSoU4QhTfcoBg0KhQQL9kVjoazusH0lG8zqWHwTiJR839C4lolUwLCws0TK/4j3HN2TUqUT6IDuvw29DosC8KYkvZ3gRU8M+8jJhIepqGkkIC74pacgoFF8lTOws9HNb8l6+Ob5Mkzo0HI4TXs9Dgw0+scyZrVTqfTm4EZsI13I+kezTMxH 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: 2012-11/txt/msg00123.txt.bz2 It is not always true though -- only when the array address is picked by the pass to be the induction variable. David On Thu, Nov 1, 2012 at 2:24 PM, Jakub Jelinek wrote: > On Thu, Nov 01, 2012 at 02:19:43PM -0700, Xinliang David Li wrote: >> Right -- I found the same thing, it is the ivopt that resets it -- the >> IV opt pass should have a TODO_update_address_taken. > > That wouldn't change anything. The IVopts pass adds some_ptr = &a[0]; > to the IL, so a is then address taken. > > Jakub