> From: Deepesh Varatharajan <Deepesh.Varatharajan@...>
>
> This patch series introduces a test framework to run selftests for
> target builds of Clang, LLVM, and LLD.
Hi Deepesh,
I ran into several issues specifically on 32-bit PowerPC (MACHINE=qemuppc,
TUNE=ppc7400)
that I'd like to report:
1. QEMU boot fails outright with the hardcoded -smp 4 :
qemu-system-ppc: Invalid SMP CPUs 4. The max CPUs supported by machine
'mac99' is 1
The "mac99" QEMU machine model used for qemuppc only supports a single
vCPU, so,
start_qemu_nfs() needs to special-case the CPU (and RAM, mac99 also caps at
2GiB)
count per target arch instead of hardcoding -m 8192 -smp 4 .
2. Building clang with the default PACKAGECONFIG (which includes "clangd")
fails on ppc32
while compiling clang-tools-extra/clangd's CompletionModel.cpp:
{standard input}:177591: Error: operand out of range (0x81f8 is not
between 0xffffffffffff8000 and 0x7fff)
CompletionModel.cpp embeds a large static ML-model lookup table; codegen
the compiler emits
displacement relocations exceeding the assembler's 16-bit signed immediate
range. This is
a long-standing, unresolved LLVM/GCC ppc32 codegen issue, not specific to
this recipe:
https://bugs.gentoo.org/829602
https://reviews.llvm.org/D136283
https://reviews.llvm.org/D139107
All of them resolve it the same way: don't build clangd on ppc32. I'll send
this as a separate patch
against clang_git.bb (disabling "clangd" in PACKAGECONFIG for the
powerpc/powerpcle overrides),
since it's independent of the selftest changes and affects the recipe
regardless of whether these tests
are run.
3. Even once the above are fixed and the test suite runs on qemuppc
ClangSelfTestSystemEmulated.test_clang takes about 16 hours (Testing Time:
59358.78s).
That's a very long pole for a CI job on this target.
4. With the above fixed, the run still reports the following consistent
failures on qemuppc:
Failed Tests (11):
LLVM :: ExecutionEngine/Orc/global-ctor-order.ll
LLVM :: ExecutionEngine/Orc/global-ctor-with-cast.ll
LLVM :: ExecutionEngine/Orc/global-variable-alignment.ll
LLVM :: ExecutionEngine/Orc/trivial-call-to-function.ll
LLVM :: ExecutionEngine/Orc/trivial-call-to-internal-function.ll
LLVM :: ExecutionEngine/Orc/trivial-reference-to-global-variable.ll
LLVM ::
ExecutionEngine/Orc/trivial-reference-to-internal-variable-nonzeroinit.ll
LLVM :: ExecutionEngine/Orc/trivial-reference-to-internal-variable-zeroinit.ll
LLVM :: ExecutionEngine/Orc/trivial-return-zero.ll
LLVM :: ExecutionEngine/Orc/weak-comdat.ll
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/0/1
Failed Tests (21):
Clang :: Interpreter/access.cpp
Clang :: Interpreter/assignment-with-implicit-ctor.cpp
Clang :: Interpreter/bad_percent_command.cpp
Clang :: Interpreter/code-undo.cpp
Clang :: Interpreter/const.cpp
Clang :: Interpreter/dynamic-library-bad-args.cpp
Clang :: Interpreter/execute-pch.cpp
Clang :: Interpreter/execute-stmts.cpp
Clang :: Interpreter/execute-weak.cpp
Clang :: Interpreter/execute.c
Clang :: Interpreter/execute.cpp
Clang :: Interpreter/fail.cpp
Clang :: Interpreter/global-dtor.cpp
Clang :: Interpreter/help.cpp
Clang :: Interpreter/incremental-mode.cpp
Clang :: Interpreter/inline-virtual.cpp
Clang :: Interpreter/lambda.cpp
Clang :: Interpreter/multiline.cpp
Clang :: Interpreter/pretty-print.c
Clang :: Interpreter/pretty-print.cpp
Clang :: Interpreter/simple-exception.cpp
All of these are clang-repl / ORC JIT related, which suggests the JIT backend
may simply
not support ppc32 (or not reliably in this emulated environment).
Given the combination of (3) the very long runtime and (4) a consistent set of
JIT-related failures,
I'd like to ask: would it be acceptable to disable this test suite entirely for
32-bit PowerPC, or
would you prefer patches that make the tests pass on ppc32?
Regards, Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246047):
https://lists.openembedded.org/g/openembedded-core/message/246047
Mute This Topic: https://lists.openembedded.org/mt/120572724/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-