Xref: utzoo comp.unix.wizards:15363 comp.std.c:1000
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.wizards,comp.std.c
Subject: Re: noalias
Message-ID: <9974@smoke.BRL.MIL>
Date: 3 Apr 89 20:51:42 GMT
References: <9135@alice.UUCP> <12975@watdragon.waterloo.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Followup-To: comp.std.c
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <12975@watdragon.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes:
>In article <9135@alice.UUCP> dmr@alice.UUCP writes:
>>Noalias went in, but it went out again.
>Why? Inquiring minds not in the standardization community but interested in 
>optimization want to know.

This was explained before (in a C newsgroup, probably not UNIX-WIZARDS),
but here goes again, in brief:

Why it went in:

To provide optimizers a way to know when pointer aliasing was not possible,
so they could vectorize etc. to a much higher degree than allowed otherwise.

Why it went out:

The "noalias" qualification was improperly specified, and consequently
spread its influence into internals of C library routines, etc. making
a mess that conforming programs would have to contend with.  It probably
could have been fixed, but there was a big enough stink made about it
that it wasn't politically feasible to do otherwise than remove the
tainted word "noalias".  No other proposal for providing similar
function was found acceptable to a 2/3 majority of X3J11.