search

ROCm / HIPIFY

HIPIFY: Convert CUDA to Portable C++ Code
https://rocm.docs.amd.com/projects/HIPIFY/en/latest/
MIT License
524 stars 75 forks source link

hipify-clang introducing non-ASCII characters #41

Closed MichaelLettrich closed 4 years ago

MichaelLettrich commented 6 years ago

reproduce by compiling square sample: hipify-clang square.cu -- -x cuda --cuda-gpu-arch=sm_50 -L/usr/local/cuda/lib64 -lcudart_static -ldl -lrt -pthread -I/opt/rocm/include will terminate without problems. Looking inside, I get #include <hip/hipn^D^@^@^P^@^@^@¸p¥ square.cu.hip.txt

Using hipconvertinplace.sh for a multifile project a couple of files were transformed OK while some resulted in 

/home/milettri/Projects/gemmCUDA/gemmHIP/matmul/../helpers/cudaHelpers.hpp:5:21: warning: null character ignored [-Wnull-character]
#include <hip/hip+<U+0000><U+0000><U+0000><U+0008><U+0000><U+0000><U+0000><A8>U<U+000B>
                                  ^

reproduced on two different ubuntu 18.04 machines, one with ubuntu packaged clang, the other with official llvm packages. Building hipify-clang from release tag 1.9.1 resulted in the same issues.

kneternal commented 6 years ago

Experiencing the same issue: OS: Ubuntu 16.04 with kernel 4.15.0.38 CUDA 9.0 Origin Hipify-clang built from commit 2c99ef9 and one of the earlier commit used couple days ago also has this issue.

It looks like that if the file doesn't have any #include <cuda_runtime.h>, then hipify-clang can successfully add #include <hip_runtime.h> to it. However, while the file has that line of include, non-ascii issue will be up.

Nvm, PUBLIC doesn't solve anything, I mistaking the run files.

MichaelLettrich commented 6 years ago

@kneternal I ran hipconvertinplace.sh (which uses hipify-clang) with removed includes for #include <cuda_runtime.h> and ran into the very same problems again. Only after removing #include <cuda.h> as well, conversion went smoothly. As of now, this can be seen as a workaround.

MichaelLettrich commented 6 years ago

Update:

change the target_link_libraries in CMakelist from private to public will solve the non-ascii issue and the conflict.

Cannot confirm this works on my system. Which CMakelist did you modify - the one of hipify-clang?

kneternal commented 6 years ago

@kneternal I ran hipconvertinplace.sh (which uses hipify-clang) with removed includes for #include <cuda_runtime.h> and ran into the very same problems again. Only after removing #include <cuda.h> as well, conversion went smoothly. As of now, this can be seen as a workaround.

Yeap, I am assuming that, all the cuda-related includes will affect hipify-clang.

Sorry for the spam that PUBLIC can be a workaround, I just messed up the run files.

MichaelLettrich commented 6 years ago

Can confirm that the fix resolves the bug. Thank you for the quick intervention.