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=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!news2.google.com!proxad.net!proxad.net!194.159.246.34.MISMATCH!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Semantics of Inline vs non-Inline Date: 15 Oct 2004 06:50:22 +0100 Organization: Pushface Sender: simon@smaug.pushface.org Message-ID: References: <35f054ea.0410140733.5f250e6f@posting.google.com> NNTP-Posting-Host: pogner.demon.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.demon.co.uk 1097819801 27989 62.49.19.209 (15 Oct 2004 05:56:41 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 15 Oct 2004 05:56:41 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Xref: g2news1.google.com comp.lang.ada:5234 Date: 2004-10-15T06:50:22+01:00 List-Id: aschwarz@acm.org (skidmarks) writes: > 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? I can see that those aspects of execution that aren't defined by the language, or which are erroneous, could be affected by inlining. At the very least the sequence of instructions is going to be different. GNAT has occasionally told me that something couldn't be inlined because of some feature of my code, and I would expect at the least that this would happen here. (I suspect your code is much cut down, a simple test here shows no problem -- 3.16a1). But, the variable only got into the register because the compiler backend put it there, you would have thought the backend would say "can I leave this variable into a register? oh no, I see I need 'Address, better spill it to store". I think your claim sounds 100% right. And even if I'm wrong, the vendor's view seems less than helpful. The compiler ought to _try_ to do the Right Thing. -- Simon Wright 100% Ada, no bugs.