ROCm releases vs hipfort interfaces

[domcharrier]

ROCm 3.7 was just released.
We should generate a new batch of interface modules.

Any suggestions how we contribute them to the repository?

• Do we just overwrite the existing ones (and tag a commit
  that we regard as stable)?

• Do we keep subfolders per ROCm release?

• ...

[gregrodgers]

If we regenerated the interface based on ROCm 3.7 HIP headers, how different would the new hipfort interface be? I presume it would be small. Git would show you with git diff. If there are additional or inconsistent functions, then we need to set a new dependency for ROCM 3.7 in hipfc.

Can you regenerate the hipfort.f and hipfort_enums.f and create a PR for us to review the differences? Thank you Dominic.

[domcharrier]

See #29 for the newly generated modules.

[gregrodgers]

Thank you. It appears this PR is more than just ROCm 3.7 updates. Does the generator have some improvements? Also, I was not aware that the generator was also building the interfaces for the library interfaces. That is very cool. But we should discuss this with Dan and Colin's teams.

[gregrodgers]

The current master is the most stable we have and this requires ROCM 3.5. So we could make a github release 3.5 which would create a rel 3.5 tag. Joe wants a development model where the master (default) branch is our most stable. So that would mean that this PR for ROCm 3.7 should go into a dev branch. When we are happy with the dev branch, we could merge dev into master and create a new release 3.7. We need to develop a policy where all PRs are applied to dev . Then a release manager merges to master and creates a new release.

[domcharrier]

Does the generator have some improvements?

• It is better in distinguishing between scalars passed as pointers and arrays.
  That was the problem that affected the rocfft module.
• It further is a little more conservative regarding using intent qualifiers. For example, if you have a function argument with intent(inout),
  Fortran complains when you pass a constant like c_null_ptr. In general, I use the qualifier less often now.

Also, I was not aware that the generator was also building the interfaces for the library interfaces. That is very cool. But we should discuss this with Dan and Colin's teams.

The generator is still quite general. It is not specialized for HIP runtime headers.
It is not even specialized for ROCm (aside from a single command-line argument).

Agree to discuss this with the lib owners though.