Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workarounds for NAG #108

Open
certik opened this issue Jan 13, 2020 · 21 comments
Open

Workarounds for NAG #108

certik opened this issue Jan 13, 2020 · 21 comments
Labels
compiler: nagfor Specific to NAG Fortran compiler

Comments

@certik
Copy link
Member

certik commented Jan 13, 2020

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.
  1. 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
Copy link
Member

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
Copy link
Member

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

@scivision
Copy link
Member

Yes NAG 7.0 was the first to support submodule

@certik
Copy link
Member Author

certik commented Jan 15, 2020

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
Copy link
Member

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
Copy link
Member

-f2018 is the option we need

@nncarlson
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

nncarlson commented Jan 15, 2020

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
Copy link
Member

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
Copy link
Member Author

certik commented Jan 22, 2020

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

@zbeekman
Copy link
Member

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
Copy link
Member

scivision commented Jan 27, 2020

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
Copy link
Member

awvwgk commented Jan 16, 2021

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
Copy link
Contributor

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
Copy link
Member Author

certik commented Oct 16, 2021

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

@awvwgk
Copy link
Member

awvwgk commented Oct 16, 2021

     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
Copy link
Contributor

sakamoti commented Oct 17, 2021

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler: nagfor Specific to NAG Fortran compiler
Projects
None yet
Development

No branches or pull requests

8 participants