limited allocated classwide types

limited allocated classwide types

[Simon Belmont]

I am attempting to create a limited, private, controlled type that
extends an interface type via an allocator (i think that's the right
termonology) with GNAT (GNATMAKE GPL 2011 20110428), but not having
much luck.  To summarize, when the access type is that of the concrete
type, or if the type is made non-limited, everything works as it
should.  However, when the access type is of the classwide variety and
the type is limited, things go bananas in a way that I cannot just
wrap my head around.

I'm not sure if I'm misusing the limited nature, the extended return
syntax, or the classwide type, but I have had no success unravelling
the mystery.  If anybody can point out where I've gone off the rails,
and also the appropriate part of the RM that i've missed, I would be
eternally grateful.

The entire sample program is at the bottom, but here is the basic
jist:

When the access type is defined as:

type Foo_Ptr is access all P.Foo_Type;

the execution performs as expected:

Entered Create
Entered Initialize
Entered Extended Return
Leaving Extended Return
Starting...
Entered Doo!
Ending...
Entered Finalize
[2011-11-03 17:38:57] process terminated successfully (elapsed time:
00.12s)

When the access type is changed to:

type Foo_Ptr is access all I.LI'Class;

the output crashes to some strange function that indicates it should
be impossible to ever get to (hence my confusion):

Entered Create
Entered Initialize
Entered Extended Return
Leaving Extended Return
Starting...
Entered Finalize

raised PROGRAM_ERROR : s-finroo.adb:42 explicit raise
[2011-11-03 17:40:27] process exited with status 1 (elapsed time:
00.13s)


The sample code is as follows:

with Ada.Text_IO;
with Ada.Finalization;

procedure Test_Init is

   -- An interface with one function Doo
   package I is
      type LI is limited interface;
      procedure Doo (This : LI) is abstract;
   end I;

   -- Concrete, limited, controlled implementation
   package P is
      type Foo_Type is limited new Ada.Finalization.Limited_Controlled
and I.LI with
         record
            o : Integer;
         end record;

      function Create (Arg : in Integer) return Foo_Type;
      overriding procedure Initialize (This : in out Foo_Type);
      overriding procedure Finalize   (This : in out Foo_Type);
      overriding procedure Doo (This :  Foo_Type);
    end P;

   package body P is

      function Create (Arg : in Integer) return Foo_Type is
      begin
         Ada.Text_IO.Put_Line("Entered Create");
         return Object : Foo_Type do
            Ada.Text_IO.Put_Line("Entered Extended Return");
            Object.o := Arg;
            Ada.Text_IO.Put_Line("Leaving Extended Return");
         end return;
      end Create;

      overriding procedure Initialize (This : in out Foo_Type) is
      begin
         Ada.Text_IO.Put_Line("Entered Initialize");
      end Initialize;

      overriding procedure Finalize   (This : in out Foo_Type) is
      begin
         Ada.Text_IO.Put_Line("Entered Finalize");
      end Finalize;

      overriding procedure Doo (This : Foo_Type) is
      begin
         Ada.Text_IO.Put_Line("Entered Doo!");
      end Doo;

   end P;

--      type Foo_Ptr is access P.Foo_Type;  -- Output A
--      type Foo_Ptr is access I.LI'Class;  -- Output B


   Bar : Foo_Ptr := new P.Foo_Type'(P.Create(42));

begin

   Ada.Text_IO.Put_Line("Starting...");
   Bar.all.Doo;
   Ada.Text_IO.Put_Line("Ending...");

end Test_Init;


Thank you in advance to anyone who can explain what exactly is going
on here.

-sb

Re: limited allocated classwide types

[Adam Beneschan]

On Nov 3, 3:01 pm, Simon Belmont <sbelmont...@gmail.com> wrote:
> I am attempting to create a limited, private, controlled type that
> extends an interface type via an allocator (i think that's the right
> termonology) with GNAT (GNATMAKE GPL 2011 20110428), but not having
> much luck.  To summarize, when the access type is that of the concrete
> type, or if the type is made non-limited, everything works as it
> should.  However, when the access type is of the classwide variety and
> the type is limited, things go bananas in a way that I cannot just
> wrap my head around.
>
> I'm not sure if I'm misusing the limited nature, the extended return
> syntax, or the classwide type, but I have had no success unravelling
> the mystery.  If anybody can point out where I've gone off the rails,
> and also the appropriate part of the RM that i've missed, I would be
> eternally grateful.

With an earlier version of GNAT (4.5.2), I don't get a Program_Error
but I also don't seem to get the same output you get with "Output A"
with either declaration of Foo_Ptr.  Using "access all P.Foo_Type",
the last "Entered Finalize" doesn't appear.  Using "access all
I.LI'Class", a second "Entered Initialize" appears instead of "Entered
Doo!", and no "Entered Finalize" appears.  But no Program_Error is
raised.

With our compiler (Irvine Compiler), the output is what you say is
expected, in both cases.

I haven't studied the program carefully to make sure the output really
should be what you say it should be.  But my initial impression is
that this is a GNAT error.

What happens if you remove the "limited" (and change
Limited_Controlled to Controlled)?  Does it work correctly in both
cases?  Since there's nothing tricky in your program, it really should
have the same behavior except possibly for some additional Adjust and
Finalize calls (since build-in-place is required for function calls
returning limited types).  If it works correctly without "limited" but
not with it, that would be an additional reason to suspect a GNAT bug.

                     -- Adam





>
> The entire sample program is at the bottom, but here is the basic
> jist:
>
> When the access type is defined as:
>
> type Foo_Ptr is access all P.Foo_Type;
>
> the execution performs as expected:
>
> Entered Create
> Entered Initialize
> Entered Extended Return
> Leaving Extended Return
> Starting...
> Entered Doo!
> Ending...
> Entered Finalize
> [2011-11-03 17:38:57] process terminated successfully (elapsed time:
> 00.12s)
>
> When the access type is changed to:
>
> type Foo_Ptr is access all I.LI'Class;
>
> the output crashes to some strange function that indicates it should
> be impossible to ever get to (hence my confusion):
>
> Entered Create
> Entered Initialize
> Entered Extended Return
> Leaving Extended Return
> Starting...
> Entered Finalize
>
> raised PROGRAM_ERROR : s-finroo.adb:42 explicit raise
> [2011-11-03 17:40:27] process exited with status 1 (elapsed time:
> 00.13s)
>
> The sample code is as follows:
>
> with Ada.Text_IO;
> with Ada.Finalization;
>
> procedure Test_Init is
>
>    -- An interface with one function Doo
>    package I is
>       type LI is limited interface;
>       procedure Doo (This : LI) is abstract;
>    end I;
>
>    -- Concrete, limited, controlled implementation
>    package P is
>       type Foo_Type is limited new Ada.Finalization.Limited_Controlled
> and I.LI with
>          record
>             o : Integer;
>          end record;
>
>       function Create (Arg : in Integer) return Foo_Type;
>       overriding procedure Initialize (This : in out Foo_Type);
>       overriding procedure Finalize   (This : in out Foo_Type);
>       overriding procedure Doo (This :  Foo_Type);
>     end P;
>
>    package body P is
>
>       function Create (Arg : in Integer) return Foo_Type is
>       begin
>          Ada.Text_IO.Put_Line("Entered Create");
>          return Object : Foo_Type do
>             Ada.Text_IO.Put_Line("Entered Extended Return");
>             Object.o := Arg;
>             Ada.Text_IO.Put_Line("Leaving Extended Return");
>          end return;
>       end Create;
>
>       overriding procedure Initialize (This : in out Foo_Type) is
>       begin
>          Ada.Text_IO.Put_Line("Entered Initialize");
>       end Initialize;
>
>       overriding procedure Finalize   (This : in out Foo_Type) is
>       begin
>          Ada.Text_IO.Put_Line("Entered Finalize");
>       end Finalize;
>
>       overriding procedure Doo (This : Foo_Type) is
>       begin
>          Ada.Text_IO.Put_Line("Entered Doo!");
>       end Doo;
>
>    end P;
>
> --      type Foo_Ptr is access P.Foo_Type;  -- Output A
> --      type Foo_Ptr is access I.LI'Class;  -- Output B
>
>    Bar : Foo_Ptr := new P.Foo_Type'(P.Create(42));
>
> begin
>
>    Ada.Text_IO.Put_Line("Starting...");
>    Bar.all.Doo;
>    Ada.Text_IO.Put_Line("Ending...");
>
> end Test_Init;
>
> Thank you in advance to anyone who can explain what exactly is going
> on here.
>
> -sb

Re: limited allocated classwide types

[Simon Wright]

Simon Belmont <sbelmont700@gmail.com> writes:

> The entire sample program is at the bottom, but here is the basic
> jist:
>
[...]
> When the access type is changed to:
>
> type Foo_Ptr is access all I.LI'Class;
>
> the output crashes to some strange function that indicates it should
> be impossible to ever get to (hence my confusion):
>
> Entered Create
> Entered Initialize
> Entered Extended Return
> Leaving Extended Return
> Starting...
> Entered Finalize
>
> raised PROGRAM_ERROR : s-finroo.adb:42 explicit raise
> [2011-11-03 17:40:27] process exited with status 1 (elapsed time:
> 00.13s)

I added another procedure to LI:

   package I is
      type LI is limited interface;
      procedure Dummy (This : LI) is abstract;
      procedure Doo (This : LI) is abstract;
   end I;

and added the expected implementation, and then the output was

Entered Create
Entered Initialize
Entered Extended Return
Leaving Extended Return
Starting...
Entered Finalize               <-------------- !!!!
Ending...
Entered Finalize

but if I write

   package I is
      type LI is limited interface;
      procedure Doo (This : LI) is abstract;
      procedure Dummy (This : LI) is abstract;
   end I;

I get the Program_Error as before.

The reason it's possible to end up at Adjust in s-finroo.adb is that
System.Finalization_Root is common to Limited_Controlled and Controlled,
it's just that Limited_Controlled should of course never call it.

Looks as though the compiler has managed to mangle the dispatch table,
which is clearly a compiler error.

GCC 4.6, with your original code, outputs

Entered Create
Entered Initialize
Entered Extended Return
Leaving Extended Return
Starting...
Entered Initialize
Ending...

which is differently wrong, and GCC 4.7 (into which AdaCore have been
rolling changes to finalization like those in GNAT GPL 2011) behaves
like GNAT GPL 2011.

Re: limited allocated classwide types

[Simon Belmont]

To answer the first response, removing the limited type (for both the
interface and implementation and, obviously, switching to 'normal'
controlled) causes it to behave normally.

More vexxing is that I can alter what happens in the presumably
incorrect case simply by adding, removing, and reordering the
functions in the spec (which smacks heavily of a mixed up vtable, to
excuse the c++ terminology), which the second response more-or-less
supports.

Though it is satisfying to hear that this is most likely a compiler
error, and not poor programming skills on my part, I can't help but
feel unnerved by this.  I am only months into being an Ada programmer
and not trying to anything that isn't well described and ostensibly
supported, so it seems odd that such a basic test case would uncover
and compiler bug.  Moreover, one of the points of pride is that Ada
compilers are heavily tested and verified for safety critical apps,
which this seems to undercut.  Not to sound snarky, but I personally
have never found a bug in a GPL C compiler.

In either case, just to confirm, this is the "correct" way to code
this?  Is there any official channel for calling this a bug?

Thank you again for verifying my sanity

-ab

Re: limited allocated classwide types

[Adam Beneschan]

On Nov 3, 4:35 pm, Simon Belmont <sbelmont...@gmail.com> wrote:
>
> More vexxing is that I can alter what happens in the presumably
> incorrect case simply by adding, removing, and reordering the
> functions in the spec (which smacks heavily of a mixed up vtable, to
> excuse the c++ terminology), which the second response more-or-less
> supports.

Although there's no official Ada terminology, I think, a paragraph in
the AARM calls it the "dispatch table".  We Ada people tend to prefer
readable English over incomprehensible abbreviations.

> Though it is satisfying to hear that this is most likely a compiler
> error, and not poor programming skills on my part, I can't help but
> feel unnerved by this.  I am only months into being an Ada programmer
> and not trying to anything that isn't well described and ostensibly
> supported, so it seems odd that such a basic test case would uncover
> and compiler bug.  Moreover, one of the points of pride is that Ada
> compilers are heavily tested and verified for safety critical apps,
> which this seems to undercut.  Not to sound snarky, but I personally
> have never found a bug in a GPL C compiler.

You haven't run into any number of bugs that get dismissed as
"Duplicate of Bug 323", I guess.  Like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12331
which is something I ran into some years ago.

> In either case, just to confirm, this is the "correct" way to code
> this?

I don't know if this is the best way without knowing more about what
your entire program.  But I don't see anything wrong with it.  It's
probably correct enough.

                            -- Adam

Re: limited allocated classwide types

[Adam Beneschan]

On Nov 3, 5:30 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Nov 3, 4:35 pm, Simon Belmont <sbelmont...@gmail.com> wrote:
>
>
>
> > More vexxing is that I can alter what happens in the presumably
> > incorrect case simply by adding, removing, and reordering the
> > functions in the spec (which smacks heavily of a mixed up vtable, to
> > excuse the c++ terminology), which the second response more-or-less
> > supports.
>
> Although there's no official Ada terminology, I think, a paragraph in
> the AARM calls it the "dispatch table".  We Ada people tend to prefer
> readable English over incomprehensible abbreviations.

Sorry, I missed that you had already used the "correct" term
previously.

                                 -- Adam

Re: limited allocated classwide types

[Simon Wright]

Simon Belmont <sbelmont700@gmail.com> writes:

> Is there any official channel for calling this a bug?

Since you're using GNAT GPL, you can report it to
report@adacore.com. Include GNAT at the start of the subject line. It'd
help them if the actual code is an attachment, though your original
posting will do very well if that's inconvenient.

AdaCore do take reports from this channel but you may not get a response
(they respond well to paying customers!).

Re: limited allocated classwide types

[Dmitry A. Kazakov]

On Fri, 04 Nov 2011 07:40:04 +0000, Simon Wright wrote:

> Simon Belmont <sbelmont700@gmail.com> writes:
> 
>> Is there any official channel for calling this a bug?
> 
> Since you're using GNAT GPL, you can report it to
> report@adacore.com. Include GNAT at the start of the subject line. It'd
> help them if the actual code is an attachment, though your original
> posting will do very well if that's inconvenient.
> 
> AdaCore do take reports from this channel but you may not get a response
> (they respond well to paying customers!).

I am not sure if this is the bug we had, but some time ago we too had
problems with limited return, which caused Program_Error. We reported the
bug, and it was promptly fixed in GNAT Pro.

So, maybe, you have to wait for GNAT GPL 2012.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: limited allocated classwide types

[Georg Bauhaus]

On 04.11.11 00:35, Simon Belmont wrote:
>
> I am only months into being an Ada programmer
> and not trying to anything that isn't well described and ostensibly
> supported, so it seems odd that such a basic test case would uncover
> and compiler bug.  Moreover, one of the points of pride is that Ada
> compilers are heavily tested and verified for safety critical apps,
> which this seems to undercut.

Chances are that a traditional way of ensuring the presence
of operations for a type might work better---if presence is all
that you need(*).

Depending, then, on the intent of the solution, one simple solution
could be to state the expectations where and when they must be met:

generic
    type Has_Doo_Operation is new Has_Doo with private;
package Here_We_Go is
    
    procedure System_Function_1
        (Tool : in out Has_Doo_Operation;
         Stuff : Information'Class);
    
    procedure System_Function_2
        (Tool : in out Has_Doo_Operation;
         Stuff : in out Flour;
         More_Stuff : in out Eggs);
    
end Here_We_Go;

and then ensure things by first deriving concrete Foo_Type from
Limited_Controlled and then passing Foo_Type as actual type for the
abstract type or interface Has_Doo_Operation .

  Or, more flexibly,

generic
    type T is limited private;
    with procedure Doo (This : T);
package Here_We_Go is ...

  Etc.
__
(*) For some old history, rhetoric, emotions, and examples see
http://people.cs.kuleuven.be/~dirk.craeynest/ada-mi.html
(I remember having read the phrase "multiple inheritance bug
has bitten again", somewhere in the Ada archives.)

Re: limited allocated classwide types

[Brian Drummond]

On Thu, 03 Nov 2011 16:35:14 -0700, Simon Belmont wrote:

> Though it is satisfying to hear that this is most likely a compiler
> error, and not poor programming skills on my part, I can't help but feel
> unnerved by this.  I am only months into being an Ada programmer and not
> trying to anything that isn't well described and ostensibly supported,
> so it seems odd that such a basic test case would uncover and compiler
> bug.  Moreover, one of the points of pride is that Ada compilers are
> heavily tested and verified for safety critical apps, which this seems
> to undercut.  Not to sound snarky, but I personally have never found a
> bug in a GPL C compiler.

Simon W has pointed you at Adacore for reporting the bug, and it's great 
that you have such a simple testcase.

I reported a much more trivial bug some time ago, expecting nothing 
(since it was the GPL version of the compiler). About four months later, 
out of the blue,  I received a note of thanks and an acknowledgment that 
the bug had been fixed. Well done Adacore...

My experience suggests that there are some untried corner cases simply 
because there are fewer people using and exercising the compiler. So I 
wouldn't want you to be discouraged ... that would mean one fewer pair of 
eyes!

But this bug (assuming it is confirmed, as it looks to be) is much closer 
to the core of the language ... to me it raises the question: has ACATS 
(test suite) not kept up with the language additions in Ada-2005? And is 
it being maintained and updated alongside Ada-2012?

Is there a mechanism for adding ad-hoc test cases like this one to ACATS? 
One would like to think there is a more systematic effort to add tests 
alongside features as they are developed.

- Brian

Re: limited allocated classwide types

[Stephen Leake]

Simon Belmont <sbelmont700@gmail.com> writes:

> I am attempting to create a limited, private, controlled type that
> extends an interface type via an allocator (i think that's the right
> termonology) with GNAT (GNATMAKE GPL 2011 20110428), but not having
> much luck.  To summarize, when the access type is that of the concrete
> type, or if the type is made non-limited, everything works as it
> should.  However, when the access type is of the classwide variety and
> the type is limited, things go bananas in a way that I cannot just
> wrap my head around.

With gnat 6.2.1, I get the expected behavior with both variants.

So this was a compiler bug, which has since been fixed.

-- 
-- Stephe

Re: limited allocated classwide types

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> But this bug (assuming it is confirmed, as it looks to be) is much
> closer to the core of the language ... to me it raises the question:
> has ACATS (test suite) not kept up with the language additions in
> Ada-2005? And is it being maintained and updated alongside Ada-2012?

The acats/ files in the GCC repository haven't been updated for ACATS
3.0, and I can't see any statement as to what version it actually
is. From the Changelog, looks like 2.5.

3.0 does contain tests on extended return. However, it doesn't seem to
me that any of them check the case where the object being returned is
not only limited but also controlled; they're all aimed at checking that
the compiler doesn't allow things it shouldn't. The tests are b65000*.

Re: limited allocated classwide types

[Adam Beneschan]

On Nov 4, 2:53 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>
> But this bug (assuming it is confirmed, as it looks to be) is much closer
> to the core of the language ... to me it raises the question: has ACATS
> (test suite) not kept up with the language additions in Ada-2005? And is
> it being maintained and updated alongside Ada-2012?

I should probably let Randy answer this, but I think the answer to
your questions is that it hasn't kept up, due to insufficient funding.

But what I really wanted to point out was that it's not reasonable to
expect ACATS to catch everything; and the fact that one simple test
breaks a compiler that passes ACATS isn't itself evidence that there's
a flaw in ACATS.  I believe ACATS is set up to check each feature and
rule defined in the language (or something like that), but it can't
test every combination of every feature.  And this case seems to
involve a combination of limited controlled types and interfaces (and
perhaps extended return).  Even if there is, or should be, an ACATS
test that tests interfaces in conjunction with controlled types, it
may not occur to the test suite maintainer that there needs to be a
separate test to do the same thing with limited controlled types,
because they may not envision that a compiler could work with non-
limited controlled types but blow up with limited ones.

Also, I suspect that a major purpose of ACATS is to ensure that the
compiler vendors understand the language rules and have implemented
them.  It is not, and cannot, be to ensure that the implementation is
correct and bug-free in every case.

I'm posting this because the "Why didn't ACATS test for this??"
sentiment has come up more than once, but I don't think it's
justified.


> Is there a mechanism for adding ad-hoc test cases like this one to ACATS?
> One would like to think there is a more systematic effort to add tests
> alongside features as they are developed.

I'm wondering if there might be a need for some other public test
suite that users can contribute to.  I don't think ACATS would be an
appropriate suite to for just dumping any test cases users find--that
just doesn't seem like the right place--but perhaps someone could
start a web site.

                             -- Adam

Re: limited allocated classwide types

[Simon Wright]

Adam Beneschan <adam@irvine.com> writes:

> I'm wondering if there might be a need for some other public test
> suite that users can contribute to.  I don't think ACATS would be an
> appropriate suite to for just dumping any test cases users find--that
> just doesn't seem like the right place--but perhaps someone could
> start a web site.

http://www.ada-auth.org/submit.html lists tests that have been proposed
but aren't (yet) in ACATS.

Re: limited allocated classwide types

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:14ff4109-2f02-4dee-9638-68c1befc07c2@hc5g2000vbb.googlegroups.com...
On Nov 4, 2:53 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>>
>> But this bug (assuming it is confirmed, as it looks to be) is much closer
>> to the core of the language ... to me it raises the question: has ACATS
>> (test suite) not kept up with the language additions in Ada-2005? And is
>> it being maintained and updated alongside Ada-2012?
>
>I should probably let Randy answer this, but I think the answer to
>your questions is that it hasn't kept up, due to insufficient funding.

Right, both funding and insufficient contributions of tests. (The latter may 
be in part caused by the former.)

>But what I really wanted to point out was that it's not reasonable to
>expect ACATS to catch everything; and the fact that one simple test
>breaks a compiler that passes ACATS isn't itself evidence that there's
>a flaw in ACATS.  I believe ACATS is set up to check each feature and
>rule defined in the language (or something like that), but it can't
>test every combination of every feature.  And this case seems to
>involve a combination of limited controlled types and interfaces (and
>perhaps extended return).  Even if there is, or should be, an ACATS
>test that tests interfaces in conjunction with controlled types, it
>may not occur to the test suite maintainer that there needs to be a
>separate test to do the same thing with limited controlled types,
>because they may not envision that a compiler could work with non-
>limited controlled types but blow up with limited ones.

(Thanks, you saved me a lot of time. :-)

The ACATS is mostly about testing that features are implemented according to 
the Standard. Combinations of features are only tested to the extent that it 
is necessary to verify the implementation. Indeed, there is a huge number of 
possibilities of combinations, and guessing which ones might actually cause 
problems is not likely to have any useful effect on compiler quality.

>Also, I suspect that a major purpose of ACATS is to ensure that the
>compiler vendors understand the language rules and have implemented
>them.  It is not, and cannot, be to ensure that the implementation is
>correct and bug-free in every case.

You don't have to "suspect" that; you can just read the documentation of it. 
Here is the clause "ACATS Purpose" (most of this documentation is little 
changed since the ACVC days for Ada 83):

----

1.1 ACATS Purpose
The purpose of the ACATS is to check whether an Ada compilation system is a 
conforming implementation, i.e., whether it produces an acceptable result 
for every applicable test.

A fundamental goal of conformity assessment (validation) is to promote Ada 
software portability by ensuring consistent processing of Ada language 
features as prescribed by the Ada Standard documents ([Ada95], [TC1], and 
[Amend1]). ACATS tests use language features in contexts and idioms expected 
in production software. While they exercise a wide range of language feature 
uses, they do not and cannot include examples of all possible feature uses 
and interactions.

It is important to recognize that the ACATS tests do not guarantee compiler 
correctness. A compilation system that correctly processes the ACATS tests 
is not thereby deemed error-free, nor is it thereby deemed capable of 
correctly processing all software that is submitted to it.

The ACATS tests do not test the quality of an Ada implementation. In 
particular, ACATS test do not check or report performance parameters (e.g., 
compile-time capacities or run-time speed). They do not check or report for 
characteristics such as the presence and effectiveness of compiler 
optimization. They do not investigate or report compiler or implementation 
choices in cases where the standard allows options.

----

Note that the documentation is included in the ACATS downloads, but isn't 
posted on the internet anywhere that I know of. (Not sure why I didn't put 
it on the ada-auth.org site.)

>> Is there a mechanism for adding ad-hoc test cases like this one to ACATS?
>> One would like to think there is a more systematic effort to add tests
>> alongside features as they are developed.

>I'm wondering if there might be a need for some other public test
>suite that users can contribute to.  I don't think ACATS would be an
>appropriate suite to for just dumping any test cases users find--that
>just doesn't seem like the right place--but perhaps someone could
>start a web site.

I think that would be a great idea. It also would provide a place to mine 
for possible future ACATS tests (it's hard work coming up with test 
scenarios for C-Tests [that is, executable tests]).

                                           Randy.



                             -- Adam

Re: limited allocated classwide types

[Brian Drummond]

On Mon, 07 Nov 2011 22:25:38 -0600, Randy Brukardt wrote:

> "Adam Beneschan" <adam@irvine.com> wrote in message
> 
news:14ff4109-2f02-4dee-9638-68c1befc07c2@hc5g2000vbb.googlegroups.com...
> On Nov 4, 2:53 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:

>>> has ACATS (test suite) not kept up with the language additions in
>>> Ada-2005? And is it being maintained and updated alongside Ada-2012?
>>
>>I should probably let Randy answer this, but I think the answer to your
>>questions is that it hasn't kept up, due to insufficient funding.
> 
> Right, both funding and insufficient contributions of tests. (The latter
> may be in part caused by the former.)

I can understand that! And I appreciate that much high quality work goes 
into the Standard; perhaps expecting ACATS to keep up is being greedy!

>> and the fact that one simple test
>>breaks a compiler that passes ACATS isn't itself evidence that there's a
>>flaw in ACATS.  I believe ACATS is set up to check each feature and rule
>>defined in the language (or something like that), but it can't test
>>every combination of every feature.  And this case seems to involve a
>>combination of limited controlled types and interfaces (and perhaps
>>extended return).

I agree that it's impractical to test every combination of features. 

But perhaps it is possible to test, in addition to every feature 
individually, the sum of all of them. 

(Of course I admit even then, it may not have caught this particular 
corner case)

> It is important to recognize that the ACATS tests do not guarantee
> compiler correctness. A compilation system that correctly processes the
> ACATS tests is not thereby deemed error-free, nor is it thereby deemed
> capable of correctly processing all software that is submitted to it.

Which does not negate the value of ACATS in any way.

>>> Is there a mechanism for adding ad-hoc test cases like this one to
>>> ACATS? One would like to think there is a more systematic effort to
>>> add tests alongside features as they are developed.

I should have been clearer that there were two independent questions 
here ...

(1) can I or Simon B or Joe Bloggs submit tests <somewhere>?

This has been pretty well answered : Simon W pointed to submitted not-yet-
ACATS tests. And...
>>I'm wondering if there might be a need for some other public test suite
>>that users can contribute to.  I don't think ACATS would be an
>>appropriate suite to for just dumping any test cases users find--that
>>just doesn't seem like the right place--but perhaps someone could start
>>a web site.
> 
> I think that would be a great idea. It also would provide a place to
> mine for possible future ACATS tests (it's hard work coming up with test
> scenarios for C-Tests [that is, executable tests]).

I absolutely agree that ACATS shouldn't be a dumping ground for random 
testcases ... but, if there were such an extensible test suite, it would 
inevitably contain the occasional nugget worth polishing up and adding to 
the canon.

Perhaps a starting point is to GPL any testcases we submit against (FSF 
or GPL) Gnat, so that they can become part of the public record. (I 
understand that commercial bug reports against commercial compilers will 
be treated differently!) 

The second question : 
(2) when adding a new feature or language revision, is there a systematic 
effort to add tests for it? 
I think has been answered by the remarks on funding...

Thanks,
- Brian

Re: limited allocated classwide types

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> Perhaps a starting point is to GPL any testcases we submit against
> (FSF or GPL) Gnat, so that they can become part of the public
> record. (I understand that commercial bug reports against commercial
> compilers will be treated differently!)

There are (some) test cases posted on the GCC Bugzilla, ie against FSF
GCC. Test cases posted to report@adacore.com aren't made public, even
for reports against GNAT GPL, though there'd be nothing to prevent the
author doing so if appropriate.

Re: limited allocated classwide types

[Dmitry A. Kazakov]

On Tue, 08 Nov 2011 12:35:31 +0000, Simon Wright wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> Perhaps a starting point is to GPL any testcases we submit against
>> (FSF or GPL) Gnat, so that they can become part of the public
>> record. (I understand that commercial bug reports against commercial
>> compilers will be treated differently!)
> 
> There are (some) test cases posted on the GCC Bugzilla, ie against FSF
> GCC. Test cases posted to report@adacore.com aren't made public, even
> for reports against GNAT GPL, though there'd be nothing to prevent the
> author doing so if appropriate.

There should be some defined test strategy as well to achieve minimal
coverage. E.g. each feature need to be tested in the contexts of being
publicly visible, invisible X within generic instantiation X in child
packages X in generic instance made a child package X within limited/normal
return statements.

X = Cartesian product

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: limited allocated classwide types

[Álex R. Mosteo]

Brian Drummond wrote:

(...)
> 
> I absolutely agree that ACATS shouldn't be a dumping ground for random
> testcases ... but, if there were such an extensible test suite, it would
> inevitably contain the occasional nugget worth polishing up and adding to
> the canon.
> 
> Perhaps a starting point is to GPL any testcases we submit against (FSF
> or GPL) Gnat, so that they can become part of the public record. (I
> understand that commercial bug reports against commercial compilers will
> be treated differently!)

I have read somewhere that AdaCore keeps a repository of testcases for every 
bug ever corrected. These are tested against new compiler versions to avoid 
any regression. This is very appealing to me, and it would be nice to have 
something similar for the GPL versions.

Of course this does not aid in testing new features, but as long as there is 
some interaction between new and old features, it could detect some 
problems. Besides the obvious help in checking the sanity of compiler 
releases going into public distributions.

> 
> The second question :
> (2) when adding a new feature or language revision, is there a systematic
> effort to add tests for it?
> I think has been answered by the remarks on funding...
> 
> Thanks,
> - Brian