Yet another gnat bug

Yet another gnat bug

[George Shapovalov]

This will probably sound more like venting frustration. Sorry if so. But how does anybody get anything done? 
gnat is *the major* Ada compiler and pretty much the only one implementing the standard in full. Yet I cannot seem to get it working past really small size in any project. As soon as I try to get any basic type composition done (only 3-4 inheritance levels, with, perhaps double interface overlay), I get that dreaded gnat bug message.. This is at least the 3rd one just within past week or two..
Specifically this:
https://github.com/gerr135/wann/tree/gnat_bug01
(the bug triggering code is in a separate branch pointed to by that link).

This is still early in design phase and far from being functional in any way, so I don't really expect much comments on the code itself (thus that "venting frustration" comment above). But the pattern that seems to universally trigger these gnat bugs is something along these lines:

type Base_Interface is interface;
..

type Derived1_Interface is new Base_Interface and ..;
..
perhaps few more layers here..

then 
type Base_impl1 is new Base_Interface with private;
..
type Derived1 is new Base_impl1 and Derived1_Interface with private..

basically trying to stitch together functional interface hierarchy (containing algorithmic stuff) and data storage type hierarchy. Somehow gnat very often just cannot handle this type of design :(.
(and yes, I am avoiding having to lay generics on top of other generics like Dmitry suggests - keeps design and compilation times sane, but apparently overloads gnat capacity to deal with abstraction).

So, I guess my question would be - how people deal with such situations (combining algorithmic and data representation type hierarchies) in their experience? Or, whether too many child modules makes any difference? I seem to have noticed that the more hierarchical my packages are (but this one is only like 3rd level child!) the more often I trigger that gnat bug message..
(but then keeping the code in one huge module is really messy too!)

And yeah, the specific message here is:
gprbuild -P wann.gpr
Compile
   [Ada]          run_customnn.adb
+===========================GNAT BUG DETECTED==============================+
| Community 2018 (20180524-73) (x86_64-pc-linux-gnu) GCC error:            |
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:429                   |
| Error detected at wann-nets-vectors.ads:106:5 [run_customnn.adb:23:5]    |
| Please submit a bug report by email to report@adacore.com.               |
| GAP members can alternatively use GNAT Tracker:                          |
| http://www.adacore.com/ section 'send a report'.                         |
| See gnatinfo.txt for full info on procedure for submitting bugs.         |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
| Use plain ASCII or MIME attachment(s).                                   |
+==========================================================================+

and the "please include" list of files lists pretty much all of them in the src dir.

But as I said, this is rather a pattern I observe, not just one-off situation..
This is with the latest FSF gnat compiler (2018 release based on gcc-7.3.1 backend, Gentoo Linux, relatively fresh everything else).

Sigh, I guess another report to file with AdaCore..
Sorry for disturbance here..

Re: Yet another gnat bug

[Dmitry A. Kazakov]

On 2019-02-01 15:51, George Shapovalov wrote:

> So, I guess my question would be - how people deal with such situations (combining algorithmic and data representation type hierarchies) in their experience? Or, whether too many child modules makes any difference? I seem to have noticed that the more hierarchical my packages are (but this one is only like 3rd level child!) the more often I trigger that gnat bug message..

Do not panic. In many cases the bug is triggered by an illegal program. 
Try an older version of GNAT compiler to find what triggers it. In other 
cases you can work around it using minor code variations.

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

Re: Yet another gnat bug

[Simon Wright]

George Shapovalov <gshapovalov@gmail.com> writes:

> gprbuild -P wann.gpr
> Compile
>    [Ada]          run_customnn.adb
> +===========================GNAT BUG DETECTED==============================+
> | Community 2018 (20180524-73) (x86_64-pc-linux-gnu) GCC error:            |
> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:429                   |
> | Error detected at wann-nets-vectors.ads:106:5 [run_customnn.adb:23:5]    |

but I get

$ gprbuild -p -P wann
wann.gpr:5:32: "../../libs/ada_common/src" is not a valid directory
gprbuild: "wann" processing failed

Re: Yet another gnat bug

[Per Sandberg]

Tried your repository with the branch you suggested but i failed with 
the following log:
-----------------------------------------------------------
[wann]$ make
gprbuild -p -j0 -P wann.gpr
wann.gpr:5:32: "../../libs/ada_common/src" is not a valid directory
gprbuild: "wann.gpr" processing failed
-----------------------------------------------------------
So please provide a "working" reproducible.
/P

On 2/1/19 3:51 PM, George Shapovalov wrote:
> This will probably sound more like venting frustration. Sorry if so. But how does anybody get anything done?
> gnat is *the major* Ada compiler and pretty much the only one implementing the standard in full. Yet I cannot seem to get it working past really small size in any project. As soon as I try to get any basic type composition done (only 3-4 inheritance levels, with, perhaps double interface overlay), I get that dreaded gnat bug message.. This is at least the 3rd one just within past week or two..
> Specifically this:
> https://github.com/gerr135/wann/tree/gnat_bug01
> (the bug triggering code is in a separate branch pointed to by that link).
> 
> This is still early in design phase and far from being functional in any way, so I don't really expect much comments on the code itself (thus that "venting frustration" comment above). But the pattern that seems to universally trigger these gnat bugs is something along these lines:
> 
> type Base_Interface is interface;
> ..
> 
> type Derived1_Interface is new Base_Interface and ..;
> ..
> perhaps few more layers here..
> 
> then
> type Base_impl1 is new Base_Interface with private;
> ..
> type Derived1 is new Base_impl1 and Derived1_Interface with private..
> 
> basically trying to stitch together functional interface hierarchy (containing algorithmic stuff) and data storage type hierarchy. Somehow gnat very often just cannot handle this type of design :(.
> (and yes, I am avoiding having to lay generics on top of other generics like Dmitry suggests - keeps design and compilation times sane, but apparently overloads gnat capacity to deal with abstraction).
> 
> So, I guess my question would be - how people deal with such situations (combining algorithmic and data representation type hierarchies) in their experience? Or, whether too many child modules makes any difference? I seem to have noticed that the more hierarchical my packages are (but this one is only like 3rd level child!) the more often I trigger that gnat bug message..
> (but then keeping the code in one huge module is really messy too!)
> 
> And yeah, the specific message here is:
> gprbuild -P wann.gpr
> Compile
>     [Ada]          run_customnn.adb
> +===========================GNAT BUG DETECTED==============================+
> | Community 2018 (20180524-73) (x86_64-pc-linux-gnu) GCC error:            |
> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:429                   |
> | Error detected at wann-nets-vectors.ads:106:5 [run_customnn.adb:23:5]    |
> | Please submit a bug report by email to report@adacore.com.               |
> | GAP members can alternatively use GNAT Tracker:                          |
> | http://www.adacore.com/ section 'send a report'.                         |
> | See gnatinfo.txt for full info on procedure for submitting bugs.         |
> | Use a subject line meaningful to you and us to track the bug.            |
> | Include the entire contents of this bug box in the report.               |
> | Include the exact command that you entered.                              |
> | Also include sources listed below.                                       |
> | Use plain ASCII or MIME attachment(s).                                   |
> +==========================================================================+
> 
> and the "please include" list of files lists pretty much all of them in the src dir.
> 
> But as I said, this is rather a pattern I observe, not just one-off situation..
> This is with the latest FSF gnat compiler (2018 release based on gcc-7.3.1 backend, Gentoo Linux, relatively fresh everything else).
> 
> Sigh, I guess another report to file with AdaCore..
> Sorry for disturbance here..
> 

Re: Yet another gnat bug

[George Shapovalov]

On Friday, February 1, 2019 at 9:41:08 PM UTC+1, Simon Wright wrote:
> but I get
> 
> $ gprbuild -p -P wann
> wann.gpr:5:32: "../../libs/ada_common/src" is not a valid directory
> gprbuild: "wann" processing failed

Oops, that's a stale import of an extra lib I thought to use at one point but then rolled back. Apparently I forgot to remove the path, and I obviously still have that lib on my system, even if its not withed any more.. 

Removed, you should be able to proceed now. Sorry about that.


One other note: at first build the compiler may complain about missing obj/dbg dir. Please just run:
mkdir -p obj/dbg 
from the project dir (not src, one level above it).

I have obj/ in .gitignore to prevent it tracking generated files (and git tends to ignore the entire dir, not just its contents. At least my very short attempts to force it to ignore obj/* but not obj/ itself did not succeed. I preferred the annoyance of running once the mkdir command over spending more time trying to beat git when I set it up). 

Thanks for your attempt!
George

Re: Yet another gnat bug

[George Shapovalov]

On Friday, February 1, 2019 at 7:47:39 PM UTC+1, Dmitry A. Kazakov wrote:
> Do not panic. In many cases the bug is triggered by an illegal program. 
> Try an older version of GNAT compiler to find what triggers it. In other 
> cases you can work around it using minor code variations.
Oh, I am far from panic. It is, as I mentioned, already like 3rd project where I trigger a similar bug in the space of a week or two. Just, when you finally laid out thing just the way you wanted and then gnat explodes on that final compile attempt.. Then you get such an expression of frustration :).

Thanks for the advice though! This is pretty much how I handle these. But nice to know I am not alone in this. Well, in fact not so nice - would be nicer if this never happened of course :). But at least reassuring. So thanks again.

Re: Yet another gnat bug

[George Shapovalov]

On Friday, February 1, 2019 at 10:22:36 PM UTC+1, Per Sandberg wrote:
> Tried your repository with the branch you suggested but i failed with 
> the following log:
> -----------------------------------------------------------
> [wann]$ make
> gprbuild -p -j0 -P wann.gpr
> wann.gpr:5:32: "../../libs/ada_common/src" is not a valid directory
> gprbuild: "wann.gpr" processing failed
Just fixed this, literally a minute ago. You can sync again and retry. That was some stale path I forgot to remove. Fixed now..

Re: Yet another gnat bug

[George Shapovalov]

On Friday, February 1, 2019 at 10:34:12 PM UTC+1, George Shapovalov wrote:
> Just fixed this, literally a minute ago. You can sync again and retry. That was some stale path I forgot to remove. Fixed now..

Please also run "mkdir -p obj/dbg" (needs done one time only) if compiler complains about this obj/dbg not existing (see my message above about .gitignore details).

Re: Yet another gnat bug

[Simon Wright]

George Shapovalov <gshapovalov@gmail.com> writes:

> On Friday, February 1, 2019 at 9:41:08 PM UTC+1, Simon Wright wrote:
>> but I get
>> 
>> $ gprbuild -p -P wann
>> wann.gpr:5:32: "../../libs/ada_common/src" is not a valid directory
>> gprbuild: "wann" processing failed
>
> Oops, that's a stale import of an extra lib I thought to use at one
> point but then rolled back. Apparently I forgot to remove the path,
> and I obviously still have that lib on my system, even if its not
> withed any more..
>
> Removed, you should be able to proceed now. Sorry about that.

OK, and all the compilers I have here fail in the same way:

FSF GCC 6, 7, 8, 9
GNAT 2016, 2017, 2018

For GCC 9, the relevant code in decl.c is

  /* If we get here, it means we have not yet done anything with this entity.
     If we are not defining it, it must be a type or an entity that is defined
     elsewhere or externally, otherwise we should have defined it already.  */
  gcc_assert (definition
	      || type_annotate_only
	      || is_type
	      || kind == E_Discriminant
	      || kind == E_Component
	      || kind == E_Label
	      || (kind == E_Constant && Present (Full_View (gnat_entity)))
	      || Is_Public (gnat_entity));

... and we are none the wiser.

I tried
  gprbuild -p -P wann.gpr -c -u -f wann-nets-vectors.adb
and it compiled OK except for loads of 'unimplemented' warnings.

Poking around at your main program, it seems that things go wrong at the
line

    package PNetV  is new PNet.vectors;

(i.e., I deleted stuff starting at the bottom, by the time I'd deleted
this line it compiled "OK".

> One other note: at first build the compiler may complain about missing
> obj/dbg dir. Please just run:
> mkdir -p obj/dbg 
> from the project dir (not src, one level above it).

'gprbuild -p' will create missing directories.

Or you could add

   for Create_Missing_Dirs use "true";

to your GPR (recent ones only).

Re: Yet another gnat bug

[Jere]

On Friday, February 1, 2019 at 4:26:29 PM UTC-5, George Shapovalov wrote:
> One other note: at first build the compiler may complain about missing obj/dbg dir. Please just run:
> mkdir -p obj/dbg 
> from the project dir (not src, one level above it).
> 
> I have obj/ in .gitignore to prevent it tracking generated files (and git tends to ignore the entire dir, not just its contents. At least my very short attempts to force it to ignore obj/* but not obj/ itself did not succeed. I preferred the annoyance of running once the mkdir command over spending more time trying to beat git when I set it up). 

What I do is put a "special" .gitignore in the obj directory that says ignore everything in this directory except for myself.  I don't include the obj directory in the top level .gitignore at all and rely on the special one inside the obj directory itself.  The special .gitignore file looks like this:

*
*/
!.gitignore

That's it, just 3 lines to say ignore everything in this directory, everything in any subdirectories, but don't ignore me.  Git will then add this .gitignore to your tracked files, securing the obj directory.

Re: Yet another gnat bug

[George Shapovalov]

On Saturday, February 2, 2019 at 3:00:41 AM UTC+1, Jere wrote:
> That's it, just 3 lines to say ignore everything in this directory, everything in any subdirectories, but don't ignore me.  Git will then add this .gitignore to your tracked files, securing the obj directory.
Thanks!
I was looking how to ignore subdir but not its contents (so I only keep one .gitignore around instead of many), but it seems git, with all its bells and whistles does not have a simple syntax for a common use case (or at least I did not find in a short time I looked). A pity. Thanks for the suggestion, this is another way to go about it :).
Now the github code has been updated to retain the dirs but ignore the build files. So that mkdir command should no longer be necessary..

Re: Yet another gnat bug

[Per Sandberg]

I did put some effort to reduce the problem and the workaround is quite 
simple, in file "wann-nets.ads:69" mark the procedure Del_Neuron as 
abstract instead of null.

Here is the small reproducible i ended up with after stripping the code:
-----------------------------------------------------------------
pragma Warnings (Off);
generic
     type Real is digits <>;
package wann is
end Wann;
--
generic
package Wann.Neurons is
end Wann.Neurons;
---
generic
package Wann.Nets is
    type NNet_Interface is limited interface;
    procedure Del (Net : in out NNet_Interface) is null;--  Fails
    --procedure Del (Net : in out NNet_Interface) is abstract;--  Works
    type Cached_NNet_Interface is limited interface and NNet_Interface
end Wann.Nets;
--
generic
package wann.nets.vectors is
     type Proto_NNet is abstract new NNet_Interface with NULL record;
     type Cached_Proto_NNet is abstract new Proto_NNet and 
Cached_NNet_Interface with null record;
end wann.nets.vectors;
--
pragma Warnings (Off);
with wann.nets.vectors;
procedure run_customNN is
     package PW is new wann(Real => Float);
     package PNet   is new PW.nets;
     package PNetV  is new PNet.vectors;
begin
    null;
end Run_CustomNN;
-----------------------------------------------------------------
/P

On 2/1/19 10:36 PM, George Shapovalov wrote:
> On Friday, February 1, 2019 at 10:34:12 PM UTC+1, George Shapovalov wrote:
>> Just fixed this, literally a minute ago. You can sync again and retry. That was some stale path I forgot to remove. Fixed now..
> 
> Please also run "mkdir -p obj/dbg" (needs done one time only) if compiler complains about this obj/dbg not existing (see my message above about .gitignore details).
> 

Re: Yet another gnat bug

[George Shapovalov]

On Saturday, February 2, 2019 at 12:17:19 AM UTC+1, Simon Wright wrote:
> OK, and all the compilers I have here fail in the same way:
[..]
>   /* If we get here, it means we have not yet done anything with this entity.
[..]
> ... and we are none the wiser.
> 
> I tried
>   gprbuild -p -P wann.gpr -c -u -f wann-nets-vectors.adb
> and it compiled OK except for loads of 'unimplemented' warnings.
Ok, so the file itself compiles (I gotta read up on all those switches apparently. This is a ways to quickly test stuff. Thanks for a suggestion!)
But that is quite what I expect, given the nature of the bugs I get - they clearly come from gnat getting lost in all the inheritances I throw at it..

> Poking around at your main program, it seems that things go wrong at the
> line
The specific offending lines are:
wann-nets-vectors.ads:104 and 106
these two full type definitions (if I comment out one it still fails on the other):
    type Cached_Proto_NNet is abstract new Proto_NNet and Cached_NNet_Interface with null record;

    type Cached_Checked_Proto_NNet is abstract new Proto_NNet and Cached_Checked_NNet_Interface with null record;

These are null record at the moment, as I did not yet get around to properly implement them. Just placeholders essentially. And this is what might be confusing gnat I suspect. I did not yet try to add any actual data inside..

> 'gprbuild -p' will create missing directories.
> Or you could add
Thanks, I'll add this too..

A small note: I will be at the Fosdem most of today and possibly tomorrow. So, I may not be able to reply in a timely manner these two days..
(But I will surely pass by the Ada dev room today!)

Re: Yet another gnat bug

[George Shapovalov]

On Saturday, February 2, 2019 at 8:13:04 AM UTC+1, Per Sandberg wrote:
> I did put some effort to reduce the problem and the workaround is quite 
> simple, in file "wann-nets.ads:69" mark the procedure Del_Neuron as 
> abstract instead of null.
> 
> Here is the small reproducible i ended up with after stripping the code:
Wow, thank you for your time!
Looking at how that final code is so small and basic, and thtat snippet of gnat internals that was dug out on another comment above, it looks like gnat does not implement null primitives in full.. (which is a pity, as null method makes more sense there than abstract, but well..)

Once I am completely back from Fosdem I'll play with this a bit more, to see if that's package hierarchy, generics or combination thereof that is triggering it and submit a bug with final details..
Thanks again!

Re: Yet another gnat bug

[Per Sandberg]

Well I think its more about deeply nested generics, since that is a real 
nightmare to implement in it's full context.

/P

On 2/2/19 8:05 PM, George Shapovalov wrote:
> On Saturday, February 2, 2019 at 8:13:04 AM UTC+1, Per Sandberg wrote:
>> I did put some effort to reduce the problem and the workaround is quite
>> simple, in file "wann-nets.ads:69" mark the procedure Del_Neuron as
>> abstract instead of null.
>>
>> Here is the small reproducible i ended up with after stripping the code:
> Wow, thank you for your time!
> Looking at how that final code is so small and basic, and thtat snippet of gnat internals that was dug out on another comment above, it looks like gnat does not implement null primitives in full.. (which is a pity, as null method makes more sense there than abstract, but well..)
> 
> Once I am completely back from Fosdem I'll play with this a bit more, to see if that's package hierarchy, generics or combination thereof that is triggering it and submit a bug with final details..
> Thanks again!
> 

Re: Yet another gnat bug

[George Shapovalov]

On Saturday, February 2, 2019 at 10:37:04 PM UTC+1, Per Sandberg wrote:
> Well I think its more about deeply nested generics, since that is a real 
> nightmare to implement in it's full context.
Not exactly as far as I can tell. 
I have played some more with the code and could simplify it even more - there is no need for that extra top package level. Same thing happens if the interfaces are declared at the top, and overridden in a child. Flat package structure (still generic) compiles fine. Removing generics (and instead doing "type Real is new Float" at the top) given unstable behavior - one time I got the same bug triggered, but after I renamed sources (originally names "workaround" to "alternative" to reflect better the situation) gnat started to compile it properly (giving error message about declaring vars of abstract type). Apparently it has a sense of humor - this is literally the situation of "what is written here is a lie" :).

Anyway, I have created a github project to keep the code producing gnat bugs I have so far encountered (only one at the moment, but thee are two more I need to clean-up and report). This project shows the code triggering the bug, as well as workarounds and the status of the bug report. I think such a resource would be rather useful (given that AdaCore themselves don't really support the bug tracker, at least for the community version [1]). So, please feel free to consult or even contribute, if there are any more commonly encountered bugs..

The project can be found here:
https://github.com/gerr135/gnat_bugs


[1] I chatted with them briefly 2 days ago on Fosdem and they told me that they prefer an email report and that tracker is not really functional for a community version at least.  

Re: Yet another gnat bug

[joakimds]

George, thanks for your efforts in making detailed gnat bug reports and your input in the Ada dev room on Fosdem 2019.

Best regards,
Joakim

Re: Yet another gnat bug

[Simon Wright]

George Shapovalov <gshapovalov@gmail.com> writes:

> I chatted with them briefly 2 days ago on Fosdem and they told me that
> they prefer an email report and that tracker is not really functional
> for a community version at least.

Do you mean the GCC Bugzilla? I can quite understand why reports against
just GNAT CE wouldn't really be appropriate there.

AdaCore do respond to reports on FSF GCC there, especially if the report
is about the GCC build system or about bad code generation. However, old
bugs don't really get curated as they are fixed in new releases.

This doesn't work where the sources concerned aren't publicly visible in
the repository: for example, the embedded runtimes.

Personally I like to report on Bugzilla where appropriate, because
reports to report@adacore.com aren't publicly visible. I don't know how
annoying it'd be to report in both places.

Re: Yet another gnat bug

[George Shapovalov]

On Monday, February 4, 2019 at 5:11:51 PM UTC+1, Simon Wright wrote: 
> > I chatted with them briefly 2 days ago on Fosdem and they told me that
> > they prefer an email report and that tracker is not really functional
> > for a community version at least.
> 
> Do you mean the GCC Bugzilla? I can quite understand why reports against
> just GNAT CE wouldn't really be appropriate there.
No, I meant the tracker mentioned on the bug message:
>GAP members can alternatively use GNAT Tracker:                          |
>| http://www.adacore.com/ section 'send a report'.

From his reaction I took it that that tracker is not that active. Althopugh it would not be so usefull for many people anyway, if it has usage limitations..

> AdaCore do respond to reports on FSF GCC there, especially if the report
> is about the GCC build system or about bad code generation. 
Oh, they do? Thanks for the info!
That's not something I directly thought about, as the problem is with the upstream (of FSF), so it makes sense to take it directly to upstream (the most common reaction of many projects and distibutions is to first try to figure out if its them or upstream, and if its upstream, then its universally - "report it to upstream". Which is totally logical, in avoiding messy duplication of effort. In fact it is often not something they would even have control over).
So, I just took it directly to upstream, strictly following the procedure described in the bug message :).

> Personally I like to report on Bugzilla where appropriate, because
> reports to report@adacore.com aren't publicly visible. I don't know how
> annoying it'd be to report in both places.
Yes, that's indeed a concern. This is why I created that github project, as I had a few bugs lying around already. I'll populate it with more when I get around to it. 
But to the credit of AdaCore, they react quickly - I already got a confirmation that they got it and will look into it..

Re: Yet another gnat bug

[Simon Wright]

George Shapovalov <gshapovalov@gmail.com> writes:

> On Monday, February 4, 2019 at 5:11:51 PM UTC+1, Simon Wright wrote: 
>> > I chatted with them briefly 2 days ago on Fosdem and they told me that
>> > they prefer an email report and that tracker is not really functional
>> > for a community version at least.
>> 
>> Do you mean the GCC Bugzilla? I can quite understand why reports
>> against just GNAT CE wouldn't really be appropriate there.
> No, I meant the tracker mentioned on the bug message:
>>GAP members can alternatively use GNAT Tracker:                          |
>>| http://www.adacore.com/ section 'send a report'.
>
> From his reaction I took it that that tracker is not that
> active. Althopugh it would not be so usefull for many people anyway,
> if it has usage limitations..

If you have a contract with AdaCore then Tracker is the point of
contact; and the response when I worked for a comapny with a contract
was terrific.

If not, your only direct contact is report@adacore.com (with GNAT in the
subject line).

>> AdaCore do respond to reports on FSF GCC there, especially if the report
>> is about the GCC build system or about bad code generation. 
> Oh, they do? Thanks for the info!
> That's not something I directly thought about, as the problem is with
> the upstream (of FSF), so it makes sense to take it directly to
> upstream (the most common reaction of many projects and distibutions
> is to first try to figure out if its them or upstream, and if its
> upstream, then its universally - "report it to upstream". Which is
> totally logical, in avoiding messy duplication of effort. In fact it
> is often not something they would even have control over).  So, I just
> took it directly to upstream, strictly following the procedure
> described in the bug message :).

The AdaCore people working on FSF GCC are the same people working on the
'upstream' product, which is why I've never thought of it like that; but
I see your point.

And, I've occasionally added 'same problem with GNAT CE' to Bugzilla
reports where I thought it might stimulate interest.

>> Personally I like to report on Bugzilla where appropriate, because
>> reports to report@adacore.com aren't publicly visible. I don't know how
>> annoying it'd be to report in both places.
> Yes, that's indeed a concern. This is why I created that github
> project, as I had a few bugs lying around already. I'll populate it
> with more when I get around to it.
> But to the credit of AdaCore, they react quickly - I already got a
> confirmation that they got it and will look into it..

It helps if they know you!

Re: Yet another gnat bug

[George Shapovalov]

On Tuesday, February 5, 2019 at 9:37:17 PM UTC+1, Simon Wright wrote:
> The AdaCore people working on FSF GCC are the same people working on the
> 'upstream' product, which is why I've never thought of it like that; but
> I see your point.
Oh, so they do have people working on gcc directly? Nice!
Sure, that makes total sense (for a company that essentially sells a gcc-based compiler). But unfortunately this rarely happens in reality.
AdaCore seems like a real nice company! (A bit of praise never hearts, but seriously, thanks to AdaCore people for nice work overall!)

> > But to the credit of AdaCore, they react quickly - I already got a
> > confirmation that they got it and will look into it..
> 
> It helps if they know you!
Maybe, but then I on;y saw them once in a person, and that likely were other people.. 
But more importantly, this particular issue seems to be a general omission affecting gnat universally, that would affect all kinds of users. I am just puzzled how this thing was not triggered before by at least some users? Is nobody fond of trying to lay out their types in the most abstract way possible? That *does* force better design and ends up saving quite a bit of work down the road (to the point of coding becoming really boring after the general structure is in and successfully compiled by gnat). Well, I guess people just always write "is abstract" even where "is null" would make more sense (or that not many people mix generics and OOP abstraction)..