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

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.

I cannot test your program now but it seems to me that perhaps you
should specify the alignment of the arrays and Long_Floats. Also, it
might be a good idea to double-check that on the Intel Core 2, the
long floats are really 64 bits and not 80 bits wide. It could be that
the compiler got that wrong but I doubt it.

Also, have you tried to compare the assembly language emitted by the
compiler with and without pragma Convention? (try gnatmake -c -cargs -
S)

[...]
> 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.

This is to be expected. With convention C, there is no array anymore;
instead the procedure receives a pointer to the first element of the
array, so it doesn't have any information about the range. That's why
it is necessary to pass the length of the array separately.

HTH

--
Ludovic Brenta.

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.

I suspect that one problem is using the C convention to pass a
parameter that is of an unconstrained array type, see below.

> 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):
>
....
>
> 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
....
>
>
> package type_declaration is
>
> type Real_Vector is array (Integer range <>) of Long_Float;

So Real_Vector is an unconstrained array type. According to RM
B.3(70), the C convention passes only a single pointer to the first
element of the array, so the 'Range attribute will not be available
to the subprogram.

> 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?

My guess: the compiler implements convention C for the x parameter,
which means x'range is not available, but the code for the second
quoted for-loop tries to access x'range anyway -- boom! The
compiler should IMHO have rejected the use of x'range here, with an
error message.

Using the first form of the quoted loop may trigger the same
problem in the code that checks that x(i) has a valid index, i.

In fact, when an Ada subprogram has an unconstrained array
parameter with Convention C, it seems to me that the subprogram's
body cannot make any use of individual elements of the array,
because it doesn't know the index range, so the compiler should
reject any indexing of such an array parameter, as well as any
attempt to pass it on as a Convention Ada parameter.

Conclusion: Your program tries to do something that cannot possibly
work, but the compiler should have told you so.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

On Aug 28, 1:03 am, Niklas Holsti <niklas.hol...@tidorum.invalid>
wrote:

> In fact, when an Ada subprogram has an unconstrained array
> parameter with Convention C, it seems to me that the subprogram's
> body cannot make any use of individual elements of the array,
> because it doesn't know the index range, so the compiler should
> reject any indexing of such an array parameter, as well as any
> attempt to pass it on as a Convention Ada parameter.

Yes, good point. For an unconstrained array parameter like X, the
compiler doesn't need to know what X'Last is in order to access
elements of the array---but it does need to know X'First. (X'Last is
needed for range checking but not for actually accessing elements.)
If you're using strictly Ada, with no Convention parameters or
anything, then when mapform19 is called, the caller somehow has to
make X'First and X'Last available to the routine, and then when X(I)
is accessed, the generated code must compute I - X'First, multiply
that by the element size, and add the result to the address of X's
data. When mapform19 is called from a C routine, nothing will be
passed in for X'First, but mapform19 will still try to subtract
something from I, and what value it will subtract is quite random---
could be zero, could be some other garbage value.

I agree that the compiler should have rejected this. But it might
work to declare Real_Vector as a constrained array:

type Real_Vector is array (0 .. Integer'Last) of Long_Float;

Now the compiler will know that X'First is 0 and, hopefully, behave
correctly.

-- Adam

On Aug 28, 8:54 am, Adam Beneschan <a...@irvine.com> wrote:

> I agree that the compiler should have rejected this. But it might
> work to declare Real_Vector as a constrained array:
>
> type Real_Vector is array (0 .. Integer'Last) of Long_Float;

Or, perhaps, declare a subtype:

subtype Constrained_Real_Vector is Real_Vector (0 ..
Integer'Last);

and use the subtype as the parameter type in mapform19 and your access-
to-procedure type.

-- Adam

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:48b65b3b$0$25384$4f793bc4@news.tdc.fi...
....
> In fact, when an Ada subprogram has an unconstrained array parameter with
> Convention C, it seems to me that the subprogram's body cannot make any
> use of individual elements of the array, because it doesn't know the index
> range, so the compiler should reject any indexing of such an array
> parameter, as well as any attempt to pass it on as a Convention Ada
> parameter.

This is the subject of AI05-0002-1. (It was carried over from the Ada 95.)
[Now, I have to go look this one up because I don't remember anything about
what we decided...] Ah, yes:

"We do not require support for C convention interfacing pragmas for
unconstrained
array objects, unconstrained array function results, and most unconstrained
array parameters."

In particular, "An implementation need not support ... an Export or
Convention pragma applied to a subprogram which has a parameter of an
unconstrained array subtype;". The wording goes on to include unconstrained
array objects and function results as well.

Note that an implementation *can* support this if it wants; some
implementations do implement this with various meanings (Tucker reported
that their compiler gives the array maximum bounds) and it was thought to be
bad to break user programs that depend on such behaviors. But if it does
support it, it ought to do something sensible (raising random exceptions
doesn't count). (Also note that it is required to support pragma Import in
this case, as C doesn't care about the bounds and they can just be dropped.)

> Conclusion: Your program tries to do something that cannot possibly work,
> but the compiler should have told you so.

Well, not necessarily (see Tucker's implementation, for instance). But
either it should do something defined *or* reject it at compile-time.
(Janus/Ada would have rejected the Convention pragma.) In any case, it is
not required to support this in any useful way, and, as it is not portable,
it should be avoided.

Randy.

On Aug 28, 12:56*am, Ludovic Brenta <ludo...@ludovic-brenta.org>
wrote:
> I cannot test your program now but it seems to me that perhaps you
> should specify the alignment of the arrays and Long_Floats. Also, it
> might be a good idea to double-check that on the Intel Core 2, the
> long floats are really 64 bits and not 80 bits wide. It could be that
> the compiler got that wrong but I doubt it.
>
And that would look something like this?

for Long_Float'Alignment use 64;
for Real_Vector'Alignment use ???;

Jerry

On Aug 28, 12:28*am, Jerry <lancebo...@qwest.net> 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
>
> * *--***
>
> 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


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:

========== Begin body part ==========

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;

========== End body part ==========

Does the declaration of xx here as a constrained array change anyone's
comments about array boundaries not being known later?

On Aug 28, 2:01*pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Niklas Holsti" <niklas.hol...@tidorum.invalid> wrote in message
>
> news:48b65b3b$0$25384$4f793bc4@news.tdc.fi...
> ...
>
> > In fact, when an Ada subprogram has an unconstrained array parameter with
> > Convention C, it seems to me that the subprogram's body cannot make any
> > use of individual elements of the array, because it doesn't know the index
> > range, so the compiler should reject any indexing of such an array
> > parameter, as well as any attempt to pass it on as a Convention Ada
> > parameter.
>
> This is the subject of AI05-0002-1. (It was carried over from the Ada 95.)
> [Now, I have to go look this one up because I don't remember anything about
> what we decided...] Ah, yes:
>
> "We do not require support for C convention interfacing pragmas for
> unconstrained
> array objects, unconstrained array function results, and most unconstrained
> array parameters."
>
> In particular, "An implementation need not support ... an Export or
> Convention pragma applied to a subprogram which has a parameter of an
> unconstrained array subtype;". The wording goes on to include unconstrained
> array objects and function results as well.
>
> Note that an implementation *can* support this if it wants; some
> implementations do implement this with various meanings (Tucker reported
> that their compiler gives the array maximum bounds) and it was thought tobe
> bad to break user programs that depend on such behaviors. But if it does
> support it, it ought to do something sensible (raising random exceptions
> doesn't count). (Also note that it is required to support pragma Import in
> this case, as C doesn't care about the bounds and they can just be dropped.)
>
> > Conclusion: Your program tries to do something that cannot possibly work,
> > but the compiler should have told you so.
>
> Well, not necessarily (see Tucker's implementation, for instance). But
> either it should do something defined *or* reject it at compile-time.
> (Janus/Ada would have rejected the Convention pragma.) In any case, it is
> not required to support this in any useful way, and, as it is not portable,
> it should be avoided.
>
> * * * * * * * * * * * * * * * * * * * *Randy.

Thanks, Randy. This is useful.

Superficially, in my situation, it appears that GNAT 4.3.0 on OS X PPC
supports it and GNAT 4.3.1-2 on Debian lenny on Intel duo does not
support it. I suppose there could be an element of dumb luck of GNAT
is not supposed to support it and it just happens to work on OS X. On
the other hand, if GNAT is supposed to support it then the Debian/
Intel version is broken.

The fact that warnings are issued (see my other post today where I
actually list the two warnings) indicates that passing unconstrained
arrays is supported but the caller had better not screw things up by
trying to access outside bounds (which my example handles correctly).
If that is the case, it looks like the Debian/Intel box is broken.

And yes, portability isn't good, according to your report.

FWIW, in the _real_ application that I am working on, plmap is written
in C (and accessed from my binding by an Import).

Do AdaCore people have any comments on this?

Jerry

Jerry wrote:
> On Aug 28, 12:28 am, Jerry <lancebo...@qwest.net> 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
>>
>> --***
>>
>>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 ============
....
>>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
>
>
>
> 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) ...

Even if the workaround using "in 0 .. n - 1" works on a given
compiler and machine, according to Randy this depends on
non-standard (ie. generally unportable) features of the compiler.

For example, Randy mentioned that Tucker's compiler would give the
x-array "maximum bounds", which in this case seems to mean
Integer'First .. Integer'Last, and so x(0) would lie somewhere far
beyond the actual array in memory.

For "in 0 .. n-1" to work on Tucker's compiler, you should probably
declare Real_Vector using Natural indices instead of Integer
indices, to make the "maximum bounds" be 0 .. Natural'Last.

> 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.

In C code there is no problem, as all arrays start at index 0.
(Which, of course, leads to other problems, but they are on the
design level :-)

> Also, I apologize for not including the body part of type_declarations
> which looks like this:
>
> ========== Begin body part ==========
>
> 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;
>
> ========== End body part ==========
>
> Does the declaration of xx here as a constrained array change anyone's
> comments about array boundaries not being known later?

Not for me. Although the "xx" *object* is constrained, the *type*
is still unconstrained. This is the point: Convention C means that
the actual index range of "xx", although known at the point of
call, is not passed to Map_Form_Function_Pointer.all.

If I understand Randy's explanation correctly, it does not even
help to pass the index range explicitly (instead of passing just
the length, as in your code), because the compiler invents some
index range of its own for accessing the Convention C
unconstrained-array parameter within the Ada body of the
subprogram. For this code to work, you must just know what this
invented index-range is, in your compiler.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .