With gfortran-9 (gcc version 9.2.1 20191102 ) I get the following error upon compilation

~/fortran-utils/build$ make fortran_utils
[  0%] Building Fortran object src/legacy/amos/CMakeFiles/amos.dir/zunk1.f.o
/home/ipribec/TUM/fortran-utils/src/legacy/amos/zunk1.f:129:16:

   55 |       DO 70 I=1,N
      |                                                                        2
......
  129 |         IF ((YR(I-1).EQ.ZEROR).AND.(YI(I-1).EQ.ZEROI)) GO TO 70
      |                1
Error: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2) [-Werror=do-subscript]

The error can be silenced by adding -Wno-error=do-subscript to the CMakeLists.txt in the src/legacy/amos folder.

Can a CONTRIBUTING guideline be added to the project?

Using 997228c, the spline test fails on an Atom N270 machine with gfortran 4.6.3. Here's the output:

 Assert failed.
STOP 1

Backtrace for this error:
  + function __utils_MOD_newunit (0x8051D72)
    at line 119 of file utils.f90
  + function __utils_MOD_assert (0x8050DA7)
    at line 296 of file utils.f90
  + function test_splines (0x804A237)
    at line 21 of file test_splines.f90
  + /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x2564d3]

Dear Ondrej,

I have a question about possible future contributions. What's your opinion on wrapping and shipping non-standard legacy libraries?

Specifically, I am thinking of the Bessel and Hankel functions (of complex arguments) to be found in amos. I have already wrapped some of those and I feel like adding all of those to the special module.

Interface of spherical Bessel functions yn(x) is not exist.

Hello,

while preparing a gfortran 4.4 compatibility patch that changes all open(newunit=...) calls to open(unit=newunit(...)...), I noticed that cmake seems to assume gfortran 4.4 understands the -fcheck command line option (which it does not, that's for >= 4.5).

How can this be fixed? I don't know anything about cmake, so any help is appreciated!

As a side note, I think -O3 and -fcheck=all may not be the optimal combination for the speed perspective. I personally use -fbounds-check and related during testing, but then use binaries without runtime checks in production stage.

When compiling the current version I get the following error

[  1%] Building Fortran object src/CMakeFiles/fortran_utils.dir/optimize.f90.o
[  2%] Building Fortran object src/CMakeFiles/fortran_utils.dir/lapack.f90.o
[  3%] Building Fortran object src/CMakeFiles/fortran_utils.dir/linalg.f90.o
[  3%] Building Fortran object src/CMakeFiles/fortran_utils.dir/mesh.f90.o
[  4%] Building Fortran object src/CMakeFiles/fortran_utils.dir/ppm.f90.o
[  5%] Building Fortran object src/CMakeFiles/fortran_utils.dir/sorting.f90.o
[  6%] Building Fortran object src/CMakeFiles/fortran_utils.dir/special.f90.o
/Users/carvajal/fortran-utils/src/special.f90:565:25:

 10            DJ(K)=0.0D0
                         1
Error: Obsolescent feature: DO termination statement which is not END DO or CONTINUE with label 10 at (1) [-Werror]

A few small improvements that come to my mind are

• Using Horner's rule to save a few arithmetic operations in

  fortran-utils/src/splines.f90

  Line 354 in b43bd24

  function poly3(x,c)

• Making the poly3, dpoly3, and other primitives pure which could aid compiler in-lining
• For some combinations of boundary conditions, the spline system will be tridiagonal, meaning the dgtsv solver from lapack could be used instead of the banded solver dgbsv (see line #L195 in splines.f90)
• For a cubic spline with natural conditions at both ends, the system will be positive definite (as long as the knots are distinct), meaning the even more specialized solver dptsv could be used (see Factorization of cubic spline interpolation matrix)
• For the tridiagonal matrices arising in spline interpolation which are diagonally dominant, Intel MKL even has a special function dtsvb which does not perform pivoting and is supposedly faster, but may have accuracy issues if the data are very small or very large.

I am trying to get it working in the "x" branch:

https://github.com/certik/fortran-utils/tree/x

and you can see the Travis page here:

http://travis-ci.org/certik/fortran-utils

so far it does not work, I think it's some Travis bug. Once I get it working, I'll create just one nice patch.

I use cmake version 2.6-patch 4 on Scientific Linux 6.2.

cmake . in the base project path gives

CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 2.6)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done
CMake Error: Cannot determine link language for target "fortran_utils".
CMake Error: CMake can not determine linker language for target:fortran_utils
-- Generating done
-- Build files have been written to: /home/eberspaecher/fortran-utils

This is odd for several reasons, I think: first, a required version is given. Second, cmake should know that we want a Fortran library (all source files are .f90).

A Google search indicates that something like set_property(TARGET fortran_utils PROPERTY LINKER_LANGUAGE Fortran) might be needed. I tried adding that in CMakeLists.txt, but then I get

CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_Fortran_CREATE_STATIC_LIBRARY

I don't know how to deal with that, unfortunately.

[grassy@rockarch fortran-utils]$ f95 -v
Using built-in specs.
COLLECT_GCC=f95
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 6.2.1 20160830 (GCC)
[grassy@rockarch fortran-utils]$ cmake .

Configuration results

Fortran compiler: /usr/bin/f95
Build type: Debug
Fortran compiler flags: -std=f2008 -Wall -Wextra -Wimplicit-interface -fPIC -Werror -fmax-errors=1 -g -fcheck=all -fbacktrace
Installation prefix: /usr/local
With LAPACK: yes
With HDF5: no
-- Configuring done
-- Generating done
-- Build files have been written to: /home/grassy/ftn/fortran-utils
[grassy@rockarch fortran-utils]$ make
[ 1%] Building Fortran object src/CMakeFiles/fortran_utils.dir/types.f90.o
[ 2%] Building Fortran object src/CMakeFiles/fortran_utils.dir/utils.f90.o
[ 2%] Building Fortran object src/CMakeFiles/fortran_utils.dir/amos.f90.o
[ 2%] Building Fortran object src/CMakeFiles/fortran_utils.dir/constants.f90.o
[ 3%] Building Fortran object src/CMakeFiles/fortran_utils.dir/optimize.f90.o
/home/grassy/ftn/fortran-utils/src/optimize.f90:35:8:
if (fc == 0) return ! We need to make sure f(c) is not zero below
1
Error: Equality comparison for REAL(8) at (1) [-Werror]
compilation terminated due to -fmax-errors=1.
f951: all warnings being treated as errors
make[3]: *** [src/CMakeFiles/fortran_utils.dir/build.make:207: src/CMakeFiles/fortran_utils.dir/optimize.f90.o] Error 1
make[2]: *** [src/CMakeFiles/fortran_utils.dir/build.make:222: src/CMakeFiles/fortran_utils.dir/optimize.f90.o.provides] Error 2
make[1]: *** [CMakeFiles/Makefile2:88: src/CMakeFiles/fortran_utils.dir/all] Error 2
make: *** [Makefile:95: all] Error 2