goddard-fortran-ecosystem / gftl-shared Goto Github PK

A larger use case in which 10^6 integers are inserted in a set and then deleted one at a time fails at run time. First failure is not finding element 11.

Strongly suspect this is a corner case not properly covered by recent changes to use ALLOCATABLE rather than POINTER for the child nodes.

Reproducer:

program main
   use, intrinsic :: iso_fortran_env, only: INT64, REAL64
   use gFTL2_Integer32Set
   implicit none

   type(Integer32Set) :: s
   type(Integer32SetIterator) :: iter
   integer :: i, j, n
   real(kind=REAL64) :: x

   integer(kind=INT64) :: c0, c1, cr
   
   n = 10**5
   s = Integer32Set()

   call system_clock(c0, cr)
   do i = 1, N
!!$      call random_number(x)
!!$      j = 1 + floor(N*x)/N + i
!!$      call s%insert(j)
      call s%insert(i)
   end do
   call system_clock(c1)

   print*,'construction time: ', real(c1-c0)/cr, s%size()

   call system_clock(c0)
!!$   call s%clear()
   do i = 11, N
!!$      iter = s%find(i)
!!$      print*, i, iter == s%end()
      j = s%erase(i)

      if (j /= 1) then
         print*, i, j
         associate (b => s%begin(), e => s%end())
           iter = b
           do while (iter /= e)
              print*,'iter: ', iter%of()
              call iter%next()
           end do
         end associate
      end if
   end do
   call system_clock(c1)
   print*,'deconstruction time: ', real(c1-c0)/cr
   
end program main

I'm trying to compile gFTL-shared with Cray compiler on one of the NOAA systems, and I'm getting a lot of errors. Is it intended to support the Cray compiler, or if not, is there an plan to? I'm happy to provide more detail about error messages etc.

When compiling with -i8 (Intel) | -fdefault-integer-8 (Gnu) [using fix described in #67] many subroutines are ambiguous. It would be nice if the gFTL-shared library worked with the default 64-bit integer, because using the library compiled with default 4-byte integers, in a project where the default integer is 8 bytes leads to the following error on the USE statements with gfortran (Intel does not complain, but I think it should have):

DTIO dummy argument at (1) must be of KIND = 8

which I ascribe to gFTL-shared having been compiled with default 4-byte integers, and the program that uses gFTL-shared being compiled with default 8-byte integers.

Projects that use GFTL_SHARED should not have to explicitly "find" GFTL. By adding the following line in the GFTL_SHARED.config.in all should be good:

find_package (GFTL REQUIRED)

If I try building gFTL-shared either of these ways

cmake -D CMAKE_Fortran_COMPILER_ID=NVHPC ...
cmake -D CMAKE_Fortran_COMPILER_VERSION=21.11 ...

I get this warning

-- Check for working Fortran compiler: /usr/local/pgi/Linux_x86_64/21.11/compilers/bin/pgfortran - skipped
CMake Error at CMakeLists.txt:35 (include):
  include could not find requested file:
    NVHPC

I can get around it by copying the PGI version

cp cmake/PGI.cmake cmake/NVHPC.cmake

since it looks like the contents would be identical anyway.

There is a name conflict for executable demo.x If building gFTL-shared within the source same tree as MAPL, as is done for GCHPctm.

CMake Error at src/MAPL/MAPL_Profiler/demo/CMakeLists.txt:1 (add_executable):
  add_executable cannot create target "demo.x" because another target with
  the same name already exists.  The existing target is an executable created
  in source directory
  "/n/home08/elundgren/GC/Code.GCHPctm/src/gFTL-shared/src".  See
  documentation for policy CMP0002 for more details.

This can be resolved by renaming one of the executables to a different name.

Currently, building downstream consumers of gFTL-shared such as pFUnit requires building all versions of all containers. It would be very nice if users could build only the set that they need. This would massively speed up builds.

I think this would be pretty easy to achieve. As well as adding each container to the gftl-shared library here:

also make a new target just for that container:

add_library(${T}_${Container} vector/${T}${Container}_wrap.F90)

Then users could link against GTL_SHARED::String_Vector for example, and only build what they require.

The make include GFTL_SHARED.mk.in has a reference to GFTL_TOP_DIR:

But this is nowhere assigned (as far as I can see), and so it remains empty in the installed file, and GFTK.mk is not found.
(The same happens in the fargparse and pfunit packages).

In readme.md, should be "trial" and "variants" in "After a tria period, the v2 variats"

First, demo.x should have EXCLUDE_FROM_ALL as it is just a sanity check on the implementation.
Second, it should be exercised by ctest, i.e., add_test(...).

I don't think a separate test directory is warranted.

I'm trying to build the gFTL-shared using the PGI compiler. The command

cmake -D CMAKE_Fortran_COMPILER_ID=PGI -D CMAKE_INSTALL_PREFIX=/usr/local -D CMAKE_PREFIX_PATH=/usr/local -D CMAKE_MODULE_PATH=/usr/local ..

doesn't produce the right diagnostic output:

CMake Error at cmake/fortran_try.cmake:18 (string):
  string sub-command STRIP requires two arguments.
Call Stack (most recent call first):
  cmake/check_intrinsic_kinds.cmake:3 (CHECK_Fortran_SOURCE_RUN)
  CMakeLists.txt:36 (include)
-- Performing Test _LOGICAL_DEFAULT_KIND: SUCCESS (value=)

Note that (value=) with no number bring printed.
If I make this change to the cmake/PGI.cmake file

14c14
< set(CMAKE_Fortran_FLAGS "-g ${cpp} ${traceback} ${check_all} -Mallocatable=03")
---
> set(CMAKE_Fortran_FLAGS "-g ${cpp} ${traceback} ${check_all} -Mallocatable=03 -noswitcherror")

then the output starts looking right:

-- Performing Test _LOGICAL_DEFAULT_KIND: SUCCESS (value=4)
-- Performing Test _INT_DEFAULT_KIND: SUCCESS (value=4)O_INT8: SUCCESS (value=1)
-- Performing Test _ISO_INT16: SUCCESS (value=2)
-- Performing Test _ISO_INT32: SUCCESS (value=4)
-- Performing Test _ISO_INT64: SUCCESS (value=8)
-- Performing Test _REAL_DEFAULT_KIND: SUCCESS (value=4)
-- Performing Test _DOUBLE_DEFAULT_KIND: SUCCESS (value=8)
-- Performing Test _ISO_REAL32: SUCCESS (value=4)
-- Performing Test _ISO_REAL64: SUCCESS (value=8)

IntegerSet.F90 does not export IntegerSetIterator. It is not quite like all the other queue-like structurses.

For support of shared libraries in GEOS (at least), we need gFTL to be build with fPIC.

The type StringSet is defined, but why its iterator is missing ?

I use Spack to evaluate Fujitsu Compiler for Fugaku and FX1000.
When I tried to build this package(v1.7.0), I received an error similar to the following:

==> Error: ProcessError: Command exited with status 1:
    '/fefs/spack2/spack/opt/spack/linux-rhel8-a64fx/fj-4.10.0/cmake-3.27.4-o4w4ad5gemgpf5teeimtmxl3mpktqzom/bin/cmake' '-G' 'Unix Makefiles' '-DCMAKE_INSTALL_PREFIX:STRING=/fefs/spack2/spack/opt/spack/linux-rhel8-a64fx/fj-4.10.0/gftl-shared-1.7.0-t4vfydc53scqqqketa5uiqwefcfkezkh' '-DCMAKE_BUILD_TYPE:STRING=Release' '-DCMAKE_INTERPROCEDURAL_OPTIMIZATION:BOOL=OFF' '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON' '-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=ON' '-DCMAKE_INSTALL_RPATH:STRING=/fefs/spack2/spack/opt/spack/linux-rhel8-a64fx/fj-4.10.0/gftl-shared-1.7.0-t4vfydc53scqqqketa5uiqwefcfkezkh/lib;/fefs/spack2/spack/opt/spack/linux-rhel8-a64fx/fj-4.10.0/gftl-shared-1.7.0-t4vfydc53scqqqketa5uiqwefcfkezkh/lib64' '-DCMAKE_PREFIX_PATH:STRING=/fefs/spack2/spack/opt/spack/linux-rhel8-a64fx/fj-4.10.0/gftl-1.11.0-rqedzzjschqifkbb3rvn3spanukrbagq;/fefs/spack2/spack/opt/spack/linux-rhel8-a64fx/fj-4.10.0/cmake-3.27.4-o4w4ad5gemgpf5teeimtmxl3mpktqzom' '/fefs/spack2/tmp/spack-stage/spack-stage-gftl-shared-1.7.0-t4vfydc53scqqqketa5uiqwefcfkezkh/spack-src'

1 error found in build log:
     9     
     10    
     11    -- The Fortran compiler identification is Fujitsu 4.10.0
     12    -- Detecting Fortran compiler ABI info
     13    -- Detecting Fortran compiler ABI info - done
     14    -- Check for working Fortran compiler: /fefs/spack2/spack/lib/spack/env/fj/frt - skipped
  >> 15    CMake Error at CMakeLists.txt:35 (include):
     16      include could not find requested file:
     17    
     18        Fujitsu
     19    
     20    
     21    -- Performing Test _LOGICAL_DEFAULT_KIND: SUCCESS (value=4)

I think it is because there is no Fujitsu.cmake in cmake directory.
Can you add the file to the cmake directory if I suggest the necessary options?
If it's not easy, I will post a patch to Spack.

target_include_directories (gftl-shared-v2 PUBLIC
  $<BUILD_INTERFACE:${GFTL_BINARY_DIR}/mod/v2>
  $<INSTALL_INTERFACE:${dest}/include/v2>
  )

modules are built in different directory than claimed here. Only affects attempts at building internal executable, so not urgent.

Was inconsistent with use of defined() in the FPP macros.

gFTL and gFTL-shared are now uploaded and accepted as Debian packages. This leads to a build of the packages on all Debian platforms for gFTL-shared (gFTL is build only once for all packages).

On the MIPS and ARM 32-bit platforms (little endian), this however leads to the following error:

[ 98%] Building Fortran object src/CMakeFiles/demo.x.dir/demo.F90.o
cd /<<PKGBUILDDIR>>/obj-arm-linux-gnueabihf/src && /usr/bin/f95 -D_DOUBLE_DEFAULT_KIND=8 -D_GNU -D_INT_DEFAULT_KIND=4 -D_ISO_INT16=2 -D_ISO_INT32=4 -D_ISO_INT64=8 -D_ISO_INT8=1 -D_ISO_REAL32=4 -D_ISO_REAL64=8 -D_LOGICAL_DEFAULT_KIND=4 -D_REAL_DEFAULT_KIND=4 -I/<<PKGBUILDDIR>>/obj-arm-linux-gnueabihf/mod -I/usr/include/gftl  -g -cpp -fbacktrace -ffree-line-length-512 -J../mod -fPIE   -c /<<PKGBUILDDIR>>/src/demo.F90 -o CMakeFiles/demo.x.dir/demo.F90.o
/<<PKGBUILDDIR>>/src/demo.F90:15:7:

   15 |    use gFTL_Real128Vector
      |       1
Fatal Error: Cannot open module file ‘gftl_real128vector.mod’ for reading at (1): No such file or directory
compilation terminated.
make[3]: *** [src/CMakeFiles/demo.x.dir/build.make:66: src/CMakeFiles/demo.x.dir/demo.F90.o] Error 1

Full build log for armhf here.

There is no way to set -DCMAKE_Fortran_FLAGS="<my-custom-flags>" when compiling. The compile flags from cmake/.cmake are always used.

Suggestion for GNU.cmake: replace line 9 with
set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -g ${cpp} ${traceback} -ffree-line-length-none")

Suggestion for Intel.cmake and IntelLLVM.cmake line 19
set(CMAKE_Fortran_Flags_ALL "${CMAKE_Fortran_FLAGS} ${cpp} ${disable_warning_for_long_names}")