Path: utzoo!mnetor!uunet!husc6!necntc!ima!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: Pragmas
Message-ID: <14460@think.UUCP>
Date: 7 Jan 88 20:38:41 GMT
References: <17196@topaz.rutgers.edu> <6920@brl-smoke.ARPA>
Sender: usenet@think.UUCP
Reply-To: barmar@sauron.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 22

In article <6920@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>The main reason #pragma is not suitable for "noalias" is, as I showed
>in an earlier posting, the "noalias" property has potentially visible
>and important effect on the computation, depending on the code.  Such
>code is "illegal", under the "noalias" approach, but it would have to
>be permitted if #pragma were used.  A #pragma is not supposed to
>change the interpretation of the virtual-machine semantics of the code.
>At least, that's my interpretation of what's going on here.

That's not my interpretation of noalias.  Noalias is merely a way to
point out a potential optimization.  Since a compiler that doesn't
know how to perform this optimization could validly ignore noalias
declarations, it cannot affect the semantics of the code.  Any program
tha behaves differently depending on whether a variable was declared
with noalias has a bug.  The standard doesn't specify the
virtual-machine semantics of broken programs, only correct programs.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar