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!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Ann: Gcc/GNAT 9.1 released - Test Results Date: Thu, 09 May 2019 10:04:26 +0100 Organization: A noiseless patient Spider Message-ID: References: <7d10dac8-f871-4cf9-b57f-aa9a114d2650@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="a065964bc0a1759c785a012abd368756"; logging-data="16195"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/k3/IGVi3splqIS+xs9lOsPPCwqrfSKbg=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin) Cancel-Lock: sha1:ND0JnCIvPOpO1ES70mqNmfsqB1M= sha1:2XweX9pY26yS6kuOxhGKHilYX6w= Xref: reader01.eternal-september.org comp.lang.ada:56268 Date: 2019-05-09T10:04:26+01:00 List-Id: Optikos writes: >> For info, the GCC 9.1.0 x86_64-apple-darwin official results are: >> >> === gnat Summary === >> >> # of expected passes 2964 >> # of expected failures 23 >> # of unsupported tests 10 >> >> === acats Summary === >> # of expected passes 2320 >> # of unexpected failures 0 >> >> The 4.1L results are >> >> === acats Summary === >> # of expected passes 2505 >> # of unexpected failures 11 >> # of expected failures 1463 >> # of unresolved testcases 11 >> # of unsupported tests 124 >> *** FAILURES: c250002 c452003 c611a04 c650b04 cxd1003 cxd1004 >> cxd1005 cxd2006 cxd3001 cxd3002 cxd8002 >> >> There are expected failures because I included the whole test suite. > > Ignoring MacOS and perhaps all the BSDs for a moment, does Bob Duff's > pardon extend to Linux kernels that are configured with the full set > of realtime extensions (regardless of being deployed on a GUI-based > desktop by happenstance)? It seems that Linux with the full set of > realtime extensions turned on would be expected to fully meet Annex D. > >> c250002: UTF-8 case conversion issue >> c452003: see above >> c6*: hairy tests >> cxd*: Bob Duff says full Annex D compliance not to be expected on >> desktop OS I don't think I have full evidence for the opinion I ascribed to Bob Duff. The reference I have is at [1]: "Ceiling locking is supported on Linux, but that support is fairly recent (I implemented it in the last few months or so). I think GNAT GPL 2016 doesn't have it." "You have to link with the right library, and you have to set the appropriate capability on the executable file (which requires being root), and then you can run that file without being root and get ceiling priority support." See also [2] (this documentation is for the supported GNAT; CE and FSF releases may well be behind). [1] https://groups.google.com/d/msg/comp.lang.ada/aKIP5L54kvU/f15BSLn2AAAJ [2] https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/implementation_of_specific_ada_features.html#gnat-implementation-of-tasking > Which of these unsupported tests and unexpected failures (and > unexpected successses*, if any arise) are •not• each tracked in GCC's > Bugzilla with their own individual defect report? > > * Ada source code that the ARM (or AARM's additional color) deems > impermissible Ada source code that GNAT failed to prohibit via a > (nonbugbox) compilation error. There are presently no unexpected passes. Quite a few of the unsupported tests are so because they deal with the consequences of changing the source code and rebuilding. The ACATS source for those tests contains multiple copies of some units, which results in a gnatchop failure. It'd require a lot of work to fix, and for what is essentially an IVP (installation verification procedure) seems like overkill. Some are unsupported because the test determines for itself that it is inappropriate (e.g. handling of floating-point overflow). Failures: I'm sure that AdaCore will eventually deal with the new unexpected failures, but I'm not sure that posting PRs will help: viz. response to PR 88610, "My point is that opening a PR has strictly no effects in this case, unlike for other cases. New ACATS tests are publicly available and the compiler will be changed accordingly at some point, but the priority is very low." I still think that ICEs (internal compiler errors, => bug box) are different in kind from failure to compile or failure to execute properly. As I said, "I’d certainly think twice before reporting a mere compilation failure in what’s a pretty obscure language area. But this is an ICE." CXD: there are failures in this area on Linux, but these are on macOS, and there's not a huge customer market there! Also, would you think it appropriate to base a hard real-time system on macOS? I wouldn't.