This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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]

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


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