Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance

[Simon Wright <simon@pushface.org>]

"Dan'l Miller" <optikos@verizon.net> writes:

> TL;DR; this self-contained single paragraph is an alternate wording of
> the crescendo of logic in the subsequent multiple paragraphs below:
> Does AdaCore fix ••in the exact same minor-dot-release of FSF GCC••
> (e.g., 8.0) the bugs that were introduced by the merge from GNAT-Pro
> development branch to current wavefront of FSF development on the
> public GCC branch?  Let alone minor; in recent years, does the fix
> always arrive in the same major (e.g., 8.X for any X) release of FSF
> GCC as when the merge introduced the bug into FSF GNAT's current
> wavefront of new development?  Do the bugs introduced by the merge
> from GNAT-Pro development branch into, say, GCC 8.0 sit there unfixed
> until (after a round-trip of adopting GCC 8.X into the GNAT-Pro
> development branch, itself merged with bug fixes back to FSF weeks or
> months or a year later), AdaCore releases fixes for, say, a
> hypothetical GCC 8.3 release, which again leaves, say, GCC 9.0 buggy
> for a while (e.g., until AdaCore maintains the 9.X release by the time
> of, say, a hypothetical 9.3?  If such a multi-minor-release-spanning
> (or worse, multi-major-release-spanning) window of FSF GNAT bugginess
> exists due to release-number difference between GNAT Pro and FSF,
> wouldn't that be •sporadic• (as some minor releases of FSF GNAT get a
> yep-FSF-GNAT-is-reliable checkmark and others don't for months-long or
> year-long durations)?

No one from AdaCore is commenting here about this, so what follows is my
view only.

For a start, the present GCC release naming scheme is, 8.0.0 is mainline
development in the initial phase; 8.0.1 is a release candidate; 8.1.0 is
a major release. I don't know what the last field is for after the major
release candidate, I've seen ARM use it for their own branch.

At the start of a new major release, AdaCore merge something like their
current state into GCC, very likely after some invisible-to-us
verification. There are two test suites: gnat and acats, where gnat is
maintained (again presumably) with their private repository. acats is an
old version of the official ACATS suite (2.5 vs 4.1g); I've been working
on bringing it up to date, see <https://github.com/simonjwright/ACATS>.

In GCC 8.1.0, ACATS4.1G reports

# of expected passes		2501
# of unexpected failures	11
# of expected failures		1452
# of unresolved testcases	11
# of unsupported tests		124

*** FAILURES: c250002 c611a04 c760a02 c760a03 cxag003 cxd1003 cxd1004
    cxd1005 cxd2006 cxd3001 cxd3002

where

* c250002 is a UTF8 vs case-preserving fs vs extended characters in
  filename issue (also fails on Windows)
* c611a04 (new) is to do with class-wide preconditions
* c760a0? (new) are to do with using a separate anonymous object in a
  function return
* cxd* are almost certainly to do with this being a desktop system, so
  Annex D isn't completely supported

I checked the changes made from 7.1 onwards at the Github mirror
<https://github.com/gcc-mirror/gcc/blob/gcc-7-branch/gcc/ada/ChangeLog>:

* 7.1 to 7.2, 8 changes
* 7.2 to 7.3, 17 changes

The problems I've reported myself have mostly been macOS- or bare
ARM-related: the macOS-specific ones are either to do with Darwin
handling of shared libraries or the case-preserving HFS+
filesystem. I've tended to avoid the early stages of a new release,
letting those who have server farms for the purpose do the initial check
on different architectures.