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,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news2.google.com!proxad.net!proxad.net!194.117.148.138.MISMATCH!pe2.news.blueyonder.co.uk!blueyonder!pe1.news.blueyonder.co.uk!blueyonder!news-out.ntli.net!newsrout1-gui.ntli.net!ntli.net!newspeer1-win.ntli.net!newsfe6-gui.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" Subject: 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 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 13 Apr 2005 12:46:17 GMT NNTP-Posting-Host: 81.100.88.147 X-Complaints-To: http://www.ntlworld.com/netreport X-Trace: newsfe6-gui.ntli.net 1113396377 81.100.88.147 (Wed, 13 Apr 2005 13:46:17 BST) NNTP-Posting-Date: Wed, 13 Apr 2005 13:46:17 BST Organization: ntl Cablemodem News Service Xref: g2news1.google.com comp.lang.ada:10415 Date: 2005-04-13T12:46:17+00:00 List-Id: 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. In summary: Certain uses of arrays over about 800MB cause code to fail. In particular, 'Address is sometimes incorrect Accessing high elements is incorrect, depending on exact code to generate the index. The problems only seem to occur if the upper bound of the array is compile-time constant. Can someone test this on later versions of GNAT please? -- Adrian Wrigley, Cambridge, UK with Text_IO; with System.Address_Image; procedure TestBug is -- Test devised by Adrian Wrigley, amtw@linuxchip.demon.co.uk.uk.uk (one uk is enough) -- I disclaim all rights to this code. Do what you wish with it! -- This test case illustrates a problem with code -- compiled on GNAT 3.15p for x86 under Linux -- It shows that the 'Address of elements of large -- arrays can be silently incorrect -- Notes: -- -- This test works if the word "constant" is removed -- -- The test also works if the value is less than 200_000_000 -- Indexing element also works with computed index Size : constant Integer := 210_000_000; type Big_T is array (1 .. Size) of aliased Float; type Big_A is access Big_T; Big : Big_A; function GetSomeMemory (X : Integer) return Big_A; pragma Import (C, GetSomeMemory, "malloc"); begin Big := GetSomeMemory (Size*4 + 16); -- This seems to work OK for now Text_IO.Put_Line ("First element attribute " & Integer'Image (Big_T'First)); Text_IO.Put_Line ("Last element attribute " & Integer'Image (Big_T'Last)); Text_IO.Put_Line ("Address of first element is " & System.Address_Image (Big (Big_T'First)'Address)); Text_IO.Put_Line ("Address of last element is " & System.Address_Image (Big (Big_T'Last)'Address)); -- Fails!!!!! Text_IO.Put_Line ("(Last element should be at higher address than first)"); declare J : Integer := Size; begin Text_IO.Put_Line ("Address of last element is " & System.Address_Image (Big (J)'Address)); end; Text_IO.Put_Line ("Writing to all elements in loop"); for I in Big_T'Range loop Big (I) := 0.0; end loop; Text_IO.Put_Line ("Writing to 'Last element"); --raised STORAGE_ERROR : stack overflow (or erroneous memory access): Big (Big_T'Last) := 0.0; -- Fails!!!!! end TestBug; I get $ gnatmake -O3 testbug $ ./testbug First element attribute 1 Last element attribute 210000000 Address of first element is 4212F008 Address of last element is 34245204 Last element should be at higher address than first Address of last element is 74245204 Writing to all elements in loop Writing to 'Last element raised STORAGE_ERROR : stack overflow (or erroneous memory access)