-
Notifications
You must be signed in to change notification settings - Fork 13.4k
[clang-repl] Segfault on assignment when JIT compiling with -O1 or above #95581
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
Comments
Is there a way to bisect it on your side? |
Yeah, I'll work on that and report back. |
... Several hours of compilation later ... I've bisected to find the commit (d2a9df2) which introduces the crash. Based on the stack trace, the diff looks very relevant. Author: @fhahn (Florian, would you mind please taking a look and providing your input?)
In case the full bisect log is useful, I've included it below.
I compared `release/18.x` against Vassil's `fix-pch` branch to find this.
|
Sure I'd be happy to take a look! I managed to reproduce this on macOS, but I am not sure how to get a standalone reproducer for a unit test? |
Nice! Thanks for giving it a go locally. I'm not familiar with Clang/LLVM dev at all, but I know the tests are kept over here: https://github.com/llvm/llvm-project/tree/main/clang/test/Interpreter I'm pretty sure each of those Following that, I've made one which reproduces the error (using the test case I included in this ticket): diff --git a/clang/test/Interpreter/assigment-with-implicit-ctor.cpp b/clang/test/Interpreter/assigment-with-implicit-ctor.cpp
new file mode 100644
index 000000000000..24cea8ec1a4b
--- /dev/null
+++ b/clang/test/Interpreter/assigment-with-implicit-ctor.cpp
@@ -0,0 +1,13 @@
+// REQUIRES: host-supports-jit
+// UNSUPPORTED: system-aix
+//
+// RUN: cat %s | clang-repl | FileCheck %s
+// RUN: cat %s | clang-repl -Xcc -O2 | FileCheck %s
+
+struct box { box() = default; box(int *const data) : data{data} {} int *data{}; };
+
+box foo() { box ret; ret = new int{}; return ret; }
+
+extern "C" int printf(const char *, ...);
+printf("good");
+// CHECK: good I'm not sure how they're normally executed, but I've found you can run all clang tests with
Hopefully that helps. If you're able to look into the fix for this, I'd very much appreciate it. |
Hi @fhahn! Is there any chance you've had some time to look into this crash? Or perhaps if you have some ideas you can share for anyone else who might look into this? |
…lation. In incremental compilation clang works with multiple `llvm::Module`s. Our current approach is to create a CodeGenModule entity for every new module request (via StartModule). However, some of the state such as the mangle context needs to be preserved to keep the original semantics in the ever-growing TU. Fixes: llvm#95581.
…lation. In incremental compilation clang works with multiple `llvm::Module`s. Our current approach is to create a CodeGenModule entity for every new module request (via StartModule). However, some of the state such as the mangle context needs to be preserved to keep the original semantics in the ever-growing TU. Fixes: llvm#95581.
…lation. In incremental compilation clang works with multiple `llvm::Module`s. Our current approach is to create a CodeGenModule entity for every new module request (via StartModule). However, some of the state such as the mangle context needs to be preserved to keep the original semantics in the ever-growing TU. Fixes: llvm#95581.
…lation. In incremental compilation clang works with multiple `llvm::Module`s. Our current approach is to create a CodeGenModule entity for every new module request (via StartModule). However, some of the state such as the mangle context needs to be preserved to keep the original semantics in the ever-growing TU. Fixes: llvm#95581.
@llvm/issue-subscribers-clang-codegen Author: Jeaye Wilkerson (jeaye)
Hi folks. I've been working with @vgvassilev to identify an issue with Clang/LLVM 19. Currently running on Vassil's branch here: https://github.com//pull/94166
NOTE: This issue does not exist in LLVM 18 (1118c2e). I have a minimal repro case shown below. It works with The C++ sourcestruct box {
box() = default;
box(int *const data) : data{data} {}
int *data{};
};
box foo() {
box ret;
/* The assignment here causes the crash. Using direct initialization works.
* With -O0, this compiles and works. With -O1 or above, it dies. */
ret = new int{};
return ret;
} The repro steps
The backtrace
Environment details
|
…lation. (llvm#98138) In incremental compilation clang works with multiple `llvm::Module`s. Our current approach is to create a CodeGenModule entity for every new module request (via StartModule). However, some of the state such as the mangle context needs to be preserved to keep the original semantics in the ever-growing TU. Fixes: llvm#95581. cc: @jeaye
…lation. (llvm#98138) In incremental compilation clang works with multiple `llvm::Module`s. Our current approach is to create a CodeGenModule entity for every new module request (via StartModule). However, some of the state such as the mangle context needs to be preserved to keep the original semantics in the ever-growing TU. Fixes: llvm#95581. cc: @jeaye (cherry picked from commit 6c62ad4)
…lation. (llvm#98138) In incremental compilation clang works with multiple `llvm::Module`s. Our current approach is to create a CodeGenModule entity for every new module request (via StartModule). However, some of the state such as the mangle context needs to be preserved to keep the original semantics in the ever-growing TU. Fixes: llvm#95581. cc: @jeaye (cherry picked from commit 6c62ad4)
Hi folks. I've been working with @vgvassilev to identify an issue with Clang/LLVM 19. Currently running on Vassil's branch here: #94166
NOTE: This issue does not exist in LLVM 18 (1118c2e).
I have a minimal repro case shown below. It works with
-O0
, but crashes with-O1
or higher.The C++ source
The repro steps
The backtrace
Environment details
The text was updated successfully, but these errors were encountered: