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,be7fa91648ac3f12 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!fr.ip.ndsoftware.net!62.253.162.218.MISMATCH!news-in.ntli.net!newsrout1-win.ntli.net!ntli.net!newspeer1-win.ntli.net!newsfe6-win.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" Subject: Re: Large arrays (again), problem case for GNAT User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.lang.ada References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 14 Apr 2005 10:44:35 GMT NNTP-Posting-Host: 81.100.88.147 X-Complaints-To: http://www.ntlworld.com/netreport X-Trace: newsfe6-win.ntli.net 1113475475 81.100.88.147 (Thu, 14 Apr 2005 11:44:35 BST) NNTP-Posting-Date: Thu, 14 Apr 2005 11:44:35 BST Organization: ntl Cablemodem News Service Xref: g2news1.google.com comp.lang.ada:10454 Date: 2005-04-14T10:44:35+00:00 List-Id: 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.