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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,a32653cf595422e6
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.202.168 with SMTP id kj8mr11392642pbc.1.1335113009186;
        Sun, 22 Apr 2012 09:43:29 -0700 (PDT)
Path: 
 r9ni86117pbh.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!news.internetdienste.de!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sun, 22 Apr 2012 18:43:27 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: GNAT and register allocation
References: <4f9138c2$0$6628$9b4e6d93@newsspool2.arcor-online.net>
 	<4f9145b5$0$6557$9b4e6d93@newsspool4.arcor-online.net>
 	<jmrpej$cao$1@speranza.aioe.org>
 	<4f918218$0$6557$9b4e6d93@newsspool4.arcor-online.net>
 <82r4vhi8v4.fsf@stephe-leake.org>
In-Reply-To: <82r4vhi8v4.fsf@stephe-leake.org>
Message-ID: <4f94352f$0$6625$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 22 Apr 2012 18:43:27 CEST
NNTP-Posting-Host: edaddc4b.newsspool2.arcor-online.net
X-Trace: 
 DXC=i^nD:[WDCLa]l@YUW5NBknA9EHlD;3Ycb4Fo<]lROoRa8kF<OcfhCOk@:>SDEfdW7fnc\616M64>jLh>_cHTX3jmU_ULiPPWlId
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-04-22T18:43:27+02:00
List-Id: <comp.lang.ada>

On 21.04.12 14:10, Stephen Leake wrote:

>> I must use one set of options for an entire program in this case.
>
> Why?

This requirement is likely a fact (external) that we can't change.
We may try one day.

> gpr files give you a way to apply different compilation options to
> different files. There are _lots_ of low-level gcc options controlling
> inline and other optimizations; see gnat user guide, section 3.10.

Controlling inline expansion with GCC's -f[no]-inline[-*] can
require that the entire program be reorganized. Consider a call chain:

A
-> B
--> C
---> D

I want to specify that D be expanded inline into C,
but also want to prevent C from being expanded into B.
That is, B should actually call C. Right now, the bodies
of B, C, and D are neighbors in the same scope.

In this case, a possible solution seems to be to arrange
for separate compilation units. Specify -fno-inline-functions
for the translation of B, and enable inline expansion for C and D.
Is this correct? OR will the "outer" inline prevention override
the "inner"?

I'm also no sure yet whether or not this arrangement will be possible
using Ada's feature for separate compilation ("separate" keyword),
or whether I would have to make a child package containing C and D.
(IIRC, GNAT uses slightly different rules for subprograms declared
separate in other subprograms than for subprograms declared separate
in (non-generic?) packages.)

If this procedure adequately describes how to achieve inline control,
then I will find a compiler pragma a little easier.