|
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3 |
|
| #
ba400539 |
| 13-Aug-2024 |
Vitaly Buka <vitalybuka@google.com> |
[Interp] Mark the test unsupported with Asan (#102859)
It's very flaky recently.
10 bulds are OK, then 3 failed:
https://lab.llvm.org/buildbot/#/builders/52/builds/1524
https://lab.llvm.org/bui
[Interp] Mark the test unsupported with Asan (#102859)
It's very flaky recently.
10 bulds are OK, then 3 failed:
https://lab.llvm.org/buildbot/#/builders/52/builds/1524
https://lab.llvm.org/buildbot/#/builders/52/builds/1525
https://lab.llvm.org/buildbot/#/builders/52/builds/1526
then 3 OK
https://lab.llvm.org/buildbot/#/builders/52/builds/1531
https://lab.llvm.org/buildbot/#/builders/52/builds/1532
then 2 green again
We need to stop to spam blame list by disabling the test,
and investigate later if Asan is valuable for the test.
Issue #102858
show more ...
|
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6 |
|
| #
c9ab1d89 |
| 07-May-2024 |
Sean Perry <39927768+perry-ca@users.noreply.github.com> |
Mark test cases as unsupported on z/OS (#90990)
These test cases are testing features not available when either
targeting the s390x-ibm-zos target or use tools/features not available
on the z/OS o
Mark test cases as unsupported on z/OS (#90990)
These test cases are testing features not available when either
targeting the s390x-ibm-zos target or use tools/features not available
on the z/OS operating system. In a couple cases the lit test had a
number of subtests with one or two that aren't supported on z/OS. Rather
than mark the entire test as unsupported I split out the unsupported
tests into a separate test case.
show more ...
|
|
Revision tags: llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5 |
|
| #
2c4f938f |
| 07-Nov-2023 |
Martin Storsjö <martin@martin.st> |
Reapply #2 [clang-repl] [test] Make an XFAIL more precise (#71168)
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more const
Reapply #2 [clang-repl] [test] Make an XFAIL more precise (#71168)
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.
show more ...
|
| #
89a336ad |
| 03-Nov-2023 |
Martin Storsjö <martin@martin.st> |
Revert "Reapply [clang-repl] [test] Make an XFAIL more precise (#70991)"
This reverts commit e9db60c05e2fb96ff40cbb1f78790abc5de9237e.
This was still failing (unexpectedly passing) on some Sony PS
b
Revert "Reapply [clang-repl] [test] Make an XFAIL more precise (#70991)"
This reverts commit e9db60c05e2fb96ff40cbb1f78790abc5de9237e.
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.
show more ...
|
| #
e9db60c0 |
| 02-Nov-2023 |
Martin Storsjö <martin@martin.st> |
Reapply [clang-repl] [test] Make an XFAIL more precise (#70991)
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor
Reapply [clang-repl] [test] Make an XFAIL more precise (#70991)
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.
show more ...
|
| #
b73d7390 |
| 02-Nov-2023 |
Martin Storsjö <martin@martin.st> |
Revert "[clang-repl] [test] Make an XFAIL more precise (#70991)"
This reverts commit 3bc056d5f0ebe9e4074afa088c3a0355f9ab901a.
This broke on bots with a target triple of x86_64-sie-ps5,
which also
Revert "[clang-repl] [test] Make an XFAIL more precise (#70991)"
This reverts commit 3bc056d5f0ebe9e4074afa088c3a0355f9ab901a.
This broke on bots with a target triple of x86_64-sie-ps5,
which also appear to behave like the MSVC case.
show more ...
|
| #
3bc056d5 |
| 02-Nov-2023 |
Martin Storsjö <martin@martin.st> |
[clang-repl] [test] Make an XFAIL more precise (#70991)
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor invo
[clang-repl] [test] Make an XFAIL more precise (#70991)
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
show more ...
|
|
Revision tags: llvmorg-17.0.4, llvmorg-17.0.3 |
|
| #
4812eecd |
| 03-Oct-2023 |
Jonas Hahnfeld <jonas.hahnfeld@cern.ch> |
[clang-repl] XFAIL new const.cpp test on Windows
Still failing after the previous commit:
https://lab.llvm.org/buildbot/#/builders/216/builds/28268
|
| #
b6ee41f8 |
| 03-Oct-2023 |
Jonas Hahnfeld <jonas.hahnfeld@cern.ch> |
[clang-repl] Relax regular expression for new const.cpp test
This should fix the failing test on Windows:
https://lab.llvm.org/buildbot/#/builders/216/builds/28266
|
| #
05137ecf |
| 03-Oct-2023 |
Jonas Hahnfeld <jonas.hahnfeld@cern.ch> |
[clang-repl] Emit const variables only once (#65257)
Disable internal linkage for const variables if IncrementalExtensions
are enabled. Otherwise the variables are emitted multiple times, with
mul
[clang-repl] Emit const variables only once (#65257)
Disable internal linkage for const variables if IncrementalExtensions
are enabled. Otherwise the variables are emitted multiple times, with
multiple constructions at unique memory locations, during every PTU.
show more ...
|