This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libfortran/41335] VOLATILE in Fortran does not take effect



------- Comment #7 from sgk at troutmask dot apl dot washington dot edu  2009-09-11 18:57 -------
Subject: Re:  VOLATILE in Fortran does not take effect

> - Comment #6 from denis_scherbakov at yahoo dot com  2009-09-11 18:38 -------
> By saying "works" I mean that on my system program with
> 
> "real, volatile :: a"
> returns nonzero result. This is correct, because 80-bit floating point
> gets truncated to 64-bit and then loaded again into FPU.
> 
> "double precision, volatile :: a"
> returns zero result. It means that variable "a" stays in FPU registers.
> 
> I am not sure about your code, but when I compile both versions of a sample
> program on my machine "real, volatile" is stored and then fetched again,
> "double precision, volatile" stays in FPU.
> 

If you want -ffloat-store semantics then use that option.  The
Fortran 2003 standard does not require anything about fetching
and storing a volatile entity to memory.  The standard states:

    The VOLATILE attribute specifies that an object may be referenced,
    defined, or become undefined, by means not specified by the program.

    An object may have the VOLATILE attribute in a particular scoping
    unit without necessarily having it in other scoping units.  If an
    object has the VOLATILE attribute, then all of its subobjects also
    have the VOLATILE attribute.

    NOTE 5.21
      The Fortran processor should use the most recent definition of a
      volatile object when a value is required.  Likewise, it should
      make the most recent Fortran definition available.  It is the
      programmer's responsibility to manage the interactions with the
      non-Fortran processes.

Note 5.21 is only informative text.  However, gfortran is essentially
doing what 5.21 states.  You're most recent definition of a is given
by a = Ua * Ua, then when you compute c = a - b it uses the most recent
definition.  There is no requirement that a had to be written to and
retrieved from memory.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41335


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]