Testing Fujitsu support

Development
1

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
2

Cc: @Sreepathi_Sarat

1 Like
3

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.

4

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

    "/opt/FJSVmxlang/GM-2.0.0-07/bin/FCCpx"

  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 2.0.0.7

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.

5

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.

6

Regarding cmake aarch64 binary in releases and cmake cross build (host: x86_64, target: aarch64)

7

How does CMake works please

Thanks

8

@QueenBillions Please start your own topic for questions. That said, the information you provided is not enough for us to answer since that is a large topic best handled by the documentation at the start.

9

Hi @chuckatkins - thanks so much for putting this together. Like @Sreepathi_Sarat I’ve been using your branch to build some things on Fugaku.

I’ve found in one case a build failed because of whitespace around the LAPACK_LIBRARIES variable. I believe this is specific to the Fujitsu CMake branch as the variable is printed as " -SSL2" (looks like a leading space to me).

I had a look around your branch but couldn’t find a place where this space might be introduced. Have you got any ideas?

In the mean time, I silenced this by adding string(STRIP ${LAPACK_LIBRARIES} LAPACK_LIBRARIES) to my CMakeLists.txt.

Thanks!

10

Hi @chuckatkins, thanks so much for supporting Fujitsu compiler.
I’m working on development of Fujitsu compiler.
Do you have any plans to re-open https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5646 ?
If you do not plan to re-open, I’m thinking of making a new merge request by referring to your merge request.

11

I closed that MR according to the Review Workflow’s Expiry Convention. @chuckatkins should re-open it once external feedback indicates it is ready, or earlier to make updates based on the unresolved comments in the MR itself.

12

@samhatfield @chuckatkins https://gitlab.kitware.com/yutsumi/cmake/-/commit/374d62c524846d81d8f66b4f222ac300ab55f178 fixes the problem that LAPACK_LIBRARIES includes an unnecessary whiltespace.

13

Thanks @yutsumi! I will try it on Fugaku.

Edit: it works great, thanks.

14

Hi @brad.king , as Fujitsu, we want to avoid the delay of Fujitsu compiler support for CMake.
Can I create the new MR taking over the work of @chuckatkins ?

15

@yutsumi yes, please go ahead.

If possible, let’s take the addition in smaller steps. Please start with the support for the modern forms of the compiler (4.x for arm?). IIUC that part of Chuck’s work is more mature. Once that is integrated then we can consider the older compilers in a separate merge request.

16

@brad.king Thanks for replying. I created the new MR which supports version 4.0+. https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5954