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: Studying and Maintaining GNAT, Is There Any Interest in a New Group? Date: Sat, 25 Aug 2018 20:25:03 +0100 Organization: A noiseless patient Spider Message-ID: References: <309225242.556906218.575482.laguest-archeia.com@nntp.aioe.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="e9b111d5f538076b1093e76700bfd842"; logging-data="12386"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18enX3XXl3II4eyI3TWOB69+aaUoJAwz74=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin) Cancel-Lock: sha1:VkmiMryLZg/0ALn4toTPAEKOzzM= sha1:G/5p55eO5UkSaJUNgCEGUYJnY10= Xref: reader02.eternal-september.org comp.lang.ada:54252 Date: 2018-08-25T20:25:03+01:00 List-Id: patrick@spellingbeewinnars.org writes: > I was wondering if the patches came from a group, whether the GCC > people would accept them without or without Adacore. I'm far from expert on GCC procedures, but all three of the Ada front-end maintainers (see [1]) are AdaCore employees, and I don't think you're going to get approval for updates to Ada internals from anyone else. If it's OS-related (I see some of this because Darwin) you stand more chance. [1] https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS > I know what trouble you have had with GCC and trying to get GNAT > ported over to ARM many years ago. That was very frustrating. When others (including me) joined in with more evidence things improved. But it can be hard to get the evidence, particularly for rare happenings; I'm convinced there's a bug in the bare-board RTS related to an interrupt occuring during a protected entry, reported almost a year ago, no resolution yet so far as I know. > However, could it be safe to say that most of the bugs are in the > runtime and not in the code generation? When a new compiler release is being made, almost all the bugs will be in the compiler; the RTS is pretty stable. The interface to the RTS can change a bit (for Cortex GNAT RTS, GCC7->GCC8 involved a minor change to the way tagged types are handled, and how secondary stacks are allocated).