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.