This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Failure of implicit real*8
On Sun, Feb 20, 2011 at 12:03:56PM +0000, N.M. Maclaren wrote:
> On Feb 20 2011, Tobias Burnus wrote:
>
> >Note of caution when not using -fdefault-real-8: 1.0 is a default-real
> >variable, thus for, e.g.,
> > real*8 sqrt
> > sq2 = sqrt(2.0)
> >you loose precision, unless you do
> > sq2 = sqrt(2.0d0)
>
> Is it safe for all constants and the problematic intrinsics (like cmplx)?
> If so, I may mention it a bit more definitely in my course, more as a
> debugging tool than as something to rely on - i.e. if using this works,
> look for unmodified constants and intrinsics without kind.
>
The above is just one problem. Consider the dusty deck
(ie nonconforming, nonportable) method for manipulating
the bits of a REAL:
EQUIVALENCE(X,I)
I = 2139095040
print *, I, x
end
laptop:kargl[212] gfortran -o z a.f
laptop:kargl[213] ./z
2139095040 +Infinity
laptop:kargl[214] gfortran -o z -fdefault-real-8 a.f
laptop:kargl[215] ./z
2139095040 4.85700001962471812E-270
In short, it comes down to storage association, which affects
things like EQUIVALENCE and COMMON and formal vs dummy argument
lists. One not only needs to compile all files in one's project
with this option, but all libraries that one might link into
the executable (e.g., LAPACK, BLAS, etc.)
--
Steve