Re: GCC warnings for unused global variables

[Laurent Guerby <guerby at acm dot org>]

On Fri, 2003-05-02 at 19:08, Joel Sherrill wrote:
> Hopefully Dr. Dewar is out there listening because he could comment
> on the requirements of the Ada LRM for pragma volatile.  My
> understanding
> is that the requirements for the feature and expected behavior is
> very much the same.

Volatile for Ada is defined in terms of external effects for
memory read and write. So it works for alpha particle detection
but do not apply to static unread variables being kept
in the object file. 

For this very platform (object code format) specific purpose a pragma
Export with a compiler defined convention (In_Object_But_Not_In_Memory
:) is probably the way to do it in the Ada RM spirit.

The guide to compiler writers for Volatile is pretty explicit in the
annotated RM (which is freely available):

<<
20    {external effect (volatile/atomic objects) [partial]} The external
effect of a program (see 1.1.3) is defined to include each read and update of
a volatile or atomic object. The implementation shall not generate any memory
reads or updates of atomic or volatile objects other than those specified by
the program.

    20.a  Discussion: The presumption is that volatile or atomic objects might
          reside in an ``active'' part of the address space where each read
          has a potential side-effect, and at the very least might deliver a
          different value.

    20.b  The rule above and the definition of external effect are intended to
          prevent (at least) the following incorrect optimizations, where V is
          a volatile variable:

    20.c  X:= V; Y:=V; cannot be allowed to be translated as Y:=V; X:=V;

    20.d  Deleting redundant loads: X:= V; X:= V; shall read the value of V
          from memory twice.

    20.e  Deleting redundant stores: V:= X; V:= X; shall write into V twice.

    20.f  Extra stores: V:= X+Y; should not translate to something like V:= X;
          V:= V+Y;

    20.g  Extra loads: X:= V; Y:= X+Z; X:=X+B; should not translate to
          something like Y:= V+Z; X:= V+B;

    20.h  Reordering of loads from volatile variables: X:= V1; Y:= V2;
          (whether or not V1 = V2) should not translate to Y:= V2; X:= V1;

    20.i  Reordering of stores to volatile variables: V1:= X; V2:= X; should
          not translate to V2:=X; V1:= X;
>>

If a Volatile variable is not read, the compiler is free to remove
it entirely. For Volatile constant, there's a specific rule: 

<<
13    If a pragma Volatile, Volatile_Components, Atomic, or Atomic_Components
applies to a stand-alone constant object, then a pragma Import shall also
apply to it.

    13.a  Ramification: Hence, no initialization expression is allowed for
          such a constant. Note that a constant that is atomic or volatile
          because of its type is allowed.

    13.b  Reason: Stand-alone constants that are explicitly specified as
          Atomic or Volatile only make sense if they are being manipulated
          outside the Ada program. From the Ada perspective the object is
          read-only. Nevertheless, if imported and atomic or volatile, the
          implementation should presume it might be altered externally. For an
          imported stand-alone constant that is not atomic or volatile, the
          implementation can assume that it will not be altered.
>>


-- 
Laurent Guerby <guerby@acm.org>