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 X-Received: by 10.107.9.208 with SMTP id 77mr29268779ioj.1.1441012788716; Mon, 31 Aug 2015 02:19:48 -0700 (PDT) X-Received: by 10.182.60.130 with SMTP id h2mr324590obr.28.1441012788688; Mon, 31 Aug 2015 02:19:48 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!uu8no621609igb.0!news-out.google.com!f6ni10580igi.0!nntp.google.com!i7no177657igu.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 31 Aug 2015 02:19:48 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=118.209.113.230; posting-account=l8GBMwoAAADCbqdOJSbg4dBRqkD14dJd NNTP-Posting-Host: 118.209.113.230 References: <32c623ac-817e-46fc-bb13-c77b47a506a7@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0e9794c2-8702-42bd-96db-978d87a97bf2@googlegroups.com> Subject: Re: bug in gnatgpl 2015? From: Leo Brewin Injection-Date: Mon, 31 Aug 2015 09:19:48 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:27647 Date: 2015-08-31T02:19:48-07:00 List-Id: On Monday, August 31, 2015 at 6:48:16 PM UTC+10, Simon Wright wrote: > Leo Brewin writes: >=20 > > I've run into what I think is a bug in gnatgpl 2015. > > I wonder if others could confirm the bug? > > > > I've tried to make the code as short as possible while still > > capturing the alleged bug. > > > > Using gnatgpl 2015 from Adacore, I get > > > > gnatmake crash.adb > > > > gcc -c crash.adb > > > > raised CONSTRAINT_ERROR : erroneous memory access > > gnatmake: "crash.adb" compilation error > > > > and on occassions a detailed report (too long to include here but will > > be sent to Adacore if need be). >=20 > Yes. Also, the reported point of error in the long report seems to vary > with the optimisation level. >=20 > > head : myArray1dIntg renames head_ptr.all; >=20 > The problem seems to go away if you eliminate this declaration, and use > head_ptr[.all] instead. Hi Simon, Thanks for the quick reply. Yes, I can avoid the bug by various changes to = that example but those changes don't work well with the much larger code th= at this example was drawn from. My work around is to use your gcc-5.1.0 (th= anks for the putting this together). I think the code in my example is legal so the compiler shouldn't crash.=20 Cheers, Leo