[Documentation]: Could you please tell me your gcc version?

[he97]

Description of errors

Could you please tell me your gcc version? And the minimum version of gcc required to build the project. The gcc version I used with clang is 7.0, and I cannot build the project.

Attach any links, screenshots, or additional evidence you think will be helpful.

No response

[Snektron]

Hi, projects using rocThrust must be compiled with hipcc or a hip-aware llvm toolchain. When installing ROCm, both of these should be available through your package manager, and they should also be available through any ROCm docker images.

[he97]

As far as I understand, hipcc is also based on llvm. The local gcc is used during the clang construction process of llvm. Are there any requirements for the local gcc version?

[Snektron]

Are you referring to LLVM using libgcc and/or libstdc++? If so, that's a good question, because I don't know about any version compatibilities here. The only thing I can suggest is that the current version of hipcc is based on LLVM 19, and compiling rocThrust with a version of hipcc based on a particular version of LLVM will probably do whatever this version of LLVM does. Unfortunately, I also don't know about the support in that regard.

What error are you getting?

[he97]

My current problem is that I encountered no matching function call for non-allocating call operator new at https://github.com/ROCm/rocThrust/blob/44020d667b4efa17ed6896153fb8ff5cb4dafad8/thrust/system/hip/detail/uninitialized_fill .h#L62
branch rocm-6.0.2
This problem bothers me a lot, because it seems that the functions on the device side are also compiled by hipcc. I checked and found that the new header file was included in the compilation process. I don’t know why such an error occurs. Can you give me some suggestions?

[Snektron]

Would you be able to provide some detailed intructions on how to reproduce this issue? I tried reproducing it by preparing a docker container from rocm/rocm-terminal:6.0.2 and doing the following:

• install gcc-7, g++-7, libstdc++-7-dev, cmake, and ninja-build
• remove existing gcc and g++ installation (and also ran apt autoremove to get rid of their depedencies)
• Ran some update-alternatives commands to make gcc-7 and g++-7 the default toolchains

  sudo update-alternatives --install /usr/bin/c++ c++ /usr/bin/g++-7 10
  sudo update-alternatives --install /usr/bin/cc cc /usr/bin/gcc-7 10
  sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-7 10
  sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 10
  

• After this i'm just building the rocThrust uninitialized_fill example. Clone rocThrust, git checkout rocm-6.0.2, mkdir build && cd build && cmake .. -GNinja -DBUILD_TEST=ON. After that, ninja uninitialized_fill.hip completes just fine. If I take the first hipcc command produced by ninja -nv uninitialized_fill.hip, then add the -fdriver-only -v options, I can see that its indeed using the builtins and standard library from gcc 7.

[he97]

can you build this test? this is the error case
add_rocthrust_test("adjacent_difference")
Following your suggestion later, I entered /opt/rocm-6.3.0/lib/llvm/bin/clang -v after building inside dockerContainer and the terminal still outputs
Select GCC installation:/usr/lib/gcc/x86_64-linux-gnu/9
according to

rocThrust/thrust/system/cuda/detail/uninitialized_fill.h

Line 62 in 69329f0

// XXX unsafe. cuda-clang is seemingly unable to call ::new in device code

I have made the corresponding changes to bypass the use of non-placement new on the device side, and it has passed during the compilation process. Whether it can work remains to be seen later. Thank you very much for your help

[Snektron]

can you build this test? this is the error case
add_rocthrust_test("adjacent_difference")

Yes, with the same gcc 7 setup as above. rocm-terminal is based on Ubuntu 22, which uses gcc 9 by default - this is used in our CI and there are currently no issues with that.

according to

I commented out the #if condition so that the placement new is used in device mode, and it seems to be working fine even.

I have made the corresponding changes to bypass the use of non-placement new on the device side, and it has passed during the compilation process. Whether it can work remains to be seen later.

Be sure to let me know!