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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,59d5ec062146fb1f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-30 07:32:19 PST Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!swiss.ans.net!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody From: dewar@cs.nyu.edu (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Elaboration Date: 30 Oct 1994 08:39:06 -0500 Organization: Courant Institute of Mathematical Sciences Message-ID: <3907lq$etb@gnat.cs.nyu.edu> References: <941029004807_73672.2025_DHR55-2@CompuServe.COM> NNTP-Posting-Host: gnat.cs.nyu.edu Date: 1994-10-30T08:39:06-05:00 List-Id: It is an unfortunate fact that in many implementations of Ada, pragma Inline does indeed create dependencies of this nature, and can lead to circular dependencies. Of course compilers are not *required* to introduce these dependencies. Using the source library approach of GNAT, you can never get circular dependencies from pragma Inline, since the only dependencies are from objects to sources, there are no inter-unit dependencies, or order of compilation requirements for pragma Inline to work. I believe that the Telesoft compiler (as opposed to the Alsys compiler) could also achieve this kind of freedom using the back end optimizer feature that allowed a number of units to be optimized to gether (of course this approach gets a bit marginal for really large programs, but it has advantages beyond simply handling inline "correctly") SUbunits in particular introduce situations in which inline simply doesn't work "right" in some Ada implementations. For example, if the body of a subunit provides the body for an inlined function, the parent will not be able to inline the function, since it must be compiled before its subunits.