Re: isnan in fortran

[Mike Miller]

On Tue, Apr 10, 2012 at 11:19 AM, John W. Eaton <address@hidden> wrote:
> On 10-Apr-2012, Mike Miller wrote:
>
> | On Tue, Apr 10, 2012 at 9:19 AM, Svante Signell wrote:
> | > On Tue, 2012-04-10 at 14:13 +0100, Michael Goffioul wrote:
> | >> On Tue, Apr 10, 2012 at 2:03 PM, Jordi Gutiérrez Hermoso
> | > ...
> | >> > Can Fortran be preprocessed? If so, can we write an autoconf macro to
> | >> > check for isnan and use X.NE.X if not?
> | >>
> | >> http://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-Options.html
> | >>
> | >> Apparently, it can be preprocessed, but it's not enabled by default
> | >> for .f files (assuming .f extension is treated differently than .F,
> | >> which is not clear from the documentation).
> | >
> | > From man gcc:
> | >
> | >       file.f
> | >       file.for
> | >       file.ftn
> | > Fixed form Fortran source code which should not be preprocessed.
> | >
> | >       file.F
> | >       file.FOR
> | >       file.fpp
> | >       file.FPP
> | >       file.FTN
> | > Fixed form Fortran source code which must be preprocessed (with
> | > the traditional preprocessor).
> |
> | Yes, and looks like automake will pass the right options to preprocess
> | Fortran, but only if the extension is .F, the others listed above are
> | possibly ignored by automake, even if gcc will handle them.
> |
> | 
> http://www.gnu.org/software/automake/manual/automake.html#Preprocessing-Fortran-77
> |
> | Should work, I'll come up with something if no one beats me to it.
>
> Gfortran is not the only compiler we might use to compile the Fortran
> bits of Octave.

Completely agree.  Preprocessing is by no means standard F77.
Automake has some comments that their support for it assumes the
compiler can do the work.  I have personally worked with g77,
gfortran, PG pgf77, and Intel ifort, and all support at least some of
the same preprocessing directives.  But, we can do the preprocessing
ahead anyway...

> I think it would be better to rename the files that need this
> treatment to FILE.in.f and then use sed to do the transformation to
> generate FILE.f in the build tree.

How about cpp instead of sed, so we can still have a
#if..#else..#endif syntax?  There will need to be a custom list of -D
options or a custom include file, cannot just use the same config.h,
but it's clearer and more scalable if other such feature tests are
needed in the future.

-- 
mike