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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:3d88:: with SMTP id n130mr2909518itn.6.1549032710718; Fri, 01 Feb 2019 06:51:50 -0800 (PST) X-Received: by 2002:a9d:6f14:: with SMTP id n20mr257345otq.2.1549032710503; Fri, 01 Feb 2019 06:51:50 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!k10no290024itk.0!news-out.google.com!v71ni401ita.0!nntp.google.com!k10no290021itk.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 1 Feb 2019 06:51:50 -0800 (PST) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=134.206.121.213; posting-account=O_NgcgoAAABs6pgCjroQBmOBL5ZZGPUc NNTP-Posting-Host: 134.206.121.213 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <987a6ff2-32d0-45a0-b90a-be9fbf1ff47b@googlegroups.com> Subject: Yet another gnat bug From: George Shapovalov Injection-Date: Fri, 01 Feb 2019 14:51:50 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55417 Date: 2019-02-01T06:51:50-08:00 List-Id: This will probably sound more like venting frustration. Sorry if so. But ho= w does anybody get anything done?=20 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 do= ne (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 with= in 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 wa= y, so I don't really expect much comments on the code itself (thus that "ve= nting frustration" comment above). But the pattern that seems to universall= y 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=20 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 (contain= ing algorithmic stuff) and data storage type hierarchy. Somehow gnat very o= ften just cannot handle this type of design :(. (and yes, I am avoiding having to lay generics on top of other generics lik= e 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 (co= mbining algorithmic and data representation type hierarchies) in their expe= rience? 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 on= ly 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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3DGNAT BUG DETECTED=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | 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). = | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + 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 situati= on.. 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..