goddard-fortran-ecosystem / gftl-shared Goto Github PK
View Code? Open in Web Editor NEWProvides common gFTL containers of Fortran intrinsic types that are encountered frequently.
License: Apache License 2.0
Provides common gFTL containers of Fortran intrinsic types that are encountered frequently.
License: Apache License 2.0
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:
gFTL-shared/src/v2/CMakeLists.txt
Line 41 in 8b8a483
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
:
Line 9 in 67f1338
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}")
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.