Xref: utzoo comp.lang.c:10292 comp.lang.fortran:681 Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!bu-cs!purdue!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c,comp.lang.fortran Subject: Re: no noalias not negligible - a difference between C and Fortran - long Message-ID: <7949@brl-smoke.ARPA> Date: 21 May 88 14:56:47 GMT References: <54080@sun.uucp> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 23 In article <54080@sun.uucp> dgh%dgh@Sun.COM (David Hough) writes: >Perhaps what will happen is that high-performance >C compilers will adopt the questionable CDC/Cray Fortran practice >of providing "unsafe" optimization levels that, for instance, >assume all pointers are unaliased. David's article did an excellent job of illustrating why many X3J11 members thought something like "noalias" would have been useful. He correctly points out that ANSI C as it now stands requires that aliasing be handled "right", and that this interferes with some forms of optimization. I think one of two possible "solutions" will be implemented by vendors who care about this issue (for example, on vector hardware). One is to adopt essentially "noalias", i.e. a type qualifier that makes an appropriate guarantee so the optimizer is free to do its thing (it would be best if this were "__noalias" or some other non- conflicting extension to ANSI C). The other approach is to provide a compiler switch to enable such optimization globally on a per- source file basis. Both approaches are known to be viable; the first is more general but requires more work on the part of the programmer, and the resulting code is not strictly conforming. It is even possible to support both methods simultaneously.