From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_40,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.5-pre1
X-Received: by 2002:a37:2756:: with SMTP id n83mr14485395qkn.70.1614676983269;
        Tue, 02 Mar 2021 01:23:03 -0800 (PST)
X-Received: by 2002:a25:6e57:: with SMTP id j84mr30229107ybc.277.1614676982966;
 Tue, 02 Mar 2021 01:23:02 -0800 (PST)
Path: eternal-september.org!reader02.eternal-september.org!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 2 Mar 2021 01:23:02 -0800 (PST)
In-Reply-To: <lyzgzlsyto.fsf_-_@pushface.org>
Injection-Info: google-groups.googlegroups.com; posting-host=87.88.29.208; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH
NNTP-Posting-Host: 87.88.29.208
References: <602e608e$0$27680$e4fe514c@news.kpn.nl> <60379b69$0$20345$e4fe514c@news.kpn.nl>
 <s1a9jm$1c9e$1@gioia.aioe.org> <86zgzn4xcs.fsf@stephe-leake.org>
 <5b0c7577-7dcc-468b-a24b-7447a8e796b7n@googlegroups.com> <3808e6ec-1a49-4514-84e7-f444d94cdb2cn@googlegroups.com>
 <lyzgzlsyto.fsf_-_@pushface.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f9abf700-2671-4274-ba89-43b2ddf1dc4bn@googlegroups.com>
Subject: Re: rr (was: Re: Alternative for Gnat Studio)
From: Emmanuel Briot <briot.emmanuel@gmail.com>
Injection-Date: Tue, 02 Mar 2021 09:23:03 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader02.eternal-september.org comp.lang.ada:61461
List-Id: <comp.lang.ada>

> It'd probably really help with my current problem, where GCC 11.0.0 and 
> GNAT CE 2020 arm-eabi throw an ICE when compiling a generalised 
> iteration

Might be unrelated, but: we have noticed recently that a generalized iteration ("for..of")
was wrongly calling `activate_task`. In particular, this resulted in errors when executing such
loops from a protected object and enabling the checks that no potentially blocking operation
is executed in such contexts.

We reported this to AdaCore who fixed it in their more recent wavefronts. I am not sure when the
error started to occur though, so maybe not that helpful to you :-)