This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ada/50934] Allocated address for new controlled object is offset by 16 bytes
- From: "simon at pushface dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 02 Nov 2011 20:58:09 +0000
- Subject: [Bug ada/50934] Allocated address for new controlled object is offset by 16 bytes
- Auto-submitted: auto-generated
- References: <bug-50934-4@http.gcc.gnu.org/bugzilla/>
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.