[clang] [clang-repl] : Fix clang-repl crash with --cuda flag (PR #136404)

Anutosh Bhat via cfe-commits cfe-commits at lists.llvm.org
Thu Apr 24 06:15:25 PDT 2025


================
@@ -560,6 +576,16 @@ Interpreter::Parse(llvm::StringRef Code) {
     llvm::Expected<TranslationUnitDecl *> DeviceTU = DeviceParser->Parse(Code);
     if (auto E = DeviceTU.takeError())
       return std::move(E);
+
+    RegisterPTU(*DeviceTU, nullptr, DeviceAct.get());
+
+    llvm::Expected<llvm::StringRef> PTX = DeviceParser->GeneratePTX();
+    if (!PTX)
+      return PTX.takeError();
+
+    llvm::Error Err = DeviceParser->GenerateFatbinary();
+    if (Err)
+      return std::move(Err);
   }
----------------
anutosh491 wrote:

Changes with respect to parsing if `DeviceParser` is non nullptr

If we currently look at how generatePTX is framed (check [lines](https://github.com/llvm/llvm-project/pull/136404/files#diff-facf198ec2120aeb2be299cac501daf8e32793547be89a06139bcb988ad532c7R58-R59)) 

We operate on PTUs from the list of PTUS.

But currently we add no "devicePTUs" (produced by the deviceparser) as such in our list of PTUs.

So `auto &PTU = PTUs.back();`  would
i) either return a nullptr
ii) or point to a host PTU 

Both of which are wrong. The generatePTX function is meant to work on "devicePTUs" (produced by the deviceparser) as such who's modules have the target triple `nvptx64-nvidia-cuda` rather than that provided by the host (possibly `x86_64-unknown-linux-gnu`)

So first we 
i) Parse the code
ii) Register the PTU just like we do for the host case
iii) Then we operate on it (using `GeneratePTX` and `GenerateFatbinary`)
 





https://github.com/llvm/llvm-project/pull/136404


More information about the cfe-commits mailing list