13.11.5(9/3) states that Deallocate_Subpool(...) is called during finalization of a subpool, which is a user-defined procedure. An implementation of Deallocate_Subpool might simply contain a call to Unchecked_Deallocation on the subpool, which would then finalize the subpool, which would call Deallocate_Subpool, ..., etc..
This raises the question of whether the user or the compiler is expected to prevent this.
Searching for Deallocate_Subpool on GitHub finds only a handful of subpool users and out of those only 3 call Unchecked_Deallocation within Deallocate_Subpool 1 2 3. All 3 of these implementations do not protect against a recursive loop.
I believe the most reasonable thing to do here is to just explicitly define finalization of a subpool as a no-op during the execution of 13.11.5(9/3).
13.11.5(9/3) states that Deallocate_Subpool(...) is called during finalization of a subpool, which is a user-defined procedure. An implementation of Deallocate_Subpool might simply contain a call to Unchecked_Deallocation on the subpool, which would then finalize the subpool, which would call Deallocate_Subpool, ..., etc..
This raises the question of whether the user or the compiler is expected to prevent this.
Searching for Deallocate_Subpool on GitHub finds only a handful of subpool users and out of those only 3 call Unchecked_Deallocation within Deallocate_Subpool 1 2 3. All 3 of these implementations do not protect against a recursive loop.
I believe the most reasonable thing to do here is to just explicitly define finalization of a subpool as a no-op during the execution of 13.11.5(9/3).