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

sgk at troutmask dot apl dot washington dot edu gcc-bugzilla@gcc.gnu.org
Fri Sep 11 19:45:00 GMT 2009



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

> Ok, but then "real" and "double precision" datatypes should
> behave in the same way? No?
> 

They do behave the same at least from the Fortran front-end
perspective.  I've already posted the generated intermediate
code.  Here it is again with the REAL(4) on the left and
the REAL(8) on the right.

volatiletest ()
{
  volatile real(kind=4) ra;          volatile real(kind=8) a;
  real(kind=4) rb;                   real(kind=8) b;
  real(kind=4) rc;                   real(kind=8) c;
  real(kind=4) rua;                  real(kind=8) ua;
  real(kind=4) rub;                  real(kind=8) ub;
  a=(volatile real(kind=8))(ua*ua);  ra=(volatile real(kind=4))(rua*rua);
  b = (real(kind=8)) (ub * ub);      rb = (real(kind=4)) (rub * rub);
  c = (real(kind=8)) (a - b);        rc = (real(kind=4)) (ra - rb);
}

I'll simply note that on my hardware I get 

troutmask:sgk[204] ./z
0.1 0.1 0.1 0.1
   0.0000000000000000        0.0000000    

forall options that I tried.

You've already mentioned the infamous PR 324, so I suspect
you're familiar with the pitfalls of floating point math
and the I387 behavior.  I won't rehash that here.  If you
want the middle-end and back-end to do what you want, then
you'll need to convince others that there is a problem.  See
PR 324 for the joy.

Now, what volatile should be doing is inhibiting the optimizer
from optimizing

   real, volatile :: a
   real b
   a = 0.1
   call sub1
   b = a

to

   call sub1
   b = 0.1


-- 


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



More information about the Gcc-bugs mailing list