yes another gnat bug (inherited tagged type as record field is too much for gnat??)

yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[gerrshapovalov]

Hello,

This bug gets triggered while trying to use a tiny "list library", that provides a uniform interface for an indexed/iterable storage a-la Ada.Containers.Vectors, that can be implemented in various ways: using A.C.Vecotrs internally or even plain "fixed" or "bounded" arrays..

This "library" is a part of ada_composition demo, now made into a stnandalone library, with tests as separate package, and can be found here:
https://github.com/gerr135/ada_composition

The lib itself is under ada_lists
and tests for the lib are under ada_lists_tests


Everything works just fine,.. - as long as I use these lists as "plain variables". However when such list is uses as a record field, gnat just commits suicide trying to compile it. 

Basically:

with Lists.Fixed;

package PL  is new Lists(Natural, Positive);
package PLF is new PL.Fixed;

LS : PLF.List(5);

type FRec (N : Positive) is record
    f : PLF.List(N);
end record;

LC : FRec(5);


LS(1)   := 1; -- works fine
LC.f(1) := 1; -- triggers gnat bug

+===========================GNAT BUG DETECTED==============================+
| Community 2019 (20190517-83) (x86_64-pc-linux-gnu) Storage_Error stack overflow or erroneous memory access

The code in the "library" is pretty much minimal (needed to implements indexed access and iteration), and the tests are just repeated blocks or basic code to test assignment and iteration (in the form of indexed and of loops).

So, the easiest way to reproduce this should be to just clone the project mentioned above ( https://github.com/gerr135/ada_composition )
and then:
cd ada_lists_tests
make

Quite "weirdly" the stock A.C.Vectors work fine as record fields. However, is this due to
1. them being "proper" types rather than descendants of some interface
2. some ACT black magic in their implementation (they do use locks and Unrestricted_Access) in the corresponding bodies, I looked)
is not quite clear to me..

Am I overlooking something here? 
This should be a really common use case, a very basic composition idea:
1. do all the algorithmic stuff at the "higher level", using abstract data accessor methods
2. Defer data storage and other implementation details to child packages..

Yes every time I am trying to do a very basic separation of this kind I trigger yet another gnat bug :(.

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[gerrshapovalov]

Just a short addition:

This is with gnat-gpl-2019 (Gentoo Linux), compiled against the 8.3.1 gcc backend.

Also, I can "cure" the compilation problem by wrapping access to the list into an (abstract and overridden in child) function returning Reference to the List.
gnat manages to compile it then. However, upon execution it throws  "discriminant check failed" run-time exception..

(Reference to the list is that standard construct like:

type Input_Reference_Type  (Data : not null access IL.List_Interface'Class) is null record
        with Implicit_Dereference => Data;

This allows to return a callable object that can be used to call methods of List and do indexed data access (assignment/reading)
)

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[Simon Wright]

gerrshapovalov@gmail.com writes:

> So, the easiest way to reproduce this should be to just clone the
> project mentioned above ( https://github.com/gerr135/ada_composition )
> and then:
> cd ada_lists_tests
> make

$ cd ada_lists_tests/
lockheed:ada_lists_tests simon$ make
gprbuild -P ada_lists_tests.gpr
ada_lists_tests.gpr:1:06: unknown project file: "/home/gerr/comp/kdevel/ada/ada_composition/ada_lists/ada_lists.gpr"
gprbuild: "ada_lists_tests.gpr" processing failed
make: *** [list_iface] Error 4

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[gerrshapovalov]

On Friday, November 22, 2019 at 2:39:31 PM UTC+1, Simon Wright wrote:
> gprbuild -P ada_lists_tests.gpr
> ada_lists_tests.gpr:1:06: unknown project file: "/home/gerr/comp/kdevel/ada/ada_composition/ada_lists/ada_lists.gpr"

Hm, used absolute lib reference apparently. I changed it to relative. Should work now.
Sorry about that.

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[gerrshapovalov]

A short update:
After playing around some more I narrowed it down to gnat having some problem with discriminant handling. Basically

type FRec is record
  f : List(5);
end record
R : FRec;
--
R.f(1) := 1; -- still works (as in compiles *and* executes Ok)

but

type FRec (N : Positive) is record
  f : List(N);
end record
R : FRec(5);
--
R.f(1) := 1; -- triggers the bug


I have updated the "demo" (tests) package. 
( https://github.com/gerr135/ada_composition ,  the ada_lists_tests dir)
Now simply calling make should just build the (non-failing) tests. 

To trigger the bug run:
make bug01

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[Per Sandberg]

God work.
And then I assume you followed the instructions and reported it to AdaCore?
/P

On 2019-11-25 20:31, gerrshapovalov@gmail.com wrote:
> A short update:
> After playing around some more I narrowed it down to gnat having some problem with discriminant handling. Basically
> 
> type FRec is record
>    f : List(5);
> end record
> R : FRec;
> --
> R.f(1) := 1; -- still works (as in compiles *and* executes Ok)
> 
> but
> 
> type FRec (N : Positive) is record
>    f : List(N);
> end record
> R : FRec(5);
> --
> R.f(1) := 1; -- triggers the bug
> 
> 
> I have updated the "demo" (tests) package.
> ( https://github.com/gerr135/ada_composition ,  the ada_lists_tests dir)
> Now simply calling make should just build the (non-failing) tests.
> 
> To trigger the bug run:
> make bug01
> 

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[gerrshapovalov]

On Monday, November 25, 2019 at 9:01:52 PM UTC+1, Per Sandberg wrote:
> God work.
> And then I assume you followed the instructions and reported it to AdaCore?
> /P
Not yet, in the process. First I would need to create a proper report and add it to my mini-tracker here:
https://github.com/gerr135/gnat_bugs

ACT apparently has their own tracker, but it is only for people who have subscription to their product.. (Why not open the issues to be at least visible to all? Maybe even let add simple comments - ACT would benefit from this feedback too..)
So, the only way for a "regular person" to submit a bug reprt seems to be via email, as indicated in the bug message.. AM I missing any other way, like open tracker or something else?

I did submit bugs via email previously, but I did not get any feeback beyond the original acknowledgement. And, apparently, one of the bugs was already fixed in gnat-2019. I only knew about it because I retested the bugs in my tracker now, while trying to update it. So, having a visible tracker (even read-only) would be a benefit for all, including AdaCore I think..

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[joakimds]

Hi,

You are not missing anything with regards to bug reporting to AdaCore as far as I know. But I have had a more positive experience from the bug reporting to AdaCore. Not only have I received acknowledgements but also often messages informing me that the bug has been solved in the development version of the compiler.

I have also encountered similar bugs with respect to basic separation but the code in which I triggered such bugs was in proprietary applications and often did not have time to make small code example that trigger the bug in order to report it. Thanks for you efforts in reporting your findings.

Best regards,
Joakim

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[gerrshapovalov]

On Tuesday, November 26, 2019 at 5:09:43 PM UTC+1, joak...@kth.se wrote:
> You are not missing anything with regards to bug reporting to AdaCore as far >as I know. 
Thanks for confirmation.

> But I have had a more positive experience from the bug reporting to AdaCore. 
Oh, but that was not intended to spite AdaCore or anything like that. In fact my experience can be considered positive too - one of the bug did get fixed :) (even if "silently"). Just a remark on the opaqueness of the whole proces and a suggestion on how it could be easily improved for the benefit of everybody :).

Thank for confirming the contact channels in any case!
(and to AdaCore for their efforts of course too)

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[Simon Wright]

gerrshapovalov@gmail.com writes:

> ACT apparently has their own tracker, but it is only for people who
> have subscription to their product.. (Why not open the issues to be at
> least visible to all? Maybe even let add simple comments - ACT would
> benefit from this feedback too..)

They've been AdaCore for quite a while now!

When I was working for a supported customer, we only got to see the
tracker issues for our own project, not even other projects for the same
multi-project customer!

Ours was a classified project, but even for non-classified projects we
would have been able to upload whatever code of ours was causing the
problem, without having to edit it down to a minimal reproducer. *Not*
the sort of thing you'd want your competition to see.

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[George Shapovalov]

I am happy to report that I just got a feedback to my (very recently submitted) bug report - they fixed it, and the fix is already in their current development version. 

Thanks to AdaCore for the prompt reaction! Great job!

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[joakimds]

Den måndag 2 december 2019 kl. 10:02:14 UTC+1 skrev George Shapovalov:
> I am happy to report that I just got a feedback to my (very recently submitted) bug report - they fixed it, and the fix is already in their current development version. 
> 
> Thanks to AdaCore for the prompt reaction! Great job!

Nice! :)

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[Optikos]

On Monday, December 2, 2019 at 3:02:14 AM UTC-6, George Shapovalov wrote:
> I am happy to report that I just got a feedback to my (very recently submitted) bug report - they fixed it, and the fix is already in their current development version. 
> 
> Thanks to AdaCore for the prompt reaction! Great job!

We should use this as an example to see how timely this gets fixed in FSF GNAT, to see whether it is measured in hours, days, weeks, months, etc. over in FSF GNAT.

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[AdaMagica]

Am Montag, 2. Dezember 2019 18:12:04 UTC+1 schrieb Optikos:
> We should use this as an example to see how timely this gets fixed in FSF GNAT, to see whether it is measured in hours, days, weeks, months, etc. over in FSF GNAT.

I would guess months to one year.

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[George Shapovalov]

On Monday, December 2, 2019 at 6:12:04 PM UTC+1, Optikos wrote:
> We should use this as an example to see how timely this gets fixed in 
> FSF GNAT, to see whether it is measured in hours, days, weeks, months, etc. 
> over in FSF GNAT.

That wouldn't be a fair comparison, nor a useful one. Please note, as I said, the fix is in their *development* tree. Meaning that its not yet available to the vast majority of users. maybe some -pro users with a special subscription have access to the "nightly builds" or something like that (I don;t know how that works with AdaCore), but I would guess that even most -pro users would get it only with the next release, after proper integration and testing.

Likely at a similar time it would become available to the community builders and testers - including FSF people. As far as I understand the arrangement, AdaCore would be essentially an "upstream" for the FSF people, who would then integrate Ada-specific features into public gcc backend that they maintain [1]. And only then, with the next release of FSF/gpl version would it fall into the hands of the "final" distro-level package maintainers and would normally get pushed out to the public with the next release or update of a correspondiong distro (some immediately, some with a new distro version only - depending on package update policy of that distro).

The whole process is sequential, with an established workflow, even schedules.. So, the "who gets it done faster" comparison is rather pointless here.


[1]. No inside knowledge to the specifics here, only general experience how it all works on a more public level, as a former (original, many years ago) maintainer of Ada in Gentoo Linux). But I am pretty sure they are not reimplementing the fixes and features in the Ada-specific code, when it is regularly released y a reliable upstream. That would be contrary to "the spirit" and outright impractical and prone to introducing unnecessary problems..

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[Simon Wright]

George Shapovalov <gerrshapovalov@gmail.com> writes:

> As far as I understand the arrangement, AdaCore would be essentially
> an "upstream" for the FSF people, who would then integrate
> Ada-specific features into public gcc backend that they maintain [1].

A very high proportion of the Ada changes to FSF GCC are made by AdaCore
people. You can see this by looking at gcc/ada/Changelog:
https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/ChangeLog.
I spotted 1 non-AdaCore person in the first 1000 lines or so: at 2019-08-23.

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[Optikos]

On Monday, December 2, 2019 at 1:51:29 PM UTC-6, George Shapovalov wrote:
> On Monday, December 2, 2019 at 6:12:04 PM UTC+1, Optikos wrote:
> > We should use this as an example to see how timely this gets fixed in 
> > FSF GNAT, to see whether it is measured in hours, days, weeks, months, etc. 
> > over in FSF GNAT.
> 
> That wouldn't be a fair comparison, nor a useful one.

Quit putting words in my mouth.  I never said that all AdaCore customers have this fix delivered to them today.  I effectively said that
1) we know for a (purported reported) fact that the fix hit AdaCore's internal codebase today;
2) we can eventually observe the date at which this defect's fix hits FSF GNAT to see when OP's original symptoms are no longer exhibited by FSF GNAT.
3) we can then accurately calculate the time that it empirically can take for a fix to defect to actually get released to the wild in FSF GNAT.

I did not say directly or by implication that FSF GNAT's lag is different than typical AdaCore paying customer's lag in receiving this fix.  Although now that you bring it up, that would be a fascinating side topic.

> Please note, as I said, the fix is in their *development*
> tree. Meaning that its not yet available to the vast majority of users. maybe some -pro users with a special
> subscription have access to the "nightly builds" or something like that (I don;t know how that works with
> AdaCore), but I would guess that even most -pro users would get it only with the next release, after proper
> integration and testing.

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[charlet]

> > That wouldn't be a fair comparison, nor a useful one.
> 
> Quit putting words in my mouth.  I never said that all AdaCore customers have this fix delivered to them today.  I effectively said that
> 1) we know for a (purported reported) fact that the fix hit AdaCore's internal codebase today;
> 2) we can eventually observe the date at which this defect's fix hits FSF GNAT to see when OP's original symptoms are no longer exhibited by FSF GNAT.

We regularly merge changes in our GNAT repository to the FSF GCC repository
(almost every week, as witnessed by the gcc/gcc/ada/ChangeLog file), but also have to obey GCC's release schedule and in particular currently GCC is in stage 3, which means basically only regressions are fixed, so our changes are currently on hold and will resume whenever GCC is back to stage 1. See https://gcc.gnu.org/develop.html#timeline for more details on GCC's release timeline.

> 3) we can then accurately calculate the time that it empirically can take for a fix to defect to actually get released to the wild in FSF GNAT.

You also need to take into account GCC's release constraints, see above.

Arno

Re: yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[charlet]

> > 3) we can then accurately calculate the time that it empirically can take for a fix to defect to actually get released to the wild in FSF GNAT.
> 
> You also need to take into account GCC's release constraints, see above.
> 
> Arno

Actually I mixed stage 3 and 4, so never mind the above in this case: we're in stage 3 which is general bug fixes and we'll do a merge of our changes soon :-)
stage 4