search

fortran-lang / stdlib

Fortran Standard Library
https://stdlib.fortran-lang.org
MIT License
1.03k stars 163 forks source link

Workarounds for NAG #108

Open certik opened 4 years ago

certik commented 4 years ago

For NAG 6.2 and the latest master (f300f4a609ab02620b82ee2c79566361d84505c4):

  1. Does not seem to support submodules.

    
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 72b3d25..6a11a43 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -9,12 +9,6 @@ set(SRC

add_library(fortran_stdlib ${SRC})

-if(f18errorstop)

-interface ! f{08,18}estop.f90 -module subroutine error_stop(msg, code) +public :: assert, error_stop + +contains + +subroutine error_stop(msg, code) character(*), intent(in) :: msg integer, intent(in), optional :: code -end subroutine error_stop -end interface

-public :: assert, error_stop +! Aborts the program with nonzero exit code +! this is a fallback for Fortran 2008 error stop (e.g. Intel 19.1/2020 compiler) +! +! The "stop " statement generally has return code 0. +! To allow non-zero return code termination with character message, +! error_stop() uses the statement "error stop", which by default +! has exit code 1 and prints the message to stderr. +! An optional integer return code "code" may be specified. +! +! Example +! ------- +! +! call error_stop("Invalid argument")

-contains +write(stderr,*) msg + +if(present(code)) then

  1. Can't find modules compiled before (fixed by #109). Workaround is to specify -I manually: 
    cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_Fortran_FLAGS_DEBUG="-I$HOME/repos/stdlib" .

Everything then builds and tests pass (including quadruple precision).

nncarlson commented 4 years ago

NAG 7.0 just released does support submodules. I'll get it installed on our machines tonight or tomorrow.

Regarding the need for an explicit include, something is not right in the CMakeLists.txt file; this works if done right. I'll look into it tonight.

nncarlson commented 4 years ago

I've put in PR #109 that fixes the issue of not finding compiled .mod files

scivision commented 4 years ago

Yes NAG 7.0 was the first to support submodule

certik commented 4 years ago

With the latest master (dc7e49b17fa728ad9f9cbd179292952f67b78ead) and NAG 7.0, there are three warnings:

[  3%] Building Fortran object src/CMakeFiles/fortran_stdlib.dir/stdlib_experimental_error.f90.o
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7006
Warning: /home/certik/repos/stdlib/src/stdlib_experimental_error.f90, line 34: ERROR_UNIT explicitly imported into STDLIB_EXPERIMENTAL_ERROR (as STDERR) but not used
[NAG Fortran Compiler normal termination, 1 warning]
[  6%] Building Fortran object src/CMakeFiles/fortran_stdlib.dir/f18estop.f90.o
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7006
Extension: /home/certik/repos/stdlib/src/f18estop.f90, line 23: Stop-code is not constant
Extension: /home/certik/repos/stdlib/src/f18estop.f90, line 25: Stop-code is not constant
[NAG Fortran Compiler normal termination, 2 warnings]

For now we can ignore those.

Then there is an error:

Error copying Fortran module "src/mod_files//stdlib_experimental_errorestop".  Tried "src/mod_files/STDLIB_EXPERIMENTAL_ERRORESTOP.mod" and "src/mod_files/stdlib_experimental_errorestop.mod".
make[2]: *** [src/CMakeFiles/fortran_stdlib.dir/depend.make:9: src/CMakeFiles/fortran_stdlib.dir/stdlib_experimental_errorestop.stamp] Error 1
make[1]: *** [CMakeFiles/Makefile2:93: src/CMakeFiles/fortran_stdlib.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

I think this has to do with how NAG names submodules and how cmake finds them (or not in this case).

scivision commented 4 years ago

That NAG 7.0 error may be a bug in cmake. Similar errors happenes with other compilers until CMake fixed the bugs.

The NAG 7.0 warnings are due to NAG not being in Fortran 2018 syntax mode. I didn't look if nag 7.0 has a command line option to enable Fortran 2018 syntax.

nncarlson commented 4 years ago

-f2018 is the option we need

nncarlson commented 4 years ago

The "copying" thing that cmake is complaining about had me confused. But it looks like it copies the .mod files (that are created where we want them) into the CMakeFiles tree to serve as a .stamp file.

Intel, for example, calls their compiled submodule file stdlib_experimental_error@estop.smod, whereas NAG calls it stdlib_experimental_error.estop.sub.

I think CMake just needs to be taught how NAG behaves; 7.0 is the first version with support for submodules.

scivision commented 4 years ago

Yes that NAG file naming scheme for submodules is completely different than any other compiler so I would say there's a very high chance that CMake needs to update itself.

nncarlson commented 4 years ago

I'm checking the latest CMake now to be sure it's no different than 3.14. If it doesn't work I'll submit an issue to the cmake project.

nncarlson commented 4 years ago

I submitted the cmake issue. If they don't act on it quickly, I'd bet it is easy to fix and submit a PR ourselves. But I'll leave it at that for now.

nncarlson commented 4 years ago

Well the kitware folks were very quick and helpful to point out where changes needed to be made, but labeled the issue "not a priority for us, but you're welcome to submit a PR". So I've gone ahead and done that.

Update: Looks like it will be in 3.16.3 due out around 1/23.

scivision commented 4 years ago

https://blog.kitware.com/cmake-3-16-3-available-for-download/ shows that Neil's support for NAG submodule was incorporated into CMake 3.16.3. Thanks!

certik commented 4 years ago

@zbeekman will be pleased that I am happy to recommend CMake 3.16.3 for stdlib. ;)

zbeekman commented 4 years ago

haha, well if we need it we need it. But, for the record I wasn't advocating for the latest cmake (unnecessarily...) just for a version I knew to be reliable.

scivision commented 4 years ago

NAG could require CMake 3.16.3 like:

if(CMAKE_Fortran_COMPILER_ID STREQUAL NAG)
  cmake_policy(VERSION 3.16.3)
endif()

while allowing other compilers to use older CMake

awvwgk commented 3 years ago

I can report a successful build with NAG 7.0 and CMake 3.16 after a minimal patch

diff --git a/src/stdlib_bitsets.fypp b/src/stdlib_bitsets.fypp
index ad52517..f1f204d 100644
--- a/src/stdlib_bitsets.fypp
+++ b/src/stdlib_bitsets.fypp
@@ -2006,7 +2006,7 @@ module stdlib_bitsets

     end interface operator(<=)

-    interface error_handler
+    interface
         module subroutine error_handler( message, error, status, &
             module, procedure )
             character(*), intent(in)           :: message
@@ -2015,7 +2015,7 @@ module stdlib_bitsets
             character(*), intent(in), optional :: module
             character(*), intent(in), optional :: procedure
         end subroutine error_handler
-    end interface error_handler
+    end interface

 contains

Unfortunately the tests still fail

The following tests FAILED:
     13 - stdlib_logger (Child aborted)
     15 - corr (Child aborted)
     16 - cov (Child aborted)
     17 - mean (Child aborted)
     18 - moment (Child aborted)
     19 - rawmoment (Child aborted)
     20 - var (Child aborted)
     21 - varn (Child aborted)

Test log: LastTest.log.gz

sakamoti commented 2 years ago

I can report a successful build with NAG 7.0 (Build 7061) and CMake 3.18.3 without any patch. (git 089f325) When build with NAG, we need -ieee=full option to enable all ieee arithmetics.

But some tests still fail.

The following tests FAILED:
         19 - median (Child aborted)
         30 - string_derivedtype_io (Failed)

Without -ieee=full option, test will fail like below because of floating overflow, invalid operand, and so on.

The following tests FAILED:
         16 - corr (Child aborted)
         17 - cov (Child aborted)
         18 - mean (Child aborted)
         19 - median (Child aborted)
         20 - moment (Child aborted)
         21 - rawmoment (Child aborted)
         22 - var (Child aborted)
         23 - varn (Child aborted)
         30 - string_derivedtype_io (Failed)
certik commented 2 years ago

@sakamoti thank you for testing it! Yes, we need to fix it.

awvwgk commented 2 years ago 
     30 - string_derivedtype_io (Failed)

This is a bug in the NAG compiler with UDDTIO (see https://github.com/fortran-lang/stdlib/issues/354#issuecomment-803546163). Haven't reported it yet because I currently don't have a license and therefore cannot open support requests.

sakamoti commented 2 years ago

I contacted NAG support around June 2021 with a similar error regarding UDDTIO chunk etc. I haven't checked to see if it is exactly the same as this issue (#354), but I think one of the compiler bugs related to UDTIO is resolved. (The compiler version at the time was nagfor7049)

Now (nagfor7061), stop in test_string_derivedtype_io.f90, line 27.

call check(len(string) == 21)

The return value of len(string) becomes 22 So, the check routine stops execution.

The return value of chunk read(unit,.... ,size=chunk,advance='no') seems to be compiler dependent because the handling of whitespace. This seems to be caused by the lack of an explicit definition in the fortran standard.

MuellerSeb commented 4 months ago

NAG 7.2 just released with full Fortran 2018 support: https://support.nag.com/nagware/np/r72_doc/relnotes.html