[Gentoo] Failure to build MIOpen 6.1.2

[waltercool]

Trying to build MIOpen 6.1.2, I been getting few errors related to "numeric_limits is ambiguous"

Any ideas? Using

• Clang 18.1.8
• HIP 6.1.2
• Boost 1.86.0

Also tried with MIOpen 6.1.1 but same problem

Kind regards

build.log

[ppanchad-amd]

Hi @waltercool. Internal ticket has been created to investigate your issue. Thanks!

[sohaibnd]

Hi @waltercool, can you provide the steps you followed to build MIOpen as well as your OS and ROCm version. Also, do you have both llvm and rocm-llvm installed on your system?

[waltercool]

Hi @sohaibnd,

I'm using Gentoo Linux ebuild for MIOpen. It doesn't use rocm-llvm but system llvm (18.1.8), it uses rocm 6.1.2.

Kind regards.

[sohaibnd]

ROCm isn't officially supported on Gentoo Linux, see the docs for supported distributions.

However, one suggestion to fix your build is to try installing libstdc++ and including either the CMAKE_CXX_FLAGS="--stdlib=libc++" or CLANG_DEFAULT_CXX_STDLIB="libstdc++" cmake flags in your ebuild script.

[AngryLoki]

Hi @waltercool , there are a group of issues, which did not allow to build miopen-6.1.1

1. in miopen (injection into std namespace is implementation-defined in C++)
2. in libc++ in llvm-18 ([libc++] std::isfinite() does not accept convertible-to-float llvm/llvm-project#98816) - was fixed in llvm-19
3. in ROCm/half ([Issue]: inoptimal std::isfinite or no matching function for call to 'isfinite' half#16) - was split and addressed in llvm

Overall as rocm-6.1.x releases are tied to llvm-18, there is no fix there. For rocm-6.3.0 there is a patch in https://github.com/gentoo/gentoo/pull/39654/files#diff-755d79eba9586c9b3f9a49e2b63cc3659fdf95600c1c43ae69cf68f1ea9bb7c5 - I may try to submit it to upstream if I am able to set up pytorch with libc++.

Regarding building the system with libc++ and miopen with CMAKE_CXX_FLAGS="-stdlib=libstdc++", unfortunately this idea does not work. As soon as library exposes some C++ API (like boost), libc++ must be propagated to all dependencies (otherwise you encounter linking errors like https://wiki.gentoo.org/wiki/Clang#ld.lld:_error:_undefined_symbol:_..._std::_1::basic_string)

[CAHEK7]

@AngryLoki @waltercool
Actually, almost all those injections into std namespace must be hidden from the offline compiler build (hipcc) - they are intended to be used for hipRTC only builds where we don't have any kind of stdlib at all.
So it's not an injection, it's kind of stdlib for hipRTC and all the fixes for miopen_limits.hpp, miopen_type_traits.hpp are kind of irrelevant (and some sort of overcomplication), because that code must not be compiled by any compiler with the real standard library. For example, for non-hipRTC compilation miopen_limits.hpp must be just this single line

MIOpen/src/kernels/miopen_limits.hpp

Line 98 in 31be57b

#include <limits>

As for the adding new std::numeric_limits specializations (like bfloat16) - it's the way how to do deal with limits, it's not an implementation defined code.

[sohaibnd]

@waltercool @AngryLoki Can you try this change #3467 to see if it fixes the build issue?

[AngryLoki]

@sohaibnd , yes, it fixes the build issue with libc++ (and does not break anything in libstdc++ too). Thanks!

[waltercool]

When using your PR branch, I get the following issue:

CMake Error at /usr/lib64/cmake/composable_kernel/composable_kernelConfig.cmake:34 (include):
  include could not find requested file:

    /usr/lib64/cmake/composable_kernel/composable_kerneldevice_mha_operationsTargets.cmake
Call Stack (most recent call first):
  CMakeLists.txt:331 (find_package)

But applying your changes only into 6.1.2 works fine to me, thank you very much!

[AngryLoki]

@waltercool , failure to find composable_kerneldevice_mha_operationsTargets.cmake (when ck is compiled without non-gfx9xx targets) is caused by ROCm/composable_kernel#1646. There are patches in miopen 6.3.0 and composable-kernel 6.3.0 ebuilds in Gentoo (1, 2, 3)