Possible compiler bug with this simple program

Jerry writes:
> 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 ???;

Yes. In addition, these might help:

for Real_Vector'Component_Size use 64;
for Real_Vector'Alignment use 64;
pragma Pack (Real_Vector);

I'm actually puzzled as to why the program appears to work on 32-bit
platforms. I would expect a Storage_Error when accessing X (0) since,
per your declaration, X'First = Integer'First = -2**31, so X (0) is
probably way past the end of the array. The first thing I would try
is using Natural instead of Integer as the array index subtype. If
that fails, try specifying the 'Alignment and 'Component_Size. If
that still fails, look at the assembly code emitted on amd64.

I just received http://bugs.debian.org/497067, BTW.

--
Ludovic Brenta.

On Aug 29, 1:39*pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> I'm actually puzzled as to why the program appears to work on 32-bit
> platforms. I would expect a Storage_Error when accessing X (0) since,
> per your declaration, X'First = Integer'First = -2**31, so X (0) is
> probably way past the end of the array. *The first thing I would try
> is using Natural instead of Integer as the array index subtype. *If
> that fails, try specifying the 'Alignment and 'Component_Size. *If
> that still fails, look at the assembly code emitted on amd64.
>
> I just receivedhttp://bugs.debian.org/497067, BTW.
>
> --
> Ludovic Brenta.

Thanks, Ludovic. I'll try these things and report back.

The bug report that you reference is (obviously) from the person who
initially noticed the problem on his 64-bit machine.

In his post he asks for others to try the simple example (which is a
linked tarball from the bug page that you listed) to collect more
evidence that the problem is only on 64-bit machines and not 32-bit
machines.

Here is the tarball link that might work from here:
http://bugs.debian.org/cgi-bin/bugre...t=1;bug=497067

Jerry

On Aug 29, 2:20*pm, Jerry <lancebo...@qwest.net> wrote:
>
> Thanks, Ludovic. I'll try these things and report back.
>
> Jerry

Actually, I don't have access to a 64-bit crahsing machine so trying
these things is difficult, involving e-mailing test programs to
someone who does have such a machine.

Jerry

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:48b7a778$0$23608$4f793bc4@news.tdc.fi...
....
> 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.

That is correct. For Ada, the passed in object must have some bounds, and
the compiler either invents them (hopefully documented somewhere), or
preferably, rejects the representation clause in the first place. I believe
early drafts of this AI required rejection, but there was enough concern
with compatibility that that was weakened in the final version. In any case,
this sort of thing is not portable in any way; you have to figure out what a
particular compiler does in order to use it at all.

The OP should keep in mind that an appropriate bug fix for GNAT is to reject
this example, so it's not clear to me that there is much value to pushing
for a bug fix here. The code should be fixed to avoid unconstrained array
parameters and results unless there is no chance that it will ever be used
on a different Ada compiler (including a newer version of GNAT, which could
change how this is handled).

Randy.

"Jerry" <lanceboyle@qwest.net> wrote in message
news:97b1150b-cb8f-4972-b594-2ae59af84147@x16g2000prn.googlegroups.com...
....
>FWIW, in the _real_ application that I am working on, plmap is written
>in C (and accessed from my binding by an Import).

Interestingly, that's completely different. That *should* work on all Ada
compilers (note that the wording specifically excludes unconstrained
parameters for pragma Import).

This example program is unportable garbage, unfortunately, because of
AI05-0002-1, and also because of B.1(38.1/2) (the "buyer beware" clause:
there is no requirement that an Ada program actually work as expected if you
force its conventions to another language (like C).

Admittedly, this is a bit strange. In this case, C works fine as the
receiver of such a call because it has no need to know the bounds of the
array passed. (And if it does, they're going to be passed explicitly.) But
Ada does need to know those bounds, and you can't even pass them explicitly
because the Ada compiler will have to assume something for the lower bound
in order to generate indexing operations (and that may be different than
what you intended).

The net effect is that the example program doesn't prove anything useful. It
would need to import an actual C subprogram in order to be a useful test.

Randy.

On Aug 29, 6:00*pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Jerry" <lancebo...@qwest.net> wrote in message
>
> news:97b1150b-cb8f-4972-b594-2ae59af84147@x16g2000prn.googlegroups.com...
> ...
>
> >FWIW, in the _real_ application that I am working on, plmap is written
> >in C (and accessed from my binding by an Import).
>
> Interestingly, that's completely different. That *should* work on all Ada
> compilers (note that the wording specifically excludes unconstrained
> parameters for pragma Import).
>
> This example program is unportable garbage, unfortunately, because of
> AI05-0002-1, and also because of *B.1(38.1/2) (the "buyer beware" clause:
> there is no requirement that an Ada program actually work as expected if you
> force its conventions to another language (like C).
>
> Admittedly, this is a bit strange. In this case, C works fine as the
> receiver of such a call because it has no need to know the bounds of the
> array passed. (And if it does, they're going to be passed explicitly.) But
> Ada does need to know those bounds, and you can't even pass them explicitly
> because the Ada compiler will have to assume something for the lower bound
> in order to generate indexing operations (and that may be different than
> what you intended).
>
> The net effect is that the example program doesn't prove anything useful.It
> would need to import an actual C subprogram in order to be a useful test.
>
> * * * * * * * * * * * * * * * * * * * * *Randy.

OK--this clears things up for me. And possibly validates the reason I
wrote the _real_ application the way that I did, thinking that C
arrays always starts from 0 so passing the length along as a separate
parameter should work.

But it looks like in testing (and posting) an all-Ada example I
muddied the situation--or worse--used a completely different example
from what my original code was.

I'll see if I can make another example where plmap is a simple program
in C that is Import-ed and see if it bombs on a 64-bit computer.

Jerry

On Aug 29, 9:47*pm, Jerry <lancebo...@qwest.net> wrote:
> On Aug 29, 6:00*pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > "Jerry" <lancebo...@qwest.net> wrote in message
>
> > >FWIW, in the _real_ application that I am working on, plmap is written
> > >in C (and accessed from my binding by an Import).
>
> > Interestingly, that's completely different. That *should* work on all Ada
> > compilers (note that the wording specifically excludes unconstrained
> > parameters for pragma Import).
<snip>
> > * * * * * * * * * * * * * * * * * ** * *Randy.
>
> I'll see if I can make another example where plmap is a simple program
> in C that is Import-ed and see if it bombs on a 64-bit computer.
>
> Jerry

I've changed the simple example so that plmap is implemented in C.

The results are the same as with the all-Ada version: It runs OK on my
OS X 10.4.11 machine, PPC, Ada 4.3, but my colleague reports that it
crashes on his 64-bit machine which I believe is still the 64-bit
Intel Duo running Debian lenny and GNAT 4.3.1-2. The crash looks the
same as before:

raised STORAGE_ERROR : stack overflow (or erroneous memory access)

The example as either a zip or tarball which includes the very short
code files and a three-line bash script can be downloaded from my site
here:

http://public.me.com/oscarruitt

or directly here:

http://public.me.com/oscarruitt/simp...ase_with_c.zip
http://idisk.mac.com/oscarruitt-Publ...ase_with_c.zip

(Let me know if these don't work.)

And here is the code directly:


-- x19a_temp.adb

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;



-- type_declaration.ads

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);
pragma Import(C, plmap, "plmap");

end type_declaration;



/* plplot.h */

#include <stdint.h>
void plmap( void (*mapform)(int32_t, double *));



/* plmap.c */

#include "plplot.h"
void plmap( void (*mapform)(int32_t, double *) )
{
int32_t n;
double xx[10];
n = 10;
(*mapform)(n, xx);
}


# Compile and run with these lines:

gcc -c plmap.c
gnatmake x19a_temp.adb -largs plmap.o
../x19a_temp


Thanks once again.

Jerry

> And that would look something like this?
>
> for Long_Float'Alignment use 64;
> for Real_Vector'Alignment use ???;
>
Note that 'Size is specified in _bits_ but 'Alignment is in _bytes_
(well, in storage units), so I assume that you really mean:

for Long_Float'Size use 64; -- bits
for Long_Float'Alignment use 8; -- bytes

Cheers,

--
Santiago Urueña-Pascual <suruena@gmail.com>

On Sep 1, 4:19*am, Jerry <lancebo...@qwest.net> wrote:
> On Aug 29, 9:47*pm, Jerry <lancebo...@qwest.net> wrote:
>
> > On Aug 29, 6:00*pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > > "Jerry" <lancebo...@qwest.net> wrote in message
>
> > > >FWIW, in the _real_ application that I am working on, plmap is written
> > > >in C (and accessed from my binding by an Import).
>
> > > Interestingly, that's completely different. That *should* work on allAda
> > > compilers (note that the wording specifically excludes unconstrained
> > > parameters for pragma Import).
> * *<snip>
> > > * * * * * * * * * * * * * * * * * * * * *Randy.
>
> > I'll see if I can make another example where plmap is a simple program
> > in C that is Import-ed and see if it bombs on a 64-bit computer.
>
> > Jerry
>
> I've changed the simple example so that plmap is implemented in C.
>
There haven't been any responses about the above post with mixed Ada-C
code from this list but I have reports from the other developers on my
project that it also runs OK on 32-bit systems but hangs on 64-bit
systems.

Unless somebody has further comments in a few days about why this
isn't a bug, I'm going to report it as such.

Jerry

On Sep 2, 9:22 pm, Jerry <lancebo...@qwest.net> wrote:
> On Sep 1, 4:19 am, Jerry <lancebo...@qwest.net> wrote:
>
> > On Aug 29, 9:47 pm, Jerry <lancebo...@qwest.net> wrote:
>
> > > On Aug 29, 6:00 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > > > "Jerry" <lancebo...@qwest.net> wrote in message
>
> > > > >FWIW, in the _real_ application that I am working on, plmap is written
> > > > >in C (and accessed from my binding by an Import).
>
> > > > Interestingly, that's completely different. That *should* work on all Ada
> > > > compilers (note that the wording specifically excludes unconstrained
> > > > parameters for pragma Import).
> > <snip>
> > > > Randy.
>
> > > I'll see if I can make another example where plmap is a simple program
> > > in C that is Import-ed and see if it bombs on a 64-bit computer.
>
> > > Jerry
>
> > I've changed the simple example so that plmap is implemented in C.
>
> There haven't been any responses about the above post with mixed Ada-C
> code from this list but I have reports from the other developers on my
> project that it also runs OK on 32-bit systems but hangs on 64-bit
> systems.
>
> Unless somebody has further comments in a few days about why this
> isn't a bug, I'm going to report it as such.

Several of us have pointed out that it's a bad idea to use an
unconstrained array type (i.e. Real_Vector) as a parameter to an
imported routine (or a routine with convention C), but the above code
still did it.

-- Adam