Fix ambiguous template special. errors with GCC 7+

[JM1]

Fix "ambiguous template specialization" errors like below with GCC 7 and later. #254

  include/El/blas_like/level1/Copy.hpp:562:27: error: ambiguous template specialization 'Copy<>' for 'void El::Copy(const El::SparseMatrix<El::Complex<double> >&
  , El::SparseMatrix<El::Complex<double> >&)'
     EL_EXTERN template void Copy \
                             ^~~~
  include/El/macros/Instantiate.h:54:27: note: in expansion of macro 'PROTO'
   # define PROTO_COMPLEX(T) PROTO(T)
                             ^~~~~
  include/El/macros/Instantiate.h:60:31: note: in expansion of macro 'PROTO_COMPLEX'
   # define PROTO_COMPLEX_DOUBLE PROTO_COMPLEX(Complex<double>)
                                 ^~~~~~~~~~~~~
  include/El/macros/Instantiate.h:120:1: note: in expansion of macro 'PROTO_COMPLEX_DOUBLE'
   PROTO_COMPLEX_DOUBLE
   ^~~~~~~~~~~~~~~~~~~~
  include/El/blas_like/level1/Copy.hpp:259:6: note: candidates are: 'template<class T> void El::Copy(const El::SparseMatrix<U>&, El::SparseMatrix<U>&)'
   void Copy( const SparseMatrix<T>& A, SparseMatrix<T>& B )
        ^~~~
  include/El/blas_like/level1/Copy.hpp:267:6: note:                 'template<class S, class T, class> void El::Copy(const El::SparseMatrix<U>&, El::SparseMatrix
  <V>&)'
   void Copy( const SparseMatrix<S>& A, SparseMatrix<T>& B )
        ^~~~

EDIT: Old commit can be found here.

[poulson]

Hi Jakob,

Thanks for putting this together!

Is there an explanation for the need for MPI_PROTO_COMPLEX(T) instead of MPI_PROTO(Complex<T>)?

[JM1]

Take for example function Reduce (include/El/core/imports/mpi.hpp) with these two overloads:

template<typename Real, typename=EnableIf<IsPacked<Real>>>
void Reduce
( const Real* sbuf, Real* rbuf, int count, Op op, int root, Comm comm )
EL_NO_RELEASE_EXCEPT;

template<typename Real, typename=EnableIf<IsPacked<Real>>>
void Reduce
( const Complex<Real>* sbuf, Complex<Real>* rbuf, int count, Op op,
int root, Comm comm ) EL_NO_RELEASE_EXCEPT;

Macro MPI_PROTO(Complex<float>) (src/core/imports/mpi.cpp) instantiates Reduce with

template void Reduce
  ( const Complex<float>* sbuf, Complex<float>* rbuf, int count, Op op, int root, Comm comm )
  EL_NO_RELEASE_EXCEPT;

GCC 8 throws ambiguous template specialization errors because it cannot decide which candidate it should choose. Previous GCC revisions and Clang up to 6.0 (later revisions not tested) do compile this code as expected though.

To help GCC I explicitly instantiated those function templates in src/core/imports/mpi.cpp, e.g.

 template void Reduce<T> ...

But in order to instantiate the right Complex<Real> function overload the explicit template instantiations differ for some functions, e.g.

template void Reduce<T>
  ( const Complex<T>* sbuf, Complex<T>* rbuf, int count, Op op, int root, Comm comm )
  EL_NO_RELEASE_EXCEPT;

vs.

template void Reduce<Complex<T>>
  ( const Complex<T>* sbuf, Complex<T>* rbuf, int count, int root, Comm comm )
  EL_NO_RELEASE_EXCEPT;

Here it's Reduce<T> and there its Reduce<Complex<T>>. Therefore I had to clone and adapt the MPI_PROTO macro.

[poulson]

Thanks for the explanation! Though this sounds like a bug in GCC 8 (that is worth working around).

Is it not possible to use a chain of two macros to avoid hundreds of lines of redundancy between MPI_PROTO and MPI_PROTO_COMPLEX?

Also, the OpenMP include seems unrelated to this CL.

[JM1]

A chain of macros would definitely be better. Any idea how this could look like?

I removed the OpenMP commit. Sorry, my fault.

[poulson]

Separating out the routines with equivalent definitions for both real and complex into a MPI_PROTO_BASE macro then calling it from MPI_PROTO and MPI_PROTO_COMPLEX would help. (And, at this point, renaming MPI_PROTO to MPI_PROTO_REAL makes sense).

[JM1]

Of course! 🙈😅 I'm on it..

[JM1]

Current draft is here.

[balay]

We are seeing this issue with petsc & v0.87.7

Would it be possilbe to have this fix on branch 0.87?

[poulson]

Thank you for the PR! The draft looks good and I think merging into 0.87 would be a great idea.

[balay]

BTW: this patch applies cleanly to 0.87 branch - and the build error goes away with it

[my test box is fedora 28 - with gcc version 8.1.1]

[JM1]

I will open a PR for this draft commit rebased on master (build logs) once #263 is done.

[poulson]

FWIW, I just merged said commit despite it breaking the new build tests.

[benson31]

I filed a bug report with GCC a while ago. It only seems to affect explicit template instantiation, not implicit instantiation. Last time I checked, GCC's development branch still won't accept this code, but that was last week.