clarification of ARM 12.3 Generic Instantiation

clarification of ARM 12.3 Generic Instantiation

[Christopher Broeg]

Hello,

I am having problems understanding the following sentence in the ARM:

  12.3 Generic Instantiation

Post-Compilation Rules
19  "Recursive generic instantiation is not allowed in the following 
sense: if a given generic unit includes an instantiation of a second 
generic unit, then the instance generated by this instantiation shall 
not include an instance of the first generic unit (whether this instance 
is generated directly, or indirectly by intermediate instantiations)."


Is it thus allowed to have a generic package A
that instantiates the generic packages B and C
when package C also instantiates package B?


I am experiencing very strange behaviour and I am having a rather 
complicated nested generic instantiation structure.
A spline package is used to interpolate several tabulated functions 
which are then combined and again tabulated in an array which is again 
interpolated.

Running the above in a seperate test program works fine. When I include 
it in my large code, the result is radom. Sometimes it works, sometimes 
the numbers are wrong and sometimes the numbers are even NaN values. 
This all depends on the array dimensions say 100x100 or 1000x1000 might 
work and 300x200 crashes. Further it depends on the floating point type. 
digits 18 crashes often, but long_float and even float fails in some cases.

I am compiling using GNAT Academic verision.
I tried -fstack-check and elaboration order. Everything seems fine.

Sorry if I am confusing but this is all very hard to explain.

thanks for any help,

Chris

Re: clarification of ARM 12.3 Generic Instantiation

[Marius Amado Alves]

> Is it thus allowed to have a generic package A
> that instantiates the generic packages B and C
> when package C also instantiates package B?

Yes. B and C are siblings, one can instantiate the other (but one-way 
only), it doesn't matter who their parent is.

> Running the above in a seperate test program works fine. When I 
> include it in my large code, the result is radom. Sometimes it works, 
> sometimes the numbers are wrong and sometimes the numbers are even NaN 
> values. This all depends on the array dimensions say 100x100 or 
> 1000x1000 might work and 300x200 crashes. Further it depends on the 
> floating point type. digits 18 crashes often, but long_float and even 
> float fails in some cases.

 From this description the usual suspects are: conversions, specially 
unchecked, overflows in intermediary computation, including logical 
overflows in modular types, and uninitialised arrays.

> I am compiling using GNAT Academic version.

If you're registered with the GAP programme, you can ask for help there.

Re: clarification of ARM 12.3 Generic Instantiation

[Christopher Broeg]

Thank you for your reply. My current guess is that it has something to 
do with memory management.

The test package alone works most of the time, only with digits 18 I can 
get NaN********************* values.

But if I compile it as a part of a larger program it sometimes 
(depending on the size of the array, and on the machine it is running 
on) produces garbage values also for long_float and even float.

It is very strange. I tried checking for stack_overflow, but I get
"""
test_ada_spline_generic.adb: In function `Test_Ada_Spline_Generic':
test_ada_spline_generic.adb:194: warning: frame size too large for 
reliable stack checking
"""
even though there are very little variables except for the complicated 
generic instatiation.

I tried putting the large 4-dimensional arrays in the heap by using 
access types, so that in the end a 3MB(!) stack size was enough, but the 
problem prevailed.

The behaviour is really quite random. Any ideas?

Christopher Broeg

PS. Thanks for the idea with getting help from GAP


Marius Amado Alves wrote:
>> Is it thus allowed to have a generic package A
>> that instantiates the generic packages B and C
>> when package C also instantiates package B?
> 
> 
> Yes. B and C are siblings, one can instantiate the other (but one-way 
> only), it doesn't matter who their parent is.
> 
>> Running the above in a seperate test program works fine. When I 
>> include it in my large code, the result is radom. Sometimes it works, 
>> sometimes the numbers are wrong and sometimes the numbers are even NaN 
>> values. This all depends on the array dimensions say 100x100 or 
>> 1000x1000 might work and 300x200 crashes. Further it depends on the 
>> floating point type. digits 18 crashes often, but long_float and even 
>> float fails in some cases.
> 
> 
>  From this description the usual suspects are: conversions, specially 
> unchecked, overflows in intermediary computation, including logical 
> overflows in modular types, and uninitialised arrays.
> 
>> I am compiling using GNAT Academic version.
> 
> 
> If you're registered with the GAP programme, you can ask for help there.
>