zmodem wrote:
We're seeing the test fail on our mac builds:
https://issues.chromium.org/issues/346289767
```
JIT session error: Symbols not found: [ ___clang_Interpreter_SetValueNoAlloc ]
error: Failed to materialize symbols: { (main, {
orc_init_func.incr_module_10, _c_str, $.incr_module_
vgvassilev wrote:
Ah, that’s well spotted. The current test should not require plugins. Would
dropping this conditional make it work for your case?
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
zmodem wrote:
> Would dropping this conditional make it work for your case?
I don't have a mac handy to try it right now. If you commit it, our system will
test it automatically :) Or maybe @thakis could give it a try?
https://github.com/llvm/llvm-project/pull/89811
___
vgvassilev wrote:
> > Would dropping this conditional make it work for your case?
>
> I don't have a mac handy to try it right now. If you commit it, our system
> will test it automatically :) Or maybe @Thakis could give it a try?
I am on my phone in the next couple of hours and I am not sure
zmodem wrote:
I was able to confirm on a local Mac that removing the
`if(CLANG_PLUGIN_SUPPORT)` fixes the test, so I'll go ahead and commit that.
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
aeubanks wrote:
So actually even the `export_executable_symbols_for_plugins` doesn't fix our
bots. I've narrowed it down to `-DLLVM_ENABLE_PIC=ON/OFF`. Perhaps we're not
exporting symbols when `-DLLVM_ENABLE_PIC=OFF`.
https://github.com/llvm/llvm-project/pull/89811
vgvassilev wrote:
> So actually even the `export_executable_symbols_for_plugins` doesn't fix our
> bots. I've narrowed it down to `-DLLVM_ENABLE_PIC=ON/OFF`. Perhaps we're not
> exporting symbols when `-DLLVM_ENABLE_PIC=OFF`.
That’s quite strange. Is that somehow related to ld64? @lhames donyi
aeubanks wrote:
This was with `-DLLVM_ENABLE_LLD=ON`, so probably not? I'm guessing there's
some CMake logic that doesn't fit with clang-repl's expectation of symbol
availability, but that may be wrong.
https://github.com/llvm/llvm-project/pull/89811
___
vgvassilev wrote:
Our current theory is that somehow the build system does not mark this symbol
as exported. Maybe we can confirm that by making the symbol resolution for that
particular one via the JIT absolute symbol definition. This is rather a
workaround and the real fix should be in the b
https://github.com/vgvassilev created
https://github.com/llvm/llvm-project/pull/89811
Depends on #89804.
>From 8317ce33d07d0986e314de0b39aa977f784e0619 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 18:07:06 +
Subject: [PATCH 1/2] [clang-repl] Extend the C support.
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Vassil Vassilev (vgvassilev)
Changes
Depends on #89804.
---
Full diff: https://github.com/llvm/llvm-project/pull/89811.diff
6 Files Affected:
- (modified) clang/lib/Interpreter/IncrementalParser.cpp (+11-2)
- (modified) clang/lib/Inter
https://github.com/AaronBallman commented:
Generally looks good, but it seems that some parts of this PR are also
incorporated into another PR, so it's a bit hard to review.
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
@@ -42,6 +42,9 @@
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/TargetParser/Host.h"
+
+#include
AaronBallman wrote:
`` instead?
https://github.com/llvm/llvm-project/pull/89811
__
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vgvassilev updated
https://github.com/llvm/llvm-project/pull/89811
>From 4a73cd3c3daca1cb1856a8e175dc9cb531ca Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 19:33:00 +
Subject: [PATCH] [clang-repl] Lay the foundation of pretty printing for C.
-
https://github.com/vgvassilev updated
https://github.com/llvm/llvm-project/pull/89811
>From 3e922935bc551dd5c3f76dae22a94318d0abd210 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 19:33:00 +
Subject: [PATCH] [clang-repl] Lay the foundation of pretty printing for C.
-
@@ -42,6 +42,9 @@
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/TargetParser/Host.h"
+
+#include
vgvassilev wrote:
Fixed.
https://github.com/llvm/llvm-project/pull/89811
_
vgvassilev wrote:
> Generally looks good, but it seems that some parts of this PR are also
> incorporated into another PR, so it's a bit hard to review.
Rebased, should be only the commit in question now, as the other one landed.
https://github.com/llvm/llvm-project/pull/89811
https://github.com/AaronBallman approved this pull request.
LGTM, feel free to apply my suggestion if you like it.
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -269,7 +267,10 @@ const char *const Runtimes = R"(
void __clang_Interpreter_SetValueCopyArr(const T (*Src)[N], void*
Placement, unsigned long Size) {
__clang_Interpreter_SetValueCopyArr(Src[0], Placement, Size);
}
+extern "C"
AaronBallman
https://github.com/vgvassilev updated
https://github.com/llvm/llvm-project/pull/89811
>From 0ff8aca868bfd78d4bcfd31f299e253e83c150a2 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 19:33:00 +
Subject: [PATCH] [clang-repl] Lay the foundation of pretty printing for C.
-
@@ -269,7 +267,10 @@ const char *const Runtimes = R"(
void __clang_Interpreter_SetValueCopyArr(const T (*Src)[N], void*
Placement, unsigned long Size) {
__clang_Interpreter_SetValueCopyArr(Src[0], Placement, Size);
}
+extern "C"
vgvassilev wr
vgvassilev wrote:
> LGTM, feel free to apply my suggestion if you like it.
Applied it. Thanks for the review this unblock whole bunch of work for us..
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.
https://github.com/vgvassilev updated
https://github.com/llvm/llvm-project/pull/89811
>From 3094e6026925ebcba6da86dd16111f4f70f9a700 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 19:33:00 +
Subject: [PATCH] [clang-repl] Lay the foundation of pretty printing for C.
-
https://github.com/vgvassilev updated
https://github.com/llvm/llvm-project/pull/89811
>From eb5d2ec5bb77626542671ac713714e723f66d62d Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 19:33:00 +
Subject: [PATCH] [clang-repl] Lay the foundation of pretty printing for C.
-
https://github.com/vgvassilev updated
https://github.com/llvm/llvm-project/pull/89811
>From 0c1c53e7d12bf8398c1a18dca2fa472a1b7acb3f Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Tue, 23 Apr 2024 19:33:00 +
Subject: [PATCH] [clang-repl] Lay the foundation of pretty printing for C.
-
https://github.com/vgvassilev closed
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidSpickett wrote:
I have bisected a 32 bit Arm failure down to this change:
https://lab.llvm.org/buildbot/#/builders/245/builds/25526
Is it possible that something in this code is truncating a value when
interpreting types intended for a 64 bit system, on a 32 bit system? I don't
see this
vgvassilev wrote:
Is the bot configured to build for arm64 and run on arm32 somehow? But in
either case the width of the `int` type should be the same, right?
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lis
DavidSpickett wrote:
It is a 32 bit container running on an arm64 host. As far as the compiler and
tests know, it's a 32 bit system.
> But in either case the width of the int type should be the same, right?
Yes.
So I am wondering if someone of the assumptions about types being larger than
on
vgvassilev wrote:
> So I am wondering if someone of the assumptions about types being larger than
> one another do not hold on 32 bit. Or your change has exposed an existing
> issue, it wouldn't be the first time.
My feeling is the latter but how can we get a debug build and debug?
https://gi
DavidSpickett wrote:
> My feeling is the latter but how can we get a debug build and debug?
I'm going to try a UBSAN build on the chance it pinpoints the issue right away,
but failing that it'll be cross compiling to Arm 32 bit and using qemu-user to
run the unit test binary. I will get you in
vitalybuka wrote:
It's broken here https://lab.llvm.org/buildbot/#/builders/236/builds/11633
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
vgvassilev wrote:
> It's broken here https://lab.llvm.org/buildbot/#/builders/236/builds/11633
It seems broken for a different reason. Somehow we did not export that
`__clang_Interpreter_SetValueNoAlloc` symbol. Is that some
`-fvisibility=hidden` build?
https://github.com/llvm/llvm-project/pu
vitalybuka wrote:
Not sure, nothing in cmake cmd:
```
cmake -DLLVM_APPEND_VC_REV=OFF -GNinja -DCMAKE_BUILD_TYPE=Release
-DLLVM_CCACHE_BUILD=ON -DLLVM_USE_LINKER=lld -DLLVM_ENABLE_ASSERTIONS=ON
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF
-DCMAKE_C_COMPILER=/b/sanitizer-aarch64-linux-bootstrap-hwa
vgvassilev wrote:
Very strange. I did not see a lot of platforms failing. If we decide to keep
that commit, is there a way to disable this test for exactly that platform?
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe
vgvassilev wrote:
> Not sure, nothing in cmake cmd:
>
> ```
> cmake -DLLVM_APPEND_VC_REV=OFF -GNinja -DCMAKE_BUILD_TYPE=Release
> -DLLVM_CCACHE_BUILD=ON -DLLVM_USE_LINKER=lld -DLLVM_ENABLE_ASSERTIONS=ON
> -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF
> -DCMAKE_C_COMPILER=/b/sanitizer-aarch64-linux
vitalybuka wrote:
> @vitalybuka could it be a ccache glitch?
Technically can, but I would not count on hash collision :)
Also there are two machines running same config consistently fail.
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commi
vitalybuka wrote:
Try `// UNSUPPORTED: hwasan`
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vitalybuka wrote:
Actually I will try myself, as I have access to the bot.
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidSpickett wrote:
> I will get you instructions on how to do that (will be tomorrow at this
> point).
https://github.com/llvm/llvm-project/issues/94741#issuecomment-2154656315
There is some underlying issue
(https://github.com/llvm/llvm-project/issues/94741), so if you want to try and
fix
DavidSpickett wrote:
Actually, as someone pointed out, I've been conflating clang-repl with the
constant expression interpreter. So the issue covers the latter and this must
be something else.
https://github.com/llvm/llvm-project/pull/89811
___
cfe-c
vgvassilev wrote:
Could be. Is there a way for me to debug this?
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vgvassilev wrote:
Perhaps we can disable this platform if we have a way to express the setup in
lit.
https://github.com/llvm/llvm-project/pull/89811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
DavidSpickett wrote:
You can debug it by cross-compiling a debug build, then running the unit tests
binary and connecting to qemu's built in gdbserver. The Arm toolchain might
have a copy of gdb in it already, but if not, gdb multiarch and lldb would also
work (which are both installable from
vgvassilev wrote:
> You can debug it by cross-compiling a debug build, then running the unit
> tests binary and connecting to qemu's built in gdbserver. The Arm toolchain
> might have a copy of gdb in it already, but if not, gdb multiarch and lldb
> would also work (which are both installable
47 matches
Mail list logo
