History log of /llvm-project/clang/test/Interpreter/const.cpp (Results 1 – 10 of 10)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...