Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!spool.mu.edu!snorkelwacker.mit.edu!hsdndev!cmcl2!lanl!cochiti.lanl.gov!jlg From: jlg@cochiti.lanl.gov (Jim Giles) Newsgroups: comp.lang.c Subject: Re: low level optimization Message-ID: <23016@lanl.gov> Date: 1 May 91 23:11:10 GMT References: <1991Apr17.225944.15261@zoo.toronto.edu> <22839@lanl.gov> Sender: news@lanl.gov Organization: Los Alamos National Laboratory Lines: 43 In article , burley@pogo.gnu.ai.mit.edu (Craig Burley) writes: |> [...] |> Obviously, if the decision as to whether a dummy gets defined or even |> referenced is made at run-time, then it is impossible for a compiler or |> linker/loaded to do a complete check as to whether aliasing errors have |> been coded into the application. True. The test I had in mind would signal a message whenever an instance of aliasing occurred which _might_ be illegal. That is, if either of the aliased entities is _possibly_ assigned to within the procedure (this is a simple thing for the compiler to determine - the variables either appear on the left of an assignment _somewhere_ or not). In this respect, I simply assume that the possible will happen. The bottom line is that any variable with the OUT or INOUT attribute (or, one that would have that attribute if you made an interface for it) must not be aliased or I issue a message. |> [...] |> That having been said, I do think 99% or more of all aliasing errors comitted |> in Fortran code are detectable (without falsing) at the link/load phase |> (i.e. more than 99% are provable and obvious). I agree. This is also true of all C code except where pointer assignment has been performed. Then the issue gets muddy indeed. The only safe answer is that the pointers involved are now _maybe_ aliased to all the objects in the transitive closure of assignments to which they belong. This is also simple for the compiler to determine, but will result in a lot of alias warnings that aren't actually true. Fortran pointers will suffer the same problem. The best solution is to extend the languages to allow the user to explicitly declare which pointers are allowed to be aliased and to what. Then the compiler can actually enforce the constraints (at compile time). This gets back to the issue of "empowerment". Giving the user explicit control is empowerment. Automatically making the decision for him is not. Though, if an automatic method _mostly_ does what you want, you may be satisfied to accept the default most of the time - just as long as you are given the power to override the default when you want to. With respect to aliasing, neither Fortran nor C give you that power. Using the loader in the manner I've described would give the user feedback about how to use that power most effectively - and maybe, therefore, convince implementors and language designers to provide the necessary features. J. Giles