------- 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
