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-12 10:46:10 PST Path: supernews.google.com!sn-xit-03!supernews.com!logbridge.uoregon.edu!newsfeed.nyu.edu!typhoon.nyu.edu!lab.ultra.nyu.edu!kenner Newsgroups: comp.lang.ada Subject: Re: Releasing Aliased Variables References: <3AA692A8.F1283C27@netscape.net> <87bsrcs8a3.fsf@deneb.enyo.de> Organization: New York University Ultracomputer Research Lab From: kenner@lab.ultra.nyu.edu (Richard Kenner) Message-ID: <7P8r6.16$Pa3.362@typhoon.nyu.edu> Date: Mon, 12 Mar 2001 18:45:23 GMT NNTP-Posting-Host: 128.122.140.194 X-Trace: typhoon.nyu.edu 984422723 128.122.140.194 (Mon, 12 Mar 2001 13:45:23 EST) NNTP-Posting-Date: Mon, 12 Mar 2001 13:45:23 EST Xref: supernews.google.com comp.lang.ada:5650 Date: 2001-03-12T18:45:23+00:00 List-Id: In article <87bsrcs8a3.fsf@deneb.enyo.de> Florian Weimer writes: >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. That's not completely true. It has at least two effects: (1) An aliased component of an aggregate must be on the same alignment boundary as its type, which affects packing in records and allowable record rep clauses. (2) If you have a de-reference through an access type for some type and you have a field of an aggregate that is of that type, you know that the reference *cannot* be to that field.