From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30292 invoked by alias); 2 Nov 2011 20:58:44 -0000 Received: (qmail 30280 invoked by uid 22791); 2 Nov 2011 20:58:42 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Nov 2011 20:58:29 +0000 From: "simon at pushface dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ada/50934] Allocated address for new controlled object is offset by 16 bytes Date: Wed, 02 Nov 2011 20:58:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ada X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: simon at pushface dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg00199.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50934 --- Comment #1 from simon at pushface dot org 2011-11-02 20:58:09 UTC --- I've now traced the reason for this. Controlled objects require some memory to be allocated to manage the chains of objects which are to be finalised when a scope is exited (this may not be strictly accurate, but is probably close enough for this PR). It used to be the case that System.Finalization_Root.Root_Controlled contained the necessary 2 pointers. At r177275 this was changed so that System.Finalization_Root.Root_Controlled is a null record; instead, System.Storage_Pools.Subpools.Allocate_Any_Controlled adds the necessary space to the allocated size and adjusts the returned pointer, to support Ada.Finalization.Heap_Managenent: Ada.Finalization.Heap_Management provides key functionality associated with controlled objects on the heap, their creation, finalization and reclamation. Type Finalization_Collection is effectively a wrapper which sits ontop of a storage pool and performs all necessary bookkeeping for all the objects it contains. Each access-to-controlled or access-to-class-wide type receives a collection as part of its expansion. The compiler generates buffer code and invokes Allocate / Deallocate to create and destroy allocated controlled objects. The trouble is that this means that the attribute Max_Size_In_Storage_Elements is now *wrong* for any controlled object. It seems to me that this new approach is a remarkably non-Ada way of addressing the problem; the original design is precisely the way that it should be addressed. Of course I have absolutely no objection to delegating this management to Ada.Finalization.Heap_Management (I think this should now in fact be System.Finalization_Masters). But System.Finalization_Root.Root_Controlled should contain a System.Finalization_Masters.FM_Node.