[clang-repl] Re-implement clang-interpreter as a test case.

[v.g.vassilev]

Summary

The current infrastructure in lib/Interpreter has a tool, clang-repl, very similar to clang-interpreter which also allows incremental compilation.

This patch moves clang-interpreter as a test case and drops it as conditionally built example as we already have clang-repl in place.

[lhames]

LGTM, but a clang dev should probably check this out too.

[v.g.vassilev]

clang/unittests/Interpreter/InterpreterTest.cpp

128

@rnk, would that test here be fine for both win32 and win64. Sorry for asking but I do not have an easy access to a Windows machine.

[rsmith]

clang/unittests/Interpreter/InterpreterTest.cpp

58

I don't follow why this can't be static. Is there some problem with using the address of this function if it's static?

[v.g.vassilev]

clang/unittests/Interpreter/InterpreterTest.cpp

58

That's a standard comment for each GetExecutablePath and I copy pasted it as done elsewhere. That requirement might be lifted in recent systems but I do not know the platform coverage to check.

[v.g.vassilev]

Try to fix the issues reported by the pre-merge-checks. clang-format.

[v.g.vassilev]

Try to appease the windows pre-merge bot.

[v.g.vassilev]

rebase

[v.g.vassilev]

Split the exception handling test into a separate unittest and compile it with exceptions on.

[v.g.vassilev]

Try fix the win pre-merge bot. Clang-format.

[v.g.vassilev]

Disable the case exception test of windows.

cc: @sgraenitz

[rsmith]

clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp

74–77

Presumably this is redundant now we don't run the test on Windows?

102–106

Isn't this because you're passing no arguments to main when you call it later in the test? You're not passing any arguments on line 123/124.

124–125

I think this should probably be cast to int(*)(int, const char**) instead. But the name main is special, and might not have its declared type, so selecting a different function name would have less risk of weird behavior. I'd also suggest you remove the parameters if you're not going to use them.

[v.g.vassilev]

Address comments.

[v.g.vassilev]

clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp

102–106

Ah, indeed. Thanks!

124–125

Fixed. The past intent was to keep it as close as possible to the original example.

[thakis]

The test fails for me on macOS (normal cmake build):

% tools/clang/unittests/Interpreter/ExceptionTests/ClangReplInterpreterExceptionTests
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from InterpreterTest
[ RUN      ] InterpreterTest.CatchException
In file included from <<< inputs >>>:1:
input_line_0:2:10: fatal error: 'stdexcept' file not found
#include <stdexcept>
         ^~~~~~~~~~~

The reason is probably that C++ stdlib headers are part of the toolchain, not the sysroot, on macOS. So self-built clang can't include libc++(abi) headers without some hoops.

Tests should generally be standalone though anyways. Can we remove these includes and just throw some basic type?

Finally, hardcoding the path between unit test binary and the rest of the build dir is fairly unusual. Can't this be a lit-style test that uses the normal substitution logic we use in lit?

[thakis]

Also failing on the bots: https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/23343/execution/node/39/log/ (that's for the original land, but from what I can tell nothing has changed in this regard for the reland, and I'm still seeing the same failure at head).

I'll revert this for now to unbreak mac bots.

[v.g.vassilev]

In D107049#2976603, @thakis wrote:

The test fails for me on macOS (normal cmake build):

% tools/clang/unittests/Interpreter/ExceptionTests/ClangReplInterpreterExceptionTests
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from InterpreterTest
[ RUN      ] InterpreterTest.CatchException
In file included from <<< inputs >>>:1:
input_line_0:2:10: fatal error: 'stdexcept' file not found
#include <stdexcept>
         ^~~~~~~~~~~

The reason is probably that C++ stdlib headers are part of the toolchain, not the sysroot, on macOS. So self-built clang can't include libc++(abi) headers without some hoops.

Tests should generally be standalone though anyways. Can we remove these includes and just throw some basic type?

Good point. I think I can avoid including stdexcept.

Finally, hardcoding the path between unit test binary and the rest of the build dir is fairly unusual. Can't this be a lit-style test that uses the normal substitution logic we use in lit?

I did not find a good way to 'find back' the clang resource-dir and it seems to be put in a constant place. The test needs to have a compiled and interpreted parts -- it throws an exception from the interpreter land and expects a compiled binary to be able to catch it. I am not sure if I know how to do that in lit.

[thakis]

I did not find a good way to 'find back' the clang resource-dir and it seems to be put in a constant place. The test needs to have a compiled and interpreted parts -- it throws an exception from the interpreter land and expects a compiled binary to be able to catch it. I am not sure if I know how to do that in lit.

Maybe this could be a binary with a main() function instead of a unit test, and you pass the path to the resource dir and to clang-interpreter to it, and then that sets up an exception handler and execs clang-interpreter? Or it could stay mostly as-is except make it a binary instead of a test, and call it from lit from a .test file (and pass in resource dir). That'd be more in line what other clang tests do.

(See e.g. the %resource_dir substitution, set in llvm/utils/lit/lit/llvm/config.py, used in a few places.)

[thakis]

Thanks for fixing! Intel macs are happy now.

But the test is still failing on arm macs: http://45.33.8.238/macm1/17292/step_7.txt

FAIL: Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException (28440 of 28440)
******************** TEST 'Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException' FAILED ********************
Script:
--
/Users/thakis/src/llvm-project/out/gn/obj/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests --gtest_filter=InterpreterTest.CatchException
--
Note: Google Test filter = InterpreterTest.CatchException
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from InterpreterTest
[ RUN      ] InterpreterTest.CatchException
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
....

Please take a look.

[v.g.vassilev]

In D107049#2982224, @thakis wrote:

Thanks for fixing! Intel macs are happy now.

But the test is still failing on arm macs: http://45.33.8.238/macm1/17292/step_7.txt

FAIL: Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException (28440 of 28440)
******************** TEST 'Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException' FAILED ********************
Script:
--
/Users/thakis/src/llvm-project/out/gn/obj/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests --gtest_filter=InterpreterTest.CatchException
--
Note: Google Test filter = InterpreterTest.CatchException
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from InterpreterTest
[ RUN      ] InterpreterTest.CatchException
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
....

Please take a look.

Yes, thanks for this information -- it fails also on hexagon so reverted it again :(

[v.g.vassilev]

In D107049#2982224, @thakis wrote:

Thanks for fixing! Intel macs are happy now.

But the test is still failing on arm macs: http://45.33.8.238/macm1/17292/step_7.txt

FAIL: Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException (28440 of 28440)
******************** TEST 'Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException' FAILED ********************
Script:
--
/Users/thakis/src/llvm-project/out/gn/obj/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests --gtest_filter=InterpreterTest.CatchException
--
Note: Google Test filter = InterpreterTest.CatchException
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from InterpreterTest
[ RUN      ] InterpreterTest.CatchException
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
libunwind: malformed __unwind_info at 0x192029E3C bad second level page
....

Please take a look.

It looks like we hit https://bugs.llvm.org/show_bug.cgi?id=49692

cc: @karies, @Hahnfeld

[Hahnfeld]

In D107049#2984835, @v.g.vassilev wrote:

It looks like we hit https://bugs.llvm.org/show_bug.cgi?id=49692

I agree. Unfortunately, as described in the report, this is something that needs to be fixed on Apples side first.

[karies]

clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt

2

I don't understand the term "to expect" the thrown exception. Please ignore if that's a known term of art.

clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp

93

Why not just throw Name; to avoid #include <stdexcept>?

100

Consider fwd declaring printf to avoid inclusion of stdio.h.

102

How is that provoking a test failure? What about exit(1) or whatever works for gtest?

104

To me, the wording difference between "In JIT" and "From JIT" doesn't signal anything. Maybe "the first could be "To be caught in JIT" and the second "To be caught in binary"?

[v.g.vassilev]

Upload the newest version of this patch. It has several improvements that came from various bot failures. We just need to outline the llvm::consumeError to be able to call it from exceptions land and fix the last known failure on hexagon.

[v.g.vassilev]

address comments

clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp

102

we use EXPECT_ANY_THROW and expect output on the stdout. I guess that line is not reachable.

104

The intent was to show that we can move the clang-interpreter example with relatively small amount of changes to the libInterpreter interfaces. we have changed that goal significantly and maybe we should also change the strings, too.

[thakis]

clang/unittests/Interpreter/CMakeLists.txt

4

Why are these additions needed here again? This change doesn't add any code to ClangReplInterpreterTests as far as I can tell. Are these remnants from before the exception tests were in a different binary?

[v.g.vassilev]

clang/unittests/Interpreter/CMakeLists.txt

4

Thanks for noticing that. The story was that clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt required ${LLVM_TARGETS_TO_BUILD} Core OrcJIT Support as a dependency -- I was not sure why but I added the same here. I am testing now if I can get rid of both. I do not understand why we will need different set of dependencies for these tests as they should be using more or less the same set of functionality...

[leonardchan]

Hi. I think our clang builders are failing from this after the reland (https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8833962834812688769/overview):

Script:
--
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests --gtest_filter=InterpreterTest.CatchException
--
Note: Google Test filter = InterpreterTest.CatchException
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from InterpreterTest
[ RUN      ] InterpreterTest.CatchException
JIT session error: Symbols not found: [ _Unwind_Resume, _ZSt9terminatev, _ZTVN10__cxxabiv117__class_type_infoE, __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_throw, __gxx_personality_v0 ]
Failure value returned from cantFail wrapped call
Failed to materialize symbols: { (main, { __clang_call_terminate, _ZTI16custom_exception, _ZN16custom_exceptionC2EPKc, _ZTS16custom_exception, throw_exception }) }
UNREACHABLE executed at llvm/include/llvm/Support/Error.h:778!

Would you be able to send out a fix or revert?

[v.g.vassilev]

In D107049#3052557, @leonardchan wrote:

Hi. I think our clang builders are failing from this after the reland (https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8833962834812688769/overview):

Script:
--
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests --gtest_filter=InterpreterTest.CatchException
--
Note: Google Test filter = InterpreterTest.CatchException
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from InterpreterTest
[ RUN      ] InterpreterTest.CatchException
JIT session error: Symbols not found: [ _Unwind_Resume, _ZSt9terminatev, _ZTVN10__cxxabiv117__class_type_infoE, __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_throw, __gxx_personality_v0 ]
Failure value returned from cantFail wrapped call
Failed to materialize symbols: { (main, { __clang_call_terminate, _ZTI16custom_exception, _ZN16custom_exceptionC2EPKc, _ZTS16custom_exception, throw_exception }) }
UNREACHABLE executed at llvm/include/llvm/Support/Error.h:778!

Would you be able to send out a fix or revert?

Thanks for reverting. I will look into this failure.

[v.g.vassilev]

clang/unittests/Interpreter/CMakeLists.txt

4

I dropped these dependencies as you mentioned -- thanks again.

[thakis]

clang/unittests/Interpreter/CMakeLists.txt

4

Looks like they're back in the reland. Mind dropping them again?

[v.g.vassilev]

clang/unittests/Interpreter/CMakeLists.txt

4

Yeah, thanks for keeping an eye on this. Not sure what I did wrong there.. Too many reverts I guess...

[uabelho]

Hi,

We're seeing a problem with this patch in our downstream (not public) buildbots. With an asan-built compiler we see the following:

10:08:55 FAIL: Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException (25832 of 79960)
10:08:55 ******************** TEST 'Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException' FAILED ********************
10:08:55 Script:
10:08:55 --
10:08:55 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests --gtest_filter=InterpreterTest.CatchException
10:08:55 --
10:08:55 Note: Google Test filter = InterpreterTest.CatchException
10:08:55 [==========] Running 1 test from 1 test suite.
10:08:55 [----------] Global test environment set-up.
10:08:55 [----------] 1 test from InterpreterTest
10:08:55 [ RUN      ] InterpreterTest.CatchException
10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
10:08:55 libc++abi: terminating with uncaught exception of type custom_exception
10:08:55  #0 0x000000000052072b backtrace /repo/uabelho/flacc_6.144/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4205:13
10:08:55  #1 0x0000000001873774 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:565:13
10:08:55  #2 0x000000000186c328 llvm::sys::RunSignalHandlers() /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Signals.cpp:0:5
10:08:55  #3 0x00000000018745a8 SignalHandler(int) /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:0:3
10:08:55  #4 0x00007f61246da630 __restore_rt sigaction.c:0:0
10:08:55  #5 0x00007f6122025387 raise (/lib64/libc.so.6+0x36387)
10:08:55  #6 0x00007f6122026a78 abort (/lib64/libc.so.6+0x37a78)
10:08:55  #7 0x000000000cbdedd6 (/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbdedd6)
10:08:55  #8 0x000000000cbe4407 (/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbe4407)
10:08:55  #9 0x000000000cbdecb3 std::__terminate(void (*)()) crtstuff.c:0:0
10:08:55 #10 0x000000000cbdca26 (/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbdca26)
10:08:55 #11 0x000000000cbdc9c0 __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) cxa_exception.cpp:0:0
10:08:55 #12 0x00007f611ea00171 
10:08:55 
10:08:55 ********************
10:08:55 Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
10:25:10 
10:25:10 1 warning(s) in tests
10:25:10 ********************
10:25:10 Failed Tests (1):
10:25:10   Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
10:25:10

Does an asan-build run clean for everyone else?

[v.g.vassilev]

In D107049#3096727, @uabelho wrote:

Hi,

We're seeing a problem with this patch in our downstream (not public) buildbots. With an asan-built compiler we see the following:

10:08:55 FAIL: Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException (25832 of 79960)
10:08:55 ******************** TEST 'Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException' FAILED ********************
10:08:55 Script:
10:08:55 --
10:08:55 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests --gtest_filter=InterpreterTest.CatchException
10:08:55 --
10:08:55 Note: Google Test filter = InterpreterTest.CatchException
10:08:55 [==========] Running 1 test from 1 test suite.
10:08:55 [----------] Global test environment set-up.
10:08:55 [----------] 1 test from InterpreterTest
10:08:55 [ RUN      ] InterpreterTest.CatchException
10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
10:08:55 libc++abi: terminating with uncaught exception of type custom_exception
10:08:55  #0 0x000000000052072b backtrace /repo/uabelho/flacc_6.144/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4205:13
10:08:55  #1 0x0000000001873774 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:565:13
10:08:55  #2 0x000000000186c328 llvm::sys::RunSignalHandlers() /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Signals.cpp:0:5
10:08:55  #3 0x00000000018745a8 SignalHandler(int) /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:0:3
10:08:55  #4 0x00007f61246da630 __restore_rt sigaction.c:0:0
10:08:55  #5 0x00007f6122025387 raise (/lib64/libc.so.6+0x36387)
10:08:55  #6 0x00007f6122026a78 abort (/lib64/libc.so.6+0x37a78)
10:08:55  #7 0x000000000cbdedd6 (/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbdedd6)
10:08:55  #8 0x000000000cbe4407 (/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbe4407)
10:08:55  #9 0x000000000cbdecb3 std::__terminate(void (*)()) crtstuff.c:0:0
10:08:55 #10 0x000000000cbdca26 (/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbdca26)
10:08:55 #11 0x000000000cbdc9c0 __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) cxa_exception.cpp:0:0
10:08:55 #12 0x00007f611ea00171 
10:08:55 
10:08:55 ********************
10:08:55 Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
10:25:10 
10:25:10 1 warning(s) in tests
10:25:10 ********************
10:25:10 Failed Tests (1):
10:25:10   Clang-Unit :: Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
10:25:10

Does an asan-build run clean for everyone else?

Can you share your cmake config line, the target triple and architecture?

[uabelho]

In D107049#3096807, @v.g.vassilev wrote:

Can you share your cmake config line, the target triple and architecture?

CC='/mycompiler/compiler-clang/bin/clang -march=corei7' CXX='/mycompiler/compiler-clang/bin/clang++ -march=corei7' LDFLAGS='-L/mycompiler/compiler-clang/lib64 -Wl,--disable-new-dtags,-R/mycompiler/compiler-clang/lib/x86_64-unknown-linux-gnu/c++:/mycompiler/compiler-clang/lib64:/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64 -ldl' cmake /repo/llvm --debug-trycompile -G Ninja -DCMAKE_MAKE_PROGRAM=ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' -DCMAKE_CXX_FLAGS='-stdlib=libc++' -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_INSTALL_PREFIX=/compiler-clang -DLLVM_APPEND_VC_REV=OFF -DLLVM_CCACHE_DIR=/repo/.ccache -DLLVM_CCACHE_BUILD=ON -DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache -DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' -DLLVM_ENABLE_Z3_SOLVER=ON -DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 -DLLVM_LIT_ARGS='-sv --threads 14' -DLLVM_ENABLE_PLUGINS=OFF -DLLVM_USE_SANITIZER='Address' -DLLVM_ENABLE_LIBPFM=OFF -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF -DLLVM_STATIC_LINK_CXX_STDLIB=ON -DCLANG_ENABLE_ARCMT=OFF -DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF -DCLANG_ROUND_TRIP_CC1_ARGS=OFF

[uabelho]

If we run without z3 it still fails, but in another way:

[ RUN      ] InterpreterTest.CatchException
JIT session error: Symbols not found: [ __gxx_personality_v0, _ZSt9terminatev, _ZTVN10__cxxabiv117__class_type_infoE, __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception ]
Failure value returned from cantFail wrapped call
Failed to materialize symbols: { (main, { __clang_call_terminate, _ZN16custom_exceptionC2EPKc, throw_exception, _ZTS16custom_exception, _ZTI16custom_exception }) }
UNREACHABLE executed at /repo/uabelho/master-github/llvm/include/llvm/Support/Error.h:788!
 #0 0x000000000051c0fb backtrace /repo/uabelho/flacc_6.144/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4205:13
 #1 0x000000000186f144 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:565:13
 #2 0x0000000001867cf8 llvm::sys::RunSignalHandlers() /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/Signals.cpp:0:5
 #3 0x000000000186ff78 SignalHandler(int) /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:0:3
 #4 0x00007fdcac5bd630 __restore_rt sigaction.c:0:0
 #5 0x00007fdcab8e0387 raise (/lib64/libc.so.6+0x36387)
 #6 0x00007fdcab8e1a78 abort (/lib64/libc.so.6+0x37a78)
 #7 0x0000000001708875 operator<< /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../include/llvm/Support/raw_ostream.h:221:7
 #8 0x0000000001708875 operator<< /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../include/llvm/Support/raw_ostream.h:231:18
 #9 0x0000000001708875 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/ErrorHandling.cpp:204:19
#10 0x0000000000590b65 unsigned long llvm::cantFail<unsigned long>(llvm::Expected<unsigned long>, char const*) /repo/uabelho/master-github/llvm/include/llvm/Support/Error.h:777:12
#11 0x000000000058e5b8 (anonymous namespace)::InterpreterTest_CatchException_Test::TestBody() /repo/uabelho/master-github/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:0:0
#12 0x00000000018abce8 os_stack_trace_getter /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:5635:7
#13 0x00000000018abce8 testing::Test::Run() /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:2515:9
#14 0x00000000018aeb03 testing::TestInfo::Run() /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:0:11
#15 0x00000000018aff71 testing::TestSuite::Run() /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:0:28
#16 0x00000000018dfaa9 testing::internal::UnitTestImpl::RunAllTests() /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:0:44
#17 0x00000000018ddc8e testing::UnitTest::Run() /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:4925:10
#18 0x000000000188fbce main /repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/UnitTestMain/TestMain.cpp:50:3
#19 0x00007fdcab8cc555 __libc_start_main (/lib64/libc.so.6+0x22555)
#20 0x00000000004e59c7 _start (/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0x4e59c7)

[v.g.vassilev]

In D107049#3099816, @uabelho wrote:

In D107049#3096807, @v.g.vassilev wrote:

Can you share your cmake config line, the target triple and architecture?

CC='/mycompiler/compiler-clang/bin/clang -march=corei7' CXX='/mycompiler/compiler-clang/bin/clang++ -march=corei7' LDFLAGS='-L/mycompiler/compiler-clang/lib64 -Wl,--disable-new-dtags,-R/mycompiler/compiler-clang/lib/x86_64-unknown-linux-gnu/c++:/mycompiler/compiler-clang/lib64:/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64 -ldl' cmake /repo/llvm --debug-trycompile -G Ninja -DCMAKE_MAKE_PROGRAM=ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' -DCMAKE_CXX_FLAGS='-stdlib=libc++' -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_INSTALL_PREFIX=/compiler-clang -DLLVM_APPEND_VC_REV=OFF -DLLVM_CCACHE_DIR=/repo/.ccache -DLLVM_CCACHE_BUILD=ON -DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache -DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' -DLLVM_ENABLE_Z3_SOLVER=ON -DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 -DLLVM_LIT_ARGS='-sv --threads 14' -DLLVM_ENABLE_PLUGINS=OFF -DLLVM_USE_SANITIZER='Address' -DLLVM_ENABLE_LIBPFM=OFF -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF -DLLVM_STATIC_LINK_CXX_STDLIB=ON -DCLANG_ENABLE_ARCMT=OFF -DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF -DCLANG_ROUND_TRIP_CC1_ARGS=OFF

Can you also paste the configure output of cmake?

[uabelho]

In D107049#3099941, @v.g.vassilev wrote:

Can you also paste the configure output of cmake?

Attached in file.txt

file.txt16 KBDownload

[rnk]

So, to back up a bit, do I understand correctly that this change adds tests to the check-clang test suite that JIT compiles C++ code for the host and throws C++ exceptions? Can we reconsider that?

We have a policy of not running execution tests in the clang test suite because we know they always turn out to be unreliable, flaky, and highly dependent on the environment rather than the code under test. Integration tests are great, everyone needs them, but they should definitely not be part of the default set of tests that developers run anywhere and everywhere and expect to work out of the box, regardless of the environment. +@dblaikie to confirm if I am off base here about our testing strategy, and maybe Lang can advise us about past JIT testing strategies.

[lhames]

In D107049#3096727, @uabelho wrote:

Hi,

We're seeing a problem with this patch in our downstream (not public) buildbots. With an asan-built compiler we see the following:

...
10:08:55 [ RUN      ] InterpreterTest.CatchException
10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
10:08:55 libc++abi: terminating with uncaught exception of type custom_exception
...

I suspect that this is a Linux distro that's using libunwind as the unwinder, at least for this test. Linux distros typically use libgcc_s for unwinding. The two libraries have different behavior for their __register_frame functions: libunwind's function expects to be passed a single FDE, libgcc_s's expects to be passed an entire .eh_frame section. We try to guess the unwinder in the JIT and use the appropriate argument (see [1][2]), but when we get it wrong this is often the result: we try to pass an .eh-frame section to libunwind's __register_frame and it errors out on a CIE at the start of the section.

@uabelho -- In your setup I'm seeing:

-- Looking for __unw_add_dynamic_fde
-- Looking for __unw_add_dynamic_fde - not found

So the question is, how are we failing to find __unw_add_dynamic_fde during config, only to crash in it during the test? Is use of libunwind on your platform expected?

side note: Peter Housel recently posted https://reviews.llvm.org/D111863 to add a new registration API with consistent behavior. Hopefully in the future we can rely on dynamic detection of this to eliminate the issue for users of future libunwinds.

In D107049#3100630, @rnk wrote:

So, to back up a bit, do I understand correctly that this change adds tests to the check-clang test suite that JIT compiles C++ code for the host and throws C++ exceptions? Can we reconsider that?

We have a policy of not running execution tests in the clang test suite because we know they always turn out to be unreliable, flaky, and highly dependent on the environment rather than the code under test. Integration tests are great, everyone needs them, but they should definitely not be part of the default set of tests that developers run anywhere and everywhere and expect to work out of the box, regardless of the environment. +@dblaikie to confirm if I am off base here about our testing strategy, and maybe Lang can advise us about past JIT testing strategies.

The JIT has always used execution tests. It's difficult to test the JIT properly without them, since it doesn't have persistent output.

In practice the trick has always been to tighten the criteria for where these can run until things stabilize. We're seeing more failures on the test cases that Vassil is writing because he's pushing the boundaries of ORC's feature set, but I think the solution should still be the same: fix the JIT when we find bugs there, and restrict the tests to environments where they're expected to pass.

[1] https://github.com/llvm/llvm-project/commit/957334382cd12ec07b46c0ddfdcc220731f6d80f
[2] https://llvm.org/PR44074

[dblaikie]

In D107049#3100630, @rnk wrote:

So, to back up a bit, do I understand correctly that this change adds tests to the check-clang test suite that JIT compiles C++ code for the host and throws C++ exceptions? Can we reconsider that?

We have a policy of not running execution tests in the clang test suite because we know they always turn out to be unreliable, flaky, and highly dependent on the environment rather than the code under test. Integration tests are great, everyone needs them, but they should definitely not be part of the default set of tests that developers run anywhere and everywhere and expect to work out of the box, regardless of the environment. +@dblaikie to confirm if I am off base here about our testing strategy, and maybe Lang can advise us about past JIT testing strategies.

Yeah, seems we've had some precedent for this for a while, as @lhames says (doing some archaeology I see one of the clang-interpreter tests added here, for instance: https://github.com/llvm/llvm-project/commit/1d487617f20ab9df65ab60d6cf9431ef288312ab

I push back pretty hard on end-to-end tests in clang in most cases - one place that slips through either untested or with end to end tests is anything in MCOptions, etc, since they aren't in IR and are only observable through their effect on the resulting assembly. And JITs - I didn't actually know we had live JIT tests up in clang - and yeah, would rather we didn't - perhaps via a mode in such frontends that emits the IR at various points, but it'll be a pretty significant investment to make something fairly robust, I would imagine (sort of like lldb reproducers replays (which are being removed due to unmaintainability, by the sounds of it) but being able to stub out the actual execution) - hmm, perhaps a remote execution mock would be feasible? That'd at least remove the execution part, make it portable to run on non-native environments - but wouldn't remove the end-to-end-ness, for that maybe you'd need a mock target that worked as though it ran IR natively, perhaps? Not sure.

Then maybe the more end-to-end-y tests could move out to cross-project-tests.

[uabelho]

In D107049#3100939, @lhames wrote:

In D107049#3096727, @uabelho wrote:

Hi,

We're seeing a problem with this patch in our downstream (not public) buildbots. With an asan-built compiler we see the following:

...
10:08:55 [ RUN      ] InterpreterTest.CatchException
10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
10:08:55 libc++abi: terminating with uncaught exception of type custom_exception
...

I suspect that this is a Linux distro that's using libunwind as the unwinder, at least for this test. Linux distros typically use libgcc_s for unwinding. The two libraries have different behavior for their __register_frame functions: libunwind's function expects to be passed a single FDE, libgcc_s's expects to be passed an entire .eh_frame section. We try to guess the unwinder in the JIT and use the appropriate argument (see [1][2]), but when we get it wrong this is often the result: we try to pass an .eh-frame section to libunwind's __register_frame and it errors out on a CIE at the start of the section.

@uabelho -- In your setup I'm seeing:

-- Looking for __unw_add_dynamic_fde
-- Looking for __unw_add_dynamic_fde - not found

So the question is, how are we failing to find __unw_add_dynamic_fde during config, only to crash in it during the test? Is use of libunwind on your platform expected?

Thanks for your reply. Unfortunately I'm not really sure how it's configured or what is expected. I'll try to involve someone who knows.

[lhames]

In D107049#3101456, @dblaikie wrote:

In D107049#3100630, @rnk wrote:

So, to back up a bit, do I understand correctly that this change adds tests to the check-clang test suite that JIT compiles C++ code for the host and throws C++ exceptions? Can we reconsider that?

We have a policy of not running execution tests in the clang test suite because we know they always turn out to be unreliable, flaky, and highly dependent on the environment rather than the code under test. Integration tests are great, everyone needs them, but they should definitely not be part of the default set of tests that developers run anywhere and everywhere and expect to work out of the box, regardless of the environment. +@dblaikie to confirm if I am off base here about our testing strategy, and maybe Lang can advise us about past JIT testing strategies.

Yeah, seems we've had some precedent for this for a while, as @lhames says (doing some archaeology I see one of the clang-interpreter tests added here, for instance: https://github.com/llvm/llvm-project/commit/1d487617f20ab9df65ab60d6cf9431ef288312ab

Also all of the MJCIT and Orc tests in LLVM.

I push back pretty hard on end-to-end tests in clang in most cases - one place that slips through either untested or with end to end tests is anything in MCOptions, etc, since they aren't in IR and are only observable through their effect on the resulting assembly. And JITs - I didn't actually know we had live JIT tests up in clang - and yeah, would rather we didn't - perhaps via a mode in such frontends that emits the IR at various points, but it'll be a pretty significant investment to make something fairly robust, I would imagine (sort of like lldb reproducers replays (which are being removed due to unmaintainability, by the sounds of it) but being able to stub out the actual execution) - hmm, perhaps a remote execution mock would be feasible? That'd at least remove the execution part, make it portable to run on non-native environments - but wouldn't remove the end-to-end-ness, for that maybe you'd need a mock target that worked as though it ran IR natively, perhaps? Not sure.

The LLVM MCJIT and Orc tests have been stable enough once we constrained the environments that they run in. I don't see why this would be any less stable. The features being exercised (essentially the object runtimes) are likely to be more stable in practice than the environments being tested in the LLDB tests.

Then maybe the more end-to-end-y tests could move out to cross-project-tests.

Are you suggesting execution tests for cross-project-tests?

[dblaikie]

In D107049#3103984, @lhames wrote:

In D107049#3101456, @dblaikie wrote:

In D107049#3100630, @rnk wrote:

So, to back up a bit, do I understand correctly that this change adds tests to the check-clang test suite that JIT compiles C++ code for the host and throws C++ exceptions? Can we reconsider that?

We have a policy of not running execution tests in the clang test suite because we know they always turn out to be unreliable, flaky, and highly dependent on the environment rather than the code under test. Integration tests are great, everyone needs them, but they should definitely not be part of the default set of tests that developers run anywhere and everywhere and expect to work out of the box, regardless of the environment. +@dblaikie to confirm if I am off base here about our testing strategy, and maybe Lang can advise us about past JIT testing strategies.

Yeah, seems we've had some precedent for this for a while, as @lhames says (doing some archaeology I see one of the clang-interpreter tests added here, for instance: https://github.com/llvm/llvm-project/commit/1d487617f20ab9df65ab60d6cf9431ef288312ab

Also all of the MJCIT and Orc tests in LLVM.

I think @rnk was asking/drawing a distinction between execution tests in LLVM (which is at least only testing LLVM code in LLVM) and execution tests in Clang (which is both execution, and cross-project) - so I was just talking about the Clang->LLVM->execution tests. Though I think in LLVM there'd also be some opportunity to find some ways to isolate/test JIT infrastructure with less execution (had sort of hoped in the early days of Orc that the layered architecture would allow more isolated/unit testing to robustly test pieces without execution for that testing).

I push back pretty hard on end-to-end tests in clang in most cases - one place that slips through either untested or with end to end tests is anything in MCOptions, etc, since they aren't in IR and are only observable through their effect on the resulting assembly. And JITs - I didn't actually know we had live JIT tests up in clang - and yeah, would rather we didn't - perhaps via a mode in such frontends that emits the IR at various points, but it'll be a pretty significant investment to make something fairly robust, I would imagine (sort of like lldb reproducers replays (which are being removed due to unmaintainability, by the sounds of it) but being able to stub out the actual execution) - hmm, perhaps a remote execution mock would be feasible? That'd at least remove the execution part, make it portable to run on non-native environments - but wouldn't remove the end-to-end-ness, for that maybe you'd need a mock target that worked as though it ran IR natively, perhaps? Not sure.

The LLVM MCJIT and Orc tests have been stable enough once we constrained the environments that they run in. I don't see why this would be any less stable. The features being exercised (essentially the object runtimes) are likely to be more stable in practice than the environments being tested in the LLDB tests.

Then maybe the more end-to-end-y tests could move out to cross-project-tests.

Are you suggesting execution tests for cross-project-tests?

I think cross-project-tests (originally debuginfo-tests) has always had/been a place for execution tests. Not all of them, and still value in having lit-style non-execution cross-project tests where possible for more robust/variation testing where possible, with fewer full end-to-end-including-execution tests where possible (always going to be fuzzy lines of what's worth the cost/benefit, etc - and we're all going to have different points on that spectrum).

[lhames]

In D107049#3104558, @dblaikie wrote:

In D107049#3103984, @lhames wrote:

In D107049#3101456, @dblaikie wrote:

Yeah, seems we've had some precedent for this for a while, as @lhames says (doing some archaeology I see one of the clang-interpreter tests added here, for instance: https://github.com/llvm/llvm-project/commit/1d487617f20ab9df65ab60d6cf9431ef288312ab

Also all of the MJCIT and Orc tests in LLVM.

I think @rnk was asking/drawing a distinction between execution tests in LLVM (which is at least only testing LLVM code in LLVM) and execution tests in Clang (which is both execution, and cross-project) - so I was just talking about the Clang->LLVM->execution tests. Though I think in LLVM there'd also be some opportunity to find some ways to isolate/test JIT infrastructure with less execution (had sort of hoped in the early days of Orc that the layered architecture would allow more isolated/unit testing to robustly test pieces without execution for that testing).

Orc has plenty of isolated unit testing and regression testing too, it's just that the nature of the project (dynamic compilation, and with relatively few resources dedicated to it) makes end to end testing attractive for now too. Perhaps in the long term we could build out enough mocking infrastructure to be confident that the JIT works without running any JIT'd code, but we're a fair way off that.

I think testing of the clang-repl is probably in a similar place: In theory you could build infrastructure to test out all the interesting states that a REPL could put your AST into. In practice we don't have the resources to do that yet, and without execution tests we're left with essentially no testing of the feature.

Execution testing seems like the right compromise for now, as long as we can make sure that there's not too much noise from the testers. The lesson from the LLVM execution tests is that this is possible without an excessive amount of work.

I think cross-project-tests (originally debuginfo-tests) has always had/been a place for execution tests. Not all of them, and still value in having lit-style non-execution cross-project tests where possible for more robust/variation testing where possible, with fewer full end-to-end-including-execution tests where possible (always going to be fuzzy lines of what's worth the cost/benefit, etc - and we're all going to have different points on that spectrum).

Yeah. Cross-project tests sounds like a great place to add more JIT tests, and maybe it's the correct home for clang-repl tests, but I think for now the right trade off is still to have execution tests and just restrict them to running on known-good configs.

clang/docs/ClangFormattedStatus.rst

* - clang/examples/Attribute
      - `1`
      - `0`
      - :good:`100%`
    * - clang/examples/CallSuperAttribute
      - `1`
      - `1`
      - `0`
      - :good:`100%`
-   * - clang/examples/clang-interpreter
-     - `1`
-     - `0`
-     - `1`
-     - :none:`0%`
    * - clang/examples/PrintFunctionNames
      - `1`
      - `0`
      - `1`
      - :none:`0%`
    * - clang/include/clang/Analysis
      - `16`
      - `4`

clang/examples/CMakeLists.txt

 if(NOT CLANG_BUILD_EXAMPLES)
   set_property(DIRECTORY PROPERTY EXCLUDE_FROM_ALL ON)
   set(EXCLUDE_FROM_ALL ON)
 endif()
 
-add_subdirectory(clang-interpreter)
 add_subdirectory(PrintFunctionNames)
 add_subdirectory(AnnotateFunctions)
 add_subdirectory(Attribute)
 add_subdirectory(CallSuperAttribute)

clang/examples/clang-interpreter/CMakeLists.txt

-set(LLVM_LINK_COMPONENTS
-  Core
-  ExecutionEngine
-  MC
-  MCJIT
-  Object
-  OrcJit
-  Option
-  RuntimeDyld
-  Support
-  native
-  )
-
-add_clang_executable(clang-interpreter
-  main.cpp
-  )
-
-add_dependencies(clang-interpreter
-  clang-resource-headers
-  )
-
-clang_target_link_libraries(clang-interpreter
-  PRIVATE
-  clangBasic
-  clangCodeGen
-  clangDriver
-  clangFrontend
-  clangSerialization
-  )
-
-export_executable_symbols(clang-interpreter)
-
-if (MSVC)
-  # Is this a CMake bug that even with export_executable_symbols, Windows
-  # needs to explictly export the type_info vtable
-  set_property(TARGET clang-interpreter
-               APPEND_STRING PROPERTY LINK_FLAGS " /EXPORT:??_7type_info@@6B@")
-endif()
-
-function(clang_enable_exceptions TARGET)
-  # Really have to jump through hoops to enable exception handling independent
-  # of how LLVM is being built.
-  if (NOT LLVM_REQUIRES_EH AND NOT LLVM_REQUIRES_RTTI)
-    if (MSVC)
-      # /EHs to allow throwing from extern "C"
-      set(excptnExceptions_ON "/D _HAS_EXCEPTIONS=1 /EHs /wd4714")
-      set(excptnExceptions_OFF "/D _HAS_EXCEPTIONS=0 /EHs-c-")
-      set(excptnRTTI_ON "/GR")
-      set(excptnRTTI_OFF "/GR-")
-      set(excptnEHRTTIRegEx "(/EHs(-c-?)|_HAS_EXCEPTIONS=(0|1))")
-    else()
-      set(excptnExceptions_ON "-fexceptions")
-      set(excptnExceptions_OFF "-fno-exceptions")
-      set(excptnRTTI_ON "-frtti")
-      set(excptnRTTI_OFF "-fno-rtti")
-      set(excptnEHRTTIRegEx "-f(exceptions|no-exceptions)")
-    endif()
-    if (LLVM_REQUIRES_EH)
-      set(excptnExceptions_DFLT ${excptnExceptions_ON})
-    else()
-      set(excptnExceptions_DFLT ${excptnExceptions_OFF})
-    endif()
-    if (LLVM_REQUIRES_RTTI)
-      set(excptnRTTI_DFLT ${excptnRTTI_ON})
-    else()
-      set(excptnRTTI_DFLT ${excptnRTTI_OFF})
-    endif()
-
-    # Strip the exception & rtti flags from the target
-    get_property(addedFlags TARGET ${TARGET} PROPERTY COMPILE_FLAGS)
-    string(REGEX REPLACE ${excptnEHRTTIRegEx} "" editedFlags "${addedFlags}")
-    string(REPLACE ${excptnRTTI_OFF} "" editedFlags "${editedFlags}")
-    set_property(TARGET ${TARGET} PROPERTY COMPILE_FLAGS "${editedFlags}")
-
-    get_property(addedFlags TARGET ${TARGET} PROPERTY COMPILE_DEFINITIONS)
-    string(REGEX REPLACE ${excptnEHRTTIRegEx} "" editedFlags "${addedFlags}")
-    string(REPLACE ${excptnRTTI_OFF} "" editedFlags "${editedFlags}")
-    set_property(TARGET ${TARGET} PROPERTY COMPILE_DEFINITIONS "${editedFlags}")
-
-    # Re-add the exception & rtti flags from LLVM
-    set_property(SOURCE main.cpp APPEND_STRING PROPERTY COMPILE_FLAGS
-                   " ${excptnExceptions_DFLT} ${excptnRTTI_DFLT} ")
-    set_property(SOURCE Manager.cpp APPEND_STRING PROPERTY COMPILE_FLAGS
-                   " ${excptnExceptions_DFLT} ${excptnRTTI_DFLT} ")
-
-    # Invoke with exceptions & rtti
-    set_property(SOURCE Invoke.cpp APPEND_STRING PROPERTY COMPILE_FLAGS
-                   " ${excptnExceptions_ON} ${excptnRTTI_ON} ")
-
-  endif()
-endfunction(clang_enable_exceptions)
-
-clang_enable_exceptions(clang-interpreter)

clang/examples/clang-interpreter/README.txt

-This is an example of Clang based interpreter, for executing standalone C/C++
-programs.
-
-It demonstrates the following features:
- 1. Parsing standard compiler command line arguments using the Driver library.
-
- 2. Constructing a Clang compiler instance, using the appropriate arguments
-    derived in step #1.
-
- 3. Invoking the Clang compiler to lex, parse, syntax check, and then generate
-    LLVM code.
-
- 4. Use the LLVM JIT functionality to execute the final module.
-
- 5. Intercepting a Win64 library call to allow throwing and catching exceptions
-    in and from the JIT.
-
-The implementation has many limitations and is not designed to be a full fledged
-interpreter. It is designed to demonstrate a simple but functional use of the
-Clang compiler libraries.

clang/examples/clang-interpreter/Test.cxx

-//===-- examples/clang-interpreter/Test.cxx - Clang C Interpreter Example -===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===----------------------------------------------------------------------===//
-
-// Example throwing in and from the JIT (particularly on Win64).
-//
-// ./bin/clang-interpreter <src>/tools/clang/examples/clang-interpreter/Test.cxx
-
-#include <stdexcept>
-#include <stdio.h>
-
-static void ThrowerAnError(const char* Name) {
-  throw std::runtime_error(Name);
-}
-
-int main(int argc, const char** argv) {
-  for (int I = 0; I < argc; ++I)
-   printf("arg[%d]='%s'\n", I, argv[I]);
-
-  try {
-    ThrowerAnError("In JIT");
-  } catch (const std::exception& E) {
-    printf("Caught: '%s'\n", E.what());
-  } catch (...) {
-    printf("Unknown exception\n");
-  }
-  ThrowerAnError("From JIT");
-  return 0;
-}

clang/include/clang/Interpreter/Interpreter.h

 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_CLANG_INTERPRETER_INTERPRETER_H
 #define LLVM_CLANG_INTERPRETER_INTERPRETER_H
 
 #include "clang/Interpreter/PartialTranslationUnit.h"
 
+#include "llvm/ExecutionEngine/JITSymbol.h"
 #include "llvm/Support/Error.h"
 
 #include <memory>
 #include <vector>
 
 namespace llvm {
 namespace orc {
 class ThreadSafeContext;
public:
   llvm::Error ParseAndExecute(llvm::StringRef Code) {
     auto PTU = Parse(Code);
     if (!PTU)
       return PTU.takeError();
     if (PTU->TheModule)
       return Execute(*PTU);
     return llvm::Error::success();
   }
+  llvm::Expected<llvm::JITTargetAddress>
+  getSymbolAddress(llvm::StringRef UnmangledName) const;
 };
 } // namespace clang
 
 #endif // LLVM_CLANG_INTERPRETER_INTERPRETER_H

clang/lib/Interpreter/IncrementalExecutor.h

 
 public:
   IncrementalExecutor(llvm::orc::ThreadSafeContext &TSC, llvm::Error &Err,
                       const llvm::Triple &Triple);
   ~IncrementalExecutor();
 
   llvm::Error addModule(std::unique_ptr<llvm::Module> M);
   llvm::Error runCtors() const;
+  llvm::Expected<llvm::JITTargetAddress>
+  getSymbolAddress(llvm::StringRef UnmangledName) const;
 };
 
 } // end namespace clang
 
 #endif // LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H

clang/lib/Interpreter/IncrementalExecutor.cpp

 llvm::Error IncrementalExecutor::addModule(std::unique_ptr<llvm::Module> M) {
   return Jit->addIRModule(llvm::orc::ThreadSafeModule(std::move(M), TSCtx));
 }
 
 llvm::Error IncrementalExecutor::runCtors() const {
   return Jit->initialize(Jit->getMainJITDylib());
 }
 
+llvm::Expected<llvm::JITTargetAddress>
+IncrementalExecutor::getSymbolAddress(llvm::StringRef UnmangledName) const {
+  auto Sym = Jit->lookup(UnmangledName);
+  if (!Sym)
+    return Sym.takeError();
+  return Sym->getAddress();
+}
+
 } // end namespace clang

clang/lib/Interpreter/Interpreter.cpp

 #include "clang/Lex/PreprocessorOptions.h"
 
 #include "llvm/IR/Module.h"
 #include "llvm/Support/Host.h"
 
 using namespace clang;
 
 // FIXME: Figure out how to unify with namespace init_convenience from
-//        tools/clang-import-test/clang-import-test.cpp and
-//        examples/clang-interpreter/main.cpp
+//        tools/clang-import-test/clang-import-test.cpp
 namespace {
 /// Retrieves the clang CC1 specific flags out of the compilation's jobs.
 /// \returns NULL on error.
 static llvm::Expected<const llvm::opt::ArgStringList *>
 GetCC1Arguments(DiagnosticsEngine *Diagnostics,
                 driver::Compilation *Compilation) {
   // We expect to get back exactly one Command job, if we didn't something
   // failed. Extract that job from the Compilation.
llvm::Error Interpreter::Execute(PartialTranslationUnit &T) {
   if (auto Err = IncrExecutor->addModule(std::move(T.TheModule)))
     return Err;
 
   if (auto Err = IncrExecutor->runCtors())
     return Err;
 
   return llvm::Error::success();
 }
+
+llvm::Expected<llvm::JITTargetAddress>
+Interpreter::getSymbolAddress(llvm::StringRef UnmangledName) const {
+  if (!IncrExecutor)
+    return llvm::make_error<llvm::StringError>("Operation failed. "
+                                               "No execution engine",
+                                               std::error_code());
+
+  return IncrExecutor->getSymbolAddress(UnmangledName);
+}

clang/test/CMakeLists.txt

if (CLANG_ENABLE_ARCMT)
   )
 endif ()
 
 if (CLANG_BUILD_EXAMPLES)
   list(APPEND CLANG_TEST_DEPS
     Attribute
     AnnotateFunctions
     CallSuperAttr
-    clang-interpreter
     PrintFunctionNames
     )
 endif ()
 
 set(CLANG_TEST_PARAMS
   USE_Z3_SOLVER=0
   )
 

clang/test/Misc/interpreter.c

-// RUN: clang-interpreter %s | FileCheck %s
-// REQUIRES: native, examples
-
-int printf(const char *, ...);
-
-int main() {
-  // CHECK: {{Hello world!}}
-  printf("Hello world!\n");
-  return 0;
-}

clang/test/lit.cfg.py

tools = [
     'apinotes-test', 'c-index-test', 'clang-diff', 'clang-format', 'clang-repl',
     'clang-tblgen', 'clang-scan-deps', 'opt', 'llvm-ifs', 'yaml2obj',
     ToolSubst('%clang_extdef_map', command=FindTool(
         'clang-extdef-mapping'), unresolved='ignore'),
 ]
 
 if config.clang_examples:
     config.available_features.add('examples')
-    tools.append('clang-interpreter')
 
 def have_host_jit_support():
     clang_repl_exe = lit.util.which('clang-repl', config.clang_tools_dir)
 
     if not clang_repl_exe:
         print('clang-repl not found')
         return False
 

clang/unittests/Interpreter/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS
   Core
   )
 
 add_clang_unittest(ClangReplInterpreterTests
   IncrementalProcessingTest.cpp
   InterpreterTest.cpp
   )
 target_link_libraries(ClangReplInterpreterTests PUBLIC
   clangAST
   clangBasic
   clangInterpreter
   clangFrontend
   )
+
+# Exceptions on Windows are not yet supported.
+if(NOT WIN32)
+  add_subdirectory(ExceptionTests)
+endif()

clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt

+# The interpreter can throw an exception from user input. The test binary needs
+# to be compiled with exception support to expect and catch the thrown
+# exception.
+set(LLVM_REQUIRES_EH ON)
+set(LLVM_REQUIRES_RTTI ON)
+
+add_clang_unittest(ClangReplInterpreterExceptionTests
+  InterpreterExceptionTest.cpp
+  )
+
+llvm_update_compile_flags(ClangReplInterpreterExceptionTests)
+target_link_libraries(ClangReplInterpreterExceptionTests PUBLIC
+  clangAST
+  clangBasic
+  clangInterpreter
+  clangFrontend
+  )
+add_dependencies(ClangReplInterpreterExceptionTests clang-resource-headers)

clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp

+//===- unittests/Interpreter/InterpreterExceptionTest.cpp -----------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===----------------------------------------------------------------------===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector<const char *>;
+static std::unique_ptr<Interpreter>
+createInterpreter(const Args &ExtraArgs = {},
+                  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+    CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void *)(intptr_t)GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+                          CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+    auto J = llvm::orc::LLJITBuilder().create();
+    if (!J) {
+      // The platform does not support JITs.
+      // We can't use llvm::consumeError as it needs typeinfo for ErrorInfoBase.
+      auto E = J.takeError();
+      (void)E;
+      return;
+    }
+  }
+  const char ExceptionCode[] =
+      R"(
+#include <stdexcept>
+#include <stdio.h>
+
+static void ThrowerAnError(const char* Name) {
+  throw std::runtime_error(Name);
+}
+
+extern "C" int throw_exception() {
+  try {
+    ThrowerAnError("In JIT");
+  } catch (const std::exception& E) {
+    printf("Caught: '%s'\n", E.what());
+  } catch (...) {
+    printf("Unknown exception\n");
+  }
+  ThrowerAnError("From JIT");
+  return 0;
+}
+    )";
+  std::string ResourceDir = MakeResourcesPath();
+  std::unique_ptr<Interpreter> Interp =
+      createInterpreter({"-resource-dir", ResourceDir.c_str()});
+  // Adjust the resource-dir
+  llvm::cantFail(Interp->ParseAndExecute(ExceptionCode));
+  testing::internal::CaptureStdout();
+  auto ThrowException =
+      (int (*)())llvm::cantFail(Interp->getSymbolAddress("throw_exception"));
+  EXPECT_THROW(ThrowException(), std::exception);
+  std::string CapturedStdOut = testing::internal::GetCapturedStdout();
+  EXPECT_EQ(CapturedStdOut, "Caught: 'In JIT'\n");
+}
+
+} // end anonymous namespace

clang/unittests/Interpreter/InterpreterTest.cpp

 
 #include "clang/Interpreter/Interpreter.h"
 
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclGroup.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
-#include "llvm/ADT/ArrayRef.h"
-
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
 using namespace clang;
 
 namespace {
 using Args = std::vector<const char *>;
 static std::unique_ptr<Interpreter>
TEST(InterpreterTest, Sanity) {
   PTU &R2(cantFail(Interp->Parse("int i;")));
   EXPECT_EQ(1U, DeclsSize(R2.TUPart));
 }
 
 static std::string DeclToString(Decl *D) {
   return llvm::cast<NamedDecl>(D)->getQualifiedNameAsString();
 }
 
 TEST(InterpreterTest, IncrementalInputTopLevelDecls) {
   std::unique_ptr<Interpreter> Interp = createInterpreter();
   auto R1 = Interp->Parse("int var1 = 42; int f() { return var1; }");
   // gtest doesn't expand into explicit bool conversions.
   EXPECT_TRUE(!!R1);
   auto R1DeclRange = R1->TUPart->decls();
   EXPECT_EQ(2U, DeclsSize(R1->TUPart));
   EXPECT_EQ("var1", DeclToString(*R1DeclRange.begin()));
   EXPECT_EQ("f", DeclToString(*(++R1DeclRange.begin())));
TEST(InterpreterTest, DeclsAndStatements) {
   EXPECT_FALSE(!!R2);
   using ::testing::HasSubstr;
   EXPECT_THAT(DiagnosticsOS.str(),
               HasSubstr("error: unknown type name 'var1'"));
   auto Err = R2.takeError();
   EXPECT_EQ("Parsing failed.", llvm::toString(std::move(Err)));
 }
 
 } // end anonymous namespace