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

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

Hi!

Thank you very much for the feedback on this, particularly
those reporting success on particular configurations.

I should also comment:

I used 'malloc' rather then 'new' for two reasons:

1) Using 'new' fails, giving "raised STORAGE_ERROR : object too large"
   (in spite of having enough store to malloc and use)

2) My original program used 'mmap', but this is much more verbose
   to set up.  On Linux, large 'malloc' uses mmap anyway.

I calculate the size to allocate manually because attempting
to use the 'Size attribute fails (even when converted to a
suitably large type).

In fact the 'Size attribute fails on objects over 2147483647 bits :(
Sometimes this failure is silent (not trapped even with -gnato),
sometimes it gets a constaint error at compile time.

(The test supplied also fails with Size set to 67_108_865, which
is the smallest failing case.  This just exceeds the 2Gbit size limit.
In the 4-6Gbit region, the access to the 'last element is to the
wrong address, silently.  This is potentially serious!)

I have just tried the same code on GNAT/gcc 3.4.2 (Fedora Core 3, x86).
Everything works correctly, as far as I can tell!

My conclusions:

1) Update compilers more often!
   Don't expect (32-bit) 3.15p to work properly on large data

2) Convert 'size to a large type (eg 64-bit) before
   calculating bytes etc.

(and upgrade to x86-64 and 64-bit GNAT as soon as practicable)
(and pay for support if this kind of thing matters!)
-- 
Adrian Wrigley, Cambridge, UK.