From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ad0f09f84e0c9396 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!213.200.89.82.MISMATCH!tiscali!newsfeed1.ip.tiscali.net!newsfeed00.sul.t-online.de!t-online.de!news-lei1.dfn.de!news.uni-jena.de!not-for-mail From: Christopher Broeg Newsgroups: comp.lang.ada Subject: Re: clarification of ARM 12.3 Generic Instantiation Date: Tue, 12 Apr 2005 14:32:52 +0200 Organization: Friedrich Schiller University Jena, Germany Message-ID: References: NNTP-Posting-Host: ent.astro.uni-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: fsuj29.rz.uni-jena.de 1113309172 20433 141.35.25.76 (12 Apr 2005 12:32:52 GMT) X-Complaints-To: news@rz.uni-jena.de NNTP-Posting-Date: 12 Apr 2005 12:32:52 GMT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:10387 Date: 2005-04-12T12:32:52+00:00 List-Id: 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. >