comp.lang.ada
 help / color / mirror / Atom feed
From: Christopher Broeg <broeg@astro.uni-jena.de>
Subject: Re: clarification of ARM  12.3 Generic Instantiation
Date: Tue, 12 Apr 2005 14:32:52 +0200
Date: 2005-04-12T12:32:52+00:00	[thread overview]
Message-ID: <d3gf5k$juh$1@fsuj29.rz.uni-jena.de> (raw)
In-Reply-To: <mailman.4.1113252433.24457.comp.lang.ada@ada-france.org>

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.
> 



      reply	other threads:[~2005-04-12 12:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-24 13:36 clarification of ARM 12.3 Generic Instantiation Christopher Broeg
2005-04-11 11:25 ` Marius Amado Alves
2005-04-12 12:32   ` Christopher Broeg [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox