From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance Date: Fri, 18 May 2018 14:02:41 +0100 Organization: A noiseless patient Spider Message-ID: References: <87vabqs7qc.fsf@jacob-sparre.dk> <25c01889-1d29-48ea-9e52-c4c3ceacf093@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: h2725194.stratoserver.net; posting-host="0e28988de108da281e5475d3050bb8e9"; logging-data="4378"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ss0W8np8iDvDZATXz0mDcRiQNsm2bajU=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin) Cancel-Lock: sha1:si7zHoGAJpjobbTIf2vwR1YAdx0= sha1:XjmM45Pbs9jcrZatk/sxTPZU6Rw= Xref: reader02.eternal-september.org comp.lang.ada:52431 Date: 2018-05-18T14:02:41+01:00 List-Id: "Dan'l Miller" 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 . 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 : * 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.