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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ce667ecdc314f22 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-08 06:54:02 PST Path: supernews.google.com!sn-xit-03!supernews.com!cyclone2.usenetserver.com!news-out.usenetserver.com!sunqbc.risq.qc.ca!newsfeed.mathworks.com!cpk-news-hub1.bbnplanet.com!cambridge1-snf1.gtei.net!news.gtei.net!inmet!not-for-mail From: Tucker Taft Newsgroups: comp.lang.ada Subject: Re: Releasing Aliased Variables Date: Thu, 08 Mar 2001 09:52:05 -0500 Organization: AverStar (formerly Intermetrics) Burlington, MA USA Message-ID: <3AA79C95.9B9F2D6D@averstar.com> References: <3AA692A8.F1283C27@netscape.net> <87bsrcs8a3.fsf@deneb.enyo.de> NNTP-Posting-Host: nebula.burl.averstar.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: inmet2.burl.averstar.com 984063125 29442 141.199.8.77 (8 Mar 2001 14:52:05 GMT) X-Complaints-To: usenet@inmet2.burl.averstar.com NNTP-Posting-Date: 8 Mar 2001 14:52:05 GMT X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:5544 Date: 2001-03-08T14:52:05+00:00 List-Id: Florian Weimer wrote: > > Robert A Duff writes: > > > In code-generation terms, it causes X to allocated at an addressable > > location (eg, not in a register). It is unlikely that "aliased" > > controls whether X is allocated on the stack versus the heap (but of > > course compilers can do what they like). > > Some time ago, there was a thread in which someone explained (I think > Robert Dewar) that 'aliased' does not provide any help to the compiler > regarding alias detection, register allocation etc. because the > compiler has to be able to determine this kind of information anyway > if an Address attribute is used. > > So in code-generation terms, 'aliased' is a no-op. The rules on 'Address are pretty tricky, and the compiler has to make several assumptions about "normal" use of 'Address to deal with it reasonably. In particular, it generally assumes that there is no use of 'Address if it can't "see" the use of 'Address. Furthermore, unless an object is marked aliased (or the object is of a by-ref type or had its address specified), there is no requirement for 'Address to work at all. See RM95 13.3(16). On the other hand, "aliased" has very well defined semantics, and compilers that do any sort of optimization treat aliased objects quite differently than non-aliased objects. Any store through a pointer of a general access type which might legitimately be pointing to the aliased object is presumed to kill the aliased object. Compilers are not that pessimistic about other objects that might somewhere have had their address taken (perhaps because their address was "captured" by calling a function which took 'Address of a formal and then stored the value in some global pointer). So *do* use "aliased" if you want reliable results... -- -Tucker Taft stt@avercom.net http://www.averstar.com/~stt/ Chief Technology Officer, AverCom Corporation (A Titan Company) Burlington, MA USA (AverCom was formerly the Commercial Division of AverStar: http://www.averstar.com/services/ebusiness_applications.html)