Hi,
The gfortran man page for this option is
-frange-check
Enable range checking on results of simplification of constant expres-
sions during compilation. For example, by default, gfortran will give
an overflow error at compile time when simplifying "a = EXP(1000)".
With -fno-range-check, no error will be given and the variable "a"
will be assigned the value "+Infinity".
So the connection between this compile time option and the run time errors
may be cryptic as may be the code according to this thread.
I recommend a code fix instead of a compiler option, but
if -fno-range-check is the only fix then include detailed comments
and/or log messages.
Scott
On Mon, 3 Nov 2008, Ross Walker wrote:
> Ah ha:
>
> cvs log $AMBERHOME/src/configure_amber
>
> revision 9.93
> date: 2008/10/20 03:52:32; author: sbrozell; state: Exp; lines: +2 -2
> Removed -fno-range-check from gfortran compile flags.
> This completely removes it. Some old gfortrans do not
> support this option; see below.
> It is still unclear to me (see revision 9.65 log) why this option
> is necessary or even useful. The log for revision 9.64 where the
> option was introduced is almost useless since it does not indicate
> why the option was added; in addition the doc subdirectory contains
> no instance of Jory; so this tiny clue didnt help.
> Testing the Fortran compiler:
> gfortran -O0 -fno-range-check -fno-second-underscore -o testp testp.f
> f951: error: unrecognized command line option "-fno-range-check"
> gcc version 4.0.0 20041009 (experimental)
> Darwin rooster.compbio.ucsf.edu 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar
> 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power
> Macintosh powerpc
>
> So adding '-fno-range-check' back in fixes the compilation (for some
> versions of gfortran) - but still seems like a bit hack to me...
>
> All the best
> Ross
>
> > -----Original Message-----
> > From: owner-amber-developers.scripps.edu [mailto:owner-amber-
> > developers.scripps.edu] On Behalf Of Volodymyr Babin
> > Sent: Monday, November 03, 2008 4:31 PM
> > To: amber-developers.scripps.edu
> > Subject: amber-developers: Re: Busted mt19937.f with gfortran in parallel.
> >
> > Hi All,
> >
> > the mt19937.f is indeed broken (well, it depends how you define things).
> > Quick googling provides semi-fix : -fno-range-check flag to gfortran.
> > I am going to take a closer look tonight.
> >
> > With kind regards,
> > Volodymyr
> >
> > On Mon, November 3, 2008 18:43, Ross Walker wrote:
> > > Okay, looking further into this it seems that the mt19937 module is only
> > > used by some of the NCSU code and the routine causing the problem here
> > is
> > > the function
> > >
> > > random_int32
> > >
> > > Which as far as I can tell is NOT legal fortran due to it trying to
> > stuff
> > > int*8 values into int*4 variables. However, since this is only used by
> > > Volodymyr code I thought I'd let him look at this first before I hack
> > the
> > > code about to see if he can see a simple solution.
> > >
> > > All the best
> > > Ross
> > >
Received on Fri Dec 05 2008 - 10:35:50 PST
