Anton Gorenko

@david-salinas Turned out that `-fstack-protector-strong` causes this crash. rocRAND doesn't use this flag but some users have it set "system-wide" (for example, in `/etc/makepkg.conf` which is used for building packages...

``` hcc hc_array.cpp -hc -o hc_array && ltrace -C -e 'hsa*' ./hc_array ``` ``` 1 libmcwamp_hsa.so->hsa_amd_memory_pool_allocate(0x19c1ff0, 492, 0, 0x7ffd1ca9c0d8) = 0 libmcwamp_hsa.so->hsa_amd_agents_allow_access(1, 0x19e17f0, 0, 0x7f00db603000 libhsa-runtime64.so.1->hsaKmtQueryPointerInfo(0x7f00db603000, 0x7ffd1ca9bea0, 0, 0) =...

@b-sumner I've created a branch with the workaround disabled and added some instructions. I hope, it's more clear now.

This issue is not fixed in ROCm 2.3. But good news: I managed to create a small test case without external dependencies: https://gist.github.com/ex-rzr/98e429dad13aa17ba1e67fc7145ba827 ``` hipcc vcc.cpp -o vcc && ./vcc...

Another example (a test case from rocPRIM): gfx803: ``` v_add_u32_e32 v1, vcc, s1, v1 // 00000000111C: 32020201 s_and_b64 vcc, exec, vcc // 000000001120: 86EA6A7E s_cbranch_vccnz BB0_2 // 000000001124: BF870073 ```...

If I remember correctly HCC doesn't support passing structs with array fields as kernel args. And this behavior was mentioned somewhere in docs but I can't find it anymore. Workaround...

Oh, I've found the doc. It's actually from HIP, but this chapter was removed from there because HIP has different kernel launching implementation now. Here the old version: https://github.com/ROCm-Developer-Tools/HIP/blob/91f82ce541b51ad1106a28e951b410a256e61f62/docs/markdown/hip_bugs.md#errors-related-to-no-matching-constructor And...

I spent some time trying to build and run OpenMM-HIP on Windows with an older pre-release HIP SDK version a few months ago. I didn't finish my attempt then because...

Deja vu. This swapping code reminds me one compiler bug. We had an issue with one test in rocPRIM: https://github.com/ROCmSoftwarePlatform/rocPRIM/blob/develop/rocprim/include/rocprim/warp/detail/warp_sort_stable.hpp#L105 As you can see, the code is very similar. So...

Are you sure that the gap is not caused by `interactingTiles.resize` and `interactingAtoms.resize`? Do you see it in other iterations?