-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid C++ Code from AST-Printer at value assignment with reflection #242
Comments
Could you check what the Note also that the transaction only keeps decls that are relevant for |
You are right.
The full gdb dump: DeclContext.txt I have a idea to solve this problem. |
You should only iterate over |
Solved with #284 |
Update: The bug is fixed with the version of the CUDA device code compiler. See: #284
This bug occurs at my CUDA implementation, which should merged in to the cling (#240 ). The bug is already in the master of the cling, but has no effect without the CUDA implementation.
Input code in cling
Error at cling -xcuda
Description of the workflow
For cuda, I need a second jit (clang target nvptx), which generate code for cuda device side (see. #240 - Concept). To generate the code, I pass all input code of cling direct to the clang (Argument
StringRef input
of cling::IncrementalParser::ParseInternal()) except one case. If a variable will declared, I need the unwrapped variable declaration. In this case, I use the c++ code, which cling has generated.https://github.com/SimeonEhrig/cling/blob/46ed41902fa18b81a98b48ea8b9d05fb8eb7f757/lib/Interpreter/IncrementalCUDADeviceCompiler.cpp#L198-L210
This implementation works with the clang AST-Printer.
Input of the clang cuda jit
Error message of clang cuda jit
Dump of Module in cling (-x c++)
The dump() function of the cling::Transaction also use the AST-Printer. I dumped the Transaction at the end of the function
cling::IncrementalParser::ParseInternal()
. The content is the same, like the input of my cuda jit.Possible reasons
I think, there are two bugs. The first is the generation of
constexpr bool value
. The second is the wrong semantic of the value assignment of "M".constexpr bool value
I don't know, why the expressions are generated but they cause two errors.
constexpr
needs an assignment and there are redefinition errors, because the statement exists four times.M assignment
I think, it is a problem of the AST-Printer. If I add two pairs of brackets, the semantic is OK.
I don't know, if my brackets are OK and the function still do the right thing, but it compiles.
Questions and possible solutions
I try to solve the problems but I need some information to develop a working solution.
constexpr bool value
?clang::VarDecl
is same, as the declaration in the original wrapper function?If the
constexpr bool value
is just relevant for cling internals, I would overwork the filter and just send the value assignment, which was original inside the wrapper function.if(clang::VarDecl * v = llvm::dyn_cast<clang::VarDecl>(decl)){
https://github.com/SimeonEhrig/cling/blob/46ed41902fa18b81a98b48ea8b9d05fb8eb7f757/lib/Interpreter/IncrementalCUDADeviceCompiler.cpp#L202
If the M assignment problem is a AST-Printer bug, I hope anyone of the cling-team or the clang-community (I would open a bug report) can fix the problem. I'm not really familiar with the AST-Printer implementation.
The text was updated successfully, but these errors were encountered: