Bug in GNAT GPL 2006?
(see below)
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?
--
Bill Findlay
<surname><forename> chez blueyonder.co.uk
Randy Brukardt
> 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?
Sure looks like a (harmless) compiler bug to me. It's hard to imagine why
you would be required to read the result of a function before returning it.
Randy.
(see below)
mailman.102.117208920...@ada-france.org, "Randy Brukardt"
<ra...@rrsoftware.com> wrote:
>> return result : Boolean do
>> |
>>>>> warning: variable "result" is assigned but never read
>> I'm inclined to assume that this is a compiler bug, but can
>> anyone more knowledgeable about Ada 200[57] confirm this?
>
> Sure looks like a (harmless) compiler bug to me. It's hard to imagine why
> you would be required to read the result of a function before returning it.
Thanks, Randy.
Adam Beneschan
Looks to me like the compiler is (incorrectly) pretending it's a
normal variable. If you had declared "result : Boolean" before the
"begin", and then assigned it but never used it, I can imagine the
compiler being suspicious that something was perhaps mistyped
somewhere, and displaying a warning. Just a very understandable
implementation bug.
-- Adam
(see below)
1172110443....@v33g2000cwv.googlegroups.com, "Adam Beneschan"
<ad...@irvine.com> wrote:
Yes, I think so.
Extraordinarily, the example given in the Ada 2005 RM has this property.
Unfortunately, it is not the only extended return bug in GNAT GPL 2006.
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.
Per Sandberg
/Per
Alex R. Mosteo
> 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. Did you
get that to work, despite the warning?
(see below)
Mosteo" <dev...@mailinator.com> wrote:
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.
Robert A Duff
If you report this inlining bug to AdaCore, it will eventually get
fixed. In fact, I've been working on this extended-return stuff lately,
so I am indeed interested in seeing bug reports related to that.
By the way, I think the bogus warning mentioned above is fixed in the
latest GNAT sources. And as far as I know, the generated code is
correct even in the presence of that warning.
- Bob
(see below)
Duff" <bob...@shell01.TheWorld.com> wrote:
> If you report this inlining bug to AdaCore, it will eventually get
> fixed. In fact, I've been working on this extended-return stuff lately,
> so I am indeed interested in seeing bug reports related to that.
>
> By the way, I think the bogus warning mentioned above is fixed in the
> latest GNAT sources. And as far as I know, the generated code is
> correct even in the presence of that warning.
Bob,
can you say what is the correct mechanism for reporting bugs in GNAT GPL?
Dirk Craeynest
>can anyone more knowledgeable about Ada 200[57] confirm this?
I notice that once in a while there appears to be some confusion
about how to refer to the latest Ada language definition.
FYI, the internationally accepted recommendation is to use the name
"Ada 2005".
Obviously the official name of the language is Ada, but when referring
to previous "instances" of the standard, the Ada community has been
using Ada 83 and Ada 95 as informal or "vernacular" names.
In an attempt to avoid possible confusion about how to refer to the
amended Ada language definition, the ISO working group on Ada (WG9)
discussed this issue during its June 2005 meeting in York. Various
proposals were made and many arguments were presented. For those of
you who are interested: a summary of the discussion is available in
the minutes of that meeting [1].
Finally, the following recommendation was accepted *unanimously*:
``Recognizing that ISO's publication date will differ from the
date of technical completion in 2005, and recognizing that the
term "Ada 2005" is widely used in the community, WG9 recommends
that an appropriate vernacular designation for the amended
language should be "Ada 2005".'' [2]
That's why in most literature, marketing material, communications, etc,
we refer to the amended language as "Ada 2005".
This includes e.g. the ARA announcement "Ada 2005 on Track for Formal
ISO Approval" [3], Ada-Europe's press release "Technical Work on Ada
2005 Standard Completed" [4], and the title "Ada 2005 Reference Manual.
Language and Standard Libraries" of the book recently published by
Springer in its LNCS (Lecture Notes in Computer Science) series [5].
[1] <http://www.open-std.org/jtc1/sc22/wg9/n451.htm#VernName>
[2] <http://www.open-std.org/jtc1/sc22/wg9/n451.htm#r5>
[3] <http://www.adaic.com/news/iso-Ada05.html>
[4] <http://www.ada-europe.org/Ada_2005_Press_Release.pdf>
[5] <http://www.springer.com/home?SGWID=5-102-22-173712407-0>
We may all have our personal preferences about how to name things,
but in the interest of global understandability and to avoid creating
confusion, may I suggest we all abide to that recommendation of the
ISO working group on Ada?
So, when referring to the language in general, use "Ada", and when
referring to the recently amended language definition in particular,
use "Ada 2005".
I hope this helps.
Dirk Craeynest
Dirk.Cr...@cs.kuleuven.be
ISO/IEC JTC1/SC22/WG9, Head of Delegation, Belgium
Stephen Leake
> I notice that once in a while there appears to be some confusion
> about how to refer to the latest Ada language definition.
>
> FYI, the internationally accepted recommendation is to use the name
> "Ada 2005".
Thank you!
--
-- Stephe
Robert A Duff
> can you say what is the correct mechanism for reporting bugs in GNAT GPL?
I think there's some info about that in the distribution.
A README file or some such. Sorry, I don't remember the details.
- Bob
Georg Bauhaus
The only way to know from the "binary" distribution
is, I think, to trigger a bug box. :-)
Jeffrey R. Carter
rep...@gnat.com; include "GNAT Bug" in the subject.
--
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26