[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