From patchwork Sat Nov 10 09:16:58 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 198178 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 9A9BF2C0082 for ; Sat, 10 Nov 2012 20:17:17 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1353143838; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=3Eq7DfakY56Xf0dpatYSoF21B+o=; b=frCMtwrYWOk9HG2 LfK9YcgBdJN3e9j+4pIaA9eeJZqMoHqtMdaHvMVK37zEMfy8P4LYpGKhM8u/UD6G Dt2pl59yYzQf8iKr1ld1sIl00HnLzQ5+FuXrk52BjXS36D+/q8STpdg1n7sHrB0n WXEKCagQ+rR08I5z7bvorOyGA0d0= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ejsLq14B+JpFy0277GpmsE2hSj2/kTp7K+ebTIHcZFFA0qzGPFDtTz7rG1Sj44 peqccWo6jcFQ9pfWl3eCgrBEr3Grizu8hwyEoKUflIr9jH3/eLwZ4EC8ypgE3WJ5 iabIFCff0J+hfFj2iVI+mDL4YzW1PstiXjz6vJcQyoN78=; Received: (qmail 25589 invoked by alias); 10 Nov 2012 09:17:14 -0000 Received: (qmail 25578 invoked by uid 22791); 10 Nov 2012 09:17:13 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, SPF_HELO_PASS, TW_TM X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 10 Nov 2012 09:17:03 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAA9H2JT010259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Nov 2012 04:17:02 -0500 Received: from zalov.redhat.com (vpn1-4-42.ams2.redhat.com [10.36.4.42]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAA9Gx0I005735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Nov 2012 04:17:01 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qAA9GxH6003960; Sat, 10 Nov 2012 10:16:59 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qAA9Gwhx003959; Sat, 10 Nov 2012 10:16:58 +0100 Date: Sat, 10 Nov 2012 10:16:58 +0100 From: Jakub Jelinek To: Tobias Burnus Cc: gcc patches , Wei Mi , Kostya Serebryany , Xinliang David Li Subject: Re: [asan] Patch - fix an ICE in asan.c Message-ID: <20121110091658.GI1886@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <509D6965.5040405@net-b.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <509D6965.5040405@net-b.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Fri, Nov 09, 2012 at 09:36:53PM +0100, Tobias Burnus wrote: > * I still have to do an all-language bootstrap and regtesting, > though the latter is probably pointless as there is currently not a > single -fasan test case. > --- gcc/asan.c.orig 2012-11-09 21:26:26.000000000 +0100 > +++ gcc/asan.c 2012-11-09 21:26:00.000000000 +0100 > @@ -1362,6 +1362,8 @@ transform_statements (void) > instrument_assignment (&i); > else if (is_gimple_call (s)) > maybe_instrument_call (&i); > + if (gsi_end_p (i)) > + break; > } > } > } That looks a wrong place for this. Instead, maybe_instrument_call should ensure that *iter is set to the last stmt that shouldn't be instrumented. instrument_derefs does that correctly, so assignments and __atomic/__sync builtins should be correct (*iter is set to the assignment/call), for strlen call it seems to DTRT, but for other builtin calls it would leave *iter elsewhere. As we want to scan for accesses the rest of the bb that contained the call (but that bb after splitting already is above the highest bb number to be insturmented), we need to keep *iter at the call we just processed, so if there are say two consecutive calls the second one is going to be processed. So untested: 2012-11-10 Jakub Jelinek * asan.c (maybe_instrument_builtin_call): Set *iter to gsi for the call at the end. Jakub --- gcc/asan.c.jj 2012-11-02 00:09:22.000000000 +0100 +++ gcc/asan.c 2012-11-10 10:00:03.717715834 +0100 @@ -1191,6 +1191,7 @@ maybe_instrument_builtin_call (gimple_st else if (dest != NULL_TREE) instrument_mem_region_access (dest, len, iter, loc, /*is_store=*/true); + *iter = gsi_for_stmt (call); return true; } return false;