[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: isnan in fortran
From: |
Mike Miller |
Subject: |
Re: isnan in fortran |
Date: |
Tue, 10 Apr 2012 12:06:33 -0400 |
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
- isnan in fortran, c., 2012/04/10
- Re: isnan in fortran, Mike Miller, 2012/04/10
- Re: isnan in fortran, Jordi Gutiérrez Hermoso, 2012/04/10
- Re: isnan in fortran, Michael Goffioul, 2012/04/10
- Re: isnan in fortran, Svante Signell, 2012/04/10
- Re: isnan in fortran, Mike Miller, 2012/04/10
- Re: isnan in fortran, John W. Eaton, 2012/04/10
- Re: isnan in fortran,
Mike Miller <=
- Re: isnan in fortran, John W. Eaton, 2012/04/10
- Re: isnan in fortran, c., 2012/04/11
- Re: isnan in fortran, John W. Eaton, 2012/04/11
- Re: isnan in fortran, John W. Eaton, 2012/04/11
- Re: isnan in fortran, Michael Goffioul, 2012/04/11
- Re: isnan in fortran, c., 2012/04/11
- Re: isnan in fortran, Michael Goffioul, 2012/04/11
- Re: isnan in fortran, c., 2012/04/11
- Re: isnan in fortran, c., 2012/04/11
- Re: isnan in fortran, Mike Miller, 2012/04/11