[HIP][hipconfig] hipconfig prints bogus "-9999" suffix when HIP_VERSION_GITHASH is empty

[talhaHavadar]

Summary

hipconfig --version prints a spurious -9999 build-number suffix when the
HIP runtime's version file (<HIP_PATH>/share/hip/version) contains an
empty HIP_VERSION_GITHASH= line. -9999 is HIP_BASE_VERSION_DEFAULT
leaking into user-visible output, not a real value.

This trips downstream consumers that parse hipconfig --version — e.g.
rocBLAS's Tensile version-check aborts on the resulting string (see
ROCm/rocm-libraries#7945).

Reproduction

Shape 1 — via distro packages (Ubuntu)

# apt install hipcc-rocm
# hipconfig --version
7.2.53211-9999

libamdhip64-dev (src:rocm-hipamd) installs
/usr/share/hip/version with HIP_VERSION_GITHASH= (empty), because CMake
couldn't populate it — the source tarball has no .git/. hipcc then falls
back to the "9999" sentinel.

Shape 2 — portable (any distro)

mkdir -p /tmp/fakehip/share/hip
cat > /tmp/fakehip/share/hip/version <<'END'
HIP_VERSION_MAJOR=7
HIP_VERSION_MINOR=1
HIP_VERSION_PATCH=52801
HIP_VERSION_GITHASH=
END
HIP_PATH=/tmp/fakehip hipconfig --version
# → 7.1.52801-9999

Expected: 7.1.52801 (no bogus suffix).

Root cause

Two interacting behaviours in amd/hipcc/src/:

• hipBin_util.h:170-174 (parseConfigFile): after splitting on =,
  std::getline(is_line, value) fails on a line with an empty tail
  (HIP_VERSION_GITHASH=), so the key is not inserted into the map.
• hipBin_base.h:418-422 (readHipVersion): the missing key then falls
  back to HIP_BASE_VERSION_DEFAULT ("9999", defined at
  hipBin_base.h:55), and the string is unconditionally concatenated as
  MAJOR.MINOR.PATCH-GITHASH.

Net effect: an empty githash — which is a legitimate "not a git build"
answer from the runtime's CMake — becomes the string "-9999" in
hipconfig output.

Impact

• Any environment where the HIP runtime is packaged from a tarball (no
  .git/ at build time) ships an empty HIP_VERSION_GITHASH. That
  includes Debian/Ubuntu, and likely other distros doing tarball builds.
• Downstream parsers that assume the version output is
  MAJOR.MINOR.PATCH[-hash] with a real hash break. Concrete case:
  rocBLAS's TensileCreateLibrary (shared/tensile/Tensile/Common.py)
  aborts with ValueError: invalid literal for int() with base 10: '9999'
  when trying to convert the version components. See
  [rocBLAS][Bug]: TensileCreateLibrary fails to parse hipconfig --version output starting with "HIP version:" prefix rocm-libraries#7945 for the failing build path.
• Cosmetic-but-misleading for anyone reading hipconfig --version output
  directly.

Suggested fix

Treat an absent/empty HIP_VERSION_GITHASH as "no build hash" rather than
falling back to the shared "9999" sentinel. Keep the sentinel for
MAJOR/MINOR/PATCH, where a missing value really is an installation error
and the visible 9999.9999.9999 is a useful signal.

--- a/amd/hipcc/src/hipBin_base.h
+++ b/amd/hipcc/src/hipBin_base.h
@@ -417,9 +417,11 @@ void HipBinBase::readHipVersion() {
                         HIP_BASE_VERSION_DEFAULT);
     hip_version_githash = hipBinUtilPtr_->readConfigMap(
                         hipVersionMap, "HIP_VERSION_GITHASH",
-                        HIP_BASE_VERSION_DEFAULT);
+                        "");
     hipVersion = hip_version_major + "." + hip_version_minor +
-                 "." + hip_version_patch  + "-" + hip_version_githash;
+                 "." + hip_version_patch;
+    if (!hip_version_githash.empty())
+      hipVersion += "-" + hip_version_githash;
     hipVersion_ = hipVersion;
   }
 }

Verified with both repro shapes above: output degrades to
7.1.52801 when the hash is unavailable, and remains
7.1.52801-abc1234 when the runtime file has a real hash. Happy to open a
PR against amd-staging if the direction is acceptable.

Environment

• Distro: Ubuntu 26.10 (stonking), amd64
• hipcc-rocm: 7.2.14~git20260701.cd7668d75d+dfsg2-0ubuntu2
• libamdhip64-dev: 7.1.0-0ubuntu2
• ROCm/llvm-project reference: amd-staging HEAD as of filing

Related

• [rocBLAS][Bug]: TensileCreateLibrary fails to parse hipconfig --version output starting with "HIP version:" prefix rocm-libraries#7945 — original report from the rocBLAS/Tensile side;
  the Tensile-side workaround there and this hipconfig-side fix are
  complementary (Tensile becomes robust to any label, hipconfig stops
  emitting the misleading suffix in the first place).

Reported while packaging llvm-toolchain-rocm for Debian/Ubuntu.

[lamb-j]

@david-salinas thoughts on adding the suggested fix as a temporary patch while we work on removing hipconfig?

[david-salinas]

@david-salinas thoughts on adding the suggested fix as a temporary patch while we work on removing hipconfig?

Do we know if changing this in hipconfig would break anything (math_libs or frameworks) downstream - like is anyone depending on the "-9999" ?

If not, I'm ok with this change. But we are going to be removing calls to hipconfig soon from TheRock components. So this change would disappear anyway. I'd suggest we just change rocBLAS to get the version info from /opt/rocm-x.y.z/share/hip/version. But if it is easier/smoother for rocBLAS to change hipconfig now, sure, as long as is doesn't break anyone else.

[talhaHavadar]

In which version we are planning to remove hipconfig in the next release you mean?

[david-salinas]

In which version we are planning to remove hipconfig in the next release you mean?

Ideally it would be in the next release. But there are a fair amount of (small) changes needed, especially for removing hipconfig. In fact one of those changes would be to have all of the downstream components (math libraries and frameworks), switch from using hipconfig to get HIP version, and just read the version file the HIP RT produces (that hipconfig reads). That would be one of the needed (smallish) changes. I'm actually working on putting those changes together.