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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: suppress "unspecified order" error in gnat? Date: Mon, 18 Mar 2019 18:25:37 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Mon, 18 Mar 2019 23:25:38 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="29526"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:55892 Date: 2019-03-18T18:25:37-05:00 List-Id: "Stephen Leake" wrote in message news:f09c8b98-5f65-4a63-bbc7-b192ad906113@googlegroups.com... > I'd like to compile the following: > > New_Nonterm : constant Valid_Node_Index := Tree.Add_Nonterm > ((+nonterminal_ID, 0), > (1 => Tree.Add_Identifier (+IDENTIFIER_ID, New_Identifier), > 2 => Tree.Add_Terminal (+COLON_ID), > 3 => RHS_Alt_Node, > 4 => Tree.Add_Nonterm > ((+semicolon_opt_ID, 0), > (1 => Tree.Add_Terminal (+SEMICOLON_ID))))); > > but GNAT complains: > > wisitoken_grammar_runtime.adb:715:19: value of actual may be affected by > call in other actual because they are evaluated in unspecified order > > Here "Tree" is a syntax tree, and the various Tree.Add_* functions insert > items in the tree and return a tree node id. > > In this case, it does not matter what order the aggregate elements are > evaluated in. Normally I applaud this error, but I'd like to turn it off > in this case. This was the compromize that let us get "in out" parameters in functions added to the language. It's an error, but it is purposely designed to be conservative. So it should happen rarely (if at all) in code where it doesn't matter. The rule is strong for functions with in out parameters and weak otherwise. It shouldn't trigger unless you have a bunch of functions with "in out" parameters or you did something obviously wrong. I don't see either of those in the above, although it's hard to tell without any compilable code. (Note: many of us complain about non-compilable examples from outsiders -- that applies to us as well!! :-) GNAT was known to have enforced this rule incorrectly; I ran into an error like the above in some of my own code, and when I analyzed the code, it turned out to be legal (and also that there was a minor bug in the Standard, big surprise - it was requiring checks on composite parameters to procedures that had at least 3 paraameters, two of which were in out elementary). We've fixed the bug in the Standard, I have no idea if the bugs in GNAT were fixed (although I did report my specific case and I think that was fixed). There never has been ACATS tests for this rule written, and clearly there needs to be. If I had an unlimited budget... :-) > Applying 'pragma Warnings' doesn't work, because this is not a warning; > it's an error. Duh. :-) > Surprisingly, I can write a subprogram to work around this; the above > becomes > > New_Nonterm : constant Valid_Node_Index := Add_Nonterm > ((+nonterminal_ID, 0), > Child_1 => Tree.Add_Identifier (+IDENTIFIER_ID, > New_Identifier), > Child_2 => Tree.Add_Terminal (+COLON_ID), > Child_3 => RHS_Alt_Node, > Child_4 => Tree.Add_Nonterm > ((+semicolon_opt_ID, 0), > (1 => Tree.Add_Terminal (+SEMICOLON_ID)))); I don't see any difference with this that the other except that the component names are properly given here. Again, a full example might make it clearer what the heck you are talking about here. In any case, the rule for the parameters of a subprogram call and those for an aggregate are the same, so if you are getting different results, I'd expect a GNAT bug. But it's hard to be certain without running the actual case through the 2 pages of rules in 6.4.1. That requires a complete example (yes, broken record ... ;-). Randy.