Tim Gu

@rdiarra Hi, have your issue been resolved? It seems to be a really odd issue based on your output. The problematic code https://github.com/ROCm/hipfort/blob/release/rocm-rel-6.0/cmake/Modules/SetFortranFlags.cmake#L83 suggest that dummy compilation tests are failing...

Hi, this issue will be closed for now due to inactivity. Please feel free to re-open or add a follow up in the future. Thank you!

@misos1, thanks for reaching out and sorry for the lack of follow-ups. Based on their [docs](https://github.com/AdaptiveCpp/AdaptiveCpp/blob/8cf7a90232d065b80813eedfae678518fa67eed7/doc/hip-source-interop.md?plain=1#L29), seems like AdaptiveCpp does not have it nailed either. Initially parsing everything as `__host__`...

@Thyre, ROCm 6.4 has upgraded to llvm19. Would you be able to see if the issue still persists? Thanks!

@ArturoBlas and @kazulittlefox Thanks for reaching out and sorry for the lack of responses. Runtime compilation is supported via HIP RTC and runtime linking has been supported since ROCm 5.6.0x....

Hi @jinz2014, the function is recently added part of [this](https://github.com/ROCm/clr/commit/ecd812b2d867c176d75217263c3f30132471e6ad). You can see it on staging but it hasn't made to 6.2.2 release yet, but please keep an eye out...

Hi @jinz2014, to follow up on the discussion, in our opinion, it is best to have two versions of the atomic functions because atomic* and unsafeAtomic* APIs behave differently, hence...

@jinz2014 No problem! Is there anything else we can help you with? If not I will close this issue for now. Thanks!

> anther thing may need you clarify, looks in `/opt/rocm/include`, there is no `clr` headers, only found: `/opt/rocm/include/./hip/amd_detail/amd_hip_bf16.h` , supposing `clr` headers has merged to `hip` header dir? Yes, that's...

This issue will be closed since there is no further actionable item/activity. Please feel free to re-open for follow ups and further inquires requiring the release status. Thanks!