From: Simon Wright <simon@pushface.org>
Subject: Re: Error: allocation from empty storage pool
Date: Thu, 12 Jul 2018 12:41:52 +0100
Date: 2018-07-12T12:41:52+01:00 [thread overview]
Message-ID: <lyin5kfzpb.fsf@pushface.org> (raw)
In-Reply-To: pi789g$8c1$1@dont-email.me
"Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
> In a library I'm trying to have all allocations done from
> user-specified storage pools. There is no restriction on using the
> heap, as long as it comes from a user pool (that can default to the
> regular heap, of course).
>
> The idea was then to use "pragma Default_Storage_Pool (null)" at the
> library root to ensure no use of default allocators, and wherever
> needed provide facilities to get a pool from the user.
>
> However, this test fails:
>
> ---8<---
>
> pragma Restrictions (No_Secondary_Stack); -- Just to be sure in this ex.
> pragma Default_Storage_Pool (null);
>
> procedure Anon is
>
> type Holder is record
> I : aliased Integer;
> end record;
>
> type Ref (Elem : access constant Integer) is limited null record;
>
> function To_Ref (Hold : aliased Holder) return Ref is
> (Elem => Hold.I'Access); -- Error in subject here
>
> begin
> null;
> end Anon;
>
> ---8<---
>
> There's actually no allocation being made, and I could have a Holder
> variable in the stack, and take a reference, and still no pool would
> be used at all.
>
> So it seems this pragma is too naïve. To make it into questions:
>
> Is this the pragma expected behavior or a particularity of gnat? Is
> the approach reasonable? This is my first attempt at working in a
> "restricted" Ada environment so I don't really have a clear idea of
> the preferred way to do what I want. Also, I'd like if possible to
> avoid making everything generic on the user pool.
I'm 99% confident this is a bug in GNAT.
The repreentation of the generated code (-gnatG) for To_Ref is
function to_ref (hold : aliased holder; to_refBIPalloc : natural;
to_refBIPstoragepool :
system__storage_pools__root_storage_pool_ptr; to_refBIPaccess :
T5b) return ref is
begin
R14b : declare
[subtype T12b is ref (hold.i'access)]
type A16b is access all T12b;
R17b : A16b := null;
if to_refBIPalloc = 1 then
R17b := A16b!(to_refBIPaccess);
elsif to_refBIPalloc = 2 then
R17b := new T12b[storage_pool =
system__secondary_stack__ss_pool];
elsif to_refBIPalloc = 3 then
R17b := new T12b;
elsif to_refBIPalloc = 4 then
P15b : system__storage_pools__root_storage_pool renames
to_refBIPstoragepool.all;
R17b := new T12b[storage_pool = P15b];
else
[program_error "build in place mismatch"]
end if;
R13b : T12b renames R17b.all;
R13b.elem := hold.i'access;
begin
return R13b;
end R14b;
end to_ref;
where to_refBIPalloc is a parameter determined by the compiler. In the
case of
H : aliased Holder := (I => 42);
R : Ref := To_Ref (H);
it's 1, and to_refBIPaccess is R'Unrestricted_Access.
The other cases are presumably to cope with other calling patterns
(can't imagine what), and in particular case 3 is a standard 'new',
which would be what triggers the error message.
next prev parent reply other threads:[~2018-07-12 11:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-12 9:50 Error: allocation from empty storage pool Alejandro R. Mosteo
2018-07-12 11:41 ` Simon Wright [this message]
2018-07-12 12:14 ` Alejandro R. Mosteo
2018-07-12 21:08 ` Randy Brukardt
2018-07-13 8:02 ` Alejandro R. Mosteo
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox