On Aug 25, 2008, at 11:33 PM, Alan W. Irwin wrote:
> On 2008-08-25 22:02-0700 Jerry wrote:
>> On Aug 25, 2008, at 8:18 PM, Alan W. Irwin wrote:
>>> We now have a working simple test case that generates the run-time
>>> error (at
>>> least on my 64-bit box with gnat version 4.3.1-2).
>>> irwin@...> ./x19a_temp
>>> raised STORAGE_ERROR : stack overflow (or erroneous memory access)
> To get a broader picture about this issue, I would appreciate it if
> with access to gnat (it's a standard package on Debian and probably
> other distros as well) try the simple example to make sure it
> always raises
> the above error at run-time on all 64-bit platforms and works fine
> output below) on all 32-bit platforms. Please include your distro,
> version, and hardware with each report.
>>> Jerry, did the compressed tarball attachment survive your ISP? If
>>> so does it
>>> compile and run properly for you?
>> I got the tarball. It compiles and runs correctly on my machine.
>> I'm running GNAT 4.3.0.
>> So what do we do now? I'm inclined to post this example to
>> comp.lang.ada but maybe I should just directly figure out how to file
>> a bug report. Alan, remind me what OS
> Debian lenny
>> and hardware you're running.
> 64-bit Intel duo processor.
> irwin@...> uname -a
> Linux raven 2.6.25-2-amd64 #1 SMP Mon Jul 14 11:05:23 UTC 2008 x86_64
>> [...]Also, I wonder if the problem is related to the fact that C
>> conventions are being enforced. Alan, if you want to, you could try
>> commenting out those lines--when I do so, it still compiles and runs.
>> Anything we learn from this won't help us PLplot-wise since we need
>> the C calling convention but it might help the GNAT people if they
>> look into this. That would be:
>> In x19a_temp.adb, comment out, using --:
>> procedure mapform19(n : Integer; x : in out Real_Vector);
>> pragma Convention(C, mapform19);
>> In type_declarations.ads, comment out:
>> pragma Convention(Convention => C, Entity =>
> With those 3 lines commented out, the compiler warnings are gone
> and the
> programme works.
> irwin@...> gnatmake x19a_temp.adb
> gcc-4.3 -c x19a_temp.adb
> gcc-4.3 -c type_declaration.adb
> gnatbind -x x19a_temp.ali
> gnatlink x19a_temp.ali
> irwin@...> ./x19a_temp
> I would try comp.ada.lang first with the simple example. If you
> don't get
> any quick help there (say within a few days) or if the response is
> the code
> should work fine on 64-bit platforms, then the next step would be
> to write a
> gnatmake bug report including the simple example and send it to
> Debian to
> start with. I would be willing to do that part of it since I write
> bug reports quite often. If we don't get help from Debian, then the
> step (or perhaps simultaneous step?) is to post the same bug report
> to the
> GCC gnat developers.
FWIW, there is a second bug in this simple example code that appears
on _my_ machine but there is an easy work-around that I've already
implemented. But it should be mentioned in any bug reports that we file.
In the procedure mapform19 there should be a line such as this, if
normal Ada programming practice were followed:
for i in x'range loop
This begins a loop with the loop variable i which ranges over the
extent of the indices of array x which in this case is 0 through 9.
However, with the three "pragma Convention (C, foo)" lines _in_ (see
earlier e-mail in this thread), the program spits out a bunch of
bogus numbers (187 of them, it seems), then bombs with a segmentation
With the three lines _out_, it runs fine.
The work-around is to replace the above line with
for i in 0 .. n loop
which runs OK with the three lines in or out.
Finally, a dumb question. Is there any chance that floats, ints,
doubles, etc. in C or Floats, Integers, Long_Floats, or Long_Integers
in Ada have different sizes between languages on 64-bit boxes than on