[llvm-bugs] [Bug 42721] Wmisleading-indentation in X86GenDAGISel.inc
https://bugs.llvm.org/show_bug.cgi?id=42721 Simon Pilgrim changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #3 from Simon Pilgrim --- This is an annoying gcc issue but doesn't seem to cause any actual harm, even on Werror builds AFAICT. -- 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 47589] New: clang-format-11: regression in aligned comments
https://bugs.llvm.org/show_bug.cgi?id=47589
Bug ID: 47589
Summary: clang-format-11: regression in aligned comments
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: sylves...@debian.org
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Blocks: 46725
With this simple code:
namespace mozilla {
#define IPV6_SCOPE_GLOBAL 0 // Global scope.
#define IPV6_SCOPE_LINKLOCAL 1 // Link-local scope.
#define IPV6_SCOPE_SITELOCAL 2 // Site-local scope (deprecated).
#define IPV6_SCOPE_UNIQUELOCAL 3 // Unique local
#define IPV6_SCOPE_NODELOCAL 4 // Loopback
} // namespace mozilla
clang-format-10 left it intact
With clang-format-11, the output is:
% clang-format-11 IPv6Utils.h
namespace mozilla {
#define IPV6_SCOPE_GLOBAL 0 // Global scope.
#define IPV6_SCOPE_LINKLOCAL 1 // Link-local scope.
#define IPV6_SCOPE_SITELOCAL 2 // Site-local scope (deprecated).
#define IPV6_SCOPE_UNIQUELOCAL 3 // Unique local
#define IPV6_SCOPE_NODELOCAL 4 // Loopback
} // namespace mozilla
which is a significant regression for clang-format-11
Looking at the 11 release notes,
https://prereleases.llvm.org/11.0.0/rc2/tools/clang/docs/ReleaseNotes.html
I haven't seen anything directly related.
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=46725
[Bug 46725] [meta] 11.0.0 Release Blockers
--
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 34279] Infinite loop during DAG building
https://bugs.llvm.org/show_bug.cgi?id=34279 Simon Pilgrim changed: What|Removed |Added CC||llvm-...@redking.me.uk Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Simon Pilgrim --- No longer reproducible on trunk -- 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 25809 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::using_directives
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 25809 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::using_directives https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25809#c1 ClusterFuzz testcase 5742288377217024 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009190621:202009200609 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 47495] Wsizeof-array-div false positive when divisor is sizeof reference type
https://bugs.llvm.org/show_bug.cgi?id=47495 David Bolvansky changed: What|Removed |Added Resolution|--- |FIXED CC||david.bolvan...@gmail.com Status|CONFIRMED |RESOLVED Fixed By Commit(s)||llvmorg-12-init-6365-g2ae18 ||2258c4 -- 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 47584] Missed simplifications when shl is used instead of mul
https://bugs.llvm.org/show_bug.cgi?id=47584 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||7903ae4720 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Sanjay Patel --- With the instcombine improvement, the original example collapses to the optimal code: https://github.com/llvm/llvm-project/commit/7903ae4720a8c4f3c694954d56293c7507e07945 -- 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 47590] New: Clang crashes when std::visit is called with a lambda with trailing return type that requires messy name lookup
https://bugs.llvm.org/show_bug.cgi?id=47590 Bug ID: 47590 Summary: Clang crashes when std::visit is called with a lambda with trailing return type that requires messy name lookup Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: rileylev...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 23986 --> https://bugs.llvm.org/attachment.cgi?id=23986&action=edit The repro.cpp file, the repro.ii file, and clang's stderr output pasted into one file, separated by headers with ==s Suppose you have a few types with a free function defined on each of them. You might want to define an overload that accepts a std::variant of these types and calls std::visit to choose the appropriate behavior at runtime, perhaps using a LIFT macro to pass the whole overload set to std::visit. But the name lookup in the trailing type ->decltype(the_function(...)) crashes clang sometimes. I'm attaching an example where this happened. I'm running clang 10 on Linux as installed by my package manager, but the same problem occurred on godbolt using trunk: https://godbolt.org/z/xa7oEY I ran it with $ clang++ -std=c++20 repro.cpp -- 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 45930] Emscripten + pdfium: MCStreamer::SwitchSection: Assertion `Section && "Cannot switch to a null section!"' failed
https://bugs.llvm.org/show_bug.cgi?id=45930 Andrew de los Reyes changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from Andrew de los Reyes --- I'm not sure how I missed this before, but I traced this to the -debug-info-kind=constructor argument. Removing that solves the issue. Apologies! -- 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 22260 in oss-fuzz: llvm: Coverage build failure
Comment #16 on issue 22260 by ClusterFuzz-External: llvm: Coverage build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22260#c16 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-1a055780-2304-4f4f-9a68-60a242ecb544.txt -- 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 25827 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Parser::ParseSpecifierQualifierList
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-09-21 Type: Bug New issue 25827 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Parser::ParseSpecifierQualifierList https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25827 Detailed Report: https://oss-fuzz.com/testcase?key=5695205804867584 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe9fddfe08 Crash State: clang::Parser::ParseSpecifierQualifierList clang::Parser::ParseBlockId clang::Parser::ParseBlockLiteralExpression Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009170602:202009180613 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5695205804867584 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] Issue 25832 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in processTypeAttrs
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-09-21 Type: Bug New issue 25832 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in processTypeAttrs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25832 Detailed Report: https://oss-fuzz.com/testcase?key=5961135424274432 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff25f56fe0 Crash State: processTypeAttrs GetFullTypeForDeclarator clang::Sema::GetTypeForDeclarator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009180613:202009190621 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5961135424274432 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 47248] auto type of variables can not compile
https://bugs.llvm.org/show_bug.cgi?id=47248 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 47555] Inherited constructor unusable for constexpr static member of class template
https://bugs.llvm.org/show_bug.cgi?id=47555 Richard Smith changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||7337f296194483e0959ff980049 ||e2835e226f396 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 47591] New: incorrect SelectionDAG Code generation with FrameIndex load/stores
https://bugs.llvm.org/show_bug.cgi?id=47591
Bug ID: 47591
Summary: incorrect SelectionDAG Code generation with FrameIndex
load/stores
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ys114...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
The original issue is reported in iovisor/bpftrace:
https://github.com/iovisor/bpftrace/issues/1305
I reproduced it in llvm10 and the latest trunk also has issues.
The following is the step to reproduce:
1. I have produced an IR file (ir.ll) below to reproduce the issue:
[yhs@devvm1886.ftw0 ~/work/test/ir]$ cat ir.ll
; ModuleID = 'bpftrace'
source_filename = "bpftrace"
target datalayout = "e-m:e-p:64:64-i64:64-n32:64-S128"
target triple = "bpf-pc-linux"
%printf_t = type { i64, i64 }
; Function Attrs: nounwind
declare i64 @llvm.bpf.pseudo(i64 %0, i64 %1) #0
define i64 @"kprobe:blk_update_request"(i8* %0) local_unnamed_addr section
"s_kprobe:blk_update_request_1" {
entry:
%"struct kernfs_node.parent" = alloca i64, align 8
%printf_args = alloca %printf_t, align 8
%"struct cgroup.kn" = alloca i64, align 8
%"struct cgroup_subsys_state.cgroup" = alloca i64, align 8
%"struct blkcg_gq.blkcg" = alloca i64, align 8
%"struct bio.bi_blkg" = alloca i64, align 8
%"struct request.bio" = alloca i64, align 8
%1 = getelementptr i8, i8* %0, i64 112
%2 = bitcast i8* %1 to i64*
%arg0 = load volatile i64, i64* %2, align 8
%3 = add i64 %arg0, 56
%4 = bitcast i64* %"struct request.bio" to i8*
call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %4)
%probe_read = call i64 inttoptr (i64 4 to i64 (i64*, i32, i64)*)(i64* nonnull
%"struct request.bio", i32 8, i64 %3)
%5 = load i64, i64* %"struct request.bio", align 8
call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %4)
%6 = add i64 %5, 72
%7 = bitcast i64* %"struct bio.bi_blkg" to i8*
call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %7)
%probe_read1 = call i64 inttoptr (i64 4 to i64 (i64*, i32, i64)*)(i64*
nonnull %"struct bio.bi_blkg", i32 8, i64 %6)
%8 = load i64, i64* %"struct bio.bi_blkg", align 8
call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %7)
%9 = add i64 %8, 40
%10 = bitcast i64* %"struct blkcg_gq.blkcg" to i8*
call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %10)
%probe_read2 = call i64 inttoptr (i64 4 to i64 (i64*, i32, i64)*)(i64*
nonnull %"struct blkcg_gq.blkcg", i32 8, i64 %9)
%11 = load i64, i64* %"struct blkcg_gq.blkcg", align 8
call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %10)
%12 = bitcast i64* %"struct cgroup_subsys_state.cgroup" to i8*
call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %12)
%probe_read3 = call i64 inttoptr (i64 4 to i64 (i64*, i32, i64)*)(i64*
nonnull %"struct cgroup_subsys_state.cgroup", i32 8, i64 %11)
%13 = load i64, i64* %"struct cgroup_subsys_state.cgroup", align 8
call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %12)
%14 = add i64 %13, 288
%15 = bitcast i64* %"struct cgroup.kn" to i8*
call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %15)
%probe_read4 = call i64 inttoptr (i64 4 to i64 (i64*, i32, i64)*)(i64*
nonnull %"struct cgroup.kn", i32 8, i64 %14)
%16 = load i64, i64* %"struct cgroup.kn", align 8
call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %15)
%17 = bitcast %printf_t* %printf_args to i8*
call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %17)
%18 = add i64 %16, 8
%19 = bitcast i64* %"struct kernfs_node.parent" to i8*
%20 = getelementptr inbounds %printf_t, %printf_t* %printf_args, i64 0, i32 0
store i64 0, i64* %20, align 8
call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %19)
%probe_read5 = call i64 inttoptr (i64 4 to i64 (i64*, i32, i64)*)(i64*
nonnull %"struct kernfs_node.parent", i32 8, i64 %18)
%21 = load i64, i64* %"struct kernfs_node.parent", align 8
call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %19)
%22 = getelementptr inbounds %printf_t, %printf_t* %printf_args, i64 0, i32 1
store i64 %21, i64* %22, align 8
%pseudo = call i64 @llvm.bpf.pseudo(i64 1, i64 1)
%get_cpu_id = call i64 inttoptr (i64 8 to i64 ()*)()
%perf_event_output = call i64 inttoptr (i64 25 to i64 (i8*, i64, i64,
%printf_t*, i64)*)(i8* %0, i64 %pseudo, i64 %get_cpu_id, %printf_t* nonnull
%printf_args, i64 16)
call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %17)
ret i64 0
}
; Function Attrs: argmemonly nounwind willreturn
declare void @llvm.lifetime.start.p0i8(i64 immarg %0, i8* nocapture %1) #1
; Function Attrs: argmemonly nounwind willreturn
declare void @llvm.lifetime.end.p0i8(i64 immarg %0, i8* nocapture %1) #1
attributes #0 = { nounwind }
attributes #1 = { argmemonly nounwind willre
