Bug in GNAT GPL 2006?

Bug in GNAT GPL 2006?

[(see below)]

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?

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

RE: Bug in GNAT GPL 2006?

[Randy Brukardt]

Bill Findlay writes:

> 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.

Re: Bug in GNAT GPL 2006?

[(see below)]

On 21/2/07 20:19, in article
mailman.102.1172089201.18371.comp.lang.ada@ada-france.org, "Randy Brukardt"
<randy@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.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Bug in GNAT GPL 2006?

[Adam Beneschan]

On Feb 21, 12:19 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> Bill Findlay writes:
> > 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.

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

Re: Bug in GNAT GPL 2006?

[(see below)]

On 22/2/07 02:14, in article
1172110443.971020.58150@v33g2000cwv.googlegroups.com, "Adam Beneschan"
<adam@irvine.com> wrote:

> On Feb 21, 12:19 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
>> Bill Findlay writes:
>>> 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.
> 
> 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.

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.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Bug in GNAT GPL 2006?

[Per Sandberg]

Well it is fixed in the latest version (GNATPro 6.0.1).
/Per

(see below) wrote:
> On 22/2/07 02:14, in article
> 1172110443.971020.58150@v33g2000cwv.googlegroups.com, "Adam Beneschan"
> <adam@irvine.com> wrote:
> 
>> On Feb 21, 12:19 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
>>> Bill Findlay writes:
>>>> 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.
>> 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.
> 
> 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.
> 

Re: Bug in GNAT GPL 2006?

[Alex R. Mosteo]

(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. Did you
get that to work, despite the warning?

Re: Bug in GNAT GPL 2006?

[(see below)]

On 22/2/07 10:52, in article 545av3F1ukgfpU1@mid.individual.net, "Alex R.
Mosteo" <devnull@mailinator.com> 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
<surname><forename> chez blueyonder.co.uk

Re: Bug in GNAT GPL 2006?

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 22/2/07 10:52, in article 545av3F1ukgfpU1@mid.individual.net, "Alex R.
> Mosteo" <devnull@mailinator.com> 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.

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

Re: Bug in GNAT GPL 2006?

[(see below)]

On 23/2/07 01:37, in article wccwt29k61q.fsf@shell01.TheWorld.com, "Robert A
Duff" <bobduff@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?

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Bug in GNAT GPL 2006?

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> 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

Re: Bug in GNAT GPL 2006?

[Georg Bauhaus]

On Sat, 2007-02-24 at 14:15 -0500, Robert A Duff wrote:
> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> 
> > 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.

The only way to know from the "binary" distribution
is, I think, to trigger a bug box. :-)

Re: Bug in GNAT GPL 2006?

[Jeffrey R. Carter]

Robert A Duff wrote:
> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> 
>> 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.

report@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

The Ada 2005 name (was: Re: Bug in GNAT GPL 2006?)

[Dirk Craeynest]

Bill Findlay wrote:
>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.Craeynest@cs.kuleuven.be
ISO/IEC JTC1/SC22/WG9, Head of Delegation, Belgium

Re: The Ada 2005 name

[Stephen Leake]

dirk@cs.kuleuven.ac.be (Dirk Craeynest) writes:

> 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