Re: Possible compiler bug with this simple program

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

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.