[llvm-bugs] [Bug 38419] std::filesystem::path::native() should return an std::wstring on Windows
https://bugs.llvm.org/show_bug.cgi?id=38419 Martin Storsjö changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Martin Storsjö --- This should all be fixed now, by e.g. e83e0cac041bc071301f8399bb5c32b2529fc83f ([libcxx] Make filesystem::path::value_type wchar_t on windows) and f4f5fb915104887fefa602cfcbd1d4fc8447d46b ([libcxx] Make generic_*string return paths with forward slashes on windows). Also note that before, while you could observe these incorrect behaviours in the header, it wasn't even possible to build libc++ with filesystem enabled for windows, until around cdc60a3b9aa523b49329a7a5e4c1774d3b9e3db9. Before that, you could do trivial header-only operations, but as soon as you'd try to do something that requires linking against the lib, it'd fail. (Also, after 933518fff82c8f39626bbcca81adc516483a9651, trying to use header-only bits of will fail if the lib was built with filesystem disabled.) Now at this point, the filesystem code can be built for windows, but it's only enabled by default for mingw targets. In MSVC configurations, you'll still run into a missing runtime helper for __int128, see https://reviews.llvm.org/D91139 and https://reviews.llvm.org/D91413 for various ways of getting around that. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49333, which changed state. Bug 49333 Summary: Compilation error in NVPTX deviceRLTs https://bugs.llvm.org/show_bug.cgi?id=49333 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49333] Compilation error in NVPTX deviceRLTs
https://bugs.llvm.org/show_bug.cgi?id=49333 Joachim Protze changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #9 from Joachim Protze --- Thanks, works now! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49407] New: TestFixIts: test_with_multiple_retries gets SIGILL
https://bugs.llvm.org/show_bug.cgi?id=49407
Bug ID: 49407
Summary: TestFixIts: test_with_multiple_retries gets SIGILL
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: mgo...@gentoo.org
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Apparently already XFAIL-ed on Linux, I'll be adding FreeBSD for the same
reason:
==
FAIL: test_with_multiple_retries_dwarf (TestFixIts.ExprCommandWithFixits)
Test calling expressions with errors that can be fixed by the FixIts.
--
Traceback (most recent call last):
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1846, in test_method
return attrvalue(self)
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 119, in wrapper
func(*args, **kwargs)
File
"/home/mgorny/llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py",
line 161, in test_with_multiple_retries
self.expect_expr("test_X(1)", result_type="int", result_value="123")
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2609, in expect_expr
value_check.check_value(self, eval_result, str(eval_result))
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 284, in check_value
test_base.assertSuccess(val.GetError())
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2671, in assertSuccess
"'{}' is not success".format(error)))
AssertionError: 'error: Execution was interrupted, reason: signal SIGILL:
illegal trap.
The process has been returned to the state before expression evaluation.
' is not success
Config=aarch64-/home/mgorny/llvm-project/build.arm64/bin/clang
--
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49408] New: TestMultilineCompletion: test_basic_completion times out on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=49408
Bug ID: 49408
Summary: TestMultilineCompletion: test_basic_completion times
out on FreeBSD
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: mgo...@gentoo.org
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Might also be related to pexpect or libedit.
TEST 'lldb-api ::
commands/expression/multiline-completion/TestMultilineCompletion.py' FAILED
Script:
--
/usr/local/bin/python3.7 /home/mgorny/llvm-project/lldb/test/API/dotest.py -u
CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
--env LLVM_LIBS_DIR=/home/mgorny/llvm-project/build.arm64/./lib --arch aarch64
--build-dir /home/mgorny/llvm-project/build.arm64/lldb-test-build.noindex
--lldb-module-cache-dir
/home/mgorny/llvm-project/build.arm64/lldb-test-build.noindex/module-cache-lldb/lldb-api
--clang-module-cache-dir
/home/mgorny/llvm-project/build.arm64/lldb-test-build.noindex/module-cache-clang/lldb-api
--executable /home/mgorny/llvm-project/build.arm64/./bin/lldb --compiler
/home/mgorny/llvm-project/build.arm64/./bin/clang --dsymutil
/home/mgorny/llvm-project/build.arm64/./bin/dsymutil --llvm-tools-dir
/home/mgorny/llvm-project/build.arm64/./bin --lldb-libs-dir
/home/mgorny/llvm-project/build.arm64/./lib
/home/mgorny/llvm-project/lldb/test/API/commands/expression/multiline-completion
-p TestMultilineCompletion.py
--
Exit Code: 1
Command Output (stdout):
--
lldb version 13.0.0
Libc++ tests will not be run because: Don't know how to build with libc++ on
freebsd
libstdcxx tests will not be run because: Don't know how to build with libstdcxx
on freebsd
Skipping following debug info categories: ['dwo', 'dsym', 'gmodules']
objc tests will be skipped because of unsupported platform
--
Command Output (stderr):
--
FAIL: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) ::
test_basic_completion (TestMultilineCompletion.MultilineCompletionTest)
==
ERROR: test_basic_completion (TestMultilineCompletion.MultilineCompletionTest)
Test that we can complete a simple multiline expression
--
Traceback (most recent call last):
File
"/home/mgorny/llvm-project/lldb/third_party/Python/module/pexpect-4.6/pexpect/expect.py",
line 111, in expect_loop
incoming = spawn.read_nonblocking(spawn.maxread, timeout)
File
"/home/mgorny/llvm-project/lldb/third_party/Python/module/pexpect-4.6/pexpect/pty_spawn.py",
line 482, in read_nonblocking
raise TIMEOUT('Timeout exceeded.')
pexpect.exceptions.TIMEOUT: Timeout exceeded.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 149, in wrapper
return func(*args, **kwargs)
File
"/home/mgorny/llvm-project/lldb/test/API/commands/expression/multiline-completion/TestMultilineCompletion.py",
line 45, in test_basic_completion
self.child.expect(re.compile(b"to_(\r" +
self.cursor_forward_escape_seq(len(" 1: to_")) + b")?complete"))
File
"/home/mgorny/llvm-project/lldb/third_party/Python/module/pexpect-4.6/pexpect/spawnbase.py",
line 341, in expect
timeout, searchwindowsize, async_)
File
"/home/mgorny/llvm-project/lldb/third_party/Python/module/pexpect-4.6/pexpect/spawnbase.py",
line 369, in expect_list
return exp.expect_loop(timeout)
File
"/home/mgorny/llvm-project/lldb/third_party/Python/module/pexpect-4.6/pexpect/expect.py",
line 119, in expect_loop
return self.timeout(e)
File
"/home/mgorny/llvm-project/lldb/third_party/Python/module/pexpect-4.6/pexpect/expect.py",
line 82, in timeout
raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: Timeout exceeded.
command: /home/mgorny/llvm-project/build.arm64/bin/lldb
args: ['/home/mgorny/llvm-project/build.arm64/bin/lldb', '--no-lldbinit',
'--no-use-colors', '-O', 'settings clear -all', '-O', 'settings set
symbols.enable-external-lookup false', '-O', 'settings set target.inherit-tcc
true', '-O', 'settings set target.detach-on-error false', '-O', 'settings set
target.auto-apply-fixits false', '-O', 'settings set
plugin.process.gdb-remote.packet-timeout 60', '-O', 'settings set
symbols.clang-modules-cache-path
"/home/mgorny/llvm-project/build.arm64/lldb-test-build.noindex/module-cache-lldb/lldb-api"',
'-O', 'settings set use-color false', '-O', 'setting set
target.prefer-dynamic-value no-dynamic-values', '--file',
'/home/mgorny/llvm-project/build.arm64/lldb-test-build.noindex/commands/expression/multiline-completion/TestMultilineCompletion.test_basic_completion/a.out']
buffer (las
[llvm-bugs] [Bug 49409] New: const variable cannot be implicitly captured in a lambda with no capture-default specified
https://bugs.llvm.org/show_bug.cgi?id=49409
Bug ID: 49409
Summary: const variable cannot be implicitly captured in a
lambda with no capture-default specified
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: hewi...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Clang rejected the following code with -std=c++20 flag (but GCC and MSVC do
not):
auto f() {
const auto x = 1;
return [] (auto) { return x; };
}
godbolt: https://godbolt.org/z/1174Tv
discussion:
https://stackoverflow.com/questions/66456916/implicitly-capture-const-variable-in-a-template-lambda-with-no-capture-default-s
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32955] Crash in infinite loop trying to find a proper constructor
https://bugs.llvm.org/show_bug.cgi?id=32955 Volker Reichelt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Volker Reichelt --- This is fixed since at least version 8.0.0, maybe even earlier. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49410] New: constexpr static data member template cause an error: static data member 'v' already has an initializer
https://bugs.llvm.org/show_bug.cgi?id=49410
Bug ID: 49410
Summary: constexpr static data member template cause an error:
static data member 'v' already has an initializer
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: danny321974...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
When compile the constexpr variable template below with option -std=c++14
struct A {
template
static constexpr T v{};
};
template
constexpr T A::v;
int main()
{
auto ptr1 = &A::v;
auto ptr2 = &A::v; // no error if remove this line
}
generates the error below:
clang_cxx14.cpp:3:25: error: static data member 'v' already has an initializer
static constexpr T v{};
^
clang_cxx14.cpp:10:21: note: in instantiation of static data member 'A::v'
requested here
auto ptr1 = &A::v;
^
clang_cxx14.cpp:3:25: note: previous initialization is here
static constexpr T v{};
^
1 error generated.
No error in -std=c++17 or above
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26413] movaps is generated in interrupt handler
https://bugs.llvm.org/show_bug.cgi?id=26413 Melanie Blower changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43321] Segmentation fault in clang::NestedNameSpecifier::containsUnexpandedParameterPack
https://bugs.llvm.org/show_bug.cgi?id=43321 Sam McCall changed: What|Removed |Added CC||sammcc...@google.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Sam McCall --- This was fixed sometime between 9 and 10. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49411] New: local variables are allowed as default parameters in template list
https://bugs.llvm.org/show_bug.cgi?id=49411
Bug ID: 49411
Summary: local variables are allowed as default parameters in
template list
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: hewi...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following code accept by Clang:
auto f() {
const auto x = 1;
[] {};
}
But local variables are not allowed as default parameters.
godbolt: https://godbolt.org/z/TzxT9z
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47602] __internal::__lazy_and needs to be more lazy
https://bugs.llvm.org/show_bug.cgi?id=47602 Louis Dionne changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||053146a690774f8955893fbb995 ||ae176eb2e00a7 --- Comment #2 from Louis Dionne --- commit 053146a690774f8955893fbb995ae176eb2e00a7 Author: Louis Dionne Date: Tue Mar 2 16:53:07 2021 -0500 [pstl] Fix broken policy_traits and clean up unused code https://llvm.org/PR47602 https://llvm.org/PR47601 Differential Revision: https://reviews.llvm.org/D97808 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47601] Non-reserved names in pstl/execution_impl.h
https://bugs.llvm.org/show_bug.cgi?id=47601 Louis Dionne changed: What|Removed |Added Fixed By Commit(s)||053146a690774f8955893fbb995 ||ae176eb2e00a7 Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #3 from Louis Dionne --- commit 053146a690774f8955893fbb995ae176eb2e00a7 Author: Louis Dionne Date: Tue Mar 2 16:53:07 2021 -0500 [pstl] Fix broken policy_traits and clean up unused code https://llvm.org/PR47602 https://llvm.org/PR47601 Differential Revision: https://reviews.llvm.org/D97808 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49413] New: elaborated-enum-base incompatible with NS_ENUM
https://bugs.llvm.org/show_bug.cgi?id=49413
Bug ID: 49413
Summary: elaborated-enum-base incompatible with NS_ENUM
Product: clang
Version: 11.0
Hardware: All
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: lhun...@lyndir.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Related to
https://github.com/llvm/llvm-project/commit/c90e198107431f64b73686bdce31c293e3380ac7
The new `-Welaborated-enum-base` appears to be incompatible with macros to
define nonfixed type enums.
One such example is Apple's NS_ENUM, which effectively translates:
```
typedef NS_ENUM( X, unsigned int) {
...
}
```
into:
```
typedef enum X : unsigned int X;
enum X : unsigned int {
```
Which triggers:
```
fatal error: non-defining declaration of enumeration with a fixed underlying
type is only permitted as a standalone declaration; missing list of
enumerators? [-Welaborated-enum-base]
```
The idea behind macros such as `NS_ENUM` is that they type the enum if
supported by the compiler, as well as hide the `enum` type keyword.
Unfortunately, the only way to do this now would be to remove the nonfixed type
from the typedef, but this causes another problem:
```
error: enumeration previously declared with nonfixed underlying type
```
This can only be addressed by moving the typedef below the enum declaration,
but unfortunately it appears that this is impossible to achieve with a macro.
Consequently, `clang` can no longer compile `NS_ENUM`-style macros, and there
is no path for resolving the issue other than by disabling
`elaborated-enum-base`.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40230] padding in nested std::pair
https://bugs.llvm.org/show_bug.cgi?id=40230 Louis Dionne changed: What|Removed |Added Fixed By Commit(s)||r351290 Status|CONFIRMED |RESOLVED CC||ldio...@apple.com Resolution|--- |FIXED --- Comment #9 from Louis Dionne --- Looks like this has been fixed, so I'm going to close this to clean up the bug list. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49414] New: TestGDBRemoteLoad fails on FreeBSD/aarch64
https://bugs.llvm.org/show_bug.cgi?id=49414 Bug ID: 49414 Summary: TestGDBRemoteLoad fails on FreeBSD/aarch64 Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: mgo...@gentoo.org CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org FAIL: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) :: test_flash_load (TestGDBRemoteLoad.TestGDBRemoteLoad) FAIL: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) :: test_module_load_address (TestGDBRemoteLoad.TestGDBRemoteLoad) FAIL: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) :: test_ram_load (TestGDBRemoteLoad.TestGDBRemoteLoad) The error involves huge protocol output. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49415] New: TestLinuxCore: two aarch64 reg test cases fail on FreeBSD/aarch64
https://bugs.llvm.org/show_bug.cgi?id=49415
Bug ID: 49415
Summary: TestLinuxCore: two aarch64 reg test cases fail on
FreeBSD/aarch64
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: mgo...@gentoo.org
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
FAIL: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) ::
test_aarch64_regs (TestLinuxCore.LinuxCoreTestCase)
FAIL: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) ::
test_aarch64_sve_regs_fpsimd (TestLinuxCore.LinuxCoreTestCase)
The results look a bit suspicious -- like a rounding/printing problem. I
wonder if it could be affected by some subtle stdlib difference.
==
FAIL: test_aarch64_regs (TestLinuxCore.LinuxCoreTestCase)
--
Traceback (most recent call last):
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 149, in wrapper
return func(*args, **kwargs)
File
"/home/mgorny/llvm-project/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py",
line 348, in test_aarch64_regs
substrs=["{} = {}".format(regname, value)])
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2566, in expect
self.fail(log_msg)
AssertionError: Ran command:
"register read d4"
Got output:
d4 = 0
Expecting sub string: "d4 = 5.35161536149201e-315" (was not found)
Config=aarch64-/home/mgorny/llvm-project/build.arm64/bin/clang
==
FAIL: test_aarch64_sve_regs_fpsimd (TestLinuxCore.LinuxCoreTestCase)
--
Traceback (most recent call last):
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 149, in wrapper
return func(*args, **kwargs)
File
"/home/mgorny/llvm-project/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py",
line 435, in test_aarch64_sve_regs_fpsimd
substrs=["{} = {}".format(regname, value)])
File
"/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2566, in expect
self.fail(log_msg)
AssertionError: Ran command:
"register read d4"
Got output:
d4 = 0
Expecting sub string: "d4 = 5.35161536149201e-315" (was not found)
Config=aarch64-/home/mgorny/llvm-project/build.arm64/bin/clang
--
Ran 18 tests in 37.985s
RESULT: FAILED (16 passes, 2 failures, 0 errors, 0 skipped, 0 expected
failures, 0 unexpected successes)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49413] elaborated-enum-base incompatible with NS_ENUM
https://bugs.llvm.org/show_bug.cgi?id=49413 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Smith --- The macro in question generates ill-formed code in C++; note that GCC and ICC also reject. As a result, Clang generates an error by default. (The code generated by the macro is valid in Objective-C and Objective-C++, though.) Because Clang historically incorrectly accepted this, and in particular because Apple's NS_ENUM macro currently relies on that compiler bug, we allow the error for this non-conforming code to be disabled with -Wno-elaborated-enum-base. If you need to keep building such code and can't fix it to be valid C++, you can use that flag to allow Clang to accept the code (but it will not be portable to other compilers). Hopefully Apple will fix their macro at some point, if they've not done so already. For example, this can be done with something like: #ifdef __cplusplus #define NS_ENUM(name, underlying) \ void NS_ENUM_##name##_typedef(); \ enum name : underlying #else // old definition #endif (where the first line of the macro expansion exists only to effectively swallow the preceding `typedef` keyword, which is useless in C++). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49416] New: Converting between pointers to signed and unsigned _ExtInt causes crash
https://bugs.llvm.org/show_bug.cgi?id=49416
Bug ID: 49416
Summary: Converting between pointers to signed and unsigned
_ExtInt causes crash
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: wilcox...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The following code causes clang trunk to crash.
// -
// https://godbolt.org/z/z138v6
// -
void f(unsigned _ExtInt(32)* n);
void g(_ExtInt(32)* n) {
f(n);
}
// -
It's unclear to me whether this program is intended to be supported by _ExtInt
or not, but in either case, it should not cause a crash.
Inserting a cast seems to work around the problem:
// -
// https://godbolt.org/z/nKKPY7
// -
void f(unsigned _ExtInt(32)* n);
void g(_ExtInt(32)* n) {
f((unsigned _ExtInt(32)*)n);
}
// -
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 28534 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_predication: Out-of-memory in llvm-opt-fuzzer--x86_64-loop_predication
Updates: Labels: Deadline-Approaching Comment #1 on issue 28534 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-loop_predication: Out-of-memory in llvm-opt-fuzzer--x86_64-loop_predication https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28534#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49417] New: Bind behavior mismatch when -platform_version is specified
https://bugs.llvm.org/show_bug.cgi?id=49417 Bug ID: 49417 Summary: Bind behavior mismatch when -platform_version is specified Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: jezr...@gmail.com CC: g...@fb.com, jezr...@gmail.com, llvm-bugs@lists.llvm.org, smee...@fb.com ld64 doesn't emit bind opcodes for the various dynamically-linked symbols in our stub-link.s test when `-platform_version` is specified. LLD currently emits the bind opcodes regardless. I don't see how not emitting the binds could possibly be the desired behavior, but I haven't dug much into it. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49418] New: TestVSCode_module: test_compile_units fails due to extra units on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=49418
Bug ID: 49418
Summary: TestVSCode_module: test_compile_units fails due to
extra units on FreeBSD
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: mgo...@gentoo.org
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
It seems that it gets some system files on the list too on FreeBSD. If I add a
print-debug, I get:
[{'compileUnitPath': '/usr/src/lib/csu/aarch64/crt1_c.c'}, {'compileUnitPath':
'/usr/src/lib/csu/aarch64/crt1_s.S'}, {'compileUnitPath':
'/usr/src/lib/csu/aarch64/crti.S'}, {'compileUnitPath':
'/usr/src/lib/csu/common/crtbegin.c'}, {'compileUnitPath':
'/home/mgorny/llvm-project/lldb/test/API/tools/lldb-vscode/module/main.cpp'},
{'compileUnitPath': '/usr/src/lib/csu/common/crtend.c'}, {'compileUnitPath':
'/usr/src/lib/csu/aarch64/crtn.S'}]
TEST 'lldb-api ::
tools/lldb-vscode/module/TestVSCode_module.py' FAILED
Script:
--
/usr/local/bin/python3.7 /home/mgorny/llvm-project/lldb/test/API/dotest.py -u
CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
--env LLVM_LIBS_DIR=/home/mgorny/llvm-project/build.arm64/./lib --arch aarch64
--build-dir /home/mgorny/llvm-project/build.arm64/lldb-test-build.noindex
--lldb-module-cache-dir
/home/mgorny/llvm-project/build.arm64/lldb-test-build.noindex/module-cache-lldb/lldb-api
--clang-module-cache-dir
/home/mgorny/llvm-project/build.arm64/lldb-test-build.noindex/module-cache-clang/lldb-api
--executable /home/mgorny/llvm-project/build.arm64/./bin/lldb --compiler
/home/mgorny/llvm-project/build.arm64/./bin/clang --dsymutil
/home/mgorny/llvm-project/build.arm64/./bin/dsymutil --llvm-tools-dir
/home/mgorny/llvm-project/build.arm64/./bin --lldb-libs-dir
/home/mgorny/llvm-project/build.arm64/./lib
/home/mgorny/llvm-project/lldb/test/API/tools/lldb-vscode/module -p
TestVSCode_module.py
--
Exit Code: 1
Command Output (stdout):
--
lldb version 13.0.0
Libc++ tests will not be run because: Don't know how to build with libc++ on
freebsd
libstdcxx tests will not be run because: Don't know how to build with libstdcxx
on freebsd
Skipping following debug info categories: ['dwo', 'dsym', 'gmodules']
objc tests will be skipped because of unsupported platform
description: breakpoint 1.1
description: breakpoint 1.1
--
Command Output (stderr):
--
FAIL: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) ::
test_compile_units (TestVSCode_module.TestVSCode_module)
PASS: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) ::
test_modules (TestVSCode_module.TestVSCode_module)
UNSUPPORTED: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) ::
test_modules_dsym (TestVSCode_module.TestVSCode_module) (requires one of
macosx, darwin, ios, tvos, watchos, bridgeos, iphonesimulator, watchsimulator,
appletvsimulator)
==
FAIL: test_compile_units (TestVSCode_module.TestVSCode_module)
--
Traceback (most recent call last):
File
"/home/mgorny/llvm-project/lldb/test/API/tools/lldb-vscode/module/TestVSCode_module.py",
line 94, in test_compile_units
'Only one source file should exist')
AssertionError: 7 != 1 : Only one source file should exist
Config=aarch64-/home/mgorny/llvm-project/build.arm64/bin/clang
--
Ran 3 tests in 71.177s
RESULT: FAILED (1 passes, 1 failures, 0 errors, 1 skipped, 0 expected failures,
0 unexpected successes)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49413] elaborated-enum-base incompatible with NS_ENUM
https://bugs.llvm.org/show_bug.cgi?id=49413 Richard Smith changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- CC||aa...@aaronballman.com --- Comment #3 from Richard Smith --- The error is not produced in -x objective-c nor in -x objective-c++. The 'enum name : underlying' syntax is not valid at all in C. As a Clang extension, we permit the C++ language feature in C as well, so the error is produced in -x c++ and in -x c. Apparently we produce no diagnostic for that extension by default (for cases that are valid in C++), but all uses of 'enum E : underlying' are rejected in -x c under -pedantic-errors at least. Perhaps it would be better if, under -x c, we produced the warning for 'enum name : underlying' being a Clang extension by default, instead of silently accepting the invalid code. If we do, then producing a second extension diagnostic for nesting such an enum in a typedef seems unnecessary and we could turn that off for C compilations (effectively meaning that the C extension picks up the Objective-C feature, not the similar-but-more-constraining C++ feature). Aaron, as our champion of C conformance, what do you think? Silently accepting this C++ feature in C by default seems at least questionable to me. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 49406, which changed state. Bug 49406 Summary: suboptimal allocation of operands for "rm" inline assembly constraint https://bugs.llvm.org/show_bug.cgi?id=49406 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49406] suboptimal allocation of operands for "rm" inline assembly constraint
https://bugs.llvm.org/show_bug.cgi?id=49406 Eli Friedman changed: What|Removed |Added Status|NEW |RESOLVED CC||efrie...@quicinc.com Resolution|--- |DUPLICATE --- Comment #1 from Eli Friedman --- *** This bug has been marked as a duplicate of bug 20197 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 31675 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExceptionSpecInfo
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-03-04 Type: Bug New issue 31675 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExceptionSpecInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31675 Detailed Report: https://oss-fuzz.com/testcase?key=5910946292826112 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc1ae47d98 Crash State: clang::FunctionProtoType::getExceptionSpecInfo clang::FunctionProtoType::getExtProtoInfo clang::FunctionProtoType::Profile Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202102280605:202103010627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5910946292826112 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49419] New: [LLVM-COV] No coverage with "Segmentation fault (core dumped)"
https://bugs.llvm.org/show_bug.cgi?id=49419
Bug ID: 49419
Summary: [LLVM-COV] No coverage with "Segmentation fault (core
dumped)"
Product: Runtime Libraries
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: cnwy1...@outlook.com
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/wangyang/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat test.c
#include
char fixed_regs[0x0008];
int main() {
printf("PASSED\n");
return fixed_regs[0x000ff000];
}
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw
test.c; ./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov
show a.out -instr-profile=test.profdata test.c > test.lcov; cat test.lcov
PASSED
Segmentation fault (core dumped)
1| |#include
2| |char fixed_regs[0x0008];
3| |
4| 0|int main() {
5| 0|printf("PASSED\n");
6| 0|return fixed_regs[0x000ff000];
7| 0|}
8| |
Obviously, main function has been execute. However, no coverage information
generated.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49420] New: [LLVM-COV] No coverage with "Aborted(core dumped)"
https://bugs.llvm.org/show_bug.cgi?id=49420
Bug ID: 49420
Summary: [LLVM-COV] No coverage with "Aborted(core dumped)"
Product: Runtime Libraries
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: cnwy1...@outlook.com
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/wangyang/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat test.c
#include
#include
extern void abort(void);
#ifdef __x86_64__
#define EFLAGS_TYPE unsigned long long int
#else
#define EFLAGS_TYPE unsigned int
#endif
int main() {
printf("1\n");
EFLAGS_TYPE flags = 0xD7; /* 111010111b */
__writeeflags(flags);
flags = __readeflags();
printf("2\n");
if ((flags & 0xFF) != 0xD7)
abort();
printf("3\n");
#ifdef DEBUG
printf("PASSED\n");
#endif
}
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw
test.c; ./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov
show a.out -instr-profile=test.profdata test.c > test.lcov; cat test.lcov
1
2
Aborted (core dumped)
1| |#include
2| |#include
3| |
4| |extern void abort(void);
5| |
6| |#ifdef __x86_64__
7| 0|#define EFLAGS_TYPE unsigned long long int
8| |#else
9| |#define EFLAGS_TYPE unsigned int
10| |#endif
11| |
12| 0|int main() {
13| 0| printf("1\n");
14| 0| EFLAGS_TYPE flags = 0xD7; /* 111010111b */
15| 0| __writeeflags(flags);
16| 0| flags = __readeflags();
17| 0| printf("2\n");
18| 0| if ((flags & 0xFF) != 0xD7)
19| 0|abort();
20| 0| printf("3\n");
21| |#ifdef DEBUG
22| | printf("PASSED\n");
23| |#endif
24| 0|}
We can see that line 13,14 are executed,which means that main function executed
too. However, no coverage generated.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49421] New: [LLVM-COV] Dead code was marked as executed
https://bugs.llvm.org/show_bug.cgi?id=49421
Bug ID: 49421
Summary: [LLVM-COV] Dead code was marked as executed
Product: Runtime Libraries
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: cnwy1...@outlook.com
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/wangyang/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat test.c
#include
int main() {
FILE *f = fopen("conftest.out", "w");
return ferror(f) || fclose(f) != 0;
printf("passed");
return 0;
}
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw
test.c; ./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov
show a.out -instr-profile=test.profdata test.c > test.lcov; cat test.lcov
1| |#include
2| 1|int main() {
3| 1| FILE *f = fopen("conftest.out", "w");
4| 1| return ferror(f) || fclose(f) != 0;
5| 1| printf("passed");
6| 0| return 0;
7| 1|}
line 5 was wrongly marked as executed.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49422] New: e clang::ento::BasicValueFactory::getAPSIntType(clang::QualType) const: Assertion `T->isIntegralOrEnumerationType() || Loc::isLocType(T)' failed.
https://bugs.llvm.org/show_bug.cgi?id=49422
Bug ID: 49422
Summary: e
clang::ento::BasicValueFactory::getAPSIntType(clang::Q
ualType) const: Assertion
`T->isIntegralOrEnumerationType() ||
Loc::isLocType(T)' failed.
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: rmansfi...@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
Building with -DLLVM_ENABLE_ASSERTIONS=On
$ cat ~/t.i
struct a {
int b;
};
typedef struct {
long c;
_Atomic(struct a) d[]
} e;
f;
e g;
h() {
struct a i = __c11_atomic_load(&g.d[f], 5);
_Atomic j = i.b;
0 < j;
}
$ ./bin/clang --analyze ~/t.i
clang:
/home/ryan_mansfield/llvm/llvm-project/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h:142:
clang::ento::APSIntType
clang::ento::BasicValueFactory::getAPSIntType(clang::QualType) const: Assertion
`T->isIntegralOrEnumerationType() || Loc::isLocType(T)' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: ./bin/clang --analyze /home/ryan_mansfield/t.i
1. parser at end of file
2. While analyzing stack:
#0 Calling h
3. /home/ryan_mansfield/t.i:13:3: Error evaluating statement
4. /home/ryan_mansfield/t.i:13:3: Error evaluating statement
#0 0x0362b48a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/ryan_mansfield/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:11
#1 0x0362b6bb PrintStackTraceSignalHandler(void*)
/home/ryan_mansfield/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:1
#2 0x03628830 llvm::sys::RunSignalHandlers()
/home/ryan_mansfield/llvm/llvm-project/llvm/lib/Support/Signals.cpp:71:5
#3 0x03629c7e llvm::sys::CleanupOnSignal(unsigned long)
/home/ryan_mansfield/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:362:1
#4 0x03515978 (anonymous
namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long)
/home/ryan_mansfield/llvm/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:75:20
#5 0x03515c53 CrashRecoverySignalHandler(int)
/home/ryan_mansfield/llvm/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:389:1
#6 0x779ae980 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
#7 0x76505fb7 raise
/build/glibc-S7xCS9/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#8 0x76507921 abort /build/glibc-S7xCS9/glibc-2.27/stdlib/abort.c:81:0
#9 0x764f748a __assert_fail_base
/build/glibc-S7xCS9/glibc-2.27/assert/assert.c:89:0
#10 0x764f7502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
#11 0x0695ce9e
clang::ento::BasicValueFactory::getAPSIntType(clang::QualType) const
/home/ryan_mansfield/llvm/llvm-project/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h:0:5
#12 0x074a9560 clang::ento::BasicValueFactory::Convert(clang::QualType,
llvm::APSInt const&)
/home/ryan_mansfield/llvm/llvm-project/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h:159:29
#13 0x07516406 (anonymous
namespace)::SimpleSValBuilder::MakeSymIntVal(clang::ento::SymExpr const*,
clang::BinaryOperatorKind, llvm::APSInt const&, clang::QualType)
/home/ryan_mansfield/llvm/llvm-project/llvm/tools/clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:304:22
#14 0x07513667 (anonymous
namespace)::SimpleSValBuilder::evalBinOpNN(llvm::IntrusiveRefCntPtr, clang::BinaryOperatorKind, clang::ento::NonLoc, clang::ento::NonLoc,
clang::QualType)
/home/ryan_mansfield/llvm/llvm-project/llvm/tools/clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:767:16
#15 0x0752c641
clang::ento::SValBuilder::evalBinOp(llvm::IntrusiveRefCntPtr, clang::BinaryOperatorKind, clang::ento::SVal, clang::ento::SVal,
clang::QualType)
/home/ryan_mansfield/llvm/llvm-project/llvm/tools/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:442:10
#16 0x07430936
clang::ento::ExprEngine::evalBinOp(llvm::IntrusiveRefCntPtr, clang::BinaryOperatorKind, clang::ento::SVal, clang::ento::SVal,
clang::QualType)
/home/ryan_mansfield/llvm/llvm-project/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h:631:24
#17 0x0744ba5b
clang::ento::ExprEngine::VisitBinaryOperator(clang::BinaryOperator const*,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&)
/home/ryan_mansfield/llvm/llvm-project/llvm/tools/clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp:100:21
#18 0x0741d72f clang::ento::ExprEngine::Visit(clang::Stmt const*,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&)
/home/ryan_m
[llvm-bugs] [Bug 49423] New: [LLVM-COV] Label in switch statement and dead code were wrongly marked as executed
https://bugs.llvm.org/show_bug.cgi?id=49423
Bug ID: 49423
Summary: [LLVM-COV] Label in switch statement and dead code
were wrongly marked as executed
Product: Runtime Libraries
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: cnwy1...@outlook.com
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/wangyang/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat test.c
#include
int *ptr;
struct a {
int c;
};
int main(int argc, char **argv) {
struct a e;
e.c = 2;
int x = 0;
for (;;)
switch (e.c)
case 3: {
printf("1");
int resxxx;
case 2:
ptr = &resxxx;
*ptr = 123;
if (x)
return 0;
else
x = 1;
}
printf("2");
return 1;
}
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw
test.c; ./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov
show a.out -instr-profile=test.profdata test.c > test.lcov; cat test.lcov
1| |#include
2| |int *ptr;
3| |struct a {
4| | int c;
5| |};
6| 1|int main(int argc, char **argv) {
7| 1| struct a e;
8| 1| e.c = 2;
9| 1| int x = 0;
10| 1| for (;;)
11| 2|switch (e.c)
12| 2|case 3: {
13| 0| printf("1");
14| 0| int resxxx;
15| 2|case 2:
16| 2| ptr = &resxxx;
17| 2| *ptr = 123;
18| 2| if (x)
19| 1|return 0;
20| 1| else
21| 1|x = 1;
22| 2|}
23| 1| printf("2");
24| 0| return 1;
25| 1|}
26| |
Line 12 and 23 were actually not executed.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49424] New: Clang frontend command failed when parse template lambda in function arguments
https://bugs.llvm.org/show_bug.cgi?id=49424
Bug ID: 49424
Summary: Clang frontend command failed when parse template
lambda in function arguments
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: hewi...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
The following code with "-std+c++20" will emit the clang frontend error:
auto f(auto x = 1, auto = [] {} ());
godbolt: https://godbolt.org/z/Ghq8fM
details:
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang++ -g -o
./output.s -mllvm --x86-asm-syntax=intel -S
--gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics
-fno-crash-diagnostics -std=c++20
1. :1:45: current parser token ')'
#0 0x558e41b4f2dc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x305c2dc)
#1 0x558e41b4d084 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x305a084)
#2 0x558e41b4d305 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x305a305)
#3 0x558e41ab3b28 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
#4 0x7fc1e5ede3c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#5 0x558e442a19c4 clang::DeclContext::isDependentContext() const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x57ae9c4)
#6 0x558e442a1b14 clang::Decl::isInLocalScopeForInstantiation() const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x57aeb14)
#7 0x558e43f35db1 clang::Sema::SubstParmVarDecl(clang::ParmVarDecl*,
clang::MultiLevelTemplateArgumentList const&, int, llvm::Optional, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5442db1)
#8 0x558e43f61f14 void llvm::function_ref::callback_fn(long)
SemaTemplateInstantiateDecl.cpp:0:0
#9 0x558e438a199f
clang::Sema::runWithSufficientStackSpace(clang::SourceLocation,
llvm::function_ref)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4dae99f)
#10 0x558e43f4aaa3 clang::Sema::SubstDecl(clang::Decl*,
clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5457aa3)
#11 0x558e43f5441d clang::Sema::FindInstantiatedDecl(clang::SourceLocation,
clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x546141d)
#12 0x558e43f0eacb (anonymous
namespace)::TemplateInstantiator::TransformDecl(clang::SourceLocation,
clang::Decl*) SemaTemplateInstantiate.cpp:0:0
#13 0x558e43f33943 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformDeclRefExpr(clang::DeclRefExpr*)
SemaTemplateInstantiate.cpp:0:0
#14 0x558e43f1b832 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*)
SemaTemplateInstantiate.cpp:0:0
#15 0x558e43f1b7a9 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*)
SemaTemplateInstantiate.cpp:0:0
#16 0x558e43f24d16 clang::Sema::SubstExpr(clang::Expr*,
clang::MultiLevelTemplateArgumentList const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5431d16)
#17 0x558e43e2d7b4 SubstDefaultTemplateArgument(clang::Sema&,
clang::TemplateDecl*, clang::SourceLocation, clang::SourceLocation,
clang::NonTypeTemplateParmDecl*,
llvm::SmallVectorImpl&) SemaTemplate.cpp:0:0
#18 0x558e43e2dcf7
clang::Sema::SubstDefaultTemplateArgumentIfAvailable(clang::TemplateDecl*,
clang::SourceLocation, clang::SourceLocation, clang::Decl*,
llvm::SmallVectorImpl&, bool&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x533acf7)
#19 0x558e43ef06ab
clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*,
llvm::SmallVectorImpl&, unsigned int,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&,
llvm::SmallVectorImpl const*, bool,
llvm::function_ref)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x53fd6ab)
#20 0x558e43ef1f4e void llvm::function_ref::callback_fn,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool,
llvm::function_ref)>)::'lambda1'()>(long)
SemaTemplateDeduction.cpp:0:0
#21 0x558e438a199f
clang::Sema::runWithSufficientStackSpace(clang::SourceLocation,
llvm::function_ref)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4dae99f)
#22 0x558e43efdee2
clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*,
clang::TemplateArgumentListInfo*, llvm::ArrayRef,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool,
llvm::function_ref)>)
[llvm-bugs] [Bug 49425] New: Erroneous -Wunreachable-code in some cases when C++20 `[[likely]]`/`[[unlikely]]` are used.
https://bugs.llvm.org/show_bug.cgi?id=49425
Bug ID: 49425
Summary: Erroneous -Wunreachable-code in some cases when C++20
`[[likely]]`/`[[unlikely]]` are used.
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: i...@geometrian.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Consider the following simple, complete example:
//Compile with "-std=c++20 -Wunreachable-code -O3"
bool foo();
int bar() {
if (foo()) [[likely]] return 1;
else return 0;
}
The compiler of course cannot tell what `foo()` returns in this translation
unit. However, clang (tested 13.0.0) complains:
:4:13: warning: code will never be executed [-Wunreachable-code]
if (foo()) [[likely]] return 1;
^~~
This is an incorrect claim. Note that the generated code is correct, and in
particular the positive branch is correctly implemented. Removing `[[likely]]`
also removes the warning (which makes no sense since `[[likely]]` is a hint);
the generated code in that case happens to be the same.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49426] New: [LLVM-COV] Dead code after goto statement was wrongly marked as executed
https://bugs.llvm.org/show_bug.cgi?id=49426
Bug ID: 49426
Summary: [LLVM-COV] Dead code after goto statement was wrongly
marked as executed
Product: Runtime Libraries
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: cnwy1...@outlook.com
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/wangyang/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat test.c
extern void abort(void);
extern void exit(int);
int sub1(int val) { return val; }
int testcond(int val) {
int flag1;
{
int t1 = val;
{
int t2 = t1;
{
flag1 = sub1(t2) == 0;
goto lab1;
t2++;
};
}
lab1:;
}
if (flag1 != 0)
return 0x4d;
else
return 0;
}
int main(void) {
if (testcond(1))
abort();
exit(0);
}
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw
test.c; ./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov
show a.out -instr-profile=test.profdata test.c > test.lcov; cat test.lcov
1| |extern void abort(void);
2| |extern void exit(int);
3| |
4| 1|int sub1(int val) { return val; }
5| |
6| 1|int testcond(int val) {
7| 1| int flag1;
8| 1|
9| 1| {
10| 1|int t1 = val;
11| 1|{
12| 1| int t2 = t1;
13| 1| {
14| 1|flag1 = sub1(t2) == 0;
15| 1|goto lab1;
16| 1|t2++;
17| 0| };
18| 0|}
19| 1| lab1:;
20| 1| }
21| 1|
22| 1| if (flag1 != 0)
23| 0|return 0x4d;
24| 1| else
25| 1|return 0;
26| 1|}
27| |
28| 1|int main(void) {
29| 1| if (testcond(1))
30| 0|abort();
31| 1| exit(0);
32| 1|}
Line #16 should never be excuted.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49427] New: [LLVM-COV] Wrong coverage with the default label in switch statement
https://bugs.llvm.org/show_bug.cgi?id=49427
Bug ID: 49427
Summary: [LLVM-COV] Wrong coverage with the default label in
switch statement
Product: Runtime Libraries
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: cnwy1...@outlook.com
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/wangyang/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat test.c
void foo(int v, int w) {
int i;
if (w) {
goto do_default;
}
switch (v) {
case 0:
i = 27;
break;
case 1:
i = 8;
break;
default:
do_default:
i = 10;
break;
}
}
int main(){
int i;
for(i=0;i<6;i++){
if(i<4)
foo(i,0);
else
foo(i,1);
}
}
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw
test.c; ./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov
show a.out -instr-profile=test.profdata test.c > test.lcov; cat test.lcov
1| 6|void foo(int v, int w) {
2| 6| int i;
3| 6| if (w) {
4| 2|goto do_default;
5| 2| }
6| 4| switch (v) {
7| 1| case 0:
8| 1|i = 27;
9| 1|break;
10| 1| case 1:
11| 1|i = 8;
12| 1|break;
13| 4| default:
14| 4| do_default:
15| 4|i = 10;
16| 4|break;
17| 4| }
18| 4|}
19| |
20| 1|int main(){
21| 1|int i;
22| 7|for(i=0;i<6;i++){
23| 6|if(i<4)
24| 4|foo(i,0);
25| 2|else
26| 2|foo(i,1);
27| 6|}
28| 1|}
Line #13 should be executed twice instead of 4 times
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49428] New: [LLVM-COV] Wrong coverage with for statement
https://bugs.llvm.org/show_bug.cgi?id=49428
Bug ID: 49428
Summary: [LLVM-COV] Wrong coverage with for statement
Product: Runtime Libraries
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: cnwy1...@outlook.com
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/wangyang/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat test.c
int a, b, c, e, f;
void fn1(int p) {}
int fn2(int p) { return a ? p % a : 0; }
short fn3(int p) { return (1 >> p) < 1 ? 1 : p; }
int fn4() {
int g = 0, h = 1;
if (b)
goto lbl;
fn2(0);
if (fn3(1))
fn1(e && c);
if (h) {
int i = 1;
lbl:
if (i)
return 0;
for (; g < 1; g++)
;
}
for (;;)
f || g > 0;
}
int main() {
fn4();
}
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw
test.c; ./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov
show a.out -instr-profile=test.profdata test.c > test.lcov; cat test.lcov
1| |int a, b, c, e, f;
2| 1|void fn1(int p) {}
3| 1|int fn2(int p) { return a ? p % a : 0; }
4| 1|short fn3(int p) { return (1 >> p) < 1 ? 1 : p; }
5| 1|int fn4() {
6| 1| int g = 0, h = 1;
7| 1| if (b)
8| 0|goto lbl;
9| 1| fn2(0);
10| 1| if (fn3(1))
11| 1|fn1(e && c);
12| 1| if (h) {
13| 1|int i = 1;
14| 1| lbl:
15| 1|if (i)
16| 1| return 0;
17| 0|for (; g < 1; g++)
18| 0| ;
19| 0| }
20| 1| for (;;)
21| 0|f || g > 0;
22| 0|}
23| |
24| 1|int main() {
25| 1| fn4();
26| 1|}
The number of executions of line #20 should be 0, the same as line #17
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
