From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22993 invoked by alias); 16 Nov 2015 10:29:27 -0000 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 Received: (qmail 22953 invoked by uid 89); 16 Nov 2015 10:29:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 16 Nov 2015 10:29:25 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 521DCC0DCD0A; Mon, 16 Nov 2015 10:29:24 +0000 (UTC) Received: from localhost (ovpn-116-102.ams2.redhat.com [10.36.116.102]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAGATNX0024382; Mon, 16 Nov 2015 05:29:23 -0500 Date: Mon, 16 Nov 2015 10:29:00 -0000 From: Jonathan Wakely To: =?iso-8859-1?Q?Fran=E7ois?= Dumont Cc: Jonathan Wakely , "libstdc++@gcc.gnu.org" , gcc-patches Subject: Re: vector lightweight debug mode Message-ID: <20151116102923.GI2937@redhat.com> References: <20150914195038.GQ2631@redhat.com> <55F9C4F6.6030706@gmail.com> <20150916202953.GE2631@redhat.com> <55FD0F35.4010106@gmail.com> <561574BE.1060005@gmail.com> <20151007200917.GU12094@redhat.com> <561C0D3A.7010504@gmail.com> <5648F551.5030404@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5648F551.5030404@gmail.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-11/txt/msg01917.txt.bz2 On 15/11/15 22:12 +0100, François Dumont wrote: >Here is a last version I think. > > I completed the debug light mode by adding some check on iterator >ranges. > > Even if check are light I made some changes to make sure that >internally vector is not using methods instrumented with those checks. >This is to make sure checks are not done several times. Doing so also >simplify normal mode especially when using insert range, there is no >need to check if parameters are integers or not. Yes, I'd also observed that those improvements could be made, to avoid dispatching when we already know we have iterators not integers. > I also introduce some __builtin_expect to make sure compiler will >prefer the best path. > > I didn't manage to check result on generated code. I am pretty sure >there will be an impact, you can't run more code without impact. But >that is a known drawback of debug mode, light or not, we just need to >minimize it. Mostly by making sure that checks are done only once. Not doing the checks is also an option. That minimizes the cost :-) For the full debug mode we want to check everything we can, and accept that has a cost. For the lightweight one we need to evaluate the relative benefits. Is it worth adding checks for errors that only happen rarely? Does the benefit outweigh the cost? I'm still not convinced that's the case for the "valid range" checks. I'm willing to be convinced, but am not convinced yet. > It would be great to have it for gcc 6.0. I am working on the same >for other containers. Please don't do the valid range checks for std::deque, the checks are undefined for iterators into different containers and will not give a reliable answer.