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=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,1676be4fafed1dbb
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!news.glorb.com!wns14feed!worldnet.att.net!attbi_s52.POSTED!53ab2750!not-for-mail
From: "Steve" <nospam_steved94@comcast.net>
Newsgroups: comp.lang.ada
References: <35f054ea.0410140733.5f250e6f@posting.google.com>
Subject: Re: Semantics of Inline vs non-Inline
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Message-ID: <qEHbd.242144$MQ5.96106@attbi_s52>
NNTP-Posting-Host: 24.21.42.251
X-Complaints-To: abuse@comcast.net
X-Trace: attbi_s52 1097811606 24.21.42.251 (Fri, 15 Oct 2004 03:40:06 GMT)
NNTP-Posting-Date: Fri, 15 Oct 2004 03:40:06 GMT
Organization: Comcast Online
Date: Fri, 15 Oct 2004 03:40:06 GMT
Xref: g2news1.google.com comp.lang.ada:5232
Date: 2004-10-15T03:40:06+00:00
List-Id: <comp.lang.ada>

For what it's worth I am in full agreement with your claim.  Inline
expansion of subprograms is described in section 6.3.2 of the Ada 95
Reference manual.

No special considerations are given for accessability of values and in fact
the compiler is explicity given permission to ignore the inline
recommendation.  I would agree that if the code fails with the inline pragma
and succeeds otherwise, the compiler is broken.  Of course I'm not an
authority.

Steve
(The Duck)

"skidmarks" <aschwarz@acm.org> wrote in message
news:35f054ea.0410140733.5f250e6f@posting.google.com...
> My compiler vendor says that the semantics of an inline/non-inline
> function can be different at the discretion of the compiler vendor. In
> particular, if at the point of use of an inline function the value of
> an argument (to the defined subprogram) is in a register, then it is
> acceptable to 'crash' because the address of the argument is not known
> (it's in a register).
>
> My claim is that the semantics of of an inline and non-inline
> subprogram must be identical, and further, the application writer is
> both unaware and should be unaware of the code generated at the point
> of subprogram use.
>
> Any idea which view is the correct one?
>
> Art
>
> ----------------------------------------------------------
> Example (in truncated pseudo-Ada):
>
> package body x is
>    subtype Datum_Type is Natural;
>    package List is new abc.List_Manager( <size> );
>    function Push( Datum : Datum_Type ) return List.Cell_Ptr is
>       LM_Datum : List.Datum_Type;
>                  for LM_Datum'Address use Datum'Address;
>    begin -- Push
>      return List.Push(LM_Datum);
>    end Push;
>    pragma inline( Push );
>
>    Cell : List.Cell_Ptr;
>    thing: Natural;
> begin -- x
>    Cell := Push(thing);
> end x;
>
> This code does not work with    'pragma inline'.
> This code does     work without 'pragma inline'.
>
> The vendor claims that the address of 'thing' is not known at the call
> (it may be in a register) and hence the inlined 'Push' does not have a
> valid input argument. My first statement is that the behavior for
> inline/non-inline should be the same, and that if it succeeds in one
> it should succeed in all. Is this a correct interpretation?