Testing Fujitsu support

I’ve got what I believe to be a good implementation for supporting the Fujitsu C, C++, and Fortran compilers in both Trad and Clang modes and in both the SPARC and ARM environments. If this is a platform you use then please give it a go and let me know what issues you encounter.

See the fujitsu-compiler-support branch on https://gitlab.kitware.com/chuck.atkins/cmake.git

1 Like

Cc: @Sreepathi_Sarat

1 Like

I made a test on a complex Fortran/C program using OpenMP and MPI, the cross-compilation for ARM architecture works with compiler version 4.3.1, either on Trad mode or on Clang mode. I outlined two typos on the MR discussion thread.

For the same complex program, using the old compiler version 2.0.0 targeting the SPARC architecture, and the version 1.2.0 targeting the x86_64 architecture, it works as well.

I first got the following error at configure time:

-- Check for working CXX compiler: /opt/FJSVmxlang/GM-2.0.0-07/bin/FCCpx
-- Check for working CXX compiler: /opt/FJSVmxlang/GM-2.0.0-07/bin/FCCpx - broken
CMake Error at /home/z/z592/cmake-3.20b-Linux-x86_64/share/cmake-3.19/Modules/CMakeTestCXXCompiler.cmake:59 (message):
  The C++ compiler


  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/z/z592/fastar/fastar_feature_cmake/build/fujitsu/sparc/tmp/CMakeFiles/CMakeTmp

    Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_49946/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_49946.dir/build.make CMakeFiles/cmTC_49946.dir/build
    gmake[1]: Entering directory `/fefs/home/z/z592/fastar/fastar_feature_cmake/build/fujitsu/sparc/tmp/CMakeFiles/CMakeTmp'
    Building CXX object CMakeFiles/cmTC_49946.dir/testCXXCompiler.cxx.o
    /opt/FJSVmxlang/GM-2.0.0-07/bin/FCCpx    -o CMakeFiles/cmTC_49946.dir/testCXXCompiler.cxx.o -c /home/z/z592/fastar/fastar_feature_cmake/build/fujitsu/sparc/tmp/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
    Linking CXX executable cmTC_49946
    /fefs/home/z/z592/cmake-3.20b-Linux-x86_64/bin/cmake -E cmake_link_script CMakeFiles/cmTC_49946.dir/link.txt --verbose=1
    /opt/FJSVmxlang/GM-2.0.0-07/bin/FCCpx -rdynamic CMakeFiles/cmTC_49946.dir/testCXXCompiler.cxx.o -o cmTC_49946
    FCCpx: warning: -rdynamic without -Xg is ignored because of unrecognized option to the compiler.
    FCCpx: warning: -rdynamic is unrecognized option. This option is passed to the linker.
    /opt/FJSVmxlang/GM-2.0.0-07/bin/../util/bin/sparc64-unknown-linux-gnu-ld: bad -rpath option
    gmake[1]: *** [cmTC_49946] Error 1
    gmake[1]: Leaving directory `/fefs/home/z/z592/fastar/fastar_feature_cmake/build/fujitsu/sparc/tmp/CMakeFiles/CMakeTmp'
    gmake: *** [cmTC_49946/fast] Error 2

I forced the compiler to behave as GCC command line interface with:

FC=frt CC="fcc -Xg" CXX="FCC -Xg" cmake ..

The -Xmode argument is a feature that disappeared in the newer version of the compiler. It was documented to specify the mode of language specification to be interpreted by the compiler, but it is obscure for me and it has other side effects. With -Xa, the default mode, it is said to enforce language specifications as defined in the ANSIC/C99/C++03 standard (which is weird, as the compiling standard can be set elsewhere with -std), plus implementation specific extensions. With -Xc, it is said to enforce a standard strictly without telling which one (maybe the one that can be set with -std). With -Xg, it is said to enforce GNU extensions of a standard (maybe on top of the standard set with -std), but also to enable GCC-like options in the command line interface. I remember Fujitsu helpdesk could not help me much about this argument.

Using the last mode makes everything to work. Maybe it would be good to force this mode by default for this version of the compiler?

On the other hand, MPI detection did not work for SPARC architecture, even when using the toolchain file specifying wrapper names, or setting the MPI_HOME variable. This is odd, as it is perfectly detected for the x86_64 architecture, and the two compilers have the same directories structure.

Another minor thing I got with the old compilers is that the version of the Fortran compiler cannot be fetched:

-- The Fortran compiler identification is Fujitsu 0.0.0
-- The C compiler identification is Fujitsu

There are actually 3 problems behind this:

  1. The documented option to fetch version is -V (-v is not available for the old Fortran compiler);
  2. For the old compiler, the version string is not the same for the Fortran and for the C/C++ compilers (Fujitsu Fortran Driver Version 2.0.0 vs Fujitsu C/C++ Compiler Driver Version 2.0.0), whereas it is the same for the new compiler (Fujitsu Fortran Compiler 4.3.1 tcsds-1.2.29 vs Fujitsu C/C++ Compiler 4.3.1 tcsds-1.2.29);
  3. The function CMAKE_DETERMINE_COMPILER_ID is not called for the Fortran compiler.

I proposed some improvements in the MR.

Thanks @chuckatkins. This is much appreciated.

I built this branch and tested it with Fujitsu compilers (version 4.3.1) on Fugaku, the A64FX based Japanese supercomputer (https://www.top500.org/system/179807/)

I built several climate applications, both Fortran and and C++ codes successfully. The CMake system was able to detect the SSL2 math libraries as well.