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,e5a3abec221df39 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!v13g2000pro.googlegroups.com!not-for-mail From: Jerry Newsgroups: comp.lang.ada Subject: Re: Possible compiler bug with this simple program Date: Thu, 28 Aug 2008 14:16:21 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <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: quoted-printable X-Trace: posting.google.com 1219958182 28501 127.0.0.1 (28 Aug 2008 21:16:22 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 28 Aug 2008 21:16:22 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: v13g2000pro.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:7542 Date: 2008-08-28T14:16:21-07:00 List-Id: On Aug 28, 12:28=A0am, Jerry wrote: > 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 > > =A0 =A0--*** > > 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): > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Begin program =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > with > =A0 =A0 type_declaration, > =A0 =A0 Ada.Text_IO; > use > =A0 =A0 type_declaration, > =A0 =A0 Ada.Text_IO; > > procedure x19a_temp is > > =A0 =A0 procedure mapform19(n : Integer; x : in out Real_Vector); --*** > =A0 =A0 pragma Convention(C, mapform19); --*** > > =A0 =A0 procedure mapform19(n : Integer; x : in out Real_Vector) is > =A0 =A0 begin > =A0 =A0 =A0 =A0 for i in 0 .. n - 1 loop > =A0 =A0 =A0 =A0 =A0 =A0 x(i) :=3D Long_Float(i); > =A0 =A0 =A0 =A0 =A0 =A0 Put_Line(Long_Float'image(x(i))); > =A0 =A0 =A0 =A0 end loop; > =A0 =A0 end mapform19; > > begin > =A0 =A0 plmap(mapform19'Unrestricted_Access); > end x19a_temp; > > package type_declaration is > > =A0 =A0 type Real_Vector is array (Integer range <>) of Long_Float; > > =A0 =A0 type Map_Form_Function_Pointer_Type is access > =A0 =A0 =A0 =A0 procedure (Length_Of_x : Integer; x : in out Real_Vector)= ; > =A0 =A0 pragma Convention(Convention =3D> C, > =A0 =A0 =A0 =A0 =A0Entity =3D> Map_Form_Function_Pointer_Type); --*** > > =A0 =A0 procedure plmap(Map_Form_Function_Pointer : > Map_Form_Function_Pointer_Type); > > end type_declaration; > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D End program =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > 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. > > =3D=3D=3D=3D=3D OS X 32-bit sizes =3D=3D=3D=3D=3D > Integer bits is =A032 > Long_Integer bits is =A032 > Long_Long_Integer bits is =A064 > Long_Float bits is =A064 > 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 > > =3D=3D=3D=3D=3D Debian 64-bit sizes =3D=3D=3D=3D=3D > Integer bits is =A032 > Long_Integer bits is =A064 > Long_Long_Integer bits is =A064 > Long_Float bits is =A064 > 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: > > =A0 =A0 =A0 =A0 for i in 0 .. n - 1 loop > > One would normally write this as > > =A0 =A0 =A0 =A0 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 Thanks, everybody, for the comments. As for the second problem ( in 0 .. n - 1 loop versus for i in x'range loop), my main concern (since I have a workaround--the first form) is that the compiler allows the second form at all. It looks like a situation where a simple syntactically correct program bombs. Also, I should have mentioned that the two warnings that are emitted at compile time as a result of passing the unconstrained array via C conventions are this: x19a_temp.adb:10:38: warning: type of argument "mapform19.x" is unconstrained array x19a_temp.adb:10:38: warning: foreign caller must pass bounds explicitly I get this pair of warnings in other places where I do some callbacks to C so I expected to see it here, as well, and I'm fine with that. Also, I apologize for not including the body part of type_declarations which looks like this: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Begin body part =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D package body type_declaration is procedure plmap(Map_Form_Function_Pointer : Map_Form_Function_Pointer_Type) is xx : Real_Vector(0 .. 9); begin Map_Form_Function_Pointer(xx'length, xx); end plmap; end type_declaration; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D End body part =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Does the declaration of xx here as a constrained array change anyone's comments about array boundaries not being known later?