https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124143
Liam Powell <liam at liampwll dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #63704|0 |1
is obsolete| |
--- Comment #5 from Liam Powell <liam at liampwll dot com> ---
Created attachment 63717
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63717&action=edit
untested fix 2
Ah, I saw the ordering and didn't consider what Deallocate_Subpool actually
does. Your second point should actually be "*might* have been deallocated", the
RM does not state that the subpool ceases to exist after Deallocate_Subpool, so
it's still allowed to be a valid object if the subpool implementer wants it to
be but calling Pool_of_Subpool on it afterwards must return null.
What if we just moved Owner out to SP_Node as shown in the new attached diff?
As an aside, fixing this should also fix this ??? in
System.Storage_Pools.Subpools:
procedure Deallocate_Subpool
(Pool : in out Root_Storage_Pool_With_Subpools;
Subpool : in out Subpool_Handle)
is abstract;
-- This precondition causes errors in simple tests, disabled for now???
-- with Pre'Class => Pool_Of_Subpool (Subpool) = Pool'Access;
