Diff Detail
Event Timeline
clang/include/clang/Interpreter/Interpreter.h | ||
---|---|---|
84 | I find this flag name to be very confusing, given what "mangling" usually means within Clang. I think IsMangled = false means "this is a symbol name of the same kind that Clang would emit in IR", and IsMangled = true means "this is a symbol name of the same kind that would appear in an object file's symbol table" -- and the former is a mangled name in the sense in which the term is used in Clang. Perhaps enum { IRName, LinkerName } instead of a bool flag would be clearer? But I'm not sure whether this flag is motivated given that your test case below wants / is testing the IsMangled = false behavior. I wonder if a better interface here generally would be: llvm::Expected<llvm::JITTargetAddress> getSymbolAddress(GlobalDecl GD) const; ... which could internally form the proper symbol name for the given GlobalDecl (or perhaps reuse CodeGen's decl -> mangling map rather than redoing the name mangling step). | |
clang/unittests/Interpreter/InterpreterTest.cpp | ||
131–138 | This function produces names that are not mangled in the sense that getSymbolAddress's IsMangled = true means. I would expect this test to fail on MacOS for that reason. |
clang/include/clang/Interpreter/Interpreter.h | ||
---|---|---|
72 | Add a space before \returns please (here and below). | |
clang/unittests/Interpreter/IncrementalProcessingTest.cpp | ||
20 | Given that this file is unchanged, do we need the new includes? | |
clang/unittests/Interpreter/InterpreterTest.cpp | ||
166 | Use EXPECT_EQ and EXPECT_NE as appropriate. | |
214 | EXPECT_TRUE on an integer seems surprising. |
clang/unittests/Interpreter/IncrementalProcessingTest.cpp | ||
---|---|---|
20 | A leftover from some other experiments. Thanks! |
There is no information in this patch as to why the changes are needed or useful; please use a more descriptive summary next time.
clang/unittests/Interpreter/InterpreterTest.cpp | ||
---|---|---|
205–207 | FWIW, Intel's internal testing is hitting crashes with this test. With -fno-delayed-template-parsing enabled, we get a failed assertion: Assertion failed: OffsetBytes <= AllocationSize && "Offset out of bounds!", file d:\iusers\ayrivera\dev-xmain-web\llvm\l lvm\lib\executionengine\runtimedyld\RuntimeDyldImpl.h, line 90 and when we enable the delayed template parsing, we get a different assertion: Assertion failed: DC->getLexicalParent() == CurContext && "The next DeclContext should be lexically contained in the current one.", file D:/iusers/ayrivera/dev-xmain-web/llvm/clang/lib/Sema/SemaDecl.cpp, line 1305 I think this FIXME either needs to be addressed or the patch reverted until this is addressed. | |
237–240 | This test is broken for some of our internal build bots at Intel. I think something suspicious is going on here, but I'm not certain of the intent behind the test, so I'm not certain the best way to fix it. The behavior of the test is that on an x86 Windows machine, sometimes this particular test fails: [ RUN ] IncrementalProcessing.InstantiateTemplate^M unknown file: error: SEH exception with code 0x3221225477 thrown in the test body.^M [ FAILED ] IncrementalProcessing.InstantiateTemplate (35 ms)^M but it's not a consistent failure (seems to happen about one out of every three runs). callme is a templated member function of B but here we're trying to call it like it's a free function. That's... not good. We could either make callme a static member function so that it can be called in this manner, or we could try to come up with a magic incantation to call it as a PMF. Can you investigate, @v.g.vassilev? If it is going to take considerable time to resolve, it might be worth reverting temporarily. Thanks! |
clang/unittests/Interpreter/InterpreterTest.cpp | ||
---|---|---|
237–240 | To be perhaps succinct, the problem is calling Pointer-to-member-function as a free-function. The cast on line 239 is completely invalid, and can't be done in C++ code itself without UB. We believe this shows up on x86 in particular since there is ALSO a calling-convention mismatch here, but this cast to TemplateSpecFn seems completely invalid to me. |
clang/unittests/Interpreter/InterpreterTest.cpp | ||
---|---|---|
205–207 | Ignore this -- this comment was saved in my Phab drafts from an earlier investigation and I managed to not delete it when sending my other comment (below). Oops! |
clang/unittests/Interpreter/InterpreterTest.cpp | ||
---|---|---|
237–240 | Thanks for the ping, @aaron.ballman. Does making the function static fixes it? If it does, please go ahead and commit the fix otherwise I can do it in 12 hours. If it does not fix it, could you share the bot logs or at least the cmake configure line and the platform? |
clang/unittests/Interpreter/InterpreterTest.cpp | ||
---|---|---|
237–240 | Committed here - https://reviews.llvm.org/rG3ad0c6b75ea5 |
clang/unittests/Interpreter/InterpreterTest.cpp | ||
---|---|---|
237–240 | Thanks! |
Add a space before \returns please (here and below).