[llvm-bugs] [Bug 48398] New: Compilation error
https://bugs.llvm.org/show_bug.cgi?id=48398 Bug ID: 48398 Summary: Compilation error Product: clang Version: 10.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: silver.po...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 24239 --> https://bugs.llvm.org/attachment.cgi?id=24239&action=edit The file which demonstrates the compilation error. Hello It seems like a compiler bug. I detected it during the compilation of MSVC runtime sources with CLang. For your convenience, I have created a file which demonstrates the problem. See the attached "error.cpp". Best wishes, Igor Popov -- 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 48399] New: [NewPM] PassBuilder/Clang do not support function merging
https://bugs.llvm.org/show_bug.cgi?id=48399 Bug ID: 48399 Summary: [NewPM] PassBuilder/Clang do not support function merging Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: nikita@gmail.com CC: llvm-bugs@lists.llvm.org While MergeFunctions supports NPM, it is currently not integrated in PassBuilder and not enabled by clang under -fmerge-functions. The test https://github.com/llvm/llvm-project/blob/master/clang/test/CodeGenCXX/merge-functions.cpp should have "-fno-experimental-pass-manager" removed once this is 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 48400] New: [NewPM] Memory usage regression
https://bugs.llvm.org/show_bug.cgi?id=48400 Bug ID: 48400 Summary: [NewPM] Memory usage regression Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: nikita@gmail.com CC: llvm-bugs@lists.llvm.org While the NewPM seems to improve compile-time (on average), it can also significantly regress memory usage: https://llvm-compile-time-tracker.com/compare.php?from=ec13b391170e5984894e1c8635a6964e79572205&to=29c614c923e05cd3015cbd8bceeadf427cd4b6d9&stat=max-rss The 30% regression on tramp3d-v4 especially seems notable. -- 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 28226 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupQualifiedName
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 28226 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupQualifiedName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28226#c1 ClusterFuzz testcase 5647786230022144 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202012030625:202012050612 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] Issue 28321 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupQualifiedName
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-05 Type: Bug New issue 28321 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupQualifiedName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28321 Detailed Report: https://oss-fuzz.com/testcase?key=4833083211382784 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffdfab88f40 Crash State: clang::Sema::LookupQualifiedName clang::Sema::DiagnoseEmptyLookup FinishOverloadedCallExpr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4833083211382784 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 48401] New: LLDB can't load .PDB files when debugging executables built with MSVC
https://bugs.llvm.org/show_bug.cgi?id=48401 Bug ID: 48401 Summary: LLDB can't load .PDB files when debugging executables built with MSVC Product: lldb Version: 11.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: keithwi...@gmail.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org I cannot get LLDB to display any debugging info at all for MSVC binaries that use PDB files to store their debugging info. -- 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 48402] New: Rejects valid subscript expression on array of unknown bound in constant expression
https://bugs.llvm.org/show_bug.cgi?id=48402
Bug ID: 48402
Summary: Rejects valid subscript expression on array of unknown
bound in constant expression
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: leni...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
2518433f861fcb877d0a7bdd9aec1aec1f77505a)
command line options: -std=c++11 -pedantic-errors
Also reproducible with c++14, c++17 and c++20
```
extern const int arr[];
constexpr const int (&arrref)[] = arr;
constexpr int arr[2] = {1,2};
constexpr int x = arrref[0];
```
error: constexpr variable 'x' must be initialized by a constant expression
constexpr int x = arrref[0];
^ ~
note: read of element of array without known bound is not allowed in a constant
expression
constexpr int x = arrref[0];
Accessing elements through arrays of unknown bound is not explicitly forbidden
in constant expressions, so I think it is valid.
The followings are accepted:
```
extern const int arr[];
constexpr const int * ptr = arr;
constexpr int arr[2] = {1,2};
constexpr int x = ptr[0];
```
```
extern const int arr[];
constexpr const int (&arrref)[] = arr;
constexpr int arr[2] = {1,2};
constexpr const int* decay() {
return arrref;
}
constexpr int x = decay()[0];
```
P0388 is accepted in C++20 and will enable other ways of creating subscript
constant expressions to arrays of unknown bound. Related gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97645
--
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 48403] New: Backport fix for --pgo-warn-misexpect from 12 to 11
https://bugs.llvm.org/show_bug.cgi?id=48403 Bug ID: 48403 Summary: Backport fix for --pgo-warn-misexpect from 12 to 11 Product: clang Version: 11.0 Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: jeanmichael.celer...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Issue is that invoking a compilation through libclang twice in the same process gives "clang (LLVM option parsing): for the --pgo-warn-misexpect option: may only occur zero or one times!" and then crashes : https://reviews.llvm.org/D66324#1680232 The trivial fix is in LLVM 12 : https://github.com/llvm/llvm-project/commit/6d2b75e0887ee87e247756c4d51733616bb2f356 It seems to apply without issues in current 11.X - could this be backported please ? -- 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 48404] New: Missed Optimization: CLZ Loop -> CLZ instruction
https://bugs.llvm.org/show_bug.cgi?id=48404
Bug ID: 48404
Summary: Missed Optimization: CLZ Loop -> CLZ instruction
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: haneef...@gmail.com
CC: llvm-bugs@lists.llvm.org
Both of these are equivalent (the latter uses a builtin compiler intrinsic),
but only the latter emits the platform native CLZ instruction:
C(++):
unsigned clz_a (unsigned x) {
unsigned w = sizeof (x) * 8;
while (x) {
w--;
x >>= 1;
}
return w;
}
unsigned clz_b (unsigned x) {
return __builtin_clzll (x);
}
x86-64 (clang -O3 -march=skylake) Assembly:
clz_a(unsigned int): # @clz_a(unsigned int)
mov eax, 32
testedi, edi
je .LBB0_2
.LBB0_1:# =>This Inner Loop Header: Depth=1
dec eax
shr edi
jne .LBB0_1
.LBB0_2:
ret
clz_b(unsigned int): # @clz_b(unsigned int)
mov eax, edi
lzcnt rax, rax
ret
A potential issue is that the intrinsic __builtin_clz(x) comes from GCC, where
they've stated that the behavior of the intrinsic is UB iff (x == 0), likely
since the old x86 BSR instruction yields an undefined result iff (x == 0).
However, it should be straightforward for LLVM to make __builtin_clz(x) well
defined even when (x == 0) by simply emitting a CMOV with the appropriate with
in conjunction when compiling for x86 uarchs too old to have LZCNT support.
AFAICT all other platforms have well defined results for all inputs to their
CLZ instructions.
--
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 48405] New: Segfault from template typedef inside template class instantiated with local generic lambda
https://bugs.llvm.org/show_bug.cgi?id=48405
Bug ID: 48405
Summary: Segfault from template typedef inside template class
instantiated with local generic lambda
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 program, compiled with -std=c++20, causes a segfault in clang
trunk (but not clang 11.0.0):
template
struct Factory {
template
using Instance = decltype(Lambda.template operator()(0));
};
int main() {
auto lambda = [](auto){};
using T = Factory::Instance;
}
(https://gcc.godbolt.org/z/93Gr16)
The following variant, compiled with -std=c++14, causes a segfault all the way
back in clang 3.5 (and up to and including trunk):
#include
template
struct Factory {
template
using Instance = decltype(std::declval().template
operator()(0));
};
int main() {
auto lambda = [](auto){};
using T = Factory::Instance;
}
(https://gcc.godbolt.org/z/YE1dY3)
Here is the stack trace from the first example using clang trunk:
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. :8:32: at annotation token
2. :6:12: parsing function body 'main'
3. :6:12: in compound statement ('{}')
4. :7:19: instantiating class definition ''
#0 0x55c5ad5b953c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2e0053c)
#1 0x55c5ad5b72d4 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2dfe2d4)
#2 0x55c5ad5b7565 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2dfe565)
#3 0x55c5ad525a78 CrashRecoverySignalHandler(int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2d6ca78)
#4 0x7f90dd6cc3c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#5 0x55c5af972aee
clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*,
clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation,
clang::DeclarationName, clang::CXXRecordDecl*, clang::Qualifiers)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51b9aee)
#6 0x55c5af9830c4
clang::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*,
llvm::SmallVectorImpl&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51ca0c4)
#7 0x55c5af997b10
clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*,
clang::TemplateParameterList*,
llvm::Optional,
clang::TemplateDeclInstantiator::RewriteKind)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51deb10)
#8 0x55c5af967d4f clang::Sema::InstantiateClass(clang::SourceLocation,
clang::CXXRecordDecl*, clang::CXXRecordDecl*,
clang::MultiLevelTemplateArgumentList const&,
clang::TemplateSpecializationKind, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51aed4f)
#9 0x55c5af9978a0
clang::TemplateDeclInstantiator::VisitCXXRecordDecl(clang::CXXRecordDecl*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51de8a0)
#10 0x55c5af9996b4 void llvm::function_ref::callback_fn(long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51e06b4)
#11 0x55c5af2e571f
clang::Sema::runWithSufficientStackSpace(clang::SourceLocation,
llvm::function_ref)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4b2c71f)
#12 0x55c5af982bb3 clang::Sema::SubstDecl(clang::Decl*,
clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51c9bb3)
#13 0x55c5af98bd4d clang::Sema::FindInstantiatedDecl(clang::SourceLocation,
clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51d2d4d)
#14 0x55c5af946b8b (anonymous
namespace)::TemplateInstantiator::TransformDecl(clang::SourceLocation,
clang::Decl*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x518db8b)
#15 0x55c5af96ab44 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformUnresolvedMemberExpr(clang::UnresolvedMemberExpr*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51b1b44)
#16 0x55c5af9544b1 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x519b4b1)
#17 0x55c5af95af94 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x51a1f94)
#18 0x55c5af9541ed clang::TreeTransform<(an
[llvm-bugs] [Bug 48406] New: Failure to optimize out abs when sign is known
https://bugs.llvm.org/show_bug.cgi?id=48406
Bug ID: 48406
Summary: Failure to optimize out abs when sign is known
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(int x)
{
__builtin_assume(x <= 0);
return abs(x);
}
This can be optimized to `return -x;`. This transformation is done by GCC (with
__builtin_assume replaced by `if (!(x <= 0)) __builtin_unreachable()`), but not
by LLVM.
--
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
