This is an archive of the discontinued LLVM Phabricator instance.

[test-suite] SPEC2017 CPU ROMS floating point tests.
ClosedPublic

Authored by naromero77 on Feb 15 2021, 9:42 PM.

Details

Summary
  • Helper macro for managing intermediate dependencies on Fortran modules.
  • Add SPEC2017 CPU ROMS floating point tests.
  • Emit warning message about using recent Ninja version.

Diff Detail

Repository
rT test-suite

Event Timeline

naromero77 created this revision.Feb 15 2021, 9:42 PM
naromero77 requested review of this revision.Feb 15 2021, 9:42 PM
naromero77 retitled this revision from Helper macro for managing intermediate dependencies on Fortran modules. to [test-suite] SPEC2017 CPU ROMS floating point tests..Feb 15 2021, 9:49 PM
naromero77 edited the summary of this revision. (Show Details)
Meinersbur added a comment.EditedFeb 16 2021, 10:47 AM

As far as I know, cmake detect module dependency itself, which would make speccpu2017_add_mod unnecessary.

I applied the patch locally and change the compilation part to just speccpu2017_add_executable() and it still compiles.

External/SPEC/CFP2017rate/554.roms_r/CMakeLists.txt
49

Leftover fotonik3d

370

Consider using target_link_libraries (https://cmake.org/cmake/help/latest/command/target_link_libraries.html#linking-object-libraries) for linking object libraries.

The tutorial uses generator expressions ($<TARGET_OBJECTS:${PROG}_Fortran_MOD_4>) which are missing here?

External/SPEC/SpecCPU2017.cmake
342 ↗(On Diff #323880)

[typo] heirarchy

As far as I know, cmake detect module dependency itself, which would make speccpu2017_add_mod unnecessary.

It is not really clear from the CMake docs that it can figure out complex module dependencies without intermediary targets. Searching online, it looks like many Fortran-centric projects have come up with different solutions.

If the name of the macro is the issue, we can change it to something else besides speccpu2017_add_mod

I applied the patch locally and change the compilation part to just speccpu2017_add_executable() and it still compiles.

Does it work for you if you at make -j 10 or the equivalent with ninja? It is definitely failing to build for me when I increase the number of parallel builds due to missing .mod files.

As far as I know, cmake detect module dependency itself, which would make speccpu2017_add_mod unnecessary.

I applied the patch locally and change the compilation part to just speccpu2017_add_executable() and it still compiles.

External/SPEC/CFP2017rate/554.roms_r/CMakeLists.txt
370

Consider using target_link_libraries (https://cmake.org/cmake/help/latest/command/target_link_libraries.html#linking-object-libraries) for linking object libraries.

The downside is that we would have to bump the minimum CMake requirement to 3.12 and right now the minimum requirement is 3.4.3. I am concerned that it could break any buildbots out there using older CMake versions.

The tutorial uses generator expressions ($<TARGET_OBJECTS:${PROG}_Fortran_MOD_4>) which are missing here?

I think you are right. I should also change it for the other add_dependencies(..) statements.

LLVM required cmake 3.13.4, I think we can bump the version for llvm-test-suite as well.

  • Run ROMS test out of run directory.
  • Revert "Helper macro for managing intermediate dependencies on Fortran modules."
  • Add warning about CMAKE_GENERATORS that are not Ninja.
  • Fix comment to reflect ROMS test.
  • Intermediate target dependencies are not needed when using Ninja.

LLVM required cmake 3.13.4, I think we can bump the version for llvm-test-suite as well.

I will submit a separate phabricator patch.

naromero77 edited the summary of this revision. (Show Details)Feb 17 2021, 9:26 PM

Btw, I found the following at https://blog.kitware.com/fortran-for-cc-developers-made-easier-with-cmake/ (from 2012):

Building Fortran in the correct order

Fortran 90 supports a module system that allows Fortran to import and export modules from source files. This adds a huge complexity to the build problem as the Fortran code must be compiled in the correct order to ensure that module files are available for import after they have been exported, but before they are imported. To accomplish this, CMake contains a full Fortran parser. When CMake computes depend information at build time, it will parse all of the Fortran sources. The parser determines which files are producers and which files are the consumers, and then it uses that information to order the build. There is no user interaction with CMake in order to use this feature. It is only used with Makefile builds. The Intel VS Fortran IDE plugin handles this itself.

CMakeLists.txt
11

Some generators have spaces in their name ("UNIX Makefiles"), I recommend using quotes.

The syntax of STREQUAL is <variable|string> STREQUAL <variable|string>, so

if(NOT CMAKE_GENERATOR STREQUAL "Ninja")

should work too.

13–14

When I tried the "UNIX Makefile" generator, it did not even build sequentially.

Could you add that to the message that this is a warning about the Generator/-G switch? A user who does not know about what ninja is might be confused by this message.

naromero77 edited the summary of this revision. (Show Details)
  • Improved warning message for CMAKE_GENERATOR.
This revision is now accepted and ready to land.Feb 18 2021, 9:58 PM
This revision was automatically updated to reflect the committed changes.