Compilation errors on Vortex from mangling issue with cher, cher2, zher, and zher2

[MalachiTimothyPhillips]

I'm encountering a lot of compilation errors on Vortex relating to cher, cher2, zher, and zher2. There are no other compilation issues (see attached logfile).

It seems as if having the name of the method (e.g., HostBlas::cher

kokkos-kernels/blas/tpls/KokkosBlas_Host_tpl.hpp

Line 93 in 1b0a15f

static void cher(const char uplo, KK_INT n, const tAlpha alpha, const T *x,

) and the F77_BLAS_MANGLE (e.g.,

kokkos-kernels/blas/tpls/KokkosBlas_Host_tpl.cpp

Line 296 in 6f5db17

void F77_BLAS_MANGLE(cher, CHER)(const char*, KK_INT*, const float*,

) being the same can cause compilation issues on some platforms.

#2183 should resolve this issue

edit: forgot to include the compilation logfile. I have attached it now.
install_1.log

[ndellingwood]

@MalachiTimothyPhillips thanks for reporting and adding the PR! Can you share module/tpl/configuration details that exposed the issue?

[MalachiTimothyPhillips]

@MalachiTimothyPhillips thanks for reporting and adding the PR! Can you share module/tpl/configuration details that exposed the issue?

It was part of a SIERRA/spack Trilinos build on Vortex targeting cuda. Attached is the Spack cmake build output, which should include the CMake flags passed to Trilinos.
spack-build-01-cmake-out.txt

As per the modules, they are what you get if you module load sierra-devel on Vortex:

[malphil@vortex66 ~]$ module load sierra-devel

Lmod is automatically replacing "clang/ibm-16.0.6-cuda-11.2.0-gcc-8.3.1" with "gcc/8.3.1".

module list
Due to MODULEPATH changes, the following have been reloaded:
  1) spectrum-mpi/rolling-release

[malphil@vortex66 ~]$ module list

Currently Loaded Modules:
  1) base-gcc/8.3.1       3) git/2.29.1     5) gcc/8.3.1     7) spectrum-mpi/rolling-release   9) sierra-devel/nvidia
  2) StdEnv         (S)   4) python/3.8.2   6) cuda/11.2.0   8) sntools/master

  Where:
   S:  Module is Sticky, requires --force to unload or purge

I'll also note that we were not able to replicate this on our ascicgpu builds. I wonder if it's some funky combination including the power9 architecture?

[ndellingwood]

@MalachiTimothyPhillips thanks for sharing, that will help us to try and avoid a future slip. I haven't seen this in our nightly integration builds of Trilinos on Power9+V100, we use OpenBLAS for the blas and lapack tpls in those builds, and peaking at your cmake output it looks like your build uses netlib installs, maybe something odd happens within that difference?

[MalachiTimothyPhillips]

@ndellingwood I'm going to go ahead and mark this as closed since #2183 was merged in. Let me know if you want to create a separate issue to see if we can reproduce this compilation error.