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 05:34:55 PST
Path: 
 supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!falcon.america.net!sunqbc.risq.qc.ca!newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.easynews.net!newsfeed2.easynews.net!easynews.net!news.cid.net!news.enyo.de!news1.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Releasing Aliased Variables
Date: 08 Mar 2001 14:24:36 +0100
Organization: Enyo's not your organization
Message-ID: <87bsrcs8a3.fsf@deneb.enyo.de>
References: <3AA692A8.F1283C27@netscape.net> <wccsnkpi8qb.fsf@world.std.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Xref: supernews.google.com comp.lang.ada:5542
Date: 2001-03-08T14:24:36+01:00
List-Id: <comp.lang.ada>

Robert A Duff <bobduff@world.std.com> 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.