From patchwork Mon Jan 2 16:41:28 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dodji Seketeli X-Patchwork-Id: 133872 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 AA355B6FA4 for ; Tue, 3 Jan 2012 03:41:59 +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=1326127321; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Cc:Subject:References:Date:In-Reply-To: Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=P04torohAxWlAmaRfP4raIj1YpE=; b=LVIoZkxbag3rsFJmOqOlZXKLMew2cFvBWBOTAz4ebuzGeLEEgqSgRIgsKUjgkn ur4vHk/81+jI6PPNFjgWev1mXer+MD+bjzgcUFiVEg6wrXYx3gHGHK4WS7QoKzmL w8d+8ccdvZZGPUUCeHsMPXcFQzEack+gCln9MXWPVx7ms= 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:From:To:Cc:Subject:References:X-URL:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=CC+hGxCJxqsxS7KsJq4mcbm2+G0izDxJo90Kz5R8Am/JDOoiMWsSOKvr46f56e 0wab3fM0m+ychpn0G+GPI6UnxBoLGlMRQTT1uHMw4LSnPc14mP2OaZVAlUUlLJTd ZTX/ufjaRFbrK5fQ4wMy9BZvXUAp8uLfkqTBzB4Ed34Vc=; Received: (qmail 32573 invoked by alias); 2 Jan 2012 16:41:51 -0000 Received: (qmail 32418 invoked by uid 22791); 2 Jan 2012 16:41:47 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, SPF_HELO_PASS, TW_SV, 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; Mon, 02 Jan 2012 16:41:32 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q02GfUol010445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Jan 2012 11:41:30 -0500 Received: from localhost (ovpn-116-27.ams2.redhat.com [10.36.116.27]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q02GfTqH029951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2012 11:41:30 -0500 Received: by localhost (Postfix, from userid 500) id 9A47A29C13F; Mon, 2 Jan 2012 17:41:28 +0100 (CET) From: Dodji Seketeli To: Jason Merrill Cc: Jakub Jelinek , GCC Patches Subject: Re: [PATCH] [RFC] PR debug/49951 - jumpy stepping at end of scope in C++ References: <4EEB9E6D.2090204@redhat.com> <20111219225805.GN1957@tyan-ft48-01.lab.bos.redhat.com> <4EF024EF.3060804@redhat.com> X-URL: http://www.redhat.com Date: Mon, 02 Jan 2012 17:41:28 +0100 In-Reply-To: <4EF024EF.3060804@redhat.com> (Jason Merrill's message of "Tue, 20 Dec 2011 01:02:23 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 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 Jason Merrill writes: > OK. I'd like to apply this patch to 4.5 and 4.6 as I find the jumpy stepping behaviour very annoying while using 4.6 myself. I have bootstrapped and tested the patch on these branches for x86_64-unknown-linux-gnu successfully. Would this be OK? For the record, here is the commit I have tested on these branches. commit 399ff82d2ff78acb066b91e5940e815fcdc82ed7 Author: dodji Date: Tue Dec 20 13:36:04 2011 +0000 PR debug/49951 - jumpy stepping at end of scope in C++ gcc/cp/ PR debug/49951 * decl.c (cxx_maybe_build_cleanup): Don't set location of the call to the destructor. gcc/testsuite/ PR debug/49951 * g++.dg/gcov/gcov-2.C: Adjust. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@182532 138bc75d-0d04-0410-961f-82ee72b054a4 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -13363,8 +13363,17 @@ cxx_maybe_build_cleanup (tree decl) cleanup = call; } + /* build_delete sets the location of the destructor call to the + current location, even though the destructor is going to be + called later, at the end of the current scope. This can lead to + a "jumpy" behaviour for users of debuggers when they step around + the end of the block. So let's unset the location of the + destructor call instead. */ + if (cleanup != NULL && EXPR_P (cleanup)) + SET_EXPR_LOCATION (cleanup, UNKNOWN_LOCATION); return cleanup; } /* When a stmt has been parsed, this function is called. */ diff --git a/gcc/testsuite/g++.dg/gcov/gcov-2.C b/gcc/testsuite/g++.dg/gcov/gcov-2.C index 6d002f5..66d8af3 100644 --- a/gcc/testsuite/g++.dg/gcov/gcov-2.C +++ b/gcc/testsuite/g++.dg/gcov/gcov-2.C @@ -20,7 +20,7 @@ private: void foo() { - C c; /* count(2) */ + C c; /* count(1) */ c.seti (1); /* count(1) */ }