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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,11c630572e59f461 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "(see below)" Newsgroups: comp.lang.ada Subject: Re: Bug in GNAT GPL 2006? Date: Thu, 22 Feb 2007 16:39:52 +0000 Message-ID: References: <545av3F1ukgfpU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: individual.net UwdPzCeIuWmcXSNFHhZ3sw/2fXXkRmh7l/atqQIeQXP5j2B5KO User-Agent: Microsoft-Entourage/11.3.3.061214 Thread-Topic: Bug in GNAT GPL 2006? Thread-Index: AcdWoBMvUf9EHcKTEduXeQARJIjQTg== Xref: g2news2.google.com comp.lang.ada:9418 Date: 2007-02-22T16:39:52+00:00 List-Id: On 22/2/07 10:52, in article 545av3F1ukgfpU1@mid.individual.net, "Alex R. Mosteo" wrote: > (see below) wrote: > >> Using GNAT GPL 2006 (20060522-34) I get warning messages >> like the following when using extended return statements: >> >> function is_empty (the_table : a_safe_table) return Boolean is >> begin >> return result : Boolean do >> | >>>>> warning: variable "result" is assigned but never read >> >> lock_table; >> result := is_empty(a_basic_table(the_table)); >> unlock_table; >> end return; >> end is_empty; >> >> I'm inclined to assume that this is a compiler bug, but can >> anyone more knowledgeable about Ada 200[57] confirm this? > > It was my impression that extended return wasn't completely finished. Looks like it. Trouble is, I can't find anything on the Libre site that defines what is or is not finished in GNAT GPL. 8-( > Did you get that to work, despite the warning? Yes, that runs properly as far as I have tested it. This bug: >> Obtaining the value of a defining identifier from a call to another >> (inlined) function having itself an extended return also fails to compile; >> giving a nonsensical message at the point of call of the latter. is interesting - if I interpret the error message correctly, the compiler is trying (in effect) to textually nest the extended return of the subsidiary function inside the caller's extended return and then complaining that the product of doing that is illegal (as I would hope it is). It compiles correctly (modulo further testing) if inlining is switched off. -- Bill Findlay chez blueyonder.co.uk