[clang-repl] [test] Make an XFAIL more precise #70991
Conversation
The const.cpp testcase fails when running in MSVC mode, while they
do succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected,
as the printout looks like this:
A(1), this = 0000025597930000
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
While the expected printout looks like this:
A(1), this = 000002C903E10000
f: this = 000002C903E10000, val = 1
f: this = 000002C903E10000, val = 1
~A, this = 000002C903E10000, val = 1
|
@llvm/pr-subscribers-clang Author: Martin Storsjö (mstorsjo) ChangesThe const.cpp testcase fails when running in MSVC mode, while it does succeed in MinGW mode. In MSVC mode, there are more constructor invocations than expected, as the printout looks like this: While the expected printout looks like this: Full diff: https://github.com/llvm/llvm-project/pull/70991.diff 1 Files Affected:
diff --git a/clang/test/Interpreter/const.cpp b/clang/test/Interpreter/const.cpp
index 4b6ce65e3643e64..1412a1d85d6f58f 100644
--- a/clang/test/Interpreter/const.cpp
+++ b/clang/test/Interpreter/const.cpp
@@ -1,6 +1,6 @@
// UNSUPPORTED: system-aix
// see https://github.com/llvm/llvm-project/issues/68092
-// XFAIL: system-windows
+// XFAIL: target={{.*}}-windows-msvc
// RUN: cat %s | clang-repl | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -O2 | FileCheck %s
|
No idea actually, but I tested passing Not sure at what level some JIT deduplication should be happening, but anyway, the MSVC C++ ABI is distinctly different from the Itanium C++ ABI, in most aspects. |
|
This broke on PS5 bots, like https://lab.llvm.org/buildbot/#/builders/216/builds/29677; those are configured with a triple like Not sure whom to CC to pull in Sony people to discuss this matter, so trying @pogo59. Can we use something like |
This reverts commit 3bc056d. This broke on bots with a target triple of x86_64-sie-ps5, which also appear to behave like the MSVC case.
|
FTR, the "Worker" tab on that buildbot page will point you to the maintainer. But tagging me is also fine in general. |
|
If you want to XFAIL specifically for the Sony targets, what you suggested would work. |
Ah, there it is, I tried looking around, but overlooked that one...
Ok, thanks!
Not sure - by doing
Ok, great, thanks! I'll try that and reland the commit. |
|
If you still need help reproducing or debugging the issue on our bot, please let me know. |
Thanks, much appreciated. Can you test if mstorsjo@clang-repl-xfail seems to run correctly in this environment? Otherwise I'll try to push it tomorrow and see how it fares on the bot. |
Sure, I'll take it down this evening sometime and give it a try. |
It failed, but due to a typo in the XFAIL you added: These should have balanced braces. If I add the missing braces, the test passes with an XFAIL on the bot. |
Oh, oops - but thanks for checking and verifying with the typo fixed. I'll try to reland this change now then, with that fixed. Thanks again! |
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as
the printout looks like this:
A(1), this = 0000025597930000
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
While the expected printout looks like this:
A(1), this = 000002C903E10000
f: this = 000002C903E10000, val = 1
f: this = 000002C903E10000, val = 1
~A, this = 000002C903E10000, val = 1
Reapplying with the XFAIL pattern expanded to include PS4/PS5
triples as well, which also seem to have the same behaviour
as MSVC.
This reverts commit e9db60c. This was still failing (unexpectedly passing) on some Sony PS buildbots. The issue is that the clang-repl testcases don't depend on what the default target triple is, but what the host triple is, which is used for JIT purposes.
…0991) The const.cpp testcase fails when running in MSVC mode, while it does succeed in MinGW mode. In MSVC mode, there are more constructor invocations than expected, as the printout looks like this: A(1), this = 0000025597930000 A(1), this = 0000025597930000 f: this = 0000025597930000, val = 1 A(1), this = 0000025597930000 f: this = 0000025597930000, val = 1 ~A, this = 0000025597930000, val = 1 ~A, this = 0000025597930000, val = 1 ~A, this = 0000025597930000, val = 1 While the expected printout looks like this: A(1), this = 000002C903E10000 f: this = 000002C903E10000, val = 1 f: this = 000002C903E10000, val = 1 ~A, this = 000002C903E10000, val = 1 Reapplying with the XFAIL changed to check the host triple, not the target triple. On an MSVC based build of Clang, but with the default target triple set to PS4/PS5, we will still see the failure. And a Linux based build of Clang that targets PS4/PS5 won't see the issue.
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as
the printout looks like this:
A(1), this = 0000025597930000
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
While the expected printout looks like this:
A(1), this = 000002C903E10000
f: this = 000002C903E10000, val = 1
f: this = 000002C903E10000, val = 1
~A, this = 000002C903E10000, val = 1
Reapplying #70991 with the XFAIL changed to check the host triple, not
the target triple. On an MSVC based build of Clang, but with the default
target triple set to PS4/PS5, we will still see the failure. And a Linux
based build of Clang that targets PS4/PS5 won't see the issue.
The const.cpp testcase fails when running in MSVC mode, while it does succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as the printout looks like this:
While the expected printout looks like this: