[llvm-bugs] [Bug 48367] New: Wrong warning: declaration shadows a static data member of ... ; for forward declared enums -Wshadow
https://bugs.llvm.org/show_bug.cgi?id=48367
Bug ID: 48367
Summary: Wrong warning: declaration shadows a static data
member of ... ; for forward declared enums -Wshadow
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: oleg.mishc...@itiviti.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
https://godbolt.org/z/8Kr37W
Reproduces from clang 8.0.0
//
struct A
{
enum AA : int;
enum AAA : int
{
x, y
};
};
struct B
{
enum BB : int;
enum BBB : int
{
y, z // OK
};
};
enum A::AA : int
{
a, b
};
enum B::BB : int
{
b, c // warning: declaration shadows a static data member of 'A' [-Wshadow]
};
//
:26:5: warning: declaration shadows a static data member of 'A'
[-Wshadow]
b, c // warning: declaration shadows a static data member of 'A' [-Wshadow]
^
:21:8: note: previous declaration is here
a, b
^
1 warning generated.
Compiler returned: 0
--
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 28230 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !E->isValueDependent()
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 Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-12-03 Type: Bug New issue 28230 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: !E->isValueDependent() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28230 Detailed Report: https://oss-fuzz.com/testcase?key=6276009552904192 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !E->isValueDependent() EvaluateInPlace clang::StmtVisitorBase::Visit Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202008240603:202008250614 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6276009552904192 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 48214] ThinLTO doesn't import .symver directives
https://bugs.llvm.org/show_bug.cgi?id=48214 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Hans Wennborg --- Fixed in https://github.com/llvm/llvm-project/commit/437c4653855fbbe47a860ae95eb445fd004aa4de -- 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 48368] New: Support the AArch64 variant PCS symbol st_other value
https://bugs.llvm.org/show_bug.cgi?id=48368 Bug ID: 48368 Summary: Support the AArch64 variant PCS symbol st_other value Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: smithp...@googlemail.com CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com This is an enhancement request for lld to support the AArch64 variant procedure call standard (PCS) in LLD. This is needed to support SVE functions that follow the vector procedure calling standard (a variant procedure call standard that requires more registers to be saved than normal). Functions that follow a variant PCS need special handling by a dynamic linker. To mark such functions the AArch64 ABI defines the st_other value STO_AARCH64_VARIANT_PCS in ELF for the 64 bit Arm Architecture. This is documented in: https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#551st_other-values The static linker's responsibilities with respect to STO_AARCH64_VARIANT_PCS are small. To quote from the ABI: "Static linkers must preserve the marking and propagate it to the dynamic symbol table if any reference or definition of the symbol is marked with STO_AARCH64_VARIANT_PCS, and add a DT_AARCH64_VARIANT_PCS dynamic tag if required by the Dynamic Section section." Message describing motivation and design: https://sourceware.org/legacy-ml/binutils/2019-05/msg00294.html LLVM patch that adds STO_AARCH64_VARIANT_PCS to LLVM https://reviews.llvm.org/D89138 binutils patch https://sourceware.org/pipermail/binutils/2019-May/106963.html glibc patch to support STO_AARCH64_VARIANT_PCS https://sourceware.org/pipermail/glibc-cvs/2020q1/069075.html -- 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 48369] New: opt crash with "-mem2reg -deadargelim -simplifycfg -inline -sroa -early-cse-memssa -jump-threading -instcombine" at "Combine redundant instructions"
https://bugs.llvm.org/show_bug.cgi?id=48369
Bug ID: 48369
Summary: opt crash with "-mem2reg -deadargelim -simplifycfg
-inline -sroa -early-cse-memssa -jump-threading
-instcombine" at "Combine redundant instructions"
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: suochen...@163.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 24230
--> https://bugs.llvm.org/attachment.cgi?id=24230&action=edit
bc file
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
$ cat a.c
short a=0;
int b=0, d=0, f=0;
long c=0;
char e=0;
int main() {
int g = 3;
for (; a;) {
int h = 0;
for (;; d) {
c = (h <= 0) << 8;
h = b;
for (; g;)
;
for (; f;)
for (; e;)
;
}
}
return 0;
}
***
clang version:
$ clang --version
clang version 12.0.0 (/home/suocy/src/llvm-dev/llvm-project/llvm/tools/clang
e52a91e156d7ab26989fef526434b02514428c91)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/suocy/bin/llvm-dev/bin
***
Command Lines:
$ clang -O3 -mllvm -disable-llvm-optzns -c -emit-llvm a.c -o a.bc
a.c:9:13: warning: expression result unused [-Wunused-value]
for (;; d) {
^
1 warning generated.
$ opt -mem2reg -deadargelim -simplifycfg -inline -sroa -early-cse-memssa
-jump-threading -instcombine a.bc -o a.opt.bc
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: /home/suocy/bin/llvm-dev/bin/opt -mem2reg
-deadargelim -simplifycfg -inline -sroa -early-cse-memssa -jump-threading
-instcombine a.bc -o a.opt.bc
1. Running pass 'CallGraph Pass Manager' on module 'a.bc'.
2. Running pass 'Combine redundant instructions' on function '@main'
#0 0x02a8136c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/home/suocy/bin/llvm-dev/bin/opt+0x2a8136c)
#1 0x02a7f1e4 llvm::sys::RunSignalHandlers()
(/home/suocy/bin/llvm-dev/bin/opt+0x2a7f1e4)
#2 0x02a7f343 SignalHandler(int)
(/home/suocy/bin/llvm-dev/bin/opt+0x2a7f343)
#3 0x7fec2e9b4630 __restore_rt (/lib64/libpthread.so.0+0xf630)
#4 0x02584f5e
llvm::InstCombinerImpl::visitSelectInst(llvm::SelectInst&)
(/home/suocy/bin/llvm-dev/bin/opt+0x2584f5e)
#5 0x024f310a llvm::InstCombinerImpl::run()
(/home/suocy/bin/llvm-dev/bin/opt+0x24f310a)
#6 0x024f4d29 combineInstructionsOverFunction(llvm::Function&,
llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&,
llvm::TargetLibraryInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&,
llvm::OptimizationRemarkEmitter&, llvm::BlockFrequencyInfo*,
llvm::ProfileSummaryInfo*, unsigned int, llvm::LoopInfo*)
(/home/suocy/bin/llvm-dev/bin/opt+0x24f4d29)
#7 0x024f698a
llvm::InstructionCombiningPass::runOnFunction(llvm::Function&)
(/home/suocy/bin/llvm-dev/bin/opt+0x24f698a)
#8 0x022bf598 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/suocy/bin/llvm-dev/bin/opt+0x22bf598)
#9 0x01a304f4 (anonymous
namespace)::CGPassManager::runOnModule(llvm::Module&)
(/home/suocy/bin/llvm-dev/bin/opt+0x1a304f4)
#10 0x022bee43 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/suocy/bin/llvm-dev/bin/opt+0x22bee43)
#11 0x0072c61b main (/home/suocy/bin/llvm-dev/bin/opt+0x72c61b)
#12 0x7fec2d58e555 __libc_start_main (/lib64/libc.so.6+0x22555)
#13 0x007ddac5 _start (/home/suocy/bin/llvm-dev/bin/opt+0x7ddac5)
Segmentation fault
--
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 48370] New: TestMultithreaded.py::test_python_stop_hook fails on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=48370 Bug ID: 48370 Summary: TestMultithreaded.py::test_python_stop_hook fails 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: ema...@freebsd.org, jdevliegh...@apple.com, llvm-bugs@lists.llvm.org == ERROR: test_python_stop_hook (TestMultithreaded.SBBreakpointCallbackCase) Test that you can run a python command in a stop-hook when stdin is File based. -- Traceback (most recent call last): File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 136, in wrapper return func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/test/API/api/multithreaded/TestMultithreaded.py", line 38, in test_python_stop_hook 'test_python_stop_hook') File "/usr/home/mgorny/llvm-project/lldb/test/API/api/multithreaded/TestMultithreaded.py", line 117, in build_and_test check_call(exe, env=env, stdout=fnull, stderr=fnull) File "/usr/local/lib/python3.7/subprocess.py", line 363, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/home/mgorny/llvm-project/_build/lldb-test-build.noindex/api/multithreaded/TestMultithreaded.test_python_stop_hook/test_python_stop_hook', '/home/mgorny/llvm-project/_build/lldb-test-build.noindex/api/multithreaded/TestMultithreaded.test_python_stop_hook/inferior_program']' returned non-zero exit status 1. Config=x86_64-/home/mgorny/llvm-project/_build/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 48371] New: LLDB needs a better way of expressing unavailable registers (test_register_commands failure)
https://bugs.llvm.org/show_bug.cgi?id=48371 Bug ID: 48371 Summary: LLDB needs a better way of expressing unavailable registers (test_register_commands failure) 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: ema...@freebsd.org, jdevliegh...@apple.com, llvm-bugs@lists.llvm.org LLDB can currently only hide unavailable registers via manipulating the global register count, i.e. hide the last registers on the list. This doesn't work for FreeBSD and NetBSD, and could also be problematic as new CPUs emerge (or possibly already is). Unavailable registers not being hidden cause test_register_commands to fail: FAIL: test_register_commands (TestRegisters.RegisterCommandsTestCase) Test commands related to registers, in particular vector registers. -- Traceback (most recent call last): File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 136, in wrapper return func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 136, in wrapper return func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/test/API/commands/register/register/register_command/TestRegisters.py", line 41, in test_register_commands substrs=['registers were unavailable'], matching=False) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2573, in expect self.fail(log_msg) AssertionError: Ran command: "register read -a" Got output: General Purpose Registers: [...] Memory Protection Extensions: 6 registers were unavailable. [...] Not expecting sub string: "registers were unavailable" (was found) At least one expected register is unavailable. Config=x86_64-/home/mgorny/llvm-project/_build/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 48372] New: TestTargetCreateDeps.py failures on FreeBSD (and Linux)
https://bugs.llvm.org/show_bug.cgi?id=48372 Bug ID: 48372 Summary: TestTargetCreateDeps.py failures on FreeBSD (and Linux) 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 The original test comment says: #linux does not support loading dependent files, but android does I'm not sure if the same is true of FreeBSD but certainly it's not implemented yet. -- 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 48373] New: TestBreakpointInGlobalConstructors fails on FreeBSD (needs dyld fixes)
https://bugs.llvm.org/show_bug.cgi?id=48373 Bug ID: 48373 Summary: TestBreakpointInGlobalConstructors fails on FreeBSD (needs dyld fixes) 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: ema...@freebsd.org, jdevliegh...@apple.com, llvm-bugs@lists.llvm.org The LLDB's dynamic loader support is currently oriented towards Linux behavior, i.e. reporting the dynamic loader itself on the first r_debug breakpoint hit, and then all DT_NEEDED libraries on a second hit. On FreeBSD there is only one hit for all the libraries. The relevant discussion can be found at: https://reviews.llvm.org/D92187 -- 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 48374] New: TestDeletedExecutable.py fails on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=48374
Bug ID: 48374
Summary: TestDeletedExecutable.py fails 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: ema...@freebsd.org, jdevliegh...@apple.com,
llvm-bugs@lists.llvm.org
FAIL: test (TestDeletedExecutable.TestDeletedExecutable)
--
Traceback (most recent call last):
File
"/usr/home/mgorny/llvm-project/lldb/test/API/functionalities/deleted-executable/TestDeletedExecutable.py",
line 44, in test
self.runCmd("process attach -p " + str(popen.pid))
File
"/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2184, in runCmd
msg if (msg) else CMD_MSG(cmd))
AssertionError: False is not True : Command 'process attach -p 2980
Error output:
error: attach failed: unable to find executable for
'/home/mgorny/llvm-project/_build/lldb-test-build.noindex/functionalities/deleted-executable/TestDeletedExecutable.test/a.out'
' did not return successfully
Config=x86_64-/home/mgorny/llvm-project/_build/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 48375] New: TestReturnValue.py test failures on FreeBSD/i386
https://bugs.llvm.org/show_bug.cgi?id=48375 Bug ID: 48375 Summary: TestReturnValue.py test failures on FreeBSD/i386 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 The two following tests fail on FreeBSD/i386: test_with_python test_vector_values Apparently MacOS suffers from the same problem, and Linux did with old 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 48376] New: TestCreateAfterAttach fails on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=48376 Bug ID: 48376 Summary: TestCreateAfterAttach fails 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 FAIL: test_create_after_attach_dwarf (TestCreateAfterAttach.CreateAfterAttachTestCase) Test thread creation after process attach. -- Traceback (most recent call last): File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1853, in test_method return attrvalue(self) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 136, in wrapper return func(*args, **kwargs) File "/usr/home/mgorny/llvm-project/lldb/test/API/functionalities/thread/create_after_attach/TestCreateAfterAttach.py", line 48, in test_create_after_attach self, "main.cpp", self.break_1, num_expected_locations=1) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbutil.py", line 426, in run_break_set_by_file_and_line num_locations=num_expected_locations) File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbutil.py", line 647, in check_breakpoint_result out_num_locations)) AssertionError: False is not True : Expecting 1 locations, got 2. Config=x86_64-/home/mgorny/llvm-project/_build/bin/clang This is probably related to https://reviews.llvm.org/D92264. -- 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 28198 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in DiagnoseTwoPhaseLookup
Updates: Labels: -Reproducible Unreproducible Comment #1 on issue 28198 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in DiagnoseTwoPhaseLookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28198#c1 ClusterFuzz testcase 5699236515282944 appears to be flaky, updating reproducibility label. -- 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] Issue 28138 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Decl::castFromDeclContext
Updates: Labels: -Reproducible Unreproducible Comment #1 on issue 28138 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Decl::castFromDeclContext https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28138#c1 ClusterFuzz testcase 5719153721475072 appears to be flaky, updating reproducibility label. -- 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 48377] New: [codeview] Inline sites in PDB sometimes don't contain code offset
https://bugs.llvm.org/show_bug.cgi?id=48377
Bug ID: 48377
Summary: [codeview] Inline sites in PDB sometimes don't contain
code offset
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: akhu...@google.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Some inline sites don't have starting code offsets and thus aren't found by
llvm-symbolizer.
to repro:
$ cat t.cpp
int main(int argc, char *argv[]) {
auto f = [](int x) {
return x * 100;
};
return f(argc);
}
$ clang -cc1 -triple x86_64-windows-msvc -emit-obj -gcodeview
-debug-info-kind=line-tables-only -Os -o t.obj t.cpp
$ lld-link t.obj -debug -entry:main -pdb:t.pdb
$ llvm-pdbutil dump -symbols t.pdb | grep -A3 "S_INLINESITE "
212 | S_INLINESITE [size = 20]
inlinee = 0x1000 (main(int, char **)::(anonymous c...), parent =
136, end = 232
0602 line 1 (+1)
0403 code end 0x3 (+0x3)
$ llvm-symbolizer --obj=t.exe --relative-address 0x1000
main
??:0:0
--
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 48234] CMake LANGUAGE property misused for .S assembler sources
https://bugs.llvm.org/show_bug.cgi?id=48234 Raul Tambre changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)|45344cf7ac5b848f77825ffa37b |45344cf7ac5b848f77825ffa37b |0cb3b69b9b07b |0cb3b69b9b07b ||03565ffd5da8370f5b89b69cd98 ||68f32e2d75403 Resolution|--- |FIXED --- Comment #2 from Raul Tambre --- Part of 11.0.1 as 03565ffd5da8370f5b89b69cd9868f32e2d75403. -- 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 48378] New: wasm-ld fails in Windows 7
https://bugs.llvm.org/show_bug.cgi?id=48378 Bug ID: 48378 Summary: wasm-ld fails in Windows 7 Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: cs...@ukr.net CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com Recently I installed emscripten (emsdk) and it failed to compile hello world, saying this: wasm-ld: error: failed to write the output file: permission denied I debugged wasm-ld and found out this: "\llvm\lib\Support\Windows\Path.inc" have function "static std::error_code setDeleteDisposition(HANDLE Handle, bool Delete)" It calls SetFileInformationByHandle on file handle to set it for deletion after closing. But I have Windows 7 and it behaves differently from Windows 10! "static std::error_code rename_handle(HANDLE FromHandle, const Twine &To)" called when it tries to commit all changes done to a temporary file. this function calls "rename_internal", and "rename_internal" calls "GetFinalPathNameByHandleW" On Windows 7 GetFinalPathNameByHandleW fails with error code 5 (ERROR_ACCESS_DENIED) when it tries to get path of file scheduled for deletion. On Windows 10 everything works perfectly. Here's sample code in Python to quickly test this behavior: https://pastebin.com/v51m3uBU Possible solution is to set Disposition.DeleteFile back to false before calling GetFinalPathNameByHandleW. -- 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 25560 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #1 on issue 25560 by sheriffbot: llvm:llvm-isel-fuzzer--aarch64-gisel: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25560#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 48379] New: aarch64: Some casting/shifting of __uint128_t hits an UNREACHABLE after regalloc in AArch64InstrInfo::copyPhysReg
https://bugs.llvm.org/show_bug.cgi?id=48379
Bug ID: 48379
Summary: aarch64: Some casting/shifting of __uint128_t hits an
UNREACHABLE after regalloc in
AArch64InstrInfo::copyPhysReg
Product: libraries
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: nat...@lanza.io
CC: arnaud.degrandmai...@arm.com,
llvm-bugs@lists.llvm.org, smithp...@googlemail.com,
ties.st...@arm.com
The following code hits an error with clang11 when compiled as so:
```
clang++ -march=armv8-a -target aarch64-none-linux-android21 file.cpp
```
```
long multiply() {
auto a = static_cast<__uint128_t>(0);
return (static_cast(a) & (1ULL << 63)) != 0 ? a : a;
}
```
Here' the IR that is generated via `-S -emit-llvm`:
```
; ModuleID = 'third-party/fmt/fmt/src/format.cc'
source_filename = "third-party/fmt/fmt/src/format.cc"
target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-none-linux-android21"
; Function Attrs: noinline nounwind optnone
define dso_local i64 @_Z8multiplyv() #0 {
entry:
%a = alloca i128, align 16
store i128 0, i128* %a, align 16
%0 = load i128, i128* %a, align 16
%conv = trunc i128 %0 to i64
%and = and i64 %conv, -9223372036854775808
%cmp = icmp ne i64 %and, 0
br i1 %cmp, label %cond.true, label %cond.false
cond.true:; preds = %entry
%1 = load i128, i128* %a, align 16
br label %cond.end
cond.false: ; preds = %entry
%2 = load i128, i128* %a, align 16
br label %cond.end
cond.end: ; preds = %cond.false,
%cond.true
%cond = phi i128 [ %1, %cond.true ], [ %2, %cond.false ]
%conv1 = trunc i128 %cond to i64
ret i64 %conv1
}
attributes #0 = { noinline nounwind optnone
"correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false"
"frame-pointer"="non-leaf" "less-precise-fpmad"="false"
"min-legal-vector-width"="0" "no-infs-fp-math"="false" "no-jump-tables"="false"
"no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false"
"no-trapping-math"="true" "stack-protector-buffer-size"="8"
"target-cpu"="generic" "target-features"="+neon" "unsafe-fp-math"="false"
"use-soft-float"="false" }
!llvm.module.flags = !{!0, !1, !2}
!llvm.ident = !{!3}
!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 7, !"PIC Level", i32 2}
!2 = !{i32 7, !"PIE Level", i32 2}
!3 = !{!"Facebook clang version 11.0.1 (llvm:
81c8deff8cbad869e7238842ebf9c94f3220a73d, cfe:
81c8deff8cbad869e7238842ebf9c94f3220a73d, compiler-rt:
81c8deff8cbad869e7238842ebf9c94f3220a73d, lld:
81c8deff8cbad869e7238842ebf9c94f3220a73d)"}
```
Here's the error:
```
unimplemented reg-to-reg copy
UNREACHABLE executed at
/mnt/btrfs/trunk-grepo-llvm-c2-122478666-1604424455/external/llvm-project/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:3012!
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:
/data/users/lanza/fbsource/buck-out/gen/fe3a39b8/xplat/toolchains/android/ndk/linux-llvm-11-asserts-cxx-arm64#link-tree/xplat/toolchains/android/ndk/llvm_toolchain/bin/clang++
-march=armv8-a -target aarch64-none-linux-android21 -c
third-party/fmt/fmt/src/format.cc
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module
'third-party/fmt/fmt/src/format.cc'.
4. Running pass 'Post-RA pseudo instruction expansion pass' on function
'@_Z8multiplyv'
#0 0x039dedcf llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/data/users/lanza/fbsource/buck-out/gen/fe3a39b8/xplat/toolchains/android/ndk/linux-llvm-11-asserts-cxx-arm64#link-tree/xplat/toolchains/android/ndk/llvm_toolchain/bin/clang+++0x39dedcf)
#1 0x039dcfd0 llvm::sys::RunSignalHandlers()
(/data/users/lanza/fbsource/buck-out/gen/fe3a39b8/xplat/toolchains/android/ndk/linux-llvm-11-asserts-cxx-arm64#link-tree/xplat/toolchains/android/ndk/llvm_toolchain/bin/clang+++0x39dcfd0)
#2 0x039de46d llvm::sys::CleanupOnSignal(unsigned long)
(/data/users/lanza/fbsource/buck-out/gen/fe3a39b8/xplat/toolchains/android/ndk/linux-llvm-11-asserts-cxx-arm64#link-tree/xplat/toolchains/android/ndk/llvm_toolchain/bin/clang+++0x39de46d)
#3 0x03967203
(/data/users/lanza/fbsource/buck-out/gen/fe3a39b8/xplat/toolchains/android/ndk/linux-llvm-11-asserts-cxx-arm64#link-tree/xplat/toolchains/android/ndk/llvm_toolchain/bin/clang+++0x3967203)
#4 0x03967356
(/data/users/lanza/fbsource/buck-out/gen/fe3a39b8/xplat/toolchains/android/ndk/linux-llvm-11-asserts-cxx-arm64#link-tree/xplat/toolchains/android/ndk/llvm_toolchain/bin/clang+++0x3967356)
#5
[llvm-bugs] [Bug 45699] Unexpanded parameter pack in 'requires clause' crashes the compiler
https://bugs.llvm.org/show_bug.cgi?id=45699 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||be162f4c0e8563c8de510121435 ||281ae628c8654 -- 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 48380] New: lld: Possible race condition writing files to lto cache
https://bugs.llvm.org/show_bug.cgi?id=48380 Bug ID: 48380 Summary: lld: Possible race condition writing files to lto cache Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com With lld 11.0.0, I am seeing these lit tests fail when running in a container (very slow disk IO): lld :: COFF/lto-cache.ll lld :: ELF/lto/cache.ll lld :: wasm/lto/cache.ll These tests are failing, because no objects are being written to the cache directory. While debugging I noticed if I manually ran the lld commands that are supposed to generate the cache files and passed the -verbose option to it, then the cache objects get written. If I remove the -verbose option, then the cache objects are not written. This makes me suspect there is some kind of race condition, so either the program is exiting before the files are completely written or the cache is getting pruned after the objects are written. -- 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 48381] New: lldb not stopped at an executed return statement
https://bugs.llvm.org/show_bug.cgi?id=48381
Bug ID: 48381
Summary: lldb not stopped at an executed return statement
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: yangyib...@nju.edu.cn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 24232
--> https://bugs.llvm.org/attachment.cgi?id=24232&action=edit
the binary 'a.out'
$ clang -O1 -g small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/root/DeVIL/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main at small.c:14:10, address = 0x004004a0
(lldb) run
-> 14 for (; d < 1; d++)
(lldb) step
-> 15 for (; b < 1; b++)
(lldb) step
-> 16 *c[b][d + 1] = 0;
(lldb) step
-> 15 for (; b < 1; b++)
(lldb) step
-> 14 for (; d < 1; d++)
(lldb) step
-> 18 return 0;
(lldb)
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/root/DeVIL/a.out' (x86_64).
(lldb) b 18
Breakpoint 1: where = a.out`main + 10 at small.c:18:3, address =
0x004004aa
(lldb) run
Process 27027 launched: '/root/DeVIL/a.out' (x86_64)
Process 27027 exited with status = 0 (0x)
(lldb)
$ cat small.c
struct S
{
volatile int f;
} a;
unsigned int b;
static int *c[1][2] = {{0, (int *)&a.f}};
static unsigned int d;
int
main ()
{
for (; d < 1; d++)
for (; b < 1; b++)
*c[b][d + 1] = 0;
return 0;
}
--
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 48382] New: lldb wrongly stopped at an unexecuted statement
https://bugs.llvm.org/show_bug.cgi?id=48382
Bug ID: 48382
Summary: lldb wrongly stopped at an unexecuted statement
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: yangyib...@nju.edu.cn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 24233
--> https://bugs.llvm.org/attachment.cgi?id=24233&action=edit
the binary 'a.out'
$ cat small.c
/* { dg-options "-O2" } */
/* { dg-do run } */
static const long long int TagTypeNumber = 0xll;
long long int x;
void foo(void)
{
x = TagTypeNumber + 1;
}
int main(int argc, char **argv)
{
if (argc > 0)
foo ();
if ((x & TagTypeNumber) == TagTypeNumber)
{
unsigned y = (unsigned)x;
__builtin_printf ("v: %u\n", y);
if (y != 1)
__builtin_abort ();
}
return 0;
}
$ clang -O2 -g small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/root/DeVIL/a.out' (x86_64).
(lldb) b 16
Breakpoint 1: where = a.out`main + 45 at small.c:18:8, address =
0x0040058d
(lldb) r
Process 45445 launched: '/root/DeVIL/a.out' (x86_64)
v: 1
Process 45445 exited with status = 0 (0x)
(lldb)
# when step by step, lldb is wrongly stopped at line 16 as follows.
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/root/DeVIL/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 11 at small.c:15:12, address =
0x0040056b
(lldb) r
13 int main(int argc, char **argv)
14 {
-> 15 if (argc > 0)
16 foo ();
17
(lldb) s
13 int main(int argc, char **argv)
14 {
15 if (argc > 0)
-> 16 foo ();
17
(lldb) s
8void foo(void)
9{
-> 10 x = TagTypeNumber + 1;
11 }
##
# clang and lldb versin
$ clang --version
Ubuntu clang version
12.0.0-++20201202063839+f0193623297-1~exp1~20201202174527.2077
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 12.0.0
--
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 48347] Method metadata emitted twice from synthesised properties targeting GNU Objective-C runtimes
https://bugs.llvm.org/show_bug.cgi?id=48347 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|d1ed67037de6f3f44dc446784f7 |d1ed67037de6f3f44dc446784f7 |4f0e02adec9b5 |4f0e02adec9b5 bb852a09ae3 --- Comment #1 from Tom Stellard --- Merged: bb852a09ae3 -- 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 47800] [meta] 11.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=47800 Bug 47800 depends on bug 48347, which changed state. Bug 48347 Summary: Method metadata emitted twice from synthesised properties targeting GNU Objective-C runtimes https://bugs.llvm.org/show_bug.cgi?id=48347 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 48383] New: Segfault from pseudodestructor with decltype(auto)
https://bugs.llvm.org/show_bug.cgi?id=48383
Bug ID: 48383
Summary: Segfault from pseudodestructor with decltype(auto)
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: ndkrem...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
The following ill-formed code causes a segfault rather than an error:
int main(int argc, char **argv) {
argc.~decltype(auto);
}
Reproduced on clang 3.3 up to clang 11.0.0 and trunk (with no particular flags,
or -std=c++anything, doesn't matter).
(An even more ill-formed one-liner like "_=0 .~decltype(auto)" will repro too.)
e.g. on trunk (https://gcc.godbolt.org/z/hnqzad):
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
1. :2:25: current parser token ';'
2. :1:33: parsing function body 'main'
3. :1:33: in compound statement ('{}')
#0 0x55a3ed98846c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2e1a46c)
#1 0x55a3ed986204 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2e18204)
#2 0x55a3ed986495 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2e18495)
#3 0x55a3ed8f5068 CrashRecoverySignalHandler(int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2d87068)
#4 0x7f7b12dec3c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#5 0x55a3f030e6a8 (anonymous
namespace)::StmtProfiler::VisitOMPExecutableDirective(clang::OMPExecutableDirective
const*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x57a06a8)
#6 0x55a3f030ddb6 clang::StmtVisitorBase::Visit(clang::Stmt const*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x579fdb6)
#7 0x55a3f031133b clang::Stmt::Profile(llvm::FoldingSetNodeID&,
clang::ASTContext const&, bool) const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x57a333b)
#8 0x55a3effee5c1 clang::ASTContext::getDecltypeType(clang::Expr*,
clang::QualType) const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x54805c1)
#9 0x55a3efe43976 clang::Sema::BuildDecltypeType(clang::Expr*,
clang::SourceLocation, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x52d5976)
#10 0x55a3efab9a3f clang::Sema::ActOnPseudoDestructorExpr(clang::Scope*,
clang::Expr*, clang::SourceLocation, clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4f4ba3f)
#11 0x55a3ef6cf05b clang::Parser::ParseCXXPseudoDestructor(clang::Expr*,
clang::SourceLocation, clang::tok::TokenKind, clang::CXXScopeSpec&,
clang::OpaquePtr)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4b6105b)
#12 0x55a3ef6c272b
clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4b5472b)
#13 0x55a3ef6bcb6f
clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&,
clang::Parser::TypeCastState, bool, bool*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4b4eb6f)
#14 0x55a3ef6bf536
clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool,
clang::Parser::TypeCastState, bool, bool*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4b51536)
#15 0x55a3ef6c0cd4
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4b52cd4)
#16 0x55a3ef6c1979
clang::Parser::ParseExpression(clang::Parser::TypeCastState)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4b53979)
#17 0x55a3ef71a45d
clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4bac45d)
#18 0x55a3ef7177cb
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*,
clang::Parser::ParsedAttributesWithRange&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4ba97cb)
#19 0x55a3ef718539
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4baa539)
#20 0x55a3ef71eb79 clang::Parser::ParseCompoundStatementBody(bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4bb0b79)
#21 0x55a3ef722353 clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4bb4353)
#22 0x55a3ef676ba7
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplat
[llvm-bugs] Issue 28274 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Null-dereference READ in llvm::DWARFFormValue::dumpSectionedAddress
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-2020-12-04 Type: Bug New issue 28274 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: Null-dereference READ in llvm::DWARFFormValue::dumpSectionedAddress https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28274 Detailed Report: https://oss-fuzz.com/testcase?key=6321176569839616 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x0022 Crash State: llvm::DWARFFormValue::dumpSectionedAddress llvm::DWARFFormValue::dump llvm::DWARFDebugLine::Prologue::dump Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202002120539:202002130532 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6321176569839616 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 48383] Segfault from pseudodestructor with decltype(auto)
https://bugs.llvm.org/show_bug.cgi?id=48383 David Blaikie changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||dblai...@gmail.com --- Comment #1 from David Blaikie --- Thanks! fixed in c4af1c8d939b21ac7deb631887fc26db7451c592 -- 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 48384] New: [Concepts] void f(Constrained decltype(auto)) should be rejected
https://bugs.llvm.org/show_bug.cgi?id=48384 Bug ID: 48384 Summary: [Concepts] void f(Constrained decltype(auto)) should be rejected Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: arthur.j.odw...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk // https://godbolt.org/z/deh8oT template concept C = true; void f(C decltype(auto)); Should be ill-formed, according to http://eel.is/c++draft/dcl.fct#18.sentence-6 , but Clang accepts it. Clang does know that void f(decltype(auto)); is ill-formed, but Clang doesn't know that void f(C decltype(auto)); should also be ill-formed. Incidentally, I'm confused about template void g(); template void h(); Clang, GCC, and MSVC all agree that both of those are well-formed, but I don't know the rationale for accepting _template_ parameters of decltype(auto) type, given that _function_ parameters of decltype(auto) type are forbidden. GCC also accepts decltype(auto)& here: template void i(); -- 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
