* Anyone else run ACATS on ARM?
@ 2009-08-12 16:40 Joel Sherrill
2009-08-12 22:23 ` Martin Guy
2009-08-27 4:24 ` Geert Bosch
0 siblings, 2 replies; 19+ messages in thread
From: Joel Sherrill @ 2009-08-12 16:40 UTC (permalink / raw)
To: gcc
Hi,
GNAT doesn't build for arm-rtems on 4.4.x or
SVN (PR40775). I went back to 4.3.x since I
remembered it building.
I have run the ACATS on an ep7312 target and
get a number of generic test failures that
don't look RTEMS specific. Has anyone run
ACATS on arm?
The following tests fail with gcc 4.3.4:
c34006d c34006f c34006j c34006l c34007s c34007u c34009d
c34009f c34009j c34009l c380004 c64201c c761007 c85006a
c85006b c85006c c85006d c85006e c93001a c93005b c951001
c951002 c953002 cd72a02 cxa5a01 cxa5a02 cxa5a03 cxa5a04
cxa5a05 cxa5a06 cxa5a07 cxa5a08 cxa5a09 cxa5a10 cxf3a03
cxg1005 cxg2001 cxg2002 cxg2003 cxg2004 cxg2006 cxg2007
cxg2009 cxg2010 cxg2011 cxg2012 cxg2013 cxg2014 cxg2015
cxg2016 cxg2017 cxg2018 cxg2019 cxg2020 cxg2021
Many of the c34 failures appear to be related.
,.,. C34006D ACATS 2.5 88-01-01 00:00:00
---- C34006D CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED
(IMPLICITLY) FOR DERIVED RECORD TYPES WITH DISCRIMINANTS
AND WITH NON-LIMITED COMPONENT TYPES.
* C34006D INCORRECT CONVERSION TO PARENT.
* C34006D INCORRECT SELECTION (VALUE).
**** C34006D FAILED ****************************.
I suspect the cx issues are FPU accuracy on the Skyeye simulator.
,.,. CXF3A03 ACATS 2.5 88-01-01 00:00:00
---- CXF3A03 Check that function Length returns the number of characters
in the edited output string produced by function Image,
for a particular decimal type, currency string, and
radix mark. Check that function Valid returns correct
results based on the particular decimal value, and the
Picture and Currency string parameters.
* CXF3A03 Unexpected exception raised in Length_Block.
**** CXF3A03 FAILED ****************************.
So any ACATS results from any other ARM target would be
appreciated.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-12 16:40 Anyone else run ACATS on ARM? Joel Sherrill
@ 2009-08-12 22:23 ` Martin Guy
2009-08-13 0:24 ` Matthias Klose
2009-08-27 4:24 ` Geert Bosch
1 sibling, 1 reply; 19+ messages in thread
From: Martin Guy @ 2009-08-12 22:23 UTC (permalink / raw)
To: Joel Sherrill; +Cc: gcc
On 8/12/09, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> So any ACATS results from any other ARM target would be
> appreciated.
I looked into gnat-arm for the new Debian port and the conclusion was
that it has never been bootstrapped onto ARM. The closest I have seen
is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
targetting Nucleus OS (gak!)
The community feeling was that it would "just go" given a prodigal
burst of cross-compiling, but I never got achieved sufficiently high
blood pressure to try it...
M
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-12 22:23 ` Martin Guy
@ 2009-08-13 0:24 ` Matthias Klose
2009-08-13 13:29 ` Martin Guy
2009-08-17 12:32 ` Mikael Pettersson
0 siblings, 2 replies; 19+ messages in thread
From: Matthias Klose @ 2009-08-13 0:24 UTC (permalink / raw)
To: Martin Guy; +Cc: Joel Sherrill, gcc, Ludovic Brenta
On 12.08.2009 23:07, Martin Guy wrote:
> On 8/12/09, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
>> So any ACATS results from any other ARM target would be
>> appreciated.
>
> I looked into gnat-arm for the new Debian port and the conclusion was
> that it has never been bootstrapped onto ARM. The closest I have seen
> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
> targetting Nucleus OS (gak!)
>
> The community feeling was that it would "just go" given a prodigal
> burst of cross-compiling, but I never got achieved sufficiently high
> blood pressure to try it...
is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
initial gnat-4.4 package for debian?
Matthias
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-13 0:24 ` Matthias Klose
@ 2009-08-13 13:29 ` Martin Guy
2009-08-17 12:32 ` Mikael Pettersson
1 sibling, 0 replies; 19+ messages in thread
From: Martin Guy @ 2009-08-13 13:29 UTC (permalink / raw)
To: Matthias Klose; +Cc: Joel Sherrill, gcc, Ludovic Brenta
On 8/12/09, Matthias Klose <doko@debian.org> wrote:
> On 12.08.2009 23:07, Martin Guy wrote:
> > I looked into gnat-arm for the new Debian port and the conclusion was
> > that it has never been bootstrapped onto ARM. The closest I have seen
> > is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
> > targetting Nucleus OS (gak!)
>
> is there any arm-linx-gnueabi gnat binary that could be used to bootstrap
> an initial gnat-4.4 package for debian?
No, unless someone has done this since 2007. It involved
cross-compiling to generate a native gnat compiler, but that was not a
priority for ARM Ltd when I was working on this.
M
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-13 0:24 ` Matthias Klose
2009-08-13 13:29 ` Martin Guy
@ 2009-08-17 12:32 ` Mikael Pettersson
2009-08-20 9:21 ` Matthias Klose
` (3 more replies)
1 sibling, 4 replies; 19+ messages in thread
From: Mikael Pettersson @ 2009-08-17 12:32 UTC (permalink / raw)
To: Matthias Klose; +Cc: Martin Guy, Joel Sherrill, gcc, Ludovic Brenta
On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose <doko@debian.org> wrote:
>On 12.08.2009 23:07, Martin Guy wrote:
>> On 8/12/09, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
>>> So any ACATS results from any other ARM target would be
>>> appreciated.
>>
>> I looked into gnat-arm for the new Debian port and the conclusion was
>> that it has never been bootstrapped onto ARM. The closest I have seen
>> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
>> targetting Nucleus OS (gak!)
>>
>> The community feeling was that it would "just go" given a prodigal
>> burst of cross-compiling, but I never got achieved sufficiently high
>> blood pressure to try it...
>
>is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
>initial gnat-4.4 package for debian?
>
> Matthias
Yes, see <http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
There you'll find a native --enable-languages=c,ada gcc-4.4.1 installation
for armv5tel-linux-gnueabi, and a patch file making the relatively minor
changes to gcc-4.4.1 needed for this. I'll also upload a big-endian
armv5teb-linux-gnueabi version once it's finished its final rebuild.
Notes:
- Built from vanilla gcc-4.4.1 sources with only the arm ada patch applied.
- Built with --with-arch=armv5te --prefix=/tmp/gcc-4.4.1-install, glibc-2.7,
gmp-4.2.4, mpfr-2.4.1, and binutils-2.19.1.
- Bootstrap went as follows:
(on i686-linux)
1. I wrote an arm ada support patch for gcc-4.3.4.
2. Built i686->arm cross 4.3.4.
3. Used i686->arm cross to build a crossed native arm->arm on i686.
(on armv5tel-linux-gnueabi)
4. Used the crossed native arm->arm 4.3.4 to build a native on arm.
This worked but generated tons of alignment faults the kernel had
to trap and emulate.
5. My gcc-4.3.4 is heavily updated with backported fixes. I used it to
build a vanilla 4.3.4 with ada but that one failed to build itself.
6. Quickly ported the 4.3.4 patch to 4.4.1, then used the heavily updated
4.3.4 to build a vanilla 4.4.1 with ada.
7. Used the 4.4.1 compiler to rebuild itself with a different --prefix.
This step appears to not have suffered from emulated alignment faults.
Not sure if that's due to 4.4 vs 4.3 or because the crossed native
compiler was tainted by having been built on i686.
8. The final 4.4.1 is what I uploaded.
- The patch includes a change to eliminate pointless use of exceptions
in xsinfo.adb. That was needed for 4.3 and does no harm in 4.4, but I
have not checked if 4.4 actually needs it.
- Test suite has not been run.
I did a similar bootstrap of ada for gcc-4.1.2 and ARM OABI several years ago,
so I had a rough idea on how to proceed. Especially step 3 is complicated
because the ada makefiles are utterly broken for the crossed native build case,
so lots of manual intervention is required there.
(The OABI ada compiler didn't really work however, and required invasive
hacks to avoid complex constructs that it would miscompile. I suspect the
ada compiler was incompatible with the OABI structure alignment rules.)
/Mikael
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-17 12:32 ` Mikael Pettersson
@ 2009-08-20 9:21 ` Matthias Klose
2009-08-20 12:52 ` Joel Sherrill
2009-08-22 18:55 ` Matthias Klose
2009-08-23 5:10 ` [Ada] " Laurent GUERBY
` (2 subsequent siblings)
3 siblings, 2 replies; 19+ messages in thread
From: Matthias Klose @ 2009-08-20 9:21 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: gcc, Ludovic Brenta
On 17.08.2009 12:00, Mikael Pettersson wrote:
> On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose<doko@debian.org> wrote:
>> On 12.08.2009 23:07, Martin Guy wrote:
>>> On 8/12/09, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
>>>> So any ACATS results from any other ARM target would be
>>>> appreciated.
>>>
>>> I looked into gnat-arm for the new Debian port and the conclusion was
>>> that it has never been bootstrapped onto ARM. The closest I have seen
>>> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
>>> targetting Nucleus OS (gak!)
>>>
>>> The community feeling was that it would "just go" given a prodigal
>>> burst of cross-compiling, but I never got achieved sufficiently high
>>> blood pressure to try it...
>>
>> is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
>> initial gnat-4.4 package for debian?
> >
> > Matthias
>
> Yes, see<http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
I used these binaries to build a .deb package [1], test results at [2], now
trying to build trunk with this as a bootstrap package. The Debian gnat-4.4
package doesn't build yet as it requires zero cost exception support and
probably more.
Matthias
[1] http://people.debian.org/~doko/gcc/gcc-snapshot_20090722-0ubuntu1_armel.deb
[2] http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02018.html
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-20 9:21 ` Matthias Klose
@ 2009-08-20 12:52 ` Joel Sherrill
2009-08-22 18:55 ` Matthias Klose
1 sibling, 0 replies; 19+ messages in thread
From: Joel Sherrill @ 2009-08-20 12:52 UTC (permalink / raw)
To: Matthias Klose; +Cc: Mikael Pettersson, gcc, Ludovic Brenta
Matthias Klose wrote:
> On 17.08.2009 12:00, Mikael Pettersson wrote:
>
>> On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose<doko@debian.org> wrote:
>>
>>> On 12.08.2009 23:07, Martin Guy wrote:
>>>
>>>> On 8/12/09, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
>>>>
>>>>> So any ACATS results from any other ARM target would be
>>>>> appreciated.
>>>>>
>>>> I looked into gnat-arm for the new Debian port and the conclusion was
>>>> that it has never been bootstrapped onto ARM. The closest I have seen
>>>> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
>>>> targetting Nucleus OS (gak!)
>>>>
>>>> The community feeling was that it would "just go" given a prodigal
>>>> burst of cross-compiling, but I never got achieved sufficiently high
>>>> blood pressure to try it...
>>>>
>>> is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
>>> initial gnat-4.4 package for debian?
>>>
>> >
>> > Matthias
>>
>> Yes, see<http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
>>
>
> I used these binaries to build a .deb package [1], test results at [2], now
> trying to build trunk with this as a bootstrap package. The Debian gnat-4.4
> package doesn't build yet as it requires zero cost exception support and
> probably more.
>
Your ACATS have more failures than mine on RTEMS. Is this
a no-OS arm-eabi so no threading or filesystem? My results
appear to focus on some type of math precision issue and a structure
discriminant problem.
It has been a couple of weeks, but I think I started with the head
and worked backwards to 4.3.x to get a compiler built.
--joel
> Matthias
>
> [1] http://people.debian.org/~doko/gcc/gcc-snapshot_20090722-0ubuntu1_armel.deb
> [2] http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02018.html
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-20 9:21 ` Matthias Klose
2009-08-20 12:52 ` Joel Sherrill
@ 2009-08-22 18:55 ` Matthias Klose
1 sibling, 0 replies; 19+ messages in thread
From: Matthias Klose @ 2009-08-22 18:55 UTC (permalink / raw)
To: Matthias Klose; +Cc: Mikael Pettersson, gcc, Ludovic Brenta
On 20.08.2009 10:16, Matthias Klose wrote:
> On 17.08.2009 12:00, Mikael Pettersson wrote:
>> On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose<doko@debian.org>
>> wrote:
>>> On 12.08.2009 23:07, Martin Guy wrote:
>>>> On 8/12/09, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
>>>>> So any ACATS results from any other ARM target would be
>>>>> appreciated.
>>>>
>>>> I looked into gnat-arm for the new Debian port and the conclusion was
>>>> that it has never been bootstrapped onto ARM. The closest I have seen
>>>> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
>>>> targetting Nucleus OS (gak!)
>>>>
>>>> The community feeling was that it would "just go" given a prodigal
>>>> burst of cross-compiling, but I never got achieved sufficiently high
>>>> blood pressure to try it...
>>>
>>> is there any arm-linx-gnueabi gnat binary that could be used to
>>> bootstrap an
>>> initial gnat-4.4 package for debian?
>> >
>> > Matthias
>>
>> Yes, see<http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
>
> I used these binaries to build a .deb package [1], test results at [2],
> now trying to build trunk with this as a bootstrap package. The Debian
> gnat-4.4 package doesn't build yet as it requires zero cost exception
> support and probably more.
>
> Matthias
>
> [1]
> http://people.debian.org/~doko/gcc/gcc-snapshot_20090722-0ubuntu1_armel.deb
> [2] http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02018.html
Mikael's patch applies to the trunk as well; test results are about the same as
for the 4.4 branch [1]. Package can be found at [2]. As long as Ada builds on
the trunk, the ada test results will be included in my emails to gcc-testresults.
Matthias
[1] http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02343.html
[2] http://people.canonical.com/~doko/tmp/gcc-snapshot_20090821-1ubuntu1_armel.deb
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ada] Anyone else run ACATS on ARM?
2009-08-17 12:32 ` Mikael Pettersson
2009-08-20 9:21 ` Matthias Klose
@ 2009-08-23 5:10 ` Laurent GUERBY
2009-08-29 16:29 ` Laurent GUERBY
2009-08-23 14:15 ` Laurent GUERBY
2009-08-23 22:28 ` Ludovic Brenta
3 siblings, 1 reply; 19+ messages in thread
From: Laurent GUERBY @ 2009-08-23 5:10 UTC (permalink / raw)
To: Mikael Pettersson
Cc: Matthias Klose, Martin Guy, Joel Sherrill, gcc, Ludovic Brenta
On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose <doko@debian.org> wrote:
> >On 12.08.2009 23:07, Martin Guy wrote:
> >> On 8/12/09, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
> >>> So any ACATS results from any other ARM target would be
> >>> appreciated.
> >>
> >> I looked into gnat-arm for the new Debian port and the conclusion was
> >> that it has never been bootstrapped onto ARM. The closest I have seen
> >> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
> >> targetting Nucleus OS (gak!)
> >>
> >> The community feeling was that it would "just go" given a prodigal
> >> burst of cross-compiling, but I never got achieved sufficiently high
> >> blood pressure to try it...
> >
> >is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
> >initial gnat-4.4 package for debian?
> >
> > Matthias
>
> Yes, see <http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
Nice work!
Looks like Ada exception propagation (setjmp/longjmp based) is broken at
least in some cases (see below), that might explain the high number of
ACATS failure.
My understanding is that
EH_MECHANISM=-gcc
is not correct for sjlj exceptions so I removed this line from the patch
and I'm currently testing with trunk.
Laurent
guerby@gcc50:~/tmp$ ./hello2
hello Ada
raised PROGRAM_ERROR : hello2.adb:5 explicit raise
guerby@gcc50:~/tmp$ cat hello2.adb
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello2 is
begin
Put_Line ("hello Ada");
raise Program_Error;
Put_Line ("error");
exception
when others =>
Put_Line ("OK");
end Hello2;
guerby@gcc50:~/tmp$ objdump -S hello2.o
objdump -S hello2.o
hello2.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <_ada_hello2>:
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello2 is
0: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
4: e28db020 add fp, sp, #32 ; 0x20
8: e24dd034 sub sp, sp, #52 ; 0x34
begin
Put_Line ("hello Ada");
c: ebfffffe bl 0 <system__soft_links__get_jmpbuf_address_soft>
10: e1a03000 mov r3, r0
14: e50b302c str r3, [fp, #-44]
18: e24b3044 sub r3, fp, #68 ; 0x44
1c: e24b2024 sub r2, fp, #36 ; 0x24
20: e5832000 str r2, [r3]
24: e59f20bc ldr r2, [pc, #188] ; e8 <_ada_hello2+0xe8>
28: e5832004 str r2, [r3, #4]
2c: e583d008 str sp, [r3, #8]
30: e3a03000 mov r3, #0 ; 0x0
34: ea000001 b 40 <_ada_hello2+0x40>
38: e28bb024 add fp, fp, #36 ; 0x24
3c: e3a03001 mov r3, #1 ; 0x1
40: e20330ff and r3, r3, #255 ; 0xff
44: e3530000 cmp r3, #0 ; 0x0
48: 0a000018 beq b0 <_ada_hello2+0xb0>
4c: e51b002c ldr r0, [fp, #-44]
50: ebfffffe bl 0 <system__soft_links__set_jmpbuf_address_soft>
54: ebfffffe bl 0 <system__soft_links__get_gnat_exception>
58: e1a03000 mov r3, r0
5c: e50b3028 str r3, [fp, #-40]
raise Program_Error;
Put_Line ("error");
exception
when others =>
60: e51b3028 ldr r3, [fp, #-40]
64: e5d33000 ldrb r3, [r3]
68: e2233001 eor r3, r3, #1 ; 0x1
6c: e20330ff and r3, r3, #255 ; 0xff
70: e3530000 cmp r3, #0 ; 0x0
74: 0a00000b beq a8 <_ada_hello2+0xa8>
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello2 is
begin
Put_Line ("hello Ada");
78: e59f306c ldr r3, [pc, #108] ; ec <_ada_hello2+0xec>
7c: e5933000 ldr r3, [r3]
80: e12fff33 blx r3
raise Program_Error;
Put_Line ("error");
exception
when others =>
Put_Line ("OK");
84: e59f3064 ldr r3, [pc, #100] ; f0 <_ada_hello2+0xf0>
88: e50b3054 str r3, [fp, #-84]
8c: e59f3060 ldr r3, [pc, #96] ; f4 <_ada_hello2+0xf4>
90: e50b3050 str r3, [fp, #-80]
94: e14b05d4 ldrd r0, [fp, #-84]
98: ebfffffe bl 0 <ada__text_io__put_line__2>
end Hello2;
9c: e51b002c ldr r0, [fp, #-44]
a0: ebfffffe bl 0 <system__soft_links__set_jmpbuf_address_soft>
a4: ea00000d b e0 <_ada_hello2+0xe0>
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello2 is
begin
Put_Line ("hello Ada");
a8: e51b0028 ldr r0, [fp, #-40]
ac: ebfffffe bl 0 <__gnat_raise_nodefer_with_msg>
b0: e24b3044 sub r3, fp, #68 ; 0x44
b4: e1a00003 mov r0, r3
b8: ebfffffe bl 0 <system__soft_links__set_jmpbuf_address_soft>
bc: e59f3034 ldr r3, [pc, #52] ; f8 <_ada_hello2+0xf8>
c0: e50b304c str r3, [fp, #-76]
c4: e59f2030 ldr r2, [pc, #48] ; fc <_ada_hello2+0xfc>
c8: e50b2048 str r2, [fp, #-72]
cc: e14b04dc ldrd r0, [fp, #-76]
d0: ebfffffe bl 0 <ada__text_io__put_line__2>
raise Program_Error;
d4: e59f0024 ldr r0, [pc, #36] ; 100 <_ada_hello2+0x100>
d8: e3a01005 mov r1, #5 ; 0x5
dc: ebfffffe bl 0 <__gnat_rcheck_19>
Put_Line ("error");
exception
when others =>
Put_Line ("OK");
end Hello2;
e0: e24bd020 sub sp, fp, #32 ; 0x20
e4: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
e8: 00000038 .word 0x00000038
...
f4: 00000024 .word 0x00000024
f8: 00000008 .word 0x00000008
fc: 0000002c .word 0x0000002c
100: 00000018 .word 0x00000018
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-17 12:32 ` Mikael Pettersson
2009-08-20 9:21 ` Matthias Klose
2009-08-23 5:10 ` [Ada] " Laurent GUERBY
@ 2009-08-23 14:15 ` Laurent GUERBY
2009-08-23 22:28 ` Ludovic Brenta
3 siblings, 0 replies; 19+ messages in thread
From: Laurent GUERBY @ 2009-08-23 14:15 UTC (permalink / raw)
To: Mikael Pettersson
Cc: Matthias Klose, Martin Guy, Joel Sherrill, gcc, Ludovic Brenta
On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> - The patch includes a change to eliminate pointless use of exceptions
> in xsinfo.adb. That was needed for 4.3 and does no harm in 4.4, but I
> have not checked if 4.4 actually needs it.
This patch is still needed when you use your 4.4.1 binary to bootstrap
trunk, otherwise stage1 xsinfo fails.
Laurent
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-17 12:32 ` Mikael Pettersson
` (2 preceding siblings ...)
2009-08-23 14:15 ` Laurent GUERBY
@ 2009-08-23 22:28 ` Ludovic Brenta
2009-08-24 1:45 ` Mikael Pettersson
3 siblings, 1 reply; 19+ messages in thread
From: Ludovic Brenta @ 2009-08-23 22:28 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: Matthias Klose, Martin Guy, Joel Sherrill, gcc
Mikael Pettersson <mikpe@it.uu.se> writes:
> On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose <doko@debian.org> wrote:
>>is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
>>initial gnat-4.4 package for debian?
>
> Yes, see <http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
Mikael, thanks for this outstanding work! Matthias has now added your
patch to Debian and I'm about to upload gnat-4.4 with it. However I
cannot help but notice that the new file you introduced,
system-linux-armeb.ads, has the GPLv2 or later with special exception
(aka "GNAT-Modified GPL") boilerplate in it. I suggest that a future
version of this patch migrate to GPLv3 or later with the run-time
exception.
--
Ludovic Brenta.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-23 22:28 ` Ludovic Brenta
@ 2009-08-24 1:45 ` Mikael Pettersson
0 siblings, 0 replies; 19+ messages in thread
From: Mikael Pettersson @ 2009-08-24 1:45 UTC (permalink / raw)
To: Ludovic Brenta
Cc: Mikael Pettersson, Matthias Klose, Martin Guy, Joel Sherrill, gcc
Ludovic Brenta writes:
> Mikael Pettersson <mikpe@it.uu.se> writes:
> > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose <doko@debian.org> wrote:
> >>is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
> >>initial gnat-4.4 package for debian?
> >
> > Yes, see <http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
>
> Mikael, thanks for this outstanding work! Matthias has now added your
> patch to Debian and I'm about to upload gnat-4.4 with it. However I
> cannot help but notice that the new file you introduced,
> system-linux-armeb.ads, has the GPLv2 or later with special exception
> (aka "GNAT-Modified GPL") boilerplate in it. I suggest that a future
> version of this patch migrate to GPLv3 or later with the run-time
> exception.
The system-linux-arme{l,b}.ads files have the GPLv2 boilerplate because
they were initially written for gcc-4.3, starting out as clones of the
gcc-4.3 system-linux-ppc.ads file. I just forgot to update the boilerplate
when forward-porting the patch to gcc-4.4. I've now uploaded an incremental
patch to update the boilerplate to match gcc-4.4, so it now mentions GPLv3
instead.
/Mikael
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-12 16:40 Anyone else run ACATS on ARM? Joel Sherrill
2009-08-12 22:23 ` Martin Guy
@ 2009-08-27 4:24 ` Geert Bosch
2009-08-27 14:58 ` Joel Sherrill
1 sibling, 1 reply; 19+ messages in thread
From: Geert Bosch @ 2009-08-27 4:24 UTC (permalink / raw)
To: Joel Sherrill; +Cc: GCC Development
On Aug 12, 2009, at 10:32, Joel Sherrill wrote:
> Hi,
>
> GNAT doesn't build for arm-rtems on 4.4.x or
> SVN (PR40775). I went back to 4.3.x since I
> remembered it building.
> I have run the ACATS on an ep7312 target and
> get a number of generic test failures that
> don't look RTEMS specific. Has anyone run
> ACATS on arm?
>
Yes, we ported it to ARM/Nucleus OS, and we required some fixes to
prologue generation. The patches we submitted for that to the
mailinglist and then pinged, were ignored. I'm sure this is in
the archives somewhere.
-Geert
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-27 4:24 ` Geert Bosch
@ 2009-08-27 14:58 ` Joel Sherrill
2009-08-27 21:37 ` Joel Sherrill
0 siblings, 1 reply; 19+ messages in thread
From: Joel Sherrill @ 2009-08-27 14:58 UTC (permalink / raw)
To: Geert Bosch; +Cc: GCC Development
Geert Bosch wrote:
> On Aug 12, 2009, at 10:32, Joel Sherrill wrote:
>
>
>> Hi,
>>
>> GNAT doesn't build for arm-rtems on 4.4.x or
>> SVN (PR40775). I went back to 4.3.x since I
>> remembered it building.
>> I have run the ACATS on an ep7312 target and
>> get a number of generic test failures that
>> don't look RTEMS specific. Has anyone run
>> ACATS on arm?
>>
>>
> Yes, we ported it to ARM/Nucleus OS, and we required some fixes to
> prologue generation. The patches we submitted for that to the
> mailinglist and then pinged, were ignored. I'm sure this is in
> the archives somewhere.
>
Thanks Geert. I will try to dig them up and try them.
It will be next week before I can try this again. Should
I file a PR to bump this up in visibility?
> -Geert
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-27 14:58 ` Joel Sherrill
@ 2009-08-27 21:37 ` Joel Sherrill
2009-08-28 19:15 ` Olivier Hainque
0 siblings, 1 reply; 19+ messages in thread
From: Joel Sherrill @ 2009-08-27 21:37 UTC (permalink / raw)
To: Geert Bosch; +Cc: GCC Development
Joel Sherrill wrote:
> Geert Bosch wrote:
>
>> On Aug 12, 2009, at 10:32, Joel Sherrill wrote:
>>
>>
>>
>>> Hi,
>>>
>>> GNAT doesn't build for arm-rtems on 4.4.x or
>>> SVN (PR40775). I went back to 4.3.x since I
>>> remembered it building.
>>> I have run the ACATS on an ep7312 target and
>>> get a number of generic test failures that
>>> don't look RTEMS specific. Has anyone run
>>> ACATS onl
--joel
>>> arm?
>>>
>>>
>>>
>> Yes, we ported it to ARM/Nucleus OS, and we required some fixes to
>> prologue generation. The patches we submitted for that to the
>> mailinglist and then pinged, were ignored. I'm sure this is in
>> the archives somewhere.
>>
>>
> Thanks Geert. I will try to dig them up and try them.
>
>
I can't seem to find the patch. Do you have a link?
> It will be next week before I can try this again. Should
> I file a PR to bump this up in visibility?
>
>> -Geert
>>
>>
>
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Anyone else run ACATS on ARM?
2009-08-27 21:37 ` Joel Sherrill
@ 2009-08-28 19:15 ` Olivier Hainque
0 siblings, 0 replies; 19+ messages in thread
From: Olivier Hainque @ 2009-08-28 19:15 UTC (permalink / raw)
To: Joel Sherrill; +Cc: Geert Bosch, GCC Development, hainque
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
Hi Joel,
Joel Sherrill wrote:
> I can't seem to find the patch. Do you have a link?
The initial submission, with a description of the problem we were
having, is at
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00759.html
We have been using a slightly adjusted version for our gcc 4.3 based
line of products, attached.
I'm not clear on the status on mainline (whether the issue is still
present etc).
Olivier
* config/arm/arm.c (args_to_rsa_distance): New function. Distance
between the arguments and the registers save area.
(arm_get_frame_offsets): Account for this distance in the frame
pointer and registers save area offset computations. Add comments.
(arm_expand_prologue): Add comments on the ARM frame pointer
computation scheme. Count the "ip" push in the amount of space
we use to save registers past the arguments area. Tidy the circuitry
to restore IP past the frame pointer setup.
(arm_compute_initial_elimination_offset) <from ARG_POINTER_REGNUM>:
Rewrite expressions along the lines of a straight common pattern.
[-- Attachment #2: arm-dword_align.dif --]
[-- Type: text/plain, Size: 15092 bytes --]
*** ./gcc/config/arm/arm.c.ori Wed Feb 11 17:05:47 2009
--- ./gcc/config/arm/arm.c Fri Feb 13 12:23:39 2009
*************** void (*arm_lang_output_object_attributes
*** 63,68 ****
--- 63,69 ----
/* Forward function declarations. */
static arm_stack_offsets *arm_get_frame_offsets (void);
+ static int arm_args_to_rsa_distance (void);
static void arm_add_gc_roots (void);
static int arm_gen_constant (enum rtx_code, enum machine_mode, rtx,
HOST_WIDE_INT, rtx, rtx, int, int);
*************** arm_get_frame_offsets (void)
*** 11941,11946 ****
--- 11942,11950 ----
int saved;
HOST_WIDE_INT frame_size;
+ /* Space between the arguments and the register save areas. */
+ int args_to_rsa_distance = arm_args_to_rsa_distance ();
+
offsets = &cfun->machine->stack_offsets;
/* We need to know if we are a leaf function. Unfortunately, it
*************** arm_get_frame_offsets (void)
*** 11962,11973 ****
leaf = leaf_function_p ();
! /* Space for variadic functions. */
offsets->saved_args = current_function_pretend_args_size;
!
! /* In Thumb mode this is incorrect, but never used. */
! offsets->frame = offsets->saved_args + (frame_pointer_needed ? 4 : 0);
!
if (TARGET_32BIT)
{
unsigned int regno;
--- 11966,11976 ----
leaf = leaf_function_p ();
! /* Offset from entry-sp to the bottommost slot of the arguments area,
! possibly including varargs saved by this function in its own frame. */
offsets->saved_args = current_function_pretend_args_size;
!
! /* Space for saved registers. */
if (TARGET_32BIT)
{
unsigned int regno;
*************** arm_get_frame_offsets (void)
*** 12008,12016 ****
saved += 16;
}
! /* Saved registers include the stack frame. */
! offsets->saved_regs = offsets->saved_args + saved;
offsets->soft_frame = offsets->saved_regs + CALLER_INTERWORKING_SLOT_SIZE;
/* A leaf function does not need any stack alignment if it has nothing
on the stack. */
if (leaf && frame_size == 0)
--- 12011,12032 ----
saved += 16;
}
! /* Now, other from entry-sp offset computations, accounting for a possible
! whole between the saved-arguments and saved-registers areas. */
!
! /* Offset to the bottommost slot in the registers save area. */
! offsets->saved_regs = offsets->saved_args + args_to_rsa_distance + saved;
!
! /* Offset to hard frame pointer. On ARM, topmost slot in the registers
! sava area. This would be different on THUMB but is never used. */
! offsets->frame
! = (offsets->saved_args + args_to_rsa_distance
! + (frame_pointer_needed ? 4 : 0));
!
! /* Offset to soft frame pointer, slot just above the locals area, past
! room for a possible interworking slot and alignment padding. */
offsets->soft_frame = offsets->saved_regs + CALLER_INTERWORKING_SLOT_SIZE;
+
/* A leaf function does not need any stack alignment if it has nothing
on the stack. */
if (leaf && frame_size == 0)
*************** arm_get_frame_offsets (void)
*** 12025,12031 ****
--- 12041,12051 ----
&& (offsets->soft_frame & 7))
offsets->soft_frame += 4;
+ /* Offset to bottommost slot for local variables ... */
offsets->locals_base = offsets->soft_frame + frame_size;
+
+ /* ... and for outgoing arguments, bottom of the whole stack frame for
+ this function, hence also subject to possible alignment padding. */
offsets->outgoing_args = (offsets->locals_base
+ current_function_outgoing_args_size);
*************** arm_compute_initial_elimination_offset (
*** 12058,12087 ****
switch (from)
{
case ARG_POINTER_REGNUM:
switch (to)
{
case THUMB_HARD_FRAME_POINTER_REGNUM:
return 0;
case FRAME_POINTER_REGNUM:
! /* This is the reverse of the soft frame pointer
! to hard frame pointer elimination below. */
! return offsets->soft_frame - offsets->saved_args;
case ARM_HARD_FRAME_POINTER_REGNUM:
! /* If there is no stack frame then the hard
! frame pointer and the arg pointer coincide. */
! if (offsets->frame == offsets->saved_regs)
! return 0;
! /* FIXME: Not sure about this. Maybe we should always return 0 ? */
! return (frame_pointer_needed
! && cfun->static_chain_decl != NULL
! && ! cfun->machine->uses_anonymous_args) ? 4 : 0;
case STACK_POINTER_REGNUM:
! /* If nothing has been pushed on the stack at all
! then this will return -4. This *is* correct! */
! return offsets->outgoing_args - (offsets->saved_args + 4);
default:
gcc_unreachable ();
--- 12078,12103 ----
switch (from)
{
case ARG_POINTER_REGNUM:
+ /* We use offsets->saved_args as a reference offset to the actual
+ arguments area then adjust by the difference with what the arg
+ pointer designates. */
+
switch (to)
{
case THUMB_HARD_FRAME_POINTER_REGNUM:
return 0;
case FRAME_POINTER_REGNUM:
! return (offsets->soft_frame - offsets->saved_args
! - FIRST_PARM_OFFSET (current_function_decl));
case ARM_HARD_FRAME_POINTER_REGNUM:
! return (offsets->frame - offsets->saved_args
! - FIRST_PARM_OFFSET (current_function_decl));
case STACK_POINTER_REGNUM:
! return (offsets->outgoing_args - offsets->saved_args
! - FIRST_PARM_OFFSET (current_function_decl));
default:
gcc_unreachable ();
*************** thumb_set_frame_pointer (arm_stack_offse
*** 12242,12247 ****
--- 12258,12280 ----
RTX_FRAME_RELATED_P (insn) = 1;
}
+ /* How many bytes the prologue expansion pushes between the arguments and
+ the registers save area. */
+ static int
+ arm_args_to_rsa_distance (void)
+ {
+ int distance = 0;
+
+ /* Account for our possible push of the input static chain. */
+ if (TARGET_ARM && frame_pointer_needed
+ && IS_NESTED (arm_current_func_type ())
+ && df_regs_ever_live_p(3) != 0
+ && current_function_pretend_args_size == 0)
+ distance += 4;
+
+ return distance;
+ }
+
/* Generate the prologue instructions for entry into an ARM or Thumb-2
function. */
void
*************** arm_expand_prologue (void)
*** 12252,12263 ****
rtx ip_rtx;
unsigned long live_regs_mask;
unsigned long func_type;
- int fp_offset = 0;
- int saved_pretend_args = 0;
int saved_regs = 0;
unsigned HOST_WIDE_INT args_to_push;
arm_stack_offsets *offsets;
func_type = arm_current_func_type ();
/* Naked functions don't have prologues. */
--- 12285,12314 ----
rtx ip_rtx;
unsigned long live_regs_mask;
unsigned long func_type;
int saved_regs = 0;
unsigned HOST_WIDE_INT args_to_push;
arm_stack_offsets *offsets;
+ /* When we setup the ARM frame pointer, we have it designate the topmost
+ entry in the registers save with a number of devices:
+ - We use the IP register as a temporary scratch location to hold
+ the entry sp,
+ - We keep track of the amount of data we push before the registers
+ save area, and
+ - We arrange to save/restore the initial value of the IP register when
+ this is required for proper functional behavior later on. */
+
+ /* Amount of data between the entry-sp and the ARM frame pointer. */
+ int fp_offset = 0;
+
+ /* When IP's original value is to be restored from a register, this
+ is the register number. */
+ unsigned orip_regno = INVALID_REGNUM;
+
+ /* When IP's original value is to be restored from a stack slot off
+ the entry stack pointer, this is the slot offset. */
+ int orip_sp_offset = -1;
+
func_type = arm_current_func_type ();
/* Naked functions don't have prologues. */
*************** arm_expand_prologue (void)
*** 12303,12315 ****
emit_insn (gen_movsi (stack_pointer_rtx, r1));
}
if (frame_pointer_needed && TARGET_ARM)
{
if (IS_INTERRUPT (func_type))
{
/* Interrupt functions must not corrupt any registers.
Creating a frame pointer however, corrupts the IP
! register, so we must push it first. */
insn = emit_multi_reg_push (1 << IP_REGNUM);
/* Do not set RTX_FRAME_RELATED_P on this insn.
--- 12354,12371 ----
emit_insn (gen_movsi (stack_pointer_rtx, r1));
}
+ /* Setup IP for later frame pointer computation purposes, with special
+ pre-processing when IP couldn't just be clobbered carelessly. */
+
if (frame_pointer_needed && TARGET_ARM)
{
if (IS_INTERRUPT (func_type))
{
/* Interrupt functions must not corrupt any registers.
Creating a frame pointer however, corrupts the IP
! register, so we must push it first. This value will
! be restored by the epilogue, hence is conceptually part
! of the register save area. */
insn = emit_multi_reg_push (1 << IP_REGNUM);
/* Do not set RTX_FRAME_RELATED_P on this insn.
*************** arm_expand_prologue (void)
*** 12344,12362 ****
inherited from the caller. */
if (df_regs_ever_live_p (3) == false)
! insn = emit_set_insn (gen_rtx_REG (SImode, 3), ip_rtx);
else if (args_to_push == 0)
{
rtx dwarf;
insn = gen_rtx_PRE_DEC (SImode, stack_pointer_rtx);
insn = emit_set_insn (gen_frame_mem (SImode, insn), ip_rtx);
! fp_offset = 4;
/* Just tell the dwarf backend that we adjusted SP. */
dwarf = gen_rtx_SET (VOIDmode, stack_pointer_rtx,
! plus_constant (stack_pointer_rtx,
! -fp_offset));
RTX_FRAME_RELATED_P (insn) = 1;
REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_FRAME_RELATED_EXPR,
dwarf, REG_NOTES (insn));
--- 12400,12433 ----
inherited from the caller. */
if (df_regs_ever_live_p (3) == false)
! {
! insn = emit_set_insn (gen_rtx_REG (SImode, 3), ip_rtx);
! orip_regno = 3;
! }
else if (args_to_push == 0)
{
rtx dwarf;
insn = gen_rtx_PRE_DEC (SImode, stack_pointer_rtx);
insn = emit_set_insn (gen_frame_mem (SImode, insn), ip_rtx);
!
! /* This push doesn't account as a regular register save in the
! save_reg_mask sense, so shifts the "frame" location. */
! fp_offset += 4;
!
! /* Tell IP is to be restored from the slot where we just
! pushed it. We assume fp_offset conveys the number of
! bytes pushed up to now. */
! orip_sp_offset = fp_offset;
!
! /* We need to account for the space it takes, still, and
! note that IP will have to be restored from there. */
! saved_regs += 4;
/* Just tell the dwarf backend that we adjusted SP. */
dwarf = gen_rtx_SET (VOIDmode, stack_pointer_rtx,
! plus_constant (stack_pointer_rtx, -4));
!
RTX_FRAME_RELATED_P (insn) = 1;
REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_FRAME_RELATED_EXPR,
dwarf, REG_NOTES (insn));
*************** arm_expand_prologue (void)
*** 12374,12388 ****
RTX_FRAME_RELATED_P (insn) = 1;
! saved_pretend_args = 1;
! fp_offset = args_to_push;
args_to_push = 0;
/* Now reuse r3 to preserve IP. */
emit_set_insn (gen_rtx_REG (SImode, 3), ip_rtx);
}
}
insn = emit_set_insn (ip_rtx,
plus_constant (stack_pointer_rtx, fp_offset));
RTX_FRAME_RELATED_P (insn) = 1;
--- 12445,12460 ----
RTX_FRAME_RELATED_P (insn) = 1;
! fp_offset += args_to_push;
args_to_push = 0;
/* Now reuse r3 to preserve IP. */
emit_set_insn (gen_rtx_REG (SImode, 3), ip_rtx);
+ orip_regno = 3;
}
}
+ /* Here, we setup IP to designate the entry stack pointer. */
insn = emit_set_insn (ip_rtx,
plus_constant (stack_pointer_rtx, fp_offset));
RTX_FRAME_RELATED_P (insn) = 1;
*************** arm_expand_prologue (void)
*** 12399,12404 ****
--- 12471,12479 ----
(gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx,
GEN_INT (- args_to_push)));
RTX_FRAME_RELATED_P (insn) = 1;
+
+ fp_offset += args_to_push;
+ args_to_push = 0;
}
/* If this is an interrupt service routine, and the link register
*************** arm_expand_prologue (void)
*** 12416,12421 ****
--- 12491,12497 ----
emit_set_insn (lr, plus_constant (lr, -4));
}
+ /* Now we emit the registers save operations ... */
if (live_regs_mask)
{
insn = emit_multi_reg_push (live_regs_mask);
*************** arm_expand_prologue (void)
*** 12426,12457 ****
if (! IS_VOLATILE (func_type))
saved_regs += arm_save_coproc_regs ();
if (frame_pointer_needed && TARGET_ARM)
{
! /* Create the new frame pointer. */
! {
! insn = GEN_INT (-(4 + args_to_push + fp_offset));
! insn = emit_insn (gen_addsi3 (hard_frame_pointer_rtx, ip_rtx, insn));
! RTX_FRAME_RELATED_P (insn) = 1;
! if (IS_NESTED (func_type))
! {
! /* Recover the static chain register. */
! if (!df_regs_ever_live_p (3)
! || saved_pretend_args)
! insn = gen_rtx_REG (SImode, 3);
! else /* if (current_function_pretend_args_size == 0) */
! {
! insn = plus_constant (hard_frame_pointer_rtx, 4);
! insn = gen_frame_mem (SImode, insn);
! }
! emit_set_insn (ip_rtx, insn);
! /* Add a USE to stop propagate_one_insn() from barfing. */
! emit_insn (gen_prologue_use (ip_rtx));
! }
}
}
offsets = arm_get_frame_offsets ();
if (offsets->outgoing_args != offsets->saved_args + saved_regs)
{
--- 12502,12537 ----
if (! IS_VOLATILE (func_type))
saved_regs += arm_save_coproc_regs ();
+ /* ... then create the ARM frame pointer and restore the initial IP
+ register value if need be. */
if (frame_pointer_needed && TARGET_ARM)
{
! /* At this point, we have IP setup to designate the entry sp and
! fp_offset conveys the amount of bytes we pushed before the register
! saves. Setup the frame pointer from there: */
! insn = GEN_INT (-(4 + fp_offset));
! insn = emit_insn (gen_addsi3 (hard_frame_pointer_rtx, ip_rtx, insn));
! RTX_FRAME_RELATED_P (insn) = 1;
! /* Then restore IP from the indication of where it was saved
! for this purpose. */
! if (orip_regno != INVALID_REGNUM)
! insn = gen_rtx_REG (SImode, orip_regno);
! else if (orip_sp_offset != -1)
! insn = gen_frame_mem
! (SImode, plus_constant (ip_rtx, -orip_sp_offset));
! else
! insn = NULL_RTX;
!
! if (insn != NULL_RTX)
! {
! emit_set_insn (ip_rtx, insn);
! /* Add a USE to stop propagate_one_insn() from barfing. */
! emit_insn (gen_prologue_use (ip_rtx));
}
}
+ /* Now allocate room for locals and outgoing args. */
offsets = arm_get_frame_offsets ();
if (offsets->outgoing_args != offsets->saved_args + saved_regs)
{
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ada] Anyone else run ACATS on ARM?
2009-08-23 5:10 ` [Ada] " Laurent GUERBY
@ 2009-08-29 16:29 ` Laurent GUERBY
2009-08-29 22:49 ` Mikael Pettersson
0 siblings, 1 reply; 19+ messages in thread
From: Laurent GUERBY @ 2009-08-29 16:29 UTC (permalink / raw)
To: Mikael Pettersson
Cc: Matthias Klose, Martin Guy, Joel Sherrill, gcc, Ludovic Brenta,
Geert Bosch, Olivier Hainque
[-- Attachment #1: Type: text/plain, Size: 4606 bytes --]
On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
> On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose <doko@debian.org> wrote:
> > >On 12.08.2009 23:07, Martin Guy wrote:
> > >> On 8/12/09, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
> > >>> So any ACATS results from any other ARM target would be
> > >>> appreciated.
> > >>
> > >> I looked into gnat-arm for the new Debian port and the conclusion was
> > >> that it has never been bootstrapped onto ARM. The closest I have seen
> > >> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
> > >> targetting Nucleus OS (gak!)
> > >>
> > >> The community feeling was that it would "just go" given a prodigal
> > >> burst of cross-compiling, but I never got achieved sufficiently high
> > >> blood pressure to try it...
> > >
> > >is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
> > >initial gnat-4.4 package for debian?
> > >
> > > Matthias
> >
> > Yes, see <http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
>
> Nice work!
>
> Looks like Ada exception propagation (setjmp/longjmp based) is broken at
> least in some cases (see below), that might explain the high number of
> ACATS failure.
>
> My understanding is that
>
> EH_MECHANISM=-gcc
>
> is not correct for sjlj exceptions so I removed this line from the patch
> and I'm currently testing with trunk.
With this change plus the gcc/ada/gcc-interface/targtyps.c one
I get very good native arm ACATS and gnat.dg results:
http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg03024.html
<<
Native configuration is armv5tel-unknown-linux-gnueabi
=== acats tests ===
FAIL: c250001
FAIL: c37105a
FAIL: c43205b
=== acats Summary ===
# of expected passes 2311
# of unexpected failures 3
=== gnat tests ===
Running target unix
FAIL: gnat.dg/test_raise_from_pure.adb execution test
FAIL: gnat.dg/warn5.adb (test for excess errors)
=== gnat Summary ===
# of expected passes 682
# of unexpected failures 2
# of expected failures 5
>>
It would be nice to have a ZCX port but so far the sjlj exceptions
based port works fine.
I'm attaching the patch for reference, I'm away at ICFP09 next week.
Laurent
c250001.a:1:01: warning: file contains no compilation units
no compilation units found
no source files written
BUILD
FAIL: c250001
(=> probably due to NFS use)
,.,. C37105A ACATS 2.5 09-08-29 00:53:53
---- C37105A RECORDS WITH ONLY DISCRIMINANTS.
* C37105A DISCRIMINANT-ONLY RECORDS DON'T WORK.
**** C37105A FAILED ****************************.
/home/guerby/build/gcc/xgcc -c -B/home/guerby/build/gcc/ -gnatws -O2 -I/home/guerby/build/gcc/testsuite/ada/acats/support c43205b.adb
+===========================GNAT BUG DETECTED==============================+
| 4.5.0 20090822 (experimental) [trunk revision 151016] (armv5tel-unknown-linux-gnueabi) GCC error:|
| tree check: expected integer_cst, have var_decl in int_const_binop, |
| at fold-const.c:1668 |
| Error detected around c43205b.adb:82:5 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
| Use a subject line meaningful to you and us to track the bug. |
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==========================================================================+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).
/home/guerby/build/gcc/ada/rts/system.ads
c43205b.adb
/home/guerby/build/gcc/testsuite/ada/acats/support/report.ads
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423
gnatmake: "c43205b.adb" compilation error
FAIL: c43205b
raised CONSTRAINT_ERROR : raise_from_pure.adb:5 explicit raise
FAIL: gnat.dg/test_raise_from_pure.adb execution test
warn5.adb:29:30: warning: source alignment (4) < alignment of "Element_Type" (8)^M
output is:
warn5.adb:29:30: warning: source alignment (4) < alignment of "Element_Type" (8)^M
FAIL: gnat.dg/warn5.adb (test for excess errors)
Excess errors:
warn5.adb:29:30: warning: source alignment (4) < alignment of "Element_Type" (8)
[-- Attachment #2: patch-arm-v3.txt --]
[-- Type: text/plain, Size: 20597 bytes --]
Index: gcc/ada/xsinfo.adb
===================================================================
--- gcc/ada/xsinfo.adb (revision 151016)
+++ gcc/ada/xsinfo.adb (working copy)
@@ -52,7 +52,7 @@
procedure XSinfo is
- Done : exception;
+ -- Done : exception;
Err : exception;
A : VString := Nul;
@@ -88,14 +88,14 @@
M : Match_Result;
- procedure Getline;
+ function Getline return Boolean;
-- Get non-comment, non-blank line. Also skips "for " rep clauses
-------------
-- Getline --
-------------
- procedure Getline is
+ function Getline return Boolean is
begin
loop
Line := Get_Line (InS);
@@ -104,10 +104,10 @@
and then not Match (Line, Wsp_For)
and then not Match (Line, Is_Cmnt)
then
- return;
+ return False;
elsif Match (Line, " -- End functions (note") then
- raise Done;
+ return True;
end if;
end loop;
end Getline;
@@ -146,14 +146,14 @@
-- Skip to package line
loop
- Getline;
+ if Getline then goto Done; end if;
exit when Match (Line, "package");
end loop;
-- Skip to first node kind line
loop
- Getline;
+ if Getline then goto Done; end if;
exit when Match (Line, Typ_Nod);
Put_Line (Ofile, Line);
end loop;
@@ -164,7 +164,7 @@
-- Loop through node kind codes
loop
- Getline;
+ if Getline then goto Done; end if;
if Match (Line, Get_Nam) then
Put_Line (Ofile, A & "#define N_" & Nam & ' ' & NKV);
@@ -182,7 +182,7 @@
-- Loop through subtype declarations
loop
- Getline;
+ if Getline then goto Done; end if;
if not Match (Line, Sub_Typ) then
exit when Match (Line, " function");
@@ -190,7 +190,7 @@
else
Put_Line (Ofile, A & "SUBTYPE (" & N & ", Node_Kind, ");
- Getline;
+ if Getline then goto Done; end if;
-- Normal case
@@ -204,7 +204,7 @@
raise Err;
end if;
- Getline;
+ if Getline then goto Done; end if;
if not Match (Line, Cont_N2) then
raise Err;
@@ -221,7 +221,7 @@
loop
if Match (Line, Is_Func) then
- Getline;
+ if Getline then goto Done; end if;
if not Match (Line, Get_Arg) then
raise Err;
end if;
@@ -236,11 +236,10 @@
Put_Line (Ofile, Line);
end if;
- Getline;
+ if Getline then goto Done; end if;
end loop;
-exception
- when Done =>
+ <<Done>>
Put_Line (Ofile, "");
Set_Exit_Status (0);
Index: gcc/ada/system-linux-armel.ads
===================================================================
--- gcc/ada/system-linux-armel.ads (revision 0)
+++ gcc/ada/system-linux-armel.ads (revision 0)
@@ -0,0 +1,155 @@
+------------------------------------------------------------------------------
+-- --
+-- GNAT RUN-TIME COMPONENTS --
+-- --
+-- S Y S T E M --
+-- --
+-- S p e c --
+-- (GNU-Linux/ARMEL Version) --
+-- --
+-- Copyright (C) 1992-2007, Free Software Foundation, Inc. --
+-- --
+-- This specification is derived from the Ada Reference Manual for use with --
+-- GNAT. The copyright notice above, and the license provisions that follow --
+-- apply solely to the contents of the part following the private keyword. --
+-- --
+-- GNAT is free software; you can redistribute it and/or modify it under --
+-- terms of the GNU General Public License as published by the Free Soft- --
+-- ware Foundation; either version 2, or (at your option) any later ver- --
+-- sion. GNAT is distributed in the hope that it will be useful, but WITH- --
+-- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY --
+-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License --
+-- for more details. You should have received a copy of the GNU General --
+-- Public License distributed with GNAT; see file COPYING. If not, write --
+-- to the Free Software Foundation, 51 Franklin Street, Fifth Floor, --
+-- Boston, MA 02110-1301, USA. --
+-- --
+-- As a special exception, if other files instantiate generics from this --
+-- unit, or you link this unit with other files to produce an executable, --
+-- this unit does not by itself cause the resulting executable to be --
+-- covered by the GNU General Public License. This exception does not --
+-- however invalidate any other reasons why the executable file might be --
+-- covered by the GNU Public License. --
+-- --
+-- GNAT was originally developed by the GNAT team at New York University. --
+-- Extensive contributions were provided by Ada Core Technologies Inc. --
+-- --
+------------------------------------------------------------------------------
+
+package System is
+ pragma Pure;
+ -- Note that we take advantage of the implementation permission to make
+ -- this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
+ -- 2005, this is Pure in any case (AI-362).
+
+ type Name is (SYSTEM_NAME_GNAT);
+ System_Name : constant Name := SYSTEM_NAME_GNAT;
+
+ -- System-Dependent Named Numbers
+
+ Min_Int : constant := Long_Long_Integer'First;
+ Max_Int : constant := Long_Long_Integer'Last;
+
+ Max_Binary_Modulus : constant := 2 ** Long_Long_Integer'Size;
+ Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1;
+
+ Max_Base_Digits : constant := Long_Long_Float'Digits;
+ Max_Digits : constant := Long_Long_Float'Digits;
+
+ Max_Mantissa : constant := 63;
+ Fine_Delta : constant := 2.0 ** (-Max_Mantissa);
+
+ Tick : constant := 0.000_001;
+
+ -- Storage-related Declarations
+
+ type Address is private;
+ pragma Preelaborable_Initialization (Address);
+ Null_Address : constant Address;
+
+ Storage_Unit : constant := 8;
+ Word_Size : constant := 32;
+ Memory_Size : constant := 2 ** 32;
+
+ -- Address comparison
+
+ function "<" (Left, Right : Address) return Boolean;
+ function "<=" (Left, Right : Address) return Boolean;
+ function ">" (Left, Right : Address) return Boolean;
+ function ">=" (Left, Right : Address) return Boolean;
+ function "=" (Left, Right : Address) return Boolean;
+
+ pragma Import (Intrinsic, "<");
+ pragma Import (Intrinsic, "<=");
+ pragma Import (Intrinsic, ">");
+ pragma Import (Intrinsic, ">=");
+ pragma Import (Intrinsic, "=");
+
+ -- Other System-Dependent Declarations
+
+ type Bit_Order is (High_Order_First, Low_Order_First);
+ Default_Bit_Order : constant Bit_Order := Low_Order_First;
+ pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning
+
+ -- Priority-related Declarations (RM D.1)
+
+ -- 0 .. 98 corresponds to the system priority range 1 .. 99.
+ --
+ -- If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use
+ -- of the entire range provided by the system.
+ --
+ -- If the scheduling policy is SCHED_OTHER the only valid system priority
+ -- is 1 and other values are simply ignored.
+
+ Max_Priority : constant Positive := 97;
+ Max_Interrupt_Priority : constant Positive := 98;
+
+ subtype Any_Priority is Integer range 0 .. 98;
+ subtype Priority is Any_Priority range 0 .. 97;
+ subtype Interrupt_Priority is Any_Priority range 98 .. 98;
+
+ Default_Priority : constant Priority := 48;
+
+private
+
+ type Address is mod Memory_Size;
+ Null_Address : constant Address := 0;
+
+ --------------------------------------
+ -- System Implementation Parameters --
+ --------------------------------------
+
+ -- These parameters provide information about the target that is used
+ -- by the compiler. They are in the private part of System, where they
+ -- can be accessed using the special circuitry in the Targparm unit
+ -- whose source should be consulted for more detailed descriptions
+ -- of the individual switch values.
+
+ Backend_Divide_Checks : constant Boolean := False;
+ Backend_Overflow_Checks : constant Boolean := False;
+ Command_Line_Args : constant Boolean := True;
+ Configurable_Run_Time : constant Boolean := False;
+ Denorm : constant Boolean := True;
+ Duration_32_Bits : constant Boolean := False;
+ Exit_Status_Supported : constant Boolean := True;
+ Fractional_Fixed_Ops : constant Boolean := False;
+ Frontend_Layout : constant Boolean := False;
+ Machine_Overflows : constant Boolean := False;
+ Machine_Rounds : constant Boolean := True;
+ Preallocated_Stacks : constant Boolean := False;
+ Signed_Zeros : constant Boolean := True;
+ Stack_Check_Default : constant Boolean := False;
+ Stack_Check_Probes : constant Boolean := False;
+ Stack_Check_Limits : constant Boolean := False;
+ Support_64_Bit_Divides : constant Boolean := True;
+ Support_Aggregates : constant Boolean := True;
+ Support_Composite_Assign : constant Boolean := True;
+ Support_Composite_Compare : constant Boolean := True;
+ Support_Long_Shifts : constant Boolean := True;
+ Always_Compatible_Rep : constant Boolean := False;
+ Suppress_Standard_Library : constant Boolean := False;
+ Use_Ada_Main_Program_Name : constant Boolean := False;
+ ZCX_By_Default : constant Boolean := False;
+ GCC_ZCX_Support : constant Boolean := False;
+
+end System;
Index: gcc/ada/gcc-interface/Makefile.in
===================================================================
--- gcc/ada/gcc-interface/Makefile.in (revision 151016)
+++ gcc/ada/gcc-interface/Makefile.in (working copy)
@@ -1815,6 +1815,42 @@
LIBRARY_VERSION := $(LIB_VERSION)
endif
+# arm*-*-linux-gnueabi
+ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word 4,$(targ)))),)
+ LIBGNAT_TARGET_PAIRS = \
+ a-intnam.ads<a-intnam-linux.ads \
+ s-inmaop.adb<s-inmaop-posix.adb \
+ s-intman.adb<s-intman-posix.adb \
+ s-linux.ads<s-linux.ads \
+ s-osinte.adb<s-osinte-posix.adb \
+ s-osinte.ads<s-osinte-linux.ads \
+ s-osprim.adb<s-osprim-posix.adb \
+ s-taprop.adb<s-taprop-linux.adb \
+ s-tasinf.ads<s-tasinf-linux.ads \
+ s-tasinf.adb<s-tasinf-linux.adb \
+ s-taspri.ads<s-taspri-posix-noaltstack.ads \
+ s-tpopsp.adb<s-tpopsp-posix-foreign.adb
+
+ ifeq ($(strip $(filter-out arm%b,$(arch))),)
+ LIBGNAT_TARGET_PAIRS += \
+ system.ads<system-linux-armeb.ads
+ else
+ LIBGNAT_TARGET_PAIRS += \
+ system.ads<system-linux-armel.ads
+ endif
+
+ TOOLS_TARGET_PAIRS = \
+ mlib-tgt-specific.adb<mlib-tgt-specific-linux.adb \
+ indepsw.adb<indepsw-gnu.adb
+
+ EXTRA_GNATRTL_TASKING_OBJS=s-linux.o
+ THREADSLIB = -lpthread
+ GNATLIB_SHARED = gnatlib-shared-dual
+ GMEM_LIB = gmemlib
+ PREFIX_OBJS = $(PREFIX_REAL_OBJS)
+ LIBRARY_VERSION := $(LIB_VERSION)
+endif
+
ifeq ($(strip $(filter-out sparc% linux%,$(arch) $(osys))),)
LIBGNAT_TARGET_PAIRS_COMMON = \
a-intnam.ads<a-intnam-linux.ads \
Index: gcc/ada/gcc-interface/targtyps.c
===================================================================
--- gcc/ada/gcc-interface/targtyps.c (revision 151016)
+++ gcc/ada/gcc-interface/targtyps.c (working copy)
@@ -29,6 +29,7 @@
#include "system.h"
#include "coretypes.h"
#include "tm.h"
+#include "tm_p.h"
#include "tree.h"
#include "ada.h"
Index: gcc/ada/system-linux-armeb.ads
===================================================================
--- gcc/ada/system-linux-armeb.ads (revision 0)
+++ gcc/ada/system-linux-armeb.ads (revision 0)
@@ -0,0 +1,155 @@
+------------------------------------------------------------------------------
+-- --
+-- GNAT RUN-TIME COMPONENTS --
+-- --
+-- S Y S T E M --
+-- --
+-- S p e c --
+-- (GNU-Linux/ARMEB Version) --
+-- --
+-- Copyright (C) 1992-2007, Free Software Foundation, Inc. --
+-- --
+-- This specification is derived from the Ada Reference Manual for use with --
+-- GNAT. The copyright notice above, and the license provisions that follow --
+-- apply solely to the contents of the part following the private keyword. --
+-- --
+-- GNAT is free software; you can redistribute it and/or modify it under --
+-- terms of the GNU General Public License as published by the Free Soft- --
+-- ware Foundation; either version 2, or (at your option) any later ver- --
+-- sion. GNAT is distributed in the hope that it will be useful, but WITH- --
+-- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY --
+-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License --
+-- for more details. You should have received a copy of the GNU General --
+-- Public License distributed with GNAT; see file COPYING. If not, write --
+-- to the Free Software Foundation, 51 Franklin Street, Fifth Floor, --
+-- Boston, MA 02110-1301, USA. --
+-- --
+-- As a special exception, if other files instantiate generics from this --
+-- unit, or you link this unit with other files to produce an executable, --
+-- this unit does not by itself cause the resulting executable to be --
+-- covered by the GNU General Public License. This exception does not --
+-- however invalidate any other reasons why the executable file might be --
+-- covered by the GNU Public License. --
+-- --
+-- GNAT was originally developed by the GNAT team at New York University. --
+-- Extensive contributions were provided by Ada Core Technologies Inc. --
+-- --
+------------------------------------------------------------------------------
+
+package System is
+ pragma Pure;
+ -- Note that we take advantage of the implementation permission to make
+ -- this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
+ -- 2005, this is Pure in any case (AI-362).
+
+ type Name is (SYSTEM_NAME_GNAT);
+ System_Name : constant Name := SYSTEM_NAME_GNAT;
+
+ -- System-Dependent Named Numbers
+
+ Min_Int : constant := Long_Long_Integer'First;
+ Max_Int : constant := Long_Long_Integer'Last;
+
+ Max_Binary_Modulus : constant := 2 ** Long_Long_Integer'Size;
+ Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1;
+
+ Max_Base_Digits : constant := Long_Long_Float'Digits;
+ Max_Digits : constant := Long_Long_Float'Digits;
+
+ Max_Mantissa : constant := 63;
+ Fine_Delta : constant := 2.0 ** (-Max_Mantissa);
+
+ Tick : constant := 0.000_001;
+
+ -- Storage-related Declarations
+
+ type Address is private;
+ pragma Preelaborable_Initialization (Address);
+ Null_Address : constant Address;
+
+ Storage_Unit : constant := 8;
+ Word_Size : constant := 32;
+ Memory_Size : constant := 2 ** 32;
+
+ -- Address comparison
+
+ function "<" (Left, Right : Address) return Boolean;
+ function "<=" (Left, Right : Address) return Boolean;
+ function ">" (Left, Right : Address) return Boolean;
+ function ">=" (Left, Right : Address) return Boolean;
+ function "=" (Left, Right : Address) return Boolean;
+
+ pragma Import (Intrinsic, "<");
+ pragma Import (Intrinsic, "<=");
+ pragma Import (Intrinsic, ">");
+ pragma Import (Intrinsic, ">=");
+ pragma Import (Intrinsic, "=");
+
+ -- Other System-Dependent Declarations
+
+ type Bit_Order is (High_Order_First, Low_Order_First);
+ Default_Bit_Order : constant Bit_Order := High_Order_First;
+ pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning
+
+ -- Priority-related Declarations (RM D.1)
+
+ -- 0 .. 98 corresponds to the system priority range 1 .. 99.
+ --
+ -- If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use
+ -- of the entire range provided by the system.
+ --
+ -- If the scheduling policy is SCHED_OTHER the only valid system priority
+ -- is 1 and other values are simply ignored.
+
+ Max_Priority : constant Positive := 97;
+ Max_Interrupt_Priority : constant Positive := 98;
+
+ subtype Any_Priority is Integer range 0 .. 98;
+ subtype Priority is Any_Priority range 0 .. 97;
+ subtype Interrupt_Priority is Any_Priority range 98 .. 98;
+
+ Default_Priority : constant Priority := 48;
+
+private
+
+ type Address is mod Memory_Size;
+ Null_Address : constant Address := 0;
+
+ --------------------------------------
+ -- System Implementation Parameters --
+ --------------------------------------
+
+ -- These parameters provide information about the target that is used
+ -- by the compiler. They are in the private part of System, where they
+ -- can be accessed using the special circuitry in the Targparm unit
+ -- whose source should be consulted for more detailed descriptions
+ -- of the individual switch values.
+
+ Backend_Divide_Checks : constant Boolean := False;
+ Backend_Overflow_Checks : constant Boolean := False;
+ Command_Line_Args : constant Boolean := True;
+ Configurable_Run_Time : constant Boolean := False;
+ Denorm : constant Boolean := True;
+ Duration_32_Bits : constant Boolean := False;
+ Exit_Status_Supported : constant Boolean := True;
+ Fractional_Fixed_Ops : constant Boolean := False;
+ Frontend_Layout : constant Boolean := False;
+ Machine_Overflows : constant Boolean := False;
+ Machine_Rounds : constant Boolean := True;
+ Preallocated_Stacks : constant Boolean := False;
+ Signed_Zeros : constant Boolean := True;
+ Stack_Check_Default : constant Boolean := False;
+ Stack_Check_Probes : constant Boolean := False;
+ Stack_Check_Limits : constant Boolean := False;
+ Support_64_Bit_Divides : constant Boolean := True;
+ Support_Aggregates : constant Boolean := True;
+ Support_Composite_Assign : constant Boolean := True;
+ Support_Composite_Compare : constant Boolean := True;
+ Support_Long_Shifts : constant Boolean := True;
+ Always_Compatible_Rep : constant Boolean := False;
+ Suppress_Standard_Library : constant Boolean := False;
+ Use_Ada_Main_Program_Name : constant Boolean := False;
+ ZCX_By_Default : constant Boolean := False;
+ GCC_ZCX_Support : constant Boolean := False;
+
+end System;
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ada] Anyone else run ACATS on ARM?
2009-08-29 16:29 ` Laurent GUERBY
@ 2009-08-29 22:49 ` Mikael Pettersson
2009-08-31 16:09 ` Mikael Pettersson
0 siblings, 1 reply; 19+ messages in thread
From: Mikael Pettersson @ 2009-08-29 22:49 UTC (permalink / raw)
To: Laurent GUERBY
Cc: Mikael Pettersson, Matthias Klose, Martin Guy, Joel Sherrill,
gcc, Ludovic Brenta, Geert Bosch, Olivier Hainque
Laurent GUERBY writes:
> On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
> > On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> > > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose <doko@debian.org> wrote:
> > > >On 12.08.2009 23:07, Martin Guy wrote:
> > > >> On 8/12/09, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
> > > >>> So any ACATS results from any other ARM target would be
> > > >>> appreciated.
> > > >>
> > > >> I looked into gnat-arm for the new Debian port and the conclusion was
> > > >> that it has never been bootstrapped onto ARM. The closest I have seen
> > > >> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
> > > >> targetting Nucleus OS (gak!)
> > > >>
> > > >> The community feeling was that it would "just go" given a prodigal
> > > >> burst of cross-compiling, but I never got achieved sufficiently high
> > > >> blood pressure to try it...
> > > >
> > > >is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
> > > >initial gnat-4.4 package for debian?
> > > >
> > > > Matthias
> > >
> > > Yes, see <http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
> >
> > Nice work!
> >
> > Looks like Ada exception propagation (setjmp/longjmp based) is broken at
> > least in some cases (see below), that might explain the high number of
> > ACATS failure.
> >
> > My understanding is that
> >
> > EH_MECHANISM=-gcc
> >
> > is not correct for sjlj exceptions so I removed this line from the patch
> > and I'm currently testing with trunk.
>
> With this change plus the gcc/ada/gcc-interface/targtyps.c one
> I get very good native arm ACATS and gnat.dg results:
Thanks Laurent. I've extracted an incremental diff for the Makefile
and targtyps.c changes and applied it to my gcc-4.4.1 version. When
it has finished its rebuild I'll see if this lets me eliminate the
xsinfo.adb exception handling workaround.
> It would be nice to have a ZCX port but so far the sjlj exceptions
> based port works fine.
See e.g. <http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00509.html>.
Apparently ZCX on ARM/EABI will require a new personality routine.
/Mikael
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ada] Anyone else run ACATS on ARM?
2009-08-29 22:49 ` Mikael Pettersson
@ 2009-08-31 16:09 ` Mikael Pettersson
0 siblings, 0 replies; 19+ messages in thread
From: Mikael Pettersson @ 2009-08-31 16:09 UTC (permalink / raw)
To: Mikael Pettersson
Cc: Laurent GUERBY, Matthias Klose, Martin Guy, Joel Sherrill, gcc,
Ludovic Brenta, Geert Bosch, Olivier Hainque
Mikael Pettersson writes:
> Laurent GUERBY writes:
> > On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
> > > On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> > > > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose <doko@debian.org> wrote:
> > > > >On 12.08.2009 23:07, Martin Guy wrote:
> > > > >> On 8/12/09, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
> > > > >>> So any ACATS results from any other ARM target would be
> > > > >>> appreciated.
> > > > >>
> > > > >> I looked into gnat-arm for the new Debian port and the conclusion was
> > > > >> that it has never been bootstrapped onto ARM. The closest I have seen
> > > > >> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
> > > > >> targetting Nucleus OS (gak!)
> > > > >>
> > > > >> The community feeling was that it would "just go" given a prodigal
> > > > >> burst of cross-compiling, but I never got achieved sufficiently high
> > > > >> blood pressure to try it...
> > > > >
> > > > >is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an
> > > > >initial gnat-4.4 package for debian?
> > > > >
> > > > > Matthias
> > > >
> > > > Yes, see <http://user.it.uu.se/~mikpe/linux/arm-eabi-ada/>.
> > >
> > > Nice work!
> > >
> > > Looks like Ada exception propagation (setjmp/longjmp based) is broken at
> > > least in some cases (see below), that might explain the high number of
> > > ACATS failure.
> > >
> > > My understanding is that
> > >
> > > EH_MECHANISM=-gcc
> > >
> > > is not correct for sjlj exceptions so I removed this line from the patch
> > > and I'm currently testing with trunk.
> >
> > With this change plus the gcc/ada/gcc-interface/targtyps.c one
> > I get very good native arm ACATS and gnat.dg results:
>
> Thanks Laurent. I've extracted an incremental diff for the Makefile
> and targtyps.c changes and applied it to my gcc-4.4.1 version. When
> it has finished its rebuild I'll see if this lets me eliminate the
> xsinfo.adb exception handling workaround.
It did, so exceptions do seem to be working now. I've uploaded an
updated bootstrap compiler for armel and two new patches. The patch
kit now is:
gcc-4.4.1-arm-eabi-ada-1.patch: initial patch
gcc-4.4.1-arm-eabi-ada-2.patch: update copyright and licence text
gcc-4.4.1-arm-eabi-ada-3.patch: make SJLJ exceptions work, fix a warning
gcc-4.4.1-arm-eabi-ada-4.patch: revert xsinfo.adb dont-use-exceptions kludge
For those with a compiler based on the initial patch only, apply patches
2 and 3 first, rebuild, then apply patch 4.
/Mikael
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2009-08-31 10:11 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-12 16:40 Anyone else run ACATS on ARM? Joel Sherrill
2009-08-12 22:23 ` Martin Guy
2009-08-13 0:24 ` Matthias Klose
2009-08-13 13:29 ` Martin Guy
2009-08-17 12:32 ` Mikael Pettersson
2009-08-20 9:21 ` Matthias Klose
2009-08-20 12:52 ` Joel Sherrill
2009-08-22 18:55 ` Matthias Klose
2009-08-23 5:10 ` [Ada] " Laurent GUERBY
2009-08-29 16:29 ` Laurent GUERBY
2009-08-29 22:49 ` Mikael Pettersson
2009-08-31 16:09 ` Mikael Pettersson
2009-08-23 14:15 ` Laurent GUERBY
2009-08-23 22:28 ` Ludovic Brenta
2009-08-24 1:45 ` Mikael Pettersson
2009-08-27 4:24 ` Geert Bosch
2009-08-27 14:58 ` Joel Sherrill
2009-08-27 21:37 ` Joel Sherrill
2009-08-28 19:15 ` Olivier Hainque
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).