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-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!i20g2000prf.googlegroups.com!not-for-mail From: Jerry Newsgroups: comp.lang.ada Subject: Possible compiler bug with this simple program Date: Thu, 28 Aug 2008 00:28:29 -0700 (PDT) Organization: http://groups.google.com Message-ID: <1edc3682-855f-405b-8348-72b423377b1a@i20g2000prf.googlegroups.com> NNTP-Posting-Host: 75.171.118.139 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1219908510 4476 127.0.0.1 (28 Aug 2008 07:28:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 28 Aug 2008 07:28:30 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i20g2000prf.googlegroups.com; posting-host=75.171.118.139; posting-account=x5rpZwoAAABMN2XPwcebPWPkebpwQNJG User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US) AppleWebKit/525.18 (KHTML, like Gecko, Safari/525.20) OmniWeb/v622.1.0.104377,gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:7533 Date: 2008-08-28T00:28:29-07:00 List-Id: The following is a program which emulates the structure of a binding to a bunch of C code (but there is no C code included here--it is all Ada). This structure exhibits a behavior which I think might be a compiler error but could be the result of incorrect declarations when running on certain machines. Specifically, the program compiles (with two warnings which are expected and OK) and runs correctly on my machine, OS X 10.4.11 running GNAT 4.3.0 (32-bit PowerPC G4). However, on someone else's box, a 64-bit Intel Duo running Debian lenny and GNAT 4.3.1-2, the program compiles but bombs at runtime with raised STORAGE_ERROR : stack overflow (or erroneous memory access) reported. However, on the Debian lenny machine, if the three lines with --*** at the end of them are commented out (they relate to Pragma-C conventions), the program compiles and runs correctly, printing out 10 lines of floats. (It also runs correctly on the OS X machine.) Here is the program, stored in two files (damn the line wraps): ========== Begin program ========== with type_declaration, Ada.Text_IO; use type_declaration, Ada.Text_IO; procedure x19a_temp is procedure mapform19(n : Integer; x : in out Real_Vector); --*** pragma Convention(C, mapform19); --*** procedure mapform19(n : Integer; x : in out Real_Vector) is begin for i in 0 .. n - 1 loop x(i) := Long_Float(i); Put_Line(Long_Float'image(x(i))); end loop; end mapform19; begin plmap(mapform19'Unrestricted_Access); end x19a_temp; package type_declaration is type Real_Vector is array (Integer range <>) of Long_Float; type Map_Form_Function_Pointer_Type is access procedure (Length_Of_x : Integer; x : in out Real_Vector); pragma Convention(Convention => C, Entity => Map_Form_Function_Pointer_Type); --*** procedure plmap(Map_Form_Function_Pointer : Map_Form_Function_Pointer_Type); end type_declaration; ========== End program ============ Now: Here are some integer declaration sizes for the OS X 32-bit version and the Debian 64-bit version. I could provide more but these should be more than sufficient if there is in fact a problem in this area. ===== OS X 32-bit sizes ===== Integer bits is 32 Long_Integer bits is 32 Long_Long_Integer bits is 64 Long_Float bits is 64 In Interfaces.C, int bits is 32 In Interfaces.C, long bits is 32 In Interfaces.C, C_float bits is 32 In Interfaces.C, double bits is 64 ===== Debian 64-bit sizes ===== Integer bits is 32 Long_Integer bits is 64 Long_Long_Integer bits is 64 Long_Float bits is 64 In Interfaces.C, int bits is 32 In Interfaces.C, long bits is 64 In Interfaces.C, C_float bits is 32 In Interfaces.C, double bits is 64 I'm inclined to think that there is a compiler problem that makes the 64-bit Debian version crash but am wondering if there could be a problem with word lengths that causes the problem. As a second problem, in the program above there is a loop line that looks like this: for i in 0 .. n - 1 loop One would normally write this as for i in x'range loop but when this runs on the OS X box, it segfaults after printing about 187 lines of bogus floats. I don't know what happens on the Debian box. However, if the -- *** lines are commented out, it runs OK on OS X. Comments? Jerry