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

Build fails with gcc>=10 with type mismatch error #18

Closed
platipodium opened this issue Aug 20, 2020 · 10 comments · Fixed by #28
Closed

Build fails with gcc>=10 with type mismatch error #18

platipodium opened this issue Aug 20, 2020 · 10 comments · Fixed by #28
Assignees

Comments

@platipodium
Copy link
Member

GCC 10 enforces stricter type checking, leading to build failures such as

4027 |     call mpi_irecv(e2di_2t_data,1,e2di_2t_recv_type(i),nbrrank_2t(i),17,comm,e2di_2t_recv_rqst(i),ierr)
      |                   1
.
 4060 |     call mpi_irecv(e3d_2t_data,1,e3d_2t_tr_recv_type(i),nbrrank_2t(i),18,comm,e3d_2t_tr_recv_rqst(i),ierr)
      |                   2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
@platipodium
Copy link
Member Author

To temporarily fix this, read http://www.gnu.org/software/gcc/gcc-10/changes.html

Mismatches between actual and dummy argument lists in a single file are now rejected with an error. Use the new option -fallow-argument-mismatch to turn these errors into warnings; this option is implied with -std=legacy. -Wargument-mismatch has been removed.

So, if you're using cmake, add -DCMAKE_Fortran_FLAGS="-fallow-argument-mismatch"

@josephzhang8
Copy link
Member

josephzhang8 commented Aug 20, 2020 via email

@platipodium
Copy link
Member Author

This is a well-known problem with the current gcc and MPI. It occurs when generic interfaces receive (individually correct) subsequent calls with differing argument types (a technique frequently used in all MPI_XXX() functions. So calling MPI_Isend(... MPI_INTEGER). and later MPI_Isend ( .... MPI_REAL) will trigger this error/warning. I don't know how to fix this in our code. Could be fixed upstream. Best if we add default argument "-fallow-argument-mismatch" in gcc>=10 CMake builds.

@josephzhang8
Copy link
Member

josephzhang8 commented Jan 5, 2021 via email

@platipodium platipodium self-assigned this Jan 5, 2021
@platipodium platipodium changed the title Build fails with gcc10 Build fails with gcc>=10 with type mismatch error Jan 5, 2021
@platipodium
Copy link
Member Author

platipodium commented Jan 6, 2021

The solution is to add to CMakeList.txt the following code snippet

if (CMAKE_Fortran_COMPILER_ID STREQUAL "GNU")
  if (CMAKE_Fortran_COMPILER_VERSION VERSION_GREATER_EQUAL "10.0.0" )
    add_compile_options(-fallow-argument-mismatch)
  endif()
endif()

There are probably more concise ways to do this with CMake generator expressions. Haven't tested this yet but will add to git after testing.

@platipodium
Copy link
Member Author

From the gcc manual: https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html "Using this option is strongly discouraged. It is possible to provide standard-conforming code which allows different types of arguments by using an explicit interface and TYPE(*)."

But we cannot avoid this until it is fixed upstream (i.e. in the MPI implementations)

@josephzhang8
Copy link
Member

Thx Carsten. I'm not sure what exactly u wanted me to review but your fixes seem to be fine as they do not affect other compilers. Thx.

@platipodium
Copy link
Member Author

I'd like your opinion on

  1. whether we can tolerate the warnings issued with gcc 10 and 11 in the Metis (C) part of the compilation and go ahead with pushing
  2. whether anyone is knowledgeable enough with CMake to make the warning go away.

I would like to merge this PR rather soon as more and more people are now using updated compilers (e.g. when they are on the latest Ubuntu) and need this fixed.

@josephzhang8
Copy link
Member

HI Carsten:

Warning messages are in general fine with us. I assume using ifort would not produce those messages? We hardly use gcc. Thx.

@platipodium
Copy link
Member Author

I tested with ifort and it does not affect the ifort build at all. So I'll go ahead and merge!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants