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).
>>>
>>> [EMAIL PROTECTED]> ./x19a_temp
>>>
>>> raised STORAGE_ERROR : stack overflow (or erroneous memory access)
>
> To get a broader picture about this issue, I would appreciate it if
> everyone
> with access to gnat (it's a standard package on Debian and probably
> most
> 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
> (see
> output below) on all 32-bit platforms. Please include your distro,
> gnat
> 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?
>>>
>>> Alan
>>>
>> 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.
>
> [EMAIL PROTECTED]> uname -a
> Linux raven 2.6.25-2-amd64 #1 SMP Mon Jul 14 11:05:23 UTC 2008 x86_64
> GNU/Linux
>
>>
>> [...]Also, I wonder if the problem is related to the fact that C
>> calling
>> 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 =>
>> Map_Form_Function_Pointer_Type);
>
> With those 3 lines commented out, the compiler warnings are gone
> and the
> programme works.
>
> [EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]> ./x19a_temp
> 0.00000000000000E+00
> 1.00000000000000E+00
> 2.00000000000000E+00
> 3.00000000000000E+00
> 4.00000000000000E+00
> 5.00000000000000E+00
> 6.00000000000000E+00
> 7.00000000000000E+00
> 8.00000000000000E+00
> 9.00000000000000E+00
>
> 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
> Debian
> bug reports quite often. If we don't get help from Debian, then the
> next
> step (or perhaps simultaneous step?) is to post the same bug report
> to the
> GCC gnat developers.
>
> Alan
>
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
fault.
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
32-bit boxes?
Jerry
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
