Re: Large arrays (again), problem case for GNAT

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:

> Hi guys!
> 
> A month or two back I hinted that I had been having problems
> the GNAT code accessing large data structures.  It seemed that
> incorrect code was silently being generated.  Since I didn't
> have a test case available, no progress could be made.
> 
> I have encountered the problem again, and produced a test case.

Interesting.

I ran your program on windows XP professional, using GNAT version 5.03a,
which is a supported version.  It ran fine, and produced this output:

First element attribute  1
Last element attribute   210000000
Address of first element is 02570020
Address of last element is  3468621C
(Last element should be at higher address than first)
Address of last element is 3468621C
Writing to all elements in loop
Writing to 'Last element

It ran in a few seconds.  I changed Size to 410_000_000, and it still
worked fine (but took longer).  At 510_000_000 the malloc failed.

Why do you use malloc?  Why didn't you write:

    Big := new Big_T;

?  I'm not sure it makes any difference in this case,
but in general, if you're going to play games with memory
allocation, you should use storage pools, rather than relying
on the hope that malloc returns something that the Ada compiler
likes.  If you had an access to unconstrained array, the malloc
method would almost certainly fail, unless you wrap it in the proper
storage pool thing.

Also, I would think "access" should be "access all" if you're playing
those games.

I suspect your problem is an OS problem, and not a GNAT problem.

- Bob