From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!feed.usenet.farm!feeder1.usenet.farm!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!85.12.16.70.MISMATCH!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx16.am4.POSTED!not-for-mail Subject: Re: Yet another gnat bug Newsgroups: comp.lang.ada References: <987a6ff2-32d0-45a0-b90a-be9fbf1ff47b@googlegroups.com> From: Per Sandberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <987a6ff2-32d0-45a0-b90a-be9fbf1ff47b@googlegroups.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Message-ID: X-Complaints-To: abuse@usenet.se NNTP-Posting-Date: Fri, 01 Feb 2019 21:22:34 UTC Organization: usenet.se Date: Fri, 1 Feb 2019 22:22:33 +0100 X-Received-Bytes: 5076 X-Received-Body-CRC: 3460409254 Xref: reader01.eternal-september.org comp.lang.ada:55422 Date: 2019-02-01T22:22:33+01:00 List-Id: 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.. >