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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e8d2c0ed82daf4da
X-Google-Attributes: gid103376,public
From: claveman@fern.com (Charles H. Sampson)
Subject: Re: Handling Addressing Errors
Date: 1999/03/18
Message-ID: <1999Mar18.005620.19189@nosc.mil>#1/1
X-Deja-AN: 456177472
Sender: news@nosc.mil
References: <1999Mar3.212443.1898@nosc.mil> <7bm0v3$933$1@nnrp1.dejanews.com>
Organization: Computer Sciences Corporation
Newsgroups: comp.lang.ada
Date: 1999-03-18T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <7bm0v3$933$1@nnrp1.dejanews.com>,
 <robert_dewar@my-dejanews.com> wrote:
>In article <1999Mar3.212443.1898@nosc.mil>,
>  claveman@cod.nosc.mil (me) wrote:
>
>>            ... what prevents an optimizing compiler from
>> deciding that the assignment statement is unnecessary
>> (BOGUS is never referenced after being set) so that it
>> doesn't need to access BOARD_LOCATION?
>
>Common sense and reasonable behavior!

     In short, there's not much hope.  :-)

     Seriously, while it's hard to argue against common sense and rea-
sonable behavior, I wish the LRM had explicitly said what should happen.

>Any compiler that does not use an address clause to trigger
>an implicit volatility is poorly designed in my view. Of
>course it does not harm to put in a specific pragma
>Volatile, and that will most certainly solve this problem

     Fair enough that an address clause should implicitly trigger vola-
tility, but that's not quite the issue.  Suppose the address clause had 
caused an overlay of two objects (rather than creating an access to a 
slave board location, as in my original example).  Then any reasonable 
compiler--any correct compiler--must access memory any time the value of 
one of the objects is needed, to prevent using a stale value held else-
where.  But in my example, dead store elimination would determine that 
storing BOGUS is not necessary.  It's only a small jump from that to 
determining that the value of BOARD_VALUE isn't needed, so there's no 
point in fetching it.

     By my reading, even pragma Volatile doesn't help, because C.6(10) 
only says that all reads are performed directly to memory.  It doesn't 
say that the read must be performed even if it is known that the value 
is not used.  I think it's well beyond the LRM to say that a read of a 
volatile object might have some effect in addition to obtaining its 
value and, therefore, all reads must be performed whether the value is 
needed or not.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".