Add Ada support for aarch64-*-freebsd*

The attached patch to gcc trunk enables Ada support on 
aarch64-*-freebsd*.  All tests pass except those affected by the 
currently missing unwind support (c52103x, c52104x, c52104y, cb1010a, 
cb1010c, cb1010d,  gnat.dg/null_pointer_deref* (3)).

I'd also like to get this patch backported to the gcc-6 branch.  There's 
a one-line content difference between patches, so I've attached the 6.x 
specific patch as well.

My copyright assignment is on file and in order.

Thanks,
John

gcc/ada/Changelog:
2017-02-XX  John Marino  <gnugcc@marino.st>

         * gcc-interface/Makefile.in: Support aarch64-freebsd



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--- gcc/ada/gcc-interface/Makefile.in.orig	2017-02-06 18:55:09 UTC
+++ gcc/ada/gcc-interface/Makefile.in
@@ -1475,6 +1475,34 @@ ifeq ($(strip $(filter-out x86_64 kfreeb
   LIBRARY_VERSION := $(LIB_VERSION)
 endif
 
+# aarch64 FreeBSD
+ifeq ($(strip $(filter-out %aarch64 freebsd%,$(target_cpu) $(target_os))),)
+  LIBGNAT_TARGET_PAIRS = \
+  a-intnam.ads<a-intnam-freebsd.ads \
+  s-inmaop.adb<s-inmaop-posix.adb \
+  s-intman.adb<s-intman-posix.adb \
+  s-mudido.adb<s-mudido-affinity.adb \
+  s-osinte.adb<s-osinte-freebsd.adb \
+  s-osinte.ads<s-osinte-freebsd.ads \
+  s-osprim.adb<s-osprim-posix.adb \
+  s-taprop.adb<s-taprop-posix.adb \
+  s-taspri.ads<s-taspri-posix.ads \
+  s-tpopsp.adb<s-tpopsp-posix.adb \
+  $(ATOMICS_TARGET_PAIRS) \
+  $(ATOMICS_BUILTINS_TARGET_PAIRS) \
+  system.ads<system-freebsd-x86_64.ads
+
+  TOOLS_TARGET_PAIRS = \
+  mlib-tgt-specific.adb<mlib-tgt-specific-linux.adb
+  GNATLIB_SHARED = gnatlib-shared-dual
+
+  EH_MECHANISM=-gcc
+  THREADSLIB= -lpthread
+  GMEM_LIB = gmemlib
+  LIBRARY_VERSION := $(LIB_VERSION)
+  MISCLIB = -lutil
+endif
+
 # x86 FreeBSD
 ifeq ($(strip $(filter-out %86 freebsd%,$(target_cpu) $(target_os))),)
   LIBGNAT_TARGET_PAIRS = \

> The attached patch to gcc trunk enables Ada support on
> aarch64-*-freebsd*.  All tests pass except those affected by the
> currently missing unwind support (c52103x, c52104x, c52104y,
> cb1010a, cb1010c, cb1010d,  gnat.dg/null_pointer_deref* (3)).
> 
> I'd also like to get this patch backported to the gcc-6 branch.
> There's a one-line content difference between patches, so I've
> attached the 6.x specific patch as well.
> 
> My copyright assignment is on file and in order.
> 
> gcc/ada/Changelog:
> 2017-02-XX  John Marino  <gnugcc@marino.st>
> 
>         * gcc-interface/Makefile.in: Support aarch64-freebsd

It seems wrong to reuse system-freebsd-x86.ads for a different processor.
We should either:

- use a different system file (e.g. system-freebsd-aarch64.ads)
- or rename the file to e.g. system-freebsd.ads, *and* adjust the
  setting of at least Default_Bit_Order to something like:

     Default_Bit_Order : constant Bit_Order :=
                         Bit_Order'Val (Standard'Default_Bit_Order);

Arno

On 2/7/2017 05:37, Arnaud Charlet wrote:
>> The attached patch to gcc trunk enables Ada support on
>> aarch64-*-freebsd*.  All tests pass except those affected by the
>> currently missing unwind support (c52103x, c52104x, c52104y,
>> cb1010a, cb1010c, cb1010d,  gnat.dg/null_pointer_deref* (3)).
>>
>> I'd also like to get this patch backported to the gcc-6 branch.
>> There's a one-line content difference between patches, so I've
>> attached the 6.x specific patch as well.
>>
>> My copyright assignment is on file and in order.
>>
>> gcc/ada/Changelog:
>> 2017-02-XX  John Marino  <gnugcc@marino.st>
>>
>>         * gcc-interface/Makefile.in: Support aarch64-freebsd
>
> It seems wrong to reuse system-freebsd-x86.ads for a different processor.
> We should either:
>
> - use a different system file (e.g. system-freebsd-aarch64.ads)
> - or rename the file to e.g. system-freebsd.ads, *and* adjust the
>   setting of at least Default_Bit_Order to something like:
>
>      Default_Bit_Order : constant Bit_Order :=
>                          Bit_Order'Val (Standard'Default_Bit_Order);
>
> Arno
>

Hi Arno,
This is exactly what aarch64-*-linux* is doing is doing in gcc 6 branch 
(e.g.  system.ads<system-linux-x86_64.ads) which is what I modeled it 
after, but now I see it has been changed to 
"system.ads<system-linux-arm.ads" in trunk. (changed to 
"system.ads<system-linux-armel.ads" on r241316 without explanation and 
then to "system.ads<system-linux-arm.ads" on r241328)

I would vote for simply copying system-freebsd-x86.ads to 
system-freebsd-aarch64.ads but that seems to go against the recent 
effort to merge the x86-64 and i386 system versions.  I am not currently 
aware of any content differences between system-freebsd-x86.ads and the 
proposed system-freebsd-aarch64.ads.  They would be duplicates as far as 
I know.

(I'm not particularly fond of one system file for all processors though).

John

> This is exactly what aarch64-*-linux* is doing is doing in gcc 6
> branch (e.g.  system.ads<system-linux-x86_64.ads) which is what I
> modeled it after, but now I see it has been changed to

Well no, you are reusing an x86_64 file for an aarch64 architecture, so
this is exactly the same issue.

Arno

On 2/7/2017 07:41, Arnaud Charlet wrote:
>> This is exactly what aarch64-*-linux* is doing is doing in gcc 6
>> branch (e.g.  system.ads<system-linux-x86_64.ads) which is what I
>> modeled it after, but now I see it has been changed to
>
> Well no, you are reusing an x86_64 file for an aarch64 architecture, so
> this is exactly the same issue.

I was pointing out that on gcc-6, aarch64-linux is using x86-64 system 
file too.  Since I used gcc-6 for the original testing on freebsd, 
that's where it came from.  It's been changed on trunk, but nobody 
backported those changes to gcc-6.  It was obviously "good enough" and a 
"placeholder" as indicated in the nearby comment.

If you want, I can create a duplicate file with a different name.  Or I 
can add a "placeholder" comment like we see on aarch64-linux.  Adding a 
new system file would not change the end result but if you like it more, 
I'll submit a new patch that creates this new system file.

John

> I was pointing out that on gcc-6, aarch64-linux is using x86-64
> system file too.  Since I used gcc-6 for the original testing on
> freebsd, that's where it came from.  It's been changed on trunk, but
> nobody backported those changes to gcc-6.  It was obviously "good
> enough" and a "placeholder" as indicated in the nearby comment.

Well, that's a bad practice that we want to fix rather than copy :-)

> If you want, I can create a duplicate file with a different name.
> Or I can add a "placeholder" comment like we see on aarch64-linux.
> Adding a new system file would not change the end result but if you
> like it more, I'll submit a new patch that creates this new system
> file.

Given that the more recent trend is to merge more these system files
as opposed to systematically breaking them, I'd recommend renaming the
file to system-freedbsd and change the definition of Default_Bit_Order
which will be needed sooner or later in any case (if not already).

Arno

On 2/7/2017 07:53, Arnaud Charlet wrote:
>> I was pointing out that on gcc-6, aarch64-linux is using x86-64
>> system file too.  Since I used gcc-6 for the original testing on
>> freebsd, that's where it came from.  It's been changed on trunk, but
>> nobody backported those changes to gcc-6.  It was obviously "good
>> enough" and a "placeholder" as indicated in the nearby comment.
>
> Well, that's a bad practice that we want to fix rather than copy :-)
>
>> If you want, I can create a duplicate file with a different name.
>> Or I can add a "placeholder" comment like we see on aarch64-linux.
>> Adding a new system file would not change the end result but if you
>> like it more, I'll submit a new patch that creates this new system
>> file.
>
> Given that the more recent trend is to merge more these system files
> as opposed to systematically breaking them, I'd recommend renaming the
> file to system-freedbsd and change the definition of Default_Bit_Order
> which will be needed sooner or later in any case (if not already).
>

Okay, I'll modify the patch accordingly.  It increases the complexity 
but if that's the correct approach then so be it.

John