You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some RCCL-tests require a Message Passing Interface (MPI) implementation to run in a multi-node set up. These tests get enabled through USE_MPI , which is set via THEROCK_ENABLE_MPI as soon as #1283 has landed.
We eventually want to vendor Open MPI as an MPI implementation with TheRock.
@marbre are you planning to use theRock build of flang/clang/clang++ to build OpenMPI ?
@ronlieb there are no concrete plans to build this via clang/flang. The PR bringing in Open MPI is #2599 which does not use clang/flang.
OpenMPI has fortran interfaces and exports "mod" files that are unfortuantely , NOT portable across compiler vendors and for that matter versions of the compiler. So if you build OpenMPI with gfortran, it will be unusable to any HPC Fortran application built with flang that tries to use the OpenMPI from 2599.
@ScottTodd has had a draft pr for a long time that moves third-party/sysdeps to the top level and makes it the only thing that builds with the system compiler. Then regular third-party libraries would build with ROCm's llvm. This would also let them build with sanitizers, etc which have a similar non portability between toolchains.
Currently there is a dep ordering issue that forbids all of third-party from building with the rocm llvm (because the compiler depends on sysdeps).
This could be done with less dramatic surgery easily by just changing the top level add subdirectories to:
third-party/sysdeps
base
compiler
third-party
core
...
Then third-party libs can build with the rocm llvm toolchain without physically moving anything.
I would like rocprofiler tests broken into their own subproject vs needing to block building of the core rocprofv3 infra on even more deps. That project should not be monolithic like that and it's already a tax on the critical path.
Yep, #2045 reorders the build graph such that third-party libraries can build with ROCm's LLVM. It currently only switches therock-spdlog and it does not actually move third-party/sysdeps to the top level in the repository. We can take it a step further and make those changes too.
@marbre are you planning to use theRock build of flang/clang/clang++ to build OpenMPI ?
@ronlieb there are no concrete plans to build this via clang/flang. The PR bringing in Open MPI is #2599 which does not use clang/flang.
OpenMPI has fortran interfaces and exports "mod" files that are unfortuantely , NOT portable across compiler vendors and for that matter versions of the compiler. So if you build OpenMPI with gfortran, it will be unusable to any HPC Fortran application built with flang that tries to use the OpenMPI from 2599.
The request for now was to ship Open MPI for rccl and not to ship the fortran inferfaces and exports but with what Stella and Scott elaborated on, we technically can.
Open MPI, non ROCM-aware and without Fortran support, has been landed to TheRock. Closing the issue accordingly. If additional requirements arise, we can file new, more specific issues.
Activity
[-]MPI is required for RCCL-tests[/-][+]Add Open MPI to TheRock[/+]Fix issue link in README.md (#1480)
ronlieb commentedon Feb 13, 2026
@marbre are you planning to use theRock build of flang/clang/clang++ to build OpenMPI ?
marbre commentedon Feb 16, 2026
@ronlieb there are no concrete plans to build this via clang/flang. The PR bringing in Open MPI is #2599 which does not use clang/flang.
ronlieb commentedon Feb 16, 2026
OpenMPI has fortran interfaces and exports "mod" files that are unfortuantely , NOT portable across compiler vendors and for that matter versions of the compiler. So if you build OpenMPI with gfortran, it will be unusable to any HPC Fortran application built with flang that tries to use the OpenMPI from 2599.
stellaraccident commentedon Feb 16, 2026
@ScottTodd has had a draft pr for a long time that moves third-party/sysdeps to the top level and makes it the only thing that builds with the system compiler. Then regular third-party libraries would build with ROCm's llvm. This would also let them build with sanitizers, etc which have a similar non portability between toolchains.
Currently there is a dep ordering issue that forbids all of third-party from building with the rocm llvm (because the compiler depends on sysdeps).
This could be done with less dramatic surgery easily by just changing the top level add subdirectories to:
Then third-party libs can build with the rocm llvm toolchain without physically moving anything.
I would like rocprofiler tests broken into their own subproject vs needing to block building of the core rocprofv3 infra on even more deps. That project should not be monolithic like that and it's already a tax on the critical path.
ScottTodd commentedon Feb 16, 2026
Yep, #2045 reorders the build graph such that third-party libraries can build with ROCm's LLVM. It currently only switches
therock-spdlogand it does not actually move third-party/sysdeps to the top level in the repository. We can take it a step further and make those changes too.marbre commentedon Feb 16, 2026
The request for now was to ship Open MPI for rccl and not to ship the fortran inferfaces and exports but with what Stella and Scott elaborated on, we technically can.
[enhancement] Vendoring OpenMPI as an MPI implementation within TheRoâĶ
Switch most third-party subprojects to the amd-llvm toolchain (#3474)
Switch most third-party subprojects to the amd-llvm toolchain (#3474)
marbre commentedon Apr 13, 2026
Open MPI, non ROCM-aware and without Fortran support, has been landed to TheRock. Closing the issue accordingly. If additional requirements arise, we can file new, more specific issues.