build failure without kokkos

[prlw1]

Given a include/experimental/__p1673_bits/linalg_config.h file containing

#pragma once

/* #undef LINALG_ENABLE_ATOMIC_REF */
#define LINALG_ENABLE_BLAS
#define LINALG_ENABLE_CONCEPTS
/* #undef LINALG_ENABLE_KOKKOS */
/* #undef LINALG_ENABLE_KOKKOS_DEFAULT */

when trying to compile

#include <experimental/linalg>

int main() { }

with g++ 12.3.0 or 15.0.0 20240507 (experimental) by invoking

c++ -std=c++23 -I/usr/src/local/stdBLAS/include -I/usr/src/local/mdspan/include -c trivial.cc

(or c++20 or c++26 for 15.0.0), I see many errors, which first makes me wonder: is the above meant to work?

Some seem to be related to is_line_exec_v such as:

/usr/src/local/stdBLAS/include/experimental/__p1673_bits/blas1_givens.hpp:106:16: error: ‘is_inline_exec_v’ is not a member of ‘Kokkos::Experimental::__p1673_version_0::linalg::impl’

or

/usr/src/local/stdBLAS/include/experimental/__p1673_bits/blas1_linalg_swap.hpp:127:10: error: ‘is_inline_exec_v’ was not declared in this scope

[mhoemmen]

Thanks for reporting this! We normally test by generating that file via CMake options, not by changing it directly. I generally always build without Kokkos enabled. Are you able to reproduce this issue by building the tests with CMake?

[prlw1]

Somewhat unsurprisingly, no change when using cmake, given that the cmake generated file is:

$ cat /tmp/include/experimental/__p1673_bits/linalg_config.h
#pragma once

/* #undef LINALG_ENABLE_ATOMIC_REF */
#define LINALG_ENABLE_BLAS
#define LINALG_ENABLE_CONCEPTS
/* #undef LINALG_ENABLE_KOKKOS */
/* #undef LINALG_ENABLE_KOKKOS_DEFAULT */

Just for the record:

    1 git clone https://github.com/kokkos/stdBLAS.git
    2 cd stdBLAS
    3 cmake -DLINALG_ENABLE_TESTS=OFF -DLINALG_ENABLE_EXAMPLES=OFF -S . -B build
    4 cmake --build build
    5 cmake --install build --prefix /tmp

then

c++  -O2 -g -Werror -std=c++20     -I/tmp/include -I/usr/src/local/mdspan/include  -c    trivial.cc

as per above.

[prlw1]

Just tried clang 17.0.5

$ clang++  -O2 -g -Werror -std=c++20     -I/tmp/include -I/usr/src/local/mdspan/include  -c    trivial.cc 2>&1 | more
In file included from trivial.cc:1:
In file included from /tmp/include/experimental/linalg:60:
/tmp/include/experimental/__p1673_bits/blas1_givens.hpp:106:10: error: no template named 'is_inline_exec_v' in namespace 'Kokkos::Experimental::linalg::impl'; did you mean 'MDSPAN_IMPL_STANDARD_NAMESPACE::MDSPAN_IMPL_PROPOSED_NAMESPACE::linalg::impl::is_inline_exec_v'?
  106 |     && ! impl::is_inline_exec_v<Exec>
      |          ^~~~~~~~~~~~~~~~~~~~~~
      |          MDSPAN_IMPL_STANDARD_NAMESPACE::MDSPAN_IMPL_PROPOSED_NAMESPACE::linalg::impl::is_inline_exec_v
/tmp/include/experimental/__p1673_bits/linalg_execpolicy_mapper.hpp:24:41: note: 'MDSPAN_IMPL_STANDARD_NAMESPACE::MDSPAN_IMPL_PROPOSED_NAMESPACE::linalg::impl::is_inline_exec_v' declared here
   24 | template<class T> inline constexpr bool is_inline_exec_v = is_inline_exec<T>::value;

So is it an mdspan version problem?

The -I/usr/src/local/mdspan/include above contains

commit a9c54ccd8254cc3d159fdf2adf650dca4e048c97 (HEAD -> stable, origin/stable, origin/HEAD)
Author: Mark Hoemmen <mhoemmen@users.noreply.github.com>
Date:   Fri May 3 11:11:37 2024 -0600

I note that invoking cmake in stdBLAS always shows

-- No installed mdspan found, fetching from Github

try as might to point it to the above - these are meant to be header-only libraries?

[prlw1]

The clang error message gave the clue. Adding the mdspan include to trivial.cc fixed it:

#include <mdspan/mdspan.hpp>
#include <experimental/linalg>

int main() { }

as mdspan.hpp defines MDSPAN_IMPL_STANDARD_NAMESPACE and friends.

A priori linalg should be including a sensible mdspan header file, but at least I have a work around.

[prlw1]

(clicked Close with comment but still open...

[mhoemmen]

@prlw1 Would you like me to reopen this issue?

Btw, I vaguely recall fixing this issue, at least in a PR, but I might not have gotten any humans to merge it for me. See e.g., PR https://github.com/kokkos/stdBLAS/pull/256 (which has been sitting around for a while).

@dalg24 @crtrott does this look familiar? I haven't had this problem for a while and I suspect it's either been fixed in the main branch, or in one of my PRs that y'all haven't merged yet.