Possible compiler bug with this simple program

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
.