Workarounds for NAG

[certik]

For NAG 6.2 and the latest master (f300f4a):

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)
-  target_sources(fortran_stdlib PRIVATE f18estop.f90)
-else()
-  target_sources(fortran_stdlib PRIVATE f08estop.f90)
-endif()
-
 add_subdirectory(tests)
 
 install(TARGETS fortran_stdlib
diff --git a/src/stdlib_experimental_error.f90 b/src/stdlib_experimental_error.f90
index 3d932d6..b35083b 100644
--- a/src/stdlib_experimental_error.f90
+++ b/src/stdlib_experimental_error.f90
@@ -3,16 +3,46 @@ use, intrinsic :: iso_fortran_env, only: stderr=>error_unit
 implicit none
 private
 
-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 <character>" 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
+  select case (code)
+  case (1)
+    error stop 1
+  case (2)
+    error stop 2
+  case (77)
+    error stop 77
+  case default
+    write(stderr,*) 'ERROR: code ',code,' was specified.'
+    error stop
+  end select
+else
+  error stop
+endif
+end subroutine
 
 subroutine assert(condition, code)
 ! If condition == .false., it aborts the program.

2. Can't find modules compiled before (fixed by Update CMakeLists handling of .mod files #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]

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]

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

[scivision]

Yes NAG 7.0 was the first to support submodule

[certik]

With the latest master (dc7e49b) 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]

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]

-f2018 is the option we need

[nncarlson]

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 [email protected], 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]

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]

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]

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]

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]

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]

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

[zbeekman]

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]

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]

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]

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]

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

[awvwgk]

     30 - string_derivedtype_io (Failed)

This is a bug in the NAG compiler with UDDTIO (see #354 (comment)). Haven't reported it yet because I currently don't have a license and therefore cannot open support requests.

[sakamoti]

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]

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