Hello everybody! I bring good news!

GCC with Ada support has been updated in NetBSD! Now versions 10 and 11
should work on x86 and x86_64 NetBSD machines! You can find them in
pkgsrc-wip (gcc10-aux) [1] and Ravenports (gcc11)
[http://www.ravenports.com/]!

First things first, the acknowledgements: a big thank you goes to J.
Marino who did the original gcc-aux packages and who provided most if
not all the work when it came to fixing the threads and symbols. Another
big thank you goes to tobiasu who correctly picked up that the pthread structure wrappers were not correct and had to be remade. Another big
thank you goes to Jay Patelani for his help with pkgsrc.

So, long story short. Most of the work that had been done up until a few
weeks ago was done correctly, but the failing tests (most related to
tasking) were failing in very strange ways. It happened that the pthread structure memory that the Ada wrapper was using was incorrect, so we
were getting completely erratic behaviour. Once that got fixed, pretty
much all tests passed. J. Marino also took the time and effort to create __gnat_* function wrappers to all the symbols that the NetBSD people
have renamed. This is a much cleaner fix and allows for the renamed
functions to generate the correct symbols since now they are getting preprocessed. It should also be more "upstream friendly". The issue,
however, remains if NetBSD decides to rename more functions that are
still being linked directly.

There are still some failing ACATS tests (about 10). Some are related to numerical precision and a couple others. They are mostly the same
failing tests in both GCC 10 and 11. J. Marino ran the ACATS tests on a DragonflyBSD (or was it FreeBSD?) machine and the same tests were
failing there too. So we suspect is is a common limitation on *BSDs and
it is unlikely that this will ever affect anybody. There is also the
issue of stack unwinding when it contains a signal trampoline [2], read
the following thread to gain more information about this.

[1] https://github.com/NetBSD/pkgsrc-wip/tree/master/gcc10-aux
[2] https://mail-index.netbsd.org/tech-kern/2021/10/15/msg027703.html

I have started trying to get GCC to xcompile to arm* on NetBSD. I think
I am somewhat close, but further hacking on NetBSD's src is needed (and
I think the RTS is not getting picked up correctly). So do not get your
hopes up. I mean, I have a working gcc x86_64 NetBSD host to NetBSD arm* xcompiler, it is the native gcc on arm* that is not getting built correctly.

Regards,
--
Fernando Oleo Blanco
https://irvise.xyz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/10/2021 04.47, Fernando Oleo Blanco wrote:

Hello everybody! I bring good news!

GCC with Ada support has been updated in NetBSD! Now versions 10 and 11 should work on x86 and x86_64 NetBSD machines! You can find them in pkgsrc-wip (gcc10-aux) [1] and Ravenports (gcc11) [http://www.ravenports.com/]!

First things first, the acknowledgements: a big thank you goes to J.
Marino who did the original gcc-aux packages and who provided most if
not all the work when it came to fixing the threads and symbols. Another
big thank you goes to tobiasu who correctly picked up that the pthread structure wrappers were not correct and had to be remade. Another big
thank you goes to Jay Patelani for his help with pkgsrc.

So, long story short. Most of the work that had been done up until a few weeks ago was done correctly, but the failing tests (most related to
tasking) were failing in very strange ways. It happened that the pthread structure memory that the Ada wrapper was using was incorrect, so we
were getting completely erratic behaviour. Once that got fixed, pretty
much all tests passed. J. Marino also took the time and effort to create __gnat_* function wrappers to all the symbols that the NetBSD people
have renamed. This is a much cleaner fix and allows for the renamed
functions to generate the correct symbols since now they are getting preprocessed. It should also be more "upstream friendly". The issue,
however, remains if NetBSD decides to rename more functions that are
still being linked directly.

There are still some failing ACATS tests (about 10). Some are related to numerical precision and a couple others. They are mostly the same
failing tests in both GCC 10 and 11. J. Marino ran the ACATS tests on a DragonflyBSD (or was it FreeBSD?) machine and the same tests were
failing there too. So we suspect is is a common limitation on *BSDs and
it is unlikely that this will ever affect anybody. There is also the
issue of stack unwinding when it contains a signal trampoline [2], read
the following thread to gain more information about this.

[1] https://github.com/NetBSD/pkgsrc-wip/tree/master/gcc10-aux
[2] https://mail-index.netbsd.org/tech-kern/2021/10/15/msg027703.html

I have started trying to get GCC to xcompile to arm* on NetBSD. I think
I am somewhat close, but further hacking on NetBSD's src is needed (and
I think the RTS is not getting picked up correctly). So do not get your
hopes up. I mean, I have a working gcc x86_64 NetBSD host to NetBSD arm* xcompiler, it is the native gcc on arm* that is not getting built
correctly.

Regards,

A big applause for your hard work identifying the problem in the first
place.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

When I was working at AdaCore, we used to run our internal CRM and the ticket-management tool that processes all email on a FreeBSD machine, because the sysadmin was very fond of that system. The CRM was (is?) based on AWS (Ada Web Server), so using
tasking pretty heavily. We never had any problem at the time.
I guess AdaCore has given up on FreeBSD, like they have MacOS.
Emmanuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

[1] https://github.com/NetBSD/pkgsrc-wip/tree/master/gcc10-aux

Should DESCR memntion Ada?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20.10.21 15:01, Simon Wright wrote:

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

[1] https://github.com/NetBSD/pkgsrc-wip/tree/master/gcc10-aux

Should DESCR memntion Ada?

Ooops, yes indeed. It needs to be updated, I just copied gcc10 and only
cared about it compiling...

Regards,
--
Fernando Oleo Blanco
https://irvise.xyz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20.10.21 08:43, Emmanuel Briot wrote:

I guess AdaCore has given up on FreeBSD, like they have MacOS.
Emmanuel

Well, GCC officially supports FreeBSD x86* and AFAIK, arm too. Though,
AFAIK, the gcc-aux packages from freshports have been left without maintainer...


And good news everybody! I have managed to get GPRBuild working and
Alire too! I even got the GNATColl components built using Alire ^^.
Pretty easy if you ask me :P

The mayor issue I am facing now is with make... I tried building AWS
with Alire but it could not, since it was using make, which in *BSD
world is BSD make, aka, bmake, not GNU make, aka gmake... Anyhow, I am
very happy to see so many packages getting built without issues in NetBSD :D

There is the problem where GPRBuild says that the "lib" option is not
supported on the OS. I don't think it is suprissing since GPRBuild
probably does not know anything about NetBSD.

I am also getting warnings from gnatmake:

/home/fernando/bootstrap_ada/alire/src/alire/alire-toolchains.adb: In
function 'Alire.Toolchains.Assistant': /home/fernando/bootstrap_ada/alire/src/alire/alire-toolchains.adb:331:8: warning: frame size too large for reliable stack checking

which probably come from NetBSD having a small stack by default.

Regards,
--
Fernando Oleo Blanco
https://irvise.xyz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

There are still some failing ACATS tests (about 10). Some are related
to numerical precision and a couple others. They are mostly the same
failing tests in both GCC 10 and 11

For ACATS 4.1X on macOS, with GCC 11.2.0, I got

# of expected passes 2529
# of unexpected failures 14
# of expected failures 1487
# of unresolved testcases 11
# of unsupported tests 124
*** FAILURES: c250002 c324006 c35503d c35503f c415001 c611a04 cxaib05
cxaib08 cxd1003 cxd1004 cxd1005 cxd2006 cxd3001 cxd3002

C250002 macOS/Windows UTF-8 file names
C324006 wrong exception message
C35503D GCC 11 supports 128-bit integers
C35503F likewise
C415001 non-local pointer
C611A04 Assertion_Error not raised (classwide pre-, post conditions)
CXAIB05 Map doesn't have preelaborable initialization
CXAIB08 preelaborated unit with non-static default
CXD1003 exception did not occur
CXD1004 incorrect number of calls
CXD1005 likewise
CXD2006 protected object count is messed up
CXD3001 Program_Error not raised
CXD3002 ceiling check not called correctly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Simon Wright" <simon@pushface.org> wrote in message news:lyzgr3h0t2.fsf@pushface.org...
...

*** FAILURES: c250002 c324006 c35503d c35503f c415001 c611a04 cxaib05
cxaib08 cxd1003 cxd1004 cxd1005 cxd2006 cxd3001 cxd3002

...

C35503D GCC 11 supports 128-bit integers
C35503F likewise

These two are "macro" tests, such that one is supposed to modify the values
in the Macro.Dfs file and regenerate these tests with the correct values. If the compiler supports 128-bit integers, then those values would be different (and a lot longer) than the values for 64-bit integers. They could of course fail for some other reason, but getting those values wrong in the original substitution is bad.

Randy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Randy Brukardt" <randy@rrsoftware.com> writes:

"Simon Wright" <simon@pushface.org> wrote in message news:lyzgr3h0t2.fsf@pushface.org...
...

*** FAILURES: c250002 c324006 c35503d c35503f c415001 c611a04 cxaib05
cxaib08 cxd1003 cxd1004 cxd1005 cxd2006 cxd3001 cxd3002

...

C35503D GCC 11 supports 128-bit integers
C35503F likewise

These two are "macro" tests, such that one is supposed to modify the
values in the Macro.Dfs file and regenerate these tests with the
correct values. If the compiler supports 128-bit integers, then those
values would be different (and a lot longer) than the values for
64-bit integers. They could of course fail for some other reason, but
getting those values wrong in the original substitution is bad.

Yes; what happens in the GCC version is that MACRO.DFS gets regenerated
from a template version during setup.

I missed a change made 14 months ago, i.e. in preparaton for GCC 11, in
which (for 64-bit targets) the expected max/min_int are set to 128-bit
values.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Here are quite a few results!

---------

GCC 10.3.0 NetBSD x86_64 ACATS 4.1W (Note, test c452003 is known to not
run on GCC 10, and it was manually killed)

---

bash-5.1$ ../ACATS/run_local.sh
fmt: unknown option -- 1
Usage: fmt [-Cr] [-g <goal>] [-m|w <max>] [<files>..]
fmt [-Cr] [<goal>] [<max>] [<files>]
Test Run By fernando on Wed Oct 20 20:47:10 CEST 2021
=== acats configuration ===
target gcc is /usr/pkg/gcc10/bin/gcc
Using built-in specs. COLLECT_GCC=/usr/pkg/gcc10/bin/gcc COLLECT_LTO_WRAPPER=/usr/pkg/gcc10/libexec/gcc/x86_64--netbsd/10.3.0/lto-wrapper
Target: x86_64--netbsd Configured with: ../gcc-10.3.0/configure --disable-libstdcxx-pch --enable-nls --with-libiconv-prefix=/usr --enable-__cxa_atexit --with-gxx-include-dir=/usr/pkg/gcc10/include/c++/ --disable-libssp --enable-languages='c fortran ada c++' --enable-shared --enable-long-long --with-local-prefix=/usr/pkg/gcc10
--enable-threads=posix --with-boot-ldflags='-static-libstdc++
-static-libgcc
-Wl,-R/usr/pkg/gcc6-aux/lib/gcc/x86_64-aux-netbsd9.2/6.2.0 -Wl,-R/usr/pkg/gcc6-aux/lib -Wl,-R/usr/pkg/lib ' --with-system-zlib --without-zstd --with-arch=nocona -

Simon Wright <simon@pushface.org> writes:

"Randy Brukardt" <randy@rrsoftware.com> writes:

"Simon Wright" <simon@pushface.org> wrote in message
news:lyzgr3h0t2.fsf@pushface.org...
...

*** FAILURES: c250002 c324006 c35503d c35503f c415001 c611a04 cxaib05
cxaib08 cxd1003 cxd1004 cxd1005 cxd2006 cxd3001 cxd3002

...

C35503D GCC 11 supports 128-bit integers
C35503F likewise

These two are "macro" tests, such that one is supposed to modify the
values in the Macro.Dfs file and regenerate these tests with the
correct values. If the compiler supports 128-bit integers, then those
values would be different (and a lot longer) than the values for
64-bit integers. They could of course fail for some other reason, but
getting those values wrong in the original substitution is bad.

Yes; what happens in the GCC version is that MACRO.DFS gets regenerated
from a template version during setup.

I missed a change made 14 months ago, i.e. in preparaton for GCC 11, in
which (for 64-bit targets) the expected max/min_int are set to 128-bit values.

Now fixed (for GCC 11+), tag acats-4.1x.

GCC 10 doesn't support 128-bit integers; not sure how to retain
compatibility and also abide by the spirit of the GCC version of ACATS.
I see that GCC introduced a support program Impbit, which reports the compiler's System.Address'Size'Img; a program Imp_Max_Int which reports
the compiler's System.Max_Int, and using the result to check
System.Max_Int, seems a tad incestuous.

Fernando, you're using GCC 10? I've tagged the previous release with acats-4.1w.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Simon Wright <simon@pushface.org> writes:

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

There are still some failing ACATS tests (about 10). Some are related
to numerical precision and a couple others. They are mostly the same
failing tests in both GCC 10 and 11

For ACATS 4.1X on macOS, with GCC 11.2.0, I got

# of expected passes 2529
# of unexpected failures 14
# of expected failures 1487
# of unresolved testcases 11
# of unsupported tests 124
*** FAILURES: c250002 c324006 c35503d c35503f c415001 c611a04 cxaib05
cxaib08 cxd1003 cxd1004 cxd1005 cxd2006 cxd3001 cxd3002

C250002 macOS/Windows UTF-8 file names
C324006 wrong exception message
C35503D GCC 11 supports 128-bit integers
C35503F likewise
C415001 non-local pointer
C611A04 Assertion_Error not raised (classwide pre-, post conditions)
CXAIB05 Map doesn't have preelaborable initialization
CXAIB08 preelaborated unit with non-static default
CXD1003 exception did not occur
CXD1004 incorrect number of calls
CXD1005 likewise
CXD2006 protected object count is messed up
CXD3001 Program_Error not raised
CXD3002 ceiling check not called correctly

For ACATS 4.1W, gcc version 12.0.0 20211021 (experimental), C611A04,
CXAIB05, CXAIB08 pass, leaving 9 failures (probably 8 on systems with case-sensitive filesystems - for C250002, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I just ran the tests from GCC once again. However, this time, I am using
an updated version of gcc10 from pkgsrc-current, which has a few
changes. These are the results:

LAST_UPDATED: Obtained from git: releases/gcc-10.3.0 revision f00b5710a30f22efc3171c393e56aeb335c3cd39

=== acats tests ===
FAIL: c52103x
FAIL: c52104x
FAIL: c52104y
FAIL: c52103x
FAIL: c52104x
FAIL: c52104y
FAIL: c52103x
FAIL: c52104x
FAIL: c52104y
FAIL: cb1010a
FAIL: cb1010c
FAIL: cb1010d
FAIL: cb1010a
FAIL: cb1010c
FAIL: cb1010d
FAIL: cb1010a
FAIL: cb1010c
FAIL: cb1010d

=== acats Summary ===
# of expected passes 6942
# of unexpected failures 18
Native configuration is x86_64--netbsd

=== gnat tests ===


Running target unix
FAIL: gnat.dg/align_max.adb execution test
FAIL: gnat.dg/null_pointer_deref1.adb execution test
FAIL: gnat.dg/null_pointer_deref2.adb execution test
FAIL: gnat.dg/null_pointer_deref3.adb execution test
FAIL: gnat.dg/stack_check1.adb execution test
FAIL: gnat.dg/stack_check2.adb execution test

=== gnat Summary ===

# of expected passes 3292
# of unexpected failures 6
# of expected failures 23
# of unsupported tests 9 /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/gnatmake version 10.3.0

---

So no changes. However, I take this opportunity to communicate that I am
in the process of cleaning the package and make it into pkgsrc-Q4. Most
issues have been ironed out. I just need to update the description of
the package (not DESCR), make gcc6-aux an explicit dependency and
comment the patches (required by the NetBSD people).

Regards,
--
Fernando Oleo Blanco
https://irvise.xyz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

=== acats tests ===
FAIL: c52103x
FAIL: c52104x
FAIL: c52104y
FAIL: c52103x
FAIL: c52104x
FAIL: c52104y
FAIL: c52103x
FAIL: c52104x
FAIL: c52104y
FAIL: cb1010a
FAIL: cb1010c
FAIL: cb1010d
FAIL: cb1010a
FAIL: cb1010c
FAIL: cb1010d
FAIL: cb1010a
FAIL: cb1010c
FAIL: cb1010d

That's the same 6 failures reported 3 times each. Not sure wht's going
on there! (but 6 is Pretty Impressive)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

A bit of a followup.

The package gcc10-aux has been updated in pkgsrc-wip. I am now the
maintainer. As requested by some pkgsrc developer, I have made the
package explicitly depend on gcc6-aux. That way, it may be used as a
base Ada compiler for all the packages that need Ada (although this is
just the first step). I have also rebased it on the new skeleton of
gcc10 from pkgsrc-current. Hopefully the review period an inclusion into pkgsrc-current will not take much much time.

I have ran the new version of ACATS from Simon, version 4.1X. Here are
the results:

Test Run By fernando on Tue Nov 2 20:23:32 CET 2021
=== acats configuration ===
target gcc is /usr/pkg/gcc10-aux/bin/gcc
Using built-in specs. COLLECT_GCC=/usr/pkg/gcc10-aux/bin/gcc COLLECT_LTO_WRAPPER=/usr/pkg/gcc10-aux/libexec/gcc/x86_64--netbsd/10.3.0/lto-wrapper
Target: x86_64--netbsd Configured with: ../gcc-10.3.0/configure --disable-libstdcxx-pch --enable-nls --with-libiconv-prefix=/usr --enable-__cxa_atexit
--with-gxx-include-dir=/usr/pkg/gcc10-aux/include/c++/ --disable-libssp --enable-languages='c ada fortran c++' --enable-shared
--enable-long-long --with-local-prefix=/usr/pkg/gcc10-aux --enable-threads=posix --with-boot-ldflags='-static-libstdc++
-static-libgcc -Wl,-R/usr/pkg/lib -Wl,-zrelro -Wl,-znow '
--with-system-zlib --without-zstd --with-arch=nocona --with-tune=nocona --with-fpmath=sse --with-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/bin/as --prefix=/usr/pkg/gcc10-aux --build=x86_64--netbsd --host=x86_64--netbsd --infodir=/usr/pkg/gcc10-aux/info --mandir=/usr/pkg/gcc10-aux/man Thread model: posix Supported LTO
compression algorithms: zlib gcc version 10.3.0 (GCC)
host=x86_64--netbsd
target=x86_64--netbsd
gnatmake is /usr/pkg/gcc10-aux/bin/gnatmake

=== acats support ===
Generating support files... done.
Compiling support files... done.

=== acats Summary ===
# of expected passes 2514
# of unexpected failures 30
# of expected failures 1487
# of unresolved testcases 11
# of unsupported tests 124
*** FAILURES: c324006 c350a01 c35503d c35503f c452003 c452005 c452006
c52103x c52104x c52104y c611a04 c650b04 c760a02 cb1010a cb1010c cb1010d
cdd2b03 cdd2b04 cxai001 cxai010 cxaia01 cxaib05 cxaib06 cxaib08 cxd1003
cxd1004 cxd1005 cxd2006 cxd3001 cxd3002 /home/fernando/gcc10-aux-tests/ACATS/run_all.sh completed at Tue Nov 2 21:25:36 CET 2021

Regards,
--
Fernando Oleo Blanco
https://irvise.xyz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Would you look at that:

=== acats tests ===
FAIL: ce3404c

=== acats Summary ===
# of expected passes 6959
# of unexpected failures 1
Native configuration is x86_64--netbsd

=== gnat tests ===


Running target unix
FAIL: gnat.dg/align_max.adb execution test

=== gnat Summary ===

# of expected passes 3297
# of unexpected failures 1
# of expected failures 23
# of unsupported tests 9 /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/gnatmake version 10.3.0


And I am actually a bit angry, because that one acats test was not
failing a few hours ago. I will try to run the tests once again with
just one core.

What has changed?

This is GCC 10.3.0 ACATS test suite... In NetBSD-current (9.99.92). All
working _flawlessly_! (almost).

I will make a longer commentary later.

Regards,
Fer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

=== acats tests ===
FAIL: ce3404c

=== acats Summary ===
# of expected passes 6959
# of unexpected failures 1
Native configuration is x86_64--netbsd

That's three times* the number of test cases. I noticed this before --
are you doing three parallel executions (the part of the script that
runs parallel executions is particularly gnarly)? Maybe only one of the ce3404c's failed?

* more or less. Just ran for gcc version 12.0.0 20211021 with -j4,

=== acats Summary ===
# of expected passes 2328
# of unexpected failures 0

I don't think the ACATS in GCC reports all the outcomes the way it
should: in particular, there were a considerable number of 'unsupported
tests' (e.g. those where the test reports 'NOT-APPLICABLE'), and of
course this was a .0.0 (work-in-progress) release. Perhaps x86_64-apple-darwin15 has one more unsupported test than x86_64--netbsd.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sat, 06 Nov 2021 21:02:48 +0000
schrieb Simon Wright <simon@pushface.org>:

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

=== acats tests ===
FAIL: ce3404c

=== acats Summary ===
# of expected passes 6959
# of unexpected failures 1
Native configuration is x86_64--netbsd

That's three times* the number of test cases. I noticed this before --
are you doing three parallel executions (the part of the script that
runs parallel executions is particularly gnarly)? Maybe only one of
the ce3404c's failed?

* more or less. Just ran for gcc version 12.0.0 20211021 with -j4,

=== acats Summary ===
# of expected passes 2328
# of unexpected failures 0

I don't think the ACATS in GCC reports all the outcomes the way it
should: in particular, there were a considerable number of
'unsupported tests' (e.g. those where the test reports
'NOT-APPLICABLE'), and of course this was a .0.0 (work-in-progress)
release. Perhaps x86_64-apple-darwin15 has one more unsupported test
than x86_64--netbsd.

I have good news, but first things first.

Yes, I ran the tests in parallel, to be exact, with -j3. I am using the
pkgsrc infra, which means that I am not using gcc infra directly, which
could lead to errors.

The first run I believe did not generate any errors. I tried a second
time and the results are what I posted. I tried a third time and it was
chaos. All the times I ran the tests in parallel, they seemed to run
three times, instead of in parallel.

I decided to rebuild the entire thing from scratch and run the test in
serial (-j1). Annnnnddddd....... Here are the results!

GCC 10.3.0 native ACATS NetBSD-9.99.92 (serial execution)

=== acats tests ===

=== acats Summary ===
# of expected passes 2320
# of unexpected failures 0
Native configuration is x86_64--netbsd


=== gnat tests ===


Running target unix
FAIL: gnat.dg/align_max.adb execution test

=== gnat Summary ===

# of expected passes 3297
# of unexpected failures 1
# of expected failures 23
# of unsupported tests 9 /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/gnatmake version 10.3.0

Much better!!!! I think I was right to say that the previous failing
tests where not because of our doing (or lack thereof), but because of
the compiler/OS.

I also ran ACATS 4.1X. Here are the results:

=== acats Summary ===
# of expected passes 2520
# of unexpected failures 24
# of expected failures 1487
# of unresolved testcases 11
# of unsupported tests 124
*** FAILURES: c324006 c350a01 c35503d c35503f c452003 c452005 c452006
c611a04 c650b04 c760a02 cdd2b03 cdd2b04 cxai001 cxai010 cxaia01 cxaib05
cxaib06 cxaib08 cxd1003 cxd1004 cxd1005 cxd2006 cxd3001 cxd3002 /home/fernando/ada_test/ACATS/run_all.sh completed at Sat Nov 6
19:45:05 CET 2021


Much better too! For comparison, here are the GCC 10.3 ACATS 4.1W
results in NetBSD 9.2

=== acats Summary ===
# of expected passes 2516
# of unexpected failures 28
# of expected failures 1484
# of unresolved testcases 11
# of unsupported tests 124
*** FAILURES: c324006 c350a01 c452003 c452005 c452006 c52103x c52104x
c52104y c611a04 c650b04 c760a02 cb1010a cb1010c cb1010d cdd2b03 cdd2b04
cxai001 cxai010 cxaia01 cxaib05 cxaib06 cxaib08 cxd1003 cxd1004 cxd1005
cxd2006 cxd3001 cxd3002
/home/fernando/acats/ACATS/run_all.sh completed at Wed Oct 20 22:13:57
CEST 2021

We are getting 4 less failures (with c452003 know to stall gcc), which
is always nice :D

I think my work is mostly done. Jay Patelani has also successfully
built GCC 10.3 in NetBSD 9.2; racoon from IRC has also built GCC 10.3
in NetBSD 9.99.92, so great! Another user from the ML repoted issues
with RELRO in the Ada code using NetBSD 9.99.88, but with the patch

diff --git a/gcc10-aux/Makefile b/gcc10-aux/Makefile
index 88cc2dc1ea..4b122d83d1 100644
--- a/gcc10-aux/Makefile
+++ b/gcc10-aux/Makefile
@@ -24,6 +24,8 @@ EXTRACT_ONLY= ${DEFAULT_DISTFILES}
# Relocations result in a linker error on AArch64, but not x86.
MKPIE_SUPPORTED= no

+RELRO_SUPPORTED= no
+
NOT_FOR_PLATFORM= Interix-*-*

USE_TOOLS+= gmake makeinfo sed:run tar:build

He made it compile. I think this issue if mostly due to his older
system. I think I heard that there were some issues with RELRO in
-current, which seem to have already been fixed in newer version.

Regards,
Fer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Well well well...

I come with a Christmas present... Ada running on NetBSD-powerpc! It
should run on any powerpc "port", in NetBSD terms also known as evbppc,
macppc and amigappc.

It is not perfect, but it is there.

Here are the results from ACATS 4.1X running natively on the macppc port
(as created by https://github.com/alarixnia/mkimg-netbsd)

=== acats Summary ===
# of expected passes 2490
# of unexpected failures 62
# of expected failures 1487
# of unresolved testcases 11
# of unsupported tests 116
*** FAILURES: c324006 c350a01 c452003 c452005 c452006 c452a02 c52103x
c52104x c52104y c552a01 c552a02 c611a04 c650b04 c760a02 c96001a c96008a
c96008b cb1010a cb1010c cb1010d cc40001 cc51007 cdd2b03 cdd2b04 cxa4010
cxa4011 cxa4021 cxa4022 cxa4023 cxa4030 cxa4031 cxa4032 cxa4033 cxa4035
cxaa022 cxab004 cxab005 cxac004 cxag001 cxag003 cxai001 cxai009 cxai010
cxaia01 cxaib05 cxaib06 cxaib08 cxb4002 cxb4005 cxb5002 cxb5003 cxd1003
cxd1004 cxd1005 cxd2002 cxd2003 cxd2004 cxd2006 cxd3001 cxd3002 cxd6001
cxd6002
/home/fernando/ACATS-master/run_all.sh completed at Thu Dec 23 10:13:16
UTC 2021

The compiler is GCC from the NetBSD src tree, which is an older GCC 10
version. Which means (following the results from previous runs) that 28 failures where expected; 6 from shortcomings from NetBSD and the rest
from GCC 10 not passing newer tests. That means this system generated at
least 34 new failures. This may be for a number of reasons, both related
and unrelated to GCC-Ada. Still, I think they are rather good! I believe
a lot of cxa failures were due to the system running on low memory.
Also, the compiler was built against NetBSD 9.99.92, but the actual host
is 9.2, and NetBSD is not backwards compatible; so that may explain
other failures.

Just for your own enjoyment, these tests took about 2 days to run, since
I am emulating powerpc on a virtualised NetBSD-x86_64 system :P

The reason I tried to run powerpc is because, to put it bluntly, NetBSD
has to fix their shit with aarch64 and mips64 and because they do not
provide binaries for POWER. NetBSD just works if you use their tooling,
but the moment something out of the ordinary of what has to be built,
fecal mater impacts the air impeller (credit to a reddit user for that one).

Merry Christmas everybody!
Fer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Merry Xmas
We found a potential compiler bug when running make in the tests directory of this package on OpenBSD. Does it work on NetBSD out of interest?

"https://github.com/rod-chapman/SPARKNaCl"

This is the ACATs results for OpenBSD

"https://github.com/kevlar700/OpenBSD_GNAT_11_ACATS/blob/main/acats.sum"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I do not have GCC 11 on NetBSD, which is required for SPARKNaCl.
However, I expect to spend some time with Ravenports, which does
support GCC 11 on NetBSD. So I hope to try it out soon.

Regarding ACATS on OBSD; the results seem to be good. Yes, there are
some failures, but I would expect some of those to come from
limitations of GCC 11. Afaik/seen, OpenBSD has outstanding support for
Ada in ports.

Regards,
Fer

Am Thu, 23 Dec 2021 05:15:42 -0800 (PST)
schrieb Kevin Chadwick <kevc3no4@gmail.com>:

Merry Xmas
We found a potential compiler bug when running make in the tests
directory of this package on OpenBSD. Does it work on NetBSD out of
interest?

"https://github.com/rod-chapman/SPARKNaCl"

This is the ACATs results for OpenBSD

"https://github.com/kevlar700/OpenBSD_GNAT_11_ACATS/blob/main/acats.sum"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

One last update on GCC 10 on NetBSD.

As I have already said in other messages, it works great. The package
is still under wip since no maintainer has stepped up to take care of
the review. I also have not pushed it further.

I would recommend the use of Ravenports, since it has GCC 11, which is
newer and works on FreeBSD too.

I have given up on trying to port it to other arches. It should be as
simple as adding them to the Makefile.rtl. There is a minor bug on my
patchset, the x86 intrinsics are also present on the arm sections, I
need to delete that.

The reason for giving up on supporting other arches is mostly due to
NetBSD not upstreaming support for those arches. For example, the
official binutils does not have support for aarch64-netbsd. It is only
present in NetBSD's src. And it only works on when used within
NetBSD's src. This makes everything more complex than needed and I do
not have the will to push through with it.

Regarding the use of other Ada tools in NetBSD. I added support for
grpbuild a few months ago, so you should be able to just use it.
Notice, when using GCC 10 only V21 of AdaCore tools work. Newer
versions (currently v22) need GCC 11. The rest of the tools seem to
compile without much fuzz at all. So I say that my work is mostly
complete.

I will try to get gcc10-aux pushed to stable however; sometime after
March.

For now, I will try to update the Ada changelog in GCC and write an
article about Ada-Scheme for the AUJ.

Best regards,
Fer

Am Thu, 23 Dec 2021 17:37:56 +0100
schrieb Fernando Oleo Blanco <irvise_ml@irvise.xyz>:

I do not have GCC 11 on NetBSD, which is required for SPARKNaCl.
However, I expect to spend some time with Ravenports, which does
support GCC 11 on NetBSD. So I hope to try it out soon.

Regarding ACATS on OBSD; the results seem to be good. Yes, there are
some failures, but I would expect some of those to come from
limitations of GCC 11. Afaik/seen, OpenBSD has outstanding support for
Ada in ports.

Regards,
Fer

Am Thu, 23 Dec 2021 05:15:42 -0800 (PST)
schrieb Kevin Chadwick <kevc3no4@gmail.com>:

Merry Xmas
We found a potential compiler bug when running make in the tests
directory of this package on OpenBSD. Does it work on NetBSD out of interest?

"https://github.com/rod-chapman/SPARKNaCl"

This is the ACATs results for OpenBSD

"https://github.com/kevlar700/OpenBSD_GNAT_11_ACATS/blob/main/acats.sum"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quick update. The package has now been upstreamed and is now part of
the official pkgsrc distribution!

You can find it here: https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/lang/gcc10-aux/index.html

Binaries are still not available since it just got added.

This is a nice conclusion to this journey... But there is something
else brewing behind the scenes... AVR support is coming to Alire thanks
to Fabien and we are ironing out some of the issues there :D

See you soon,
Fer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)