From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47467 invoked by alias); 28 May 2015 17:15:15 -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 47454 invoked by uid 89); 28 May 2015 17:15:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 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; Thu, 28 May 2015 17:15:14 +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 4674F3674CE; Thu, 28 May 2015 17:15:13 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-36.phx2.redhat.com [10.3.113.36]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4SHFCNm028356; Thu, 28 May 2015 13:15:13 -0400 Message-ID: <55674D20.3010402@redhat.com> Date: Thu, 28 May 2015 18:04:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Martin_Li=9Aka?= , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 01/35] Introduce new type-based pool allocator. References: <83d59ba92a3c4b3ba831ebc2fce325f0416848d0.1432735040.git.mliska@suse.cz> <55660262.8050401@redhat.com> <55670EF0.6060400@suse.cz> In-Reply-To: <55670EF0.6060400@suse.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg02675.txt.bz2 On 05/28/2015 06:49 AM, Martin Liška wrote: . > > This mechanism has been just adapted. I find it quite useful as we have > examples in source code where we > allocate same struct/class types from a various pool. For debugging > purpose, it helps to identify if > release operation is called for a correct pool. I saw that you were following existing practice for the pools in the removal patch. I still don't like it as it makes mixing and matching objects harder when debugging gcc and if the structure is exposed for plugins, then we've got an unnecessary ABI plugin breakage. I certainly understand how it's useful -- I'm not questioning that. I'm questioning changing the size of structures on ENABLE_CHECKING. My first inclination would be to include all that stuff unconditionally. If that's too much overhead, then perhaps include the structure member, but not bother with any of the bookkeeping except for ENABLE_CHECKING. > Anyway, I would like to commit all these patches at once (one by one). > Thus, I'm going to wait for approval for the whole series before I'll > commit the set. Quite reasonable -- I was mostly trying to make sure I understood the testing situation. I think at this point the whole series is approved, so you can move forward. jeff