We have seen random symbol not found "__cxa_throw" error in fuschia build bots and out-of-tree users. The understanding have been that they are built without exception support, but it turned out that these platforms have LLVM_STATIC_LINK_CXX_STDLIB ON so that they link libstdc++ to llvm statically. The reason why this is problematic for clang-repl is that by default clang-repl tries to find symbols from symbol table of executable and dynamic libraries loaded by current process. It needs to load another libstdc++, but the platform that had LLVM_STATIC_LINK_CXX_STDLIB turned on is usally those with missing or obsolate shared libstdc++ in the first place -- trying to load it again would be destined to fail eventually with a risk to introuduce mixed libstdc++ versions.
A proper solution that doesn't take a workaround is statically link the same libstdc++ by clang-repl side, but this is not possible with old JIT linker runtimedyld. New just-in-time linker JITLink handles this relatively well, but it's not availalbe in majority of platforms. For now, this patch just disables the building of clang-repl when LLVM_STATIC_LINK_CXX_STDLIB is ON and removes the "__cxa_throw" check in exception unittest as well as reverting previous exception check flag patch.
Reviewed By: v.g.vassilev
Differential Revision: https://reviews.llvm.org/D130788
Also move MangleCtx when moving some lazy emission states in
CodeGenModule. Without this patch clang-repl hits an invalid address
access when passing `-Xcc -O2` flag.
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D130420
Windows has some issues when we try to use `__attribute__((weak))` in
JIT, so we disabled that. But it's not worth to disable the whole test
just for this single feature. This patch split that part from the
original test so we can keep testing stuff that normally working in
Windows.
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D129250
This reverts 3668d1264e
As far as we know, `__attribute__((weak))` support has been really bad
in runtimeldyld, so we just disable it in Windows at this moment. This
should fix the angry Windows buildbot.
Differential Revision: https://reviews.llvm.org/D129042
In interactive C++ it is convenient to roll back to a previous state of the
compiler. For example:
clang-repl> int x = 42;
clang-repl> %undo
clang-repl> float x = 24 // not an error
To support this, the patch extends the functionality used to recover from
errors and adds functionality to recover the low-level execution infrastructure.
The current implementation is based on watermarks. It exploits the fact that
at each incremental input the underlying compiler infrastructure is in a valid
state. We can only go N incremental inputs back to a previous valid state. We do
not need and do not do any further dependency tracking.
This patch was co-developed with V. Vassilev, relies on the past work of Purva
Chaudhari in clang-repl and is inspired by the past work on the same feature
in the Cling interpreter.
Co-authored-by: Purva-Chaudhari <purva.chaudhari02@gmail.com>
Co-authored-by: Vassil Vassilev <v.g.vassilev@gmail.com>
Signed-off-by: Jun Zhang <jun@junz.org>
This reverts commits:
d3ddc251acd90eecff5c
It turned out there're some options turned on that leaks the memory
intentionally, which fires the asan builds after the patch being
applied. The issue has been fixed in
7bc00ce5cd, so reland it.
Below is the original commit message:
The intent of this patch is to selectively carry some states over to
the Builder so we won't lose the information of the previous symbols.
This used to be several downstream patches of Cling, it aims to fix
errors in Clang Interpreter when trying to use inline functions.
Before this patch:
clang-repl> inline int foo() { return 42;}
clang-repl> int x = foo();
JIT session error: Symbols not found: [ _Z3foov ]
error: Failed to materialize symbols:
{ (main, { x, $.incr_module_1.__inits.0, __orc_init_func.incr_module_1 }) }
Co-authored-by: Axel Naumann <Axel.Naumann@cern.ch>
Signed-off-by: Jun Zhang <jun@junz.org>
This reverts commits:
d3ddc251acd90eecff5c
This relands below commit with asan fix:
The intent of this patch is to selectively carry some states over to
the Builder so we won't lose the information of the previous symbols.
This used to be several downstream patches of Cling, it aims to fix
errors in Clang Interpreter when trying to use inline functions.
Before this patch:
clang-repl> inline int foo() { return 42;}
clang-repl> int x = foo();
JIT session error: Symbols not found: [ _Z3foov ]
error: Failed to materialize symbols:
{ (main, { x, $.incr_module_1.__inits.0, __orc_init_func.incr_module_1 }) }
Co-authored-by: Axel Naumann <Axel.Naumann@cern.ch>
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D127730
The intent of this patch is to selectively carry some states over to
the Builder so we won't lose the information of the previous symbols.
This used to be several downstream patches of Cling, it aims to fix
errors in Clang Interpreter when trying to use inline functions.
Before this patch:
clang-repl> inline int foo() { return 42;}
clang-repl> int x = foo();
JIT session error: Symbols not found: [ _Z3foov ]
error: Failed to materialize symbols:
{ (main, { x, $.incr_module_1.__inits.0, __orc_init_func.incr_module_1 }) }
Co-authored-by: Axel Naumann <Axel.Naumann@cern.ch>
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D126781
Before this patch, there was re-declaration error if error was encountered in
the same line. The recovery support acted only if this type of error was
encountered in the first line of the program and not in subsequent lines.
For example:
```
clang-repl> int i=9;
clang-repl> int j=9; err;
input_line_3:1:5: error: redefinition of 'j'
int j = 9;
```
Differential revision: https://reviews.llvm.org/D123674
This reverts commit 3ec88ca60b which reverted e386871e1d due to a asan build
failure.
This patch removes the new lines in the test case which seem to introduce the
failure.
Differential revision: https://reviews.llvm.org/D104898
This patch replaces the `powerpc64` token with the `system-aix` one in
the UNSUPPORTED line of a test. The `powerpc64` token was originally
added temporarily in 71a0609a2b.
If AIX uses integrated-as by default and it works both for 32-bit and
64-bit objects, then the issues encountered so far (see comments in
D96033) would be mostly solved.
As it is, marking the test as expected-to-fail (as opposed to
unsupported) on AIX might cause more trouble in the form of 32-bit
versus 64-bit differences. I am not aware of other situations where LIT
tests are dependent on whether the LLVM build is 64-bit or 32-bit.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D102560
This test is failing on some builders (see [1]) with the following error:
error: Added modules have incompatible data layouts:
e-m:e-i64:64-n32:64-S128-v256:256:256-v512:512:512 (module) vs
E-m:a-i64:64-n32:64-S128-v256:256:256-v512:512:512 (jit)
The JIT layout is correct, but some IR module added to the JIT is using a
little-endian layout instead.
This commit disables the test on ppc64 until we can investigate further and
fix the bug.
[1] https://lab.llvm.org/staging/#/builders/126/builds/371
Original commit message:
In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have
mentioned our plans to make some of the incremental compilation facilities
available in llvm mainline.
This patch proposes a minimal version of a repl, clang-repl, which enables
interpreter-like interaction for C++. For instance:
./bin/clang-repl
clang-repl> int i = 42;
clang-repl> extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=42
clang-repl> quit
The patch allows very limited functionality, for example, it crashes on invalid
C++. The design of the proposed patch follows closely the design of cling. The
idea is to gather feedback and gradually evolve both clang-repl and cling to
what the community agrees upon.
The IncrementalParser class is responsible for driving the clang parser and
codegen and allows the compiler infrastructure to process more than one input.
Every input adds to the “ever-growing” translation unit. That model is enabled
by an IncrementalAction which prevents teardown when HandleTranslationUnit.
The IncrementalExecutor class hides some of the underlying implementation
details of the concrete JIT infrastructure. It exposes the minimal set of
functionality required by our incremental compiler/interpreter.
The Transaction class keeps track of the AST and the LLVM IR for each
incremental input. That tracking information will be later used to implement
error recovery.
The Interpreter class orchestrates the IncrementalParser and the
IncrementalExecutor to model interpreter-like behavior. It provides the public
API which can be used (in future) when using the interpreter library.
Differential revision: https://reviews.llvm.org/D96033
This reverts commit 44a4000181.
We are seeing build failures due to missing dependency to libSupport and
CMake Error at tools/clang/tools/clang-repl/cmake_install.cmake
file INSTALL cannot find
In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have
mentioned our plans to make some of the incremental compilation facilities
available in llvm mainline.
This patch proposes a minimal version of a repl, clang-repl, which enables
interpreter-like interaction for C++. For instance:
./bin/clang-repl
clang-repl> int i = 42;
clang-repl> extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=42
clang-repl> quit
The patch allows very limited functionality, for example, it crashes on invalid
C++. The design of the proposed patch follows closely the design of cling. The
idea is to gather feedback and gradually evolve both clang-repl and cling to
what the community agrees upon.
The IncrementalParser class is responsible for driving the clang parser and
codegen and allows the compiler infrastructure to process more than one input.
Every input adds to the “ever-growing” translation unit. That model is enabled
by an IncrementalAction which prevents teardown when HandleTranslationUnit.
The IncrementalExecutor class hides some of the underlying implementation
details of the concrete JIT infrastructure. It exposes the minimal set of
functionality required by our incremental compiler/interpreter.
The Transaction class keeps track of the AST and the LLVM IR for each
incremental input. That tracking information will be later used to implement
error recovery.
The Interpreter class orchestrates the IncrementalParser and the
IncrementalExecutor to model interpreter-like behavior. It provides the public
API which can be used (in future) when using the interpreter library.
Differential revision: https://reviews.llvm.org/D96033
Sunho Kim