[llvm-bugs] [Bug 49504] New: Crash when parsing template with variadic template template parameter
https://bugs.llvm.org/show_bug.cgi?id=49504 Bug ID: 49504 Summary: Crash when parsing template with variadic template template parameter Product: clang Version: 11.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++11 Assignee: unassignedclangb...@nondot.org Reporter: johannes.w...@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 24613 --> https://bugs.llvm.org/attachment.cgi?id=24613&action=edit VS output and clang requested data Visual Studio 2019 with Clang. Crash when parsing template with variadic template template parameter. Compiles with msvc. Crashes with version 11 and 12 -- 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 49505] New: Clang frontend command failed when using wrong constraint functions
https://bugs.llvm.org/show_bug.cgi?id=49505
Bug ID: 49505
Summary: Clang frontend command failed when using wrong
constraint functions
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
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 will trigger the clang frontend error:
template
concept C = requires (T = {}) { true; };
auto f(C auto) {}
int main() { f(0); }
(godbolt: https://godbolt.org/z/1cPexc)
error message:
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. :6:17: current parser token ')'
2. :6:12: parsing function body 'main'
3. :6:12: in compound statement ('{}')
#0 0x5561a79561ec llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x307d1ec)
#1 0x5561a7953f94 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x307af94)
#2 0x5561a7954215 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x307b215)
#3 0x5561a78b91c8 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
#4 0x7fb5cd3263c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#5 0x5561aa0df9e4 clang::DeclContext::isDependentContext() const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x58069e4)
#6 0x5561aa0dfb34 clang::Decl::isInLocalScopeForInstantiation() const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5806b34)
#7 0x5561a9d73e11 clang::Sema::SubstParmVarDecl(clang::ParmVarDecl*,
clang::MultiLevelTemplateArgumentList const&, int, llvm::Optional, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x549ae11)
#8 0x5561a9d74ed2 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformFunctionTypeParams(clang::SourceLocation,
llvm::ArrayRef, clang::QualType const*,
clang::FunctionType::ExtParameterInfo const*,
llvm::SmallVectorImpl&,
llvm::SmallVectorImpl*,
clang::Sema::ExtParameterInfoBuilder&) SemaTemplateInstantiate.cpp:0:0
#9 0x5561a9d75dda clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformRequiresExpr(clang::RequiresExpr*)
SemaTemplateInstantiate.cpp:0:0
#10 0x5561a9d59b89 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*)
SemaTemplateInstantiate.cpp:0:0
#11 0x5561a9d62db6 clang::Sema::SubstExpr(clang::Expr*,
clang::MultiLevelTemplateArgumentList const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5489db6)
#12 0x5561a97b5487 calculateConstraintSatisfaction(clang::Sema&,
clang::NamedDecl const*, llvm::ArrayRef,
clang::SourceLocation, clang::MultiLevelTemplateArgumentList&, clang::Expr
const*, clang::ConstraintSatisfaction&)::'lambda'(clang::Expr
const*)::operator()(clang::Expr const*) const SemaConcept.cpp:0:0
#13 0x5561a97b7113 bool
calculateConstraintSatisfaction,
clang::SourceLocation, clang::MultiLevelTemplateArgumentList&, clang::Expr
const*, clang::ConstraintSatisfaction&)::'lambda'(clang::Expr
const*)>(clang::Sema&, clang::Expr const*, clang::ConstraintSatisfaction&,
calculateConstraintSatisfaction(clang::Sema&, clang::NamedDecl const*,
llvm::ArrayRef, clang::SourceLocation,
clang::MultiLevelTemplateArgumentList&, clang::Expr const*,
clang::ConstraintSatisfaction&)::'lambda'(clang::Expr const*)&&)
SemaConcept.cpp:0:0
#14 0x5561a97b7b20
clang::Sema::CheckConstraintSatisfaction(clang::NamedDecl const*,
llvm::ArrayRef, llvm::ArrayRef,
clang::SourceRange, clang::ConstraintSatisfaction&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4edeb20)
#15 0x5561a9c8441e clang::Sema::CheckConceptTemplateId(clang::CXXScopeSpec
const&, clang::SourceLocation, clang::DeclarationNameInfo const&,
clang::NamedDecl*, clang::ConceptDecl*, clang::TemplateArgumentListInfo const*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x53ab41e)
#16 0x5561a9d6abbc clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformConceptSpecializationExpr(clang::ConceptSpecializationExpr*)
SemaTemplateInstantiate.cpp:0:0
#17 0x5561a9d59874 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*)
SemaTemplateInstantiate.cpp:0:0
#18 0x5561a9d62db6 clang::Sema::SubstExpr(clang::Expr*,
clang::MultiLevelTemplateArgumentList const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5489
[llvm-bugs] [Bug 49508] New: Dependencies in INTERFACE_LINK_LIBRARIES should be detected with find_dependency
https://bugs.llvm.org/show_bug.cgi?id=49508 Bug ID: 49508 Summary: Dependencies in INTERFACE_LINK_LIBRARIES should be detected with find_dependency Product: Build scripts Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: ma...@emmenlauer.de CC: llvm-bugs@lists.llvm.org Currently `LLVMExports.cmake` contains `INTERFACE_LINK_LIBRARIES` with entries like `"z;rt;dl;tinfo;-lpthread;m;LLVMDemangle"` for the LLVM Ubuntu packages. This assumes that a user has library `z` and others available in a system directory, which may not necessarily be the case. Modern clean cmake policy suggests that library dependencies should be searched with `find_dependency` (see https://cmake.org/cmake/help/latest/module/CMakeFindDependencyMacro.html) rather than hardcoded. This will allow to include paths in the search that a user configured for the original main cmake project. I.e. it allows users to say `cmake -DCMAKE_PREFIX_PATH=xxx`, to add a number of non-standard directories to the search 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 49499] llvm-mca for cortex-a57 gets thrown off by SIMD loads with dependencies (negative latency?)
https://bugs.llvm.org/show_bug.cgi?id=49499 Martin Storsjö changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Martin Storsjö --- (In reply to Andrea Di Biagio from comment #1) > tl;dr: there is no negative latency. WAW dependencies are effectively broken > by the register renamer. > > Cortex-a57 is an out-of-order processor. The default llvm-mca pipeline for > out-of-order processors assumes the presence of a register renamer. > > It means that false dependencies are effectively broken by the register > renamer at the cost of consuming a physical register. > > As far as I undestand, each ADD has a latency of 3cy. Also, ADD instructions > are in a dependency chain. When simulating multiple iterations, there is an > implicit loop carried dependency (i.e the first ADD of an iteration must > wait for the result from the last ADD of a previous iteration). That's why > latency converges to 900cy for the first experiment. > > In the second experiment, you have inserted a load which writes the same > registers defined by the following ADD instructions. > The LD1 introduces new definitions for v0.16b, v1.16b, v2.16b, v3.16b. > There is a WAW dependency on each of those registers. In the absence of > register renaming, that load would need to wait until those registers are > written. In practice however, the register renamer "renames" breaks those > dependencies, so the LOAD doesn't need to wait on those definitions. > > The throughput of LD1 is still limited (roughly one LD1 every 4 > instructions). Therefore, every 4 cycles, the first ADD of a new iteration > can start execution. That's how you end up with that low number of cycles. > > The last example is just like the first, with the extra LD1. The LD1 is > independent from the other instructions, so it can always execute as soon as > the units are available. > > NOTE: by default, llvm-mca assumes that register renaming is always > successful (i.e. as if there is an unbounded number of phys registers > available for renaming). Renaming can be limited by introducing a (optional) > `RegisterFile` definition in the scheduling model. For an example of > `RegisterFile`, see the definition of `JIntegerPRF` in > X86/X86ScheduleBtver2.td. Thanks for the thorough explanation! That does indeed explain it, and by setting e.g. `--iterations 1`, I also see numbers that match up better with my expectations. -- 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 49509] New: [PowerPC] Infinite loop in PeepholeCROps
https://bugs.llvm.org/show_bug.cgi?id=49509
Bug ID: 49509
Summary: [PowerPC] Infinite loop in PeepholeCROps
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: nikita@gmail.com
CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com
; RUN: llc -O2 < %s
target datalayout = "E-m:e-p:32:32-i64:64-n32"
target triple = "powerpc-unknown-linux-gnu"
define void @test() {
bb:
br i1 undef, label %bb2, label %bb1
bb2: ; preds = %bb
%i = select i1 undef, i64 0, i64 72057594037927936
store i64 %i, i64* undef, align 8
ret void
bb1: ; preds = %bb
%i50 = load i8, i8* undef, align 8
%i52 = load i128, i128* null, align 8
%i62 = icmp eq i8 %i50, 0
br i1 undef, label %bb66, label %bb64
bb64: ; preds = %bb63
ret void
bb66: ; preds = %bb63
%i67 = lshr i128 -1, 0
%i68 = xor i128 %i52, -1
%i69 = add i128 0, %i68
%i70 = and i128 %i67, %i69
%i71 = icmp eq i128 %i70, 0
%i74 = select i1 %i62, i64 0, i64 72057594037927936
%i75 = select i1 %i71, i64 144115188075855872, i64 %i74
store i64 %i75, i64* undef, align 8
ret void
}
This enters an infinite combine loop inside PPCDAGToDAGISel::PeepholeCROps().
--
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 49510] New: opt crashes with Assertion `HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"' failed.
https://bugs.llvm.org/show_bug.cgi?id=49510 Bug ID: 49510 Summary: opt crashes with Assertion `HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 24614 --> https://bugs.llvm.org/attachment.cgi?id=24614&action=edit bbi-53820.ll reproducer Running opt -bonus-inst-threshold=2 -o /dev/null bbi-53820.ll -simplifycfg -early-cse-memssa results in opt: ../include/llvm/ADT/ScopedHashTable.h:245: llvm::ScopedHashTableScope<(anonymous namespace)::SimpleValue, llvm::Value *, llvm::DenseMapInfo<(anonymous namespace)::SimpleValue>, llvm::RecyclingAllocator, llvm::ScopedHashTableVal<(anonymous namespace)::SimpleValue, llvm::Value *>, 32, 8> >::~ScopedHashTableScope() [K = (anonymous namespace)::SimpleValue, V = llvm::Value *, KInfo = llvm::DenseMapInfo<(anonymous namespace)::SimpleValue>, AllocatorTy = llvm::RecyclingAllocator, llvm::ScopedHashTableVal<(anonymous namespace)::SimpleValue, llvm::Value *>, 32, 8>]: Assertion `HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: build-all/bin/opt -bonus-inst-threshold=2 -o /dev/null bbi-53820.ll -simplifycfg -early-cse-memssa 1. Running pass 'Function Pass Manager' on module 'bbi-53820.ll'. 2. Running pass 'Early CSE w/ MemorySSA' on function '@f' #0 0x02957893 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build-all/bin/opt+0x2957893) #1 0x0295554e llvm::sys::RunSignalHandlers() (build-all/bin/opt+0x295554e) #2 0x02957d56 SignalHandler(int) (build-all/bin/opt+0x2957d56) #3 0x7f83bf6ed630 __restore_rt (/lib64/libpthread.so.0+0xf630) #4 0x7f83bce20387 raise (/lib64/libc.so.6+0x36387) #5 0x7f83bce21a78 abort (/lib64/libc.so.6+0x37a78) #6 0x7f83bce191a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6) #7 0x7f83bce19252 (/lib64/libc.so.6+0x2f252) #8 0x0264784b (anonymous namespace)::EarlyCSE::run() (build-all/bin/opt+0x264784b) #9 0x026509ee (anonymous namespace)::EarlyCSELegacyCommonPass::runOnFunction(llvm::Function&) (build-all/bin/opt+0x26509ee) #10 0x02153e8f llvm::FPPassManager::runOnFunction(llvm::Function&) (build-all/bin/opt+0x2153e8f) #11 0x0215a7e8 llvm::FPPassManager::runOnModule(llvm::Module&) (build-all/bin/opt+0x215a7e8) #12 0x0215445d llvm::legacy::PassManagerImpl::run(llvm::Module&) (build-all/bin/opt+0x215445d) #13 0x0077ae0c main (build-all/bin/opt+0x77ae0c) #14 0x7f83bce0c555 __libc_start_main (/lib64/libc.so.6+0x22555) #15 0x00765d85 _start (build-all/bin/opt+0x765d85) Abort This starts happening with 1742203844: [SimplifyCFG] FoldBranchToCommonDest(): re-lift restrictions on liveout uses of bonus instructions I have previously tried doing that in b33fbbaa34f0fe9fb16789afc72ae424c1825b69 / d38205144febf4dc42c9270c6aa3d978f1ef65e1, but eventually it was pointed out that the approach taken there was just broken wrt how the uses of bonus instructions are updated to account for the fact that they should now use either bonus instruction or the cloned bonus instruction. In particluar, all that manual handling of PHI nodes in successors was just wrong. But, the fix is actually much much simpler than my initial approach: just tell SSAUpdate about both instances of bonus instruction, and let it deal with all the PHI handling. Alive2 confirms that the reproducers from the original bugs (@pr48450*) are now handled correctly. This effectively reverts commit 59560e85897afc50090b6c3d920bacfd28b49d06, effectively relanding b33fbbaa34f0fe9fb16789afc72ae424c1825b69. -- 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 47460] clang-tidy doesn't work correctly when compile_commands.json contains symlink to clang
https://bugs.llvm.org/show_bug.cgi?id=47460 Nathan James changed: What|Removed |Added Product|clang-tools-extra |clang Component|clang-tidy |Tooling CC||llvm-bugs@lists.llvm.org --- Comment #4 from Nathan James --- I'm moving this to clang->Tooling as this seems like the issue is in the tooling, all clang-tidy has done is expose this issue. -- 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 49511] New: Compilation error when applying std::views::transform to std::array
https://bugs.llvm.org/show_bug.cgi?id=49511
Bug ID: 49511
Summary: Compilation error when applying std::views::transform
to std::array
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: raff...@casagrande.ch
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Unfortunately the following code fails to compile (using the STL of g++-10.2):
begin test program
#include
#include
std::array points_;
auto foo() {
auto v = std::views::transform([](int p) {return p;});
return points_ | v;
}
int main() {
auto z = foo();
}
end test program
The same code compiles without problems using g++-10.2 so I think it should be
valid code...
See also https://godbolt.org/z/e1ncvW
--
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 49512] New: lld/test/MachO tests should require shell less
https://bugs.llvm.org/show_bug.cgi?id=49512 Bug ID: 49512 Summary: lld/test/MachO tests should require shell less Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: g...@fb.com, jezr...@gmail.com, llvm-bugs@lists.llvm.org, smee...@fb.com LLVM is a cross-platform project, and tests should run on all platforms as much as possible. People should be able to hack on lld/MachO on Windows if they so choose. Despite lld/MachO being the youngest lld port, it already has the most tests that require shell: thakis@MBP llvm-project % rg -l shell lld/test/COFF | wc -l 3 thakis@MBP llvm-project % rg -l shell lld/test/ELF | wc -l 5 thakis@MBP llvm-project % rg -l shell lld/test/MachO | wc -l 7 This is a bad pattern and we should stop it. It looks almost all of these are due to this pattern: # RUN: (llvm-objdump --syms %t.basic; llvm-objdump --macho --function-starts %t.basic) | FileCheck %s --check-prefix=BASIC Instead, we probably just: # RUN: llvm-objdump --syms %t.basic > %t-objdump.txt # RUN: llvm-objdump --macho --function-starts %t.basic >> %t-objdump.txt # RUN: FileCheck %s --check-prefix=BASIC < %t-objdump.txt That's marginally longer, but it's easy to understand. Alternatively, maybe we could change llvm-objdump to be able to dump both symbols and something else but dump symbols first."Slightly longer but easy to understand" seems like a good option to me though :) -- 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 49513] New: Invalid type in constraint substitution results in hard error instead of substitution failure
https://bugs.llvm.org/show_bug.cgi?id=49513
Bug ID: 49513
Summary: Invalid type in constraint substitution results in
hard error instead of substitution failure
Product: clang
Version: 11.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: barry.rev...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
>From StackOverflow (https://stackoverflow.com/q/66562184/2069064):
template
struct A {
constexpr bool operator()() requires T::value { return T::value; }
constexpr bool operator()() { return false; }
};
static_assert(!A()());
clang rejects this, saying:
:3:42: error: type 'void' cannot be used prior to '::' because it has
no members
constexpr bool operator()() requires T::value { return T::value; }
^
:7:16: note: in instantiation of template class 'A' requested
here
static_assert(!A()());
^
But the rule in [temp.constr.atomic] is that "if substitution results in an
invalid type or expression, the constraint is not satisfied." Which is what
should happen here. gcc and msvc accept.
--
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 49514] New: -t does not print dylibs loaded by -flat_namespace
https://bugs.llvm.org/show_bug.cgi?id=49514 Bug ID: 49514 Summary: -t does not print dylibs loaded by -flat_namespace Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: g...@fb.com, jezr...@gmail.com, llvm-bugs@lists.llvm.org, smee...@fb.com (Mostly note for future self (?)) We need tests that dylibs loaded from -flat_namespace are in -t output (at the moment, they aren't), and that they are in --reproduce output (this is already correct, I think). This command can be used for local testing after running `check-lld`: out/gn/bin/ld64.lld -syslibroot lld/test/MachO/Inputs/MacOSX.sdk -flat_namespace out/gn/obj/lld/test/MachO/Output/flat-namespace.s.tmp/main.o out/gn/obj/lld/test/MachO/Output/flat-namespace.s.tmp/baz.dylib -o out/gn/obj/lld/test/MachO/Output/flat-namespace.s.tmp/out -t -flat_namespace --reproduce=repro.tar Interesting things to check: +// - normal .dylib on cmdline not printed twice +// - dylib from -flat_namespace in LC_LOAD_DYLIB not printed twice +// - reexport-library +// - LC_LOAD_WEAK_DYLIB +// - order of -t output (should be main baz bar foo) +// - --reproduce with these I tried implementing this by putting + if (config->printEachFile) +message(toString(this)); in the two Dylib ctors and not printing dylibs in addFile() in Driver if isa(newFile). However, that doesn't quite work: Since the Dylib ctors recursively load more dylibs for flat_namespace, the cache in loadDylib() in DriverUtils.cpp is updated too late (only after the whole recursion has completed), and we print some dylibs more than once then. It's probably not a great idea to recursively load dylibs in the DylibFile ctor and we should do that after construction in a dedicated method. That'd mean DylibFile would have to keep a list of pending dylib loads. -- 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 49515] New: Segfault in llvm-profdata (11.0.1)
https://bugs.llvm.org/show_bug.cgi?id=49515 Bug ID: 49515 Summary: Segfault in llvm-profdata (11.0.1) Product: tools Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: support scripts Assignee: unassignedb...@nondot.org Reporter: warchan...@gmail.com CC: greg.bedw...@sony.com, i...@maskray.me, llvm-bugs@lists.llvm.org PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: llvm-profdata llvm-profdata merge -o 1.profdata deserialization_fuzz.profraw #0 0x7f194f1ea0db llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/../lib/libLLVM-11.so+0xa760db) #1 0x7f194f1e7e14 llvm::sys::RunSignalHandlers() (/usr/bin/../lib/libLLVM-11.so+0xa73e14) #2 0x7f194f1e7f61 (/usr/bin/../lib/libLLVM-11.so+0xa73f61) #3 0x7f194e766960 __restore_rt (/usr/bin/../lib/libpthread.so.0+0x13960) #4 0x7f194e506470 __memchr_avx2 (/usr/bin/../lib/libc.so.6+0x15d470) #5 0x7f194f17839d llvm::StringRef::find(llvm::StringRef, unsigned long) const (/usr/bin/../lib/libLLVM-11.so+0xa0439d) #6 0x7f194f178aa5 llvm::StringRef::split(llvm::SmallVectorImpl&, llvm::StringRef, int, bool) const (/usr/bin/../lib/libLLVM-11.so+0xa04aa5) #7 0x7f1951ff8821 llvm::readPGOFuncNameStrings(llvm::StringRef, llvm::InstrProfSymtab&) (/usr/bin/../lib/libLLVM-11.so+0x3884821) #8 0x7f1952bb llvm::RawInstrProfReader::createSymtab(llvm::InstrProfSymtab&) (/usr/bin/../lib/libLLVM-11.so+0x388c0bb) #9 0x7f19520003df llvm::RawInstrProfReader::readHeader(llvm::RawInstrProf::Header const&) (/usr/bin/../lib/libLLVM-11.so+0x388c3df) #10 0x7f1952000789 llvm::RawInstrProfReader::readNextHeader(char const*) (/usr/bin/../lib/libLLVM-11.so+0x388c789) #11 0x7f1952003305 llvm::RawInstrProfReader::readNextRecord(llvm::NamedInstrProfRecord&) (/usr/bin/../lib/libLLVM-11.so+0x388f305) #12 0x7f1951fff4c1 llvm::InstrProfIterator::Increment() (/usr/bin/../lib/libLLVM-11.so+0x388b4c1) #13 0x562297f1a8f3 (/usr/bin/llvm-profdata+0xf8f3) #14 0x562297f2705c (/usr/bin/llvm-profdata+0x1c05c) #15 0x562297f2abed (/usr/bin/llvm-profdata+0x1fbed) #16 0x562297f1217a (/usr/bin/llvm-profdata+0x717a) #17 0x7f194e3d0b25 __libc_start_main (/usr/bin/../lib/libc.so.6+0x27b25) #18 0x562297f123ce (/usr/bin/llvm-profdata+0x73ce) [1]331566 segmentation fault (core dumped) llvm-profdata merge -o 1.profdata deserialization_fuzz.profraw -- 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 49516] New: compiler crashes when trying to instantiate a templated lambda in function scope.
https://bugs.llvm.org/show_bug.cgi?id=49516 Bug ID: 49516 Summary: compiler crashes when trying to instantiate a templated lambda in function scope. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: jgar...@quantiqpartners.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 24616 --> https://bugs.llvm.org/attachment.cgi?id=24616&action=edit crash files Trying to instantiate a templated lambda inside a function scope causes a crash. Attached are the stack trace and the .sh and .cpp files generated by the compiler's signal handler. -- 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 49517] New: initializer_list storage considered a temporary when accessed through NTTP
https://bugs.llvm.org/show_bug.cgi?id=49517
Bug ID: 49517
Summary: initializer_list storage considered a temporary when
accessed through NTTP
Product: clang
Version: trunk
Hardware: PC
URL: https://godbolt.org/z/aWGr3P
OS: Linux
Status: NEW
Keywords: compile-fail
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: johel...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
johel...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
See https://godbolt.org/z/aWGr3P.
```C++
#include
constexpr std::initializer_listil{true};
templateconstexpr bool front=B[0];
static_assert(front);
```
https://timsong-cpp.github.io/cppwp/n4861/dcl.init.list#5 explains its storage.
https://timsong-cpp.github.io/cppwp/n4861/dcl.init.list#6 explains its
lifetime.
--
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 49518] New: llvm-objdump doesn't calculate relative branch target address for arm binaries
https://bugs.llvm.org/show_bug.cgi?id=49518 Bug ID: 49518 Summary: llvm-objdump doesn't calculate relative branch target address for arm binaries Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: yab...@google.com CC: llvm-bugs@lists.llvm.org Created attachment 24617 --> https://bugs.llvm.org/attachment.cgi?id=24617&action=edit arm binary for testing For arm binaries, llvm-objdump doesn't calculate relative branch target address. Instead, it only shows offsets from current address. And users need to calculate target address manually. Below is an example: $ llvm-objdump -dlC --no-show-raw-insn --start-address=0x784 --stop-address=0x7d4 simpleperf_runtest_two_functions_arm 0784 : ; main(): ... 7a4: movsr1, #0 ; system/extras/simpleperf/runtest/two_functions.cpp:9 7a6: str.w r1, [r7, r0, lsl #2] ; system/extras/simpleperf/runtest/two_functions.cpp:8 7aa: addsr1, #1 7ac: cmp r6, r1 7ae: bne #-12 To know the branch target address of bne instruction in 0x7ae, we need to calculate either 0x7ae + 4 - 12, or 0x784 + 0x22. But there is no directly show of 0x7a6. For comparison, binutils objdump for arm binaries shows branch target address as below: $ arm-linux-androideabi-objdump -dlC --no-show-raw-insn --start-address=0x784 --stop-address=0x7d4 simpleperf_runtest_two_functions_arm 0784 : ... system/extras/simpleperf/runtest/two_functions.cpp:9 7a6: str.w r1, [r7, r0, lsl #2] system/extras/simpleperf/runtest/two_functions.cpp:8 7aa: addsr1, #1 7ac: cmp r6, r1 7ae: bne.n 7a6 ... And llvm-objdump shows branch target address for binaries in other targets, including arm64, x86, x86_64. -- 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 49242] FAIL: test_terminate_commands (TestVSCode_attach.TestVSCode_attach)
https://bugs.llvm.org/show_bug.cgi?id=49242 Neil Nelson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Neil Nelson --- Not showing in 12.0.0 rc3 run. -- 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 49519] New: [clang-format] infinite loops
https://bugs.llvm.org/show_bug.cgi?id=49519 Bug ID: 49519 Summary: [clang-format] infinite loops Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: kadircetinkaya.06...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org running clang-format on https://github.com/mackron/miniaudio/blob/d06d4983d3ff512690eb37f5edd25bf96f8f3764/miniaudio.h results in clang-format infinite looping, constantly allocating more memory until process runs OOM. ``` $ ~/repos/llvm/build/bin/clang-format --version clang-format version 13.0.0 (g...@github.com:llvm/llvm-project.git 99b01cf28db9db1a3ec0e25367bd325b7aca6d43) ``` -- 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 49520] New: Erroneous template deduction
https://bugs.llvm.org/show_bug.cgi?id=49520
Bug ID: 49520
Summary: Erroneous template deduction
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: colinmacl...@lbl.gov
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I discovered a bug in Clang's template argument deduction while working on
array support for a pointer wrapping class. This incorrect behavior can be
simplified into the following reproducer:
#include
template
struct A {};
template
struct A : A {};
template
void foo(T* a, A& b) {}
template
void bar(T* a, A>& b) {}
void test()
{
int * t1;
A t2;
A t3;
foo(t1,t2);
foo(t1,t3); // GCC: correctly errors on conflicting deductions for T: int
and int[]
// Clang: Erroneously performs implicit cast, which should only
be allowed
//after a successful template deduction
bar(t1,t2);
bar(t1,t3); // Compliant implicit cast for second argument.
}
In the case of the function foo(), the deduction should try to deduce to both
int and int[] simultaneously with the parameters t1 and t3 and fail due to
being different types. Godbolt shows T is deduced to int on Clang.
std::type_identity_t should be necessary to establish a non-deduced context
if implicit conversion to A is desired. This implicit conversion should
only happen after a template deduction is successful.
This bug affects all known Clang versions, tested from 3.0 to trunk with
Godbolt. It also affects all C++ standard options used from C++98 to C++2a.
--
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 49521] New: OpenMP missing profile instrumentation counter in CGOpenMPRegionInfo::EmitBody
https://bugs.llvm.org/show_bug.cgi?id=49521
Bug ID: 49521
Summary: OpenMP missing profile instrumentation counter in
CGOpenMPRegionInfo::EmitBody
Product: OpenMP
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: lxf...@gmail.com
CC: llvm-bugs@lists.llvm.org
In CGOpenMPRegionInfo::EmitBody, it does not emit any profile counter
increment, which means that the instrumentation of a function generated this
way will be missing the function entry count. In some cases this leads to
inaccurate instrumentation, while in worse cases some function has no counter
emitted, causing llvm-cov to error out since some functions are missing from
the function name table.
A fix attempt is https://reviews.llvm.org/D98135, but it seems to have some
issues.
Example test case:
// RUN: %clang_cc1 -verify -fopenmp -x c -emit-llvm %s -triple
x86_64-unknown-linux -o - -femit-all-decls -disable-llvm-passes
-fprofile-instrument=clang | FileCheck %s
// expected-no-diagnostics
void sub(double *restrict a, double *restrict b, int n) {
int i;
#pragma omp parallel for
#pragma clang loop vectorize(disable)
for (i = 0; i < n; i++) {
a[i] = a[i] + b[i];
}
}
// CHECK-LABEL: @.omp_outlined.(
// CHECK-NEXT: entry:
// CHECK: call void @llvm.instrprof.increment(
// CHECK: omp.precond.then:
// CHECK-NEXT:call void @llvm.instrprof.increment(
// CHECK: cond.true:
// CEHCK-NEXT:call void @llvm.instrprof.increment(
// CHECK: omp.inner.for.body:
// CHECK-NEXT:call void @llvm.instrprof.increment(
--
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 48945] [meta] 11.1.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48945 Bug 48945 depends on bug 49096, which changed state. Bug 49096 Summary: FAIL: SanitizerCommon-Unit Test/SanitizerLinux.ThreadDescriptorSize https://bugs.llvm.org/show_bug.cgi?id=49096 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 49096] FAIL: SanitizerCommon-Unit Test/SanitizerLinux.ThreadDescriptorSize
https://bugs.llvm.org/show_bug.cgi?id=49096 Neil Nelson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Neil Nelson --- This bug not happening for the 12.0.0 r3 run. -- 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 49095] FAIL: lldb-api Assertion `(!raw_stop_description.empty() || stop_info_sp->GetStopReason() == eStopReasonNone) && "StopInfo returned an empty description."' failed.
https://bugs.llvm.org/show_bug.cgi?id=49095 Neil Nelson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Neil Nelson --- This bug not happening for 12.0.0 rc3 run. -- 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 31933 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in AnalyzeImplicitConversions
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-10 Type: Bug New issue 31933 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in AnalyzeImplicitConversions https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31933 Detailed Report: https://oss-fuzz.com/testcase?key=5677419324375040 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x70b6cfd8 Crash State: AnalyzeImplicitConversions Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010190618:202010200603 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5677419324375040 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 28731 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Updates: Labels: Deadline-Approaching Comment #1 on issue 28731 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28731#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 47613] InstCombine leaves extra call to sqrtf from pow transform
https://bugs.llvm.org/show_bug.cgi?id=47613 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||7c49f3c75be9 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Sanjay Patel --- https://reviews.llvm.org/rG7c49f3c75be9 -- 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 49522] New: DebugInfo Stripping sometimes causes a Broken Input Module
https://bugs.llvm.org/show_bug.cgi?id=49522 Bug ID: 49522 Summary: DebugInfo Stripping sometimes causes a Broken Input Module Product: libraries Version: trunk Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: rever...@digital.ai CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com Created attachment 24619 --> https://bugs.llvm.org/attachment.cgi?id=24619&action=edit Source code from Boost::Spirit (I think) that leaves Debug Metadata after stripping With the latest LLVM source and the recent Xcode 12.5 betas, we've noticed that stripping debug info from certain object files is broken both in the clang++ frontend and when directly calling llvm::StripDebugInfo or using llvm::createStripSymbolsPass(true). The error seen after lowering a stripped object file with embedded bitcode: DICompileUnit not listed in llvm.dbg.cu !3714 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !10, producer: "clang version 13.0.0 (https://github.com/llvm/llvm-project 023b5c1ed8d1577bf0cf298b64a0a047b13fc418)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !3715, retainedTypes: !3729, globals: !29030, imports: !29860, splitDebugInlining: false, nameTableKind: None, sysroot: "/Applications/Xcode_12.5b2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk", sdk: "MacOSX.sdk") warning: ignoring invalid debug info in spirit.stripped.o DICompileUnit not listed in llvm.dbg.cu !3714 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !10, producer: "clang version 13.0.0 (https://github.com/llvm/llvm-project 023b5c1ed8d1577bf0cf298b64a0a047b13fc418)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !3715, retainedTypes: !3729, globals: !29030, imports: !29860, splitDebugInlining: false, nameTableKind: None, sysroot: "/Applications/Xcode_12.5b2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk", sdk: "MacOSX.sdk") llc: error: 'spirit.stripped.o': input module cannot be verified With the latest Xcode 12.5 beta (or using the swift/release/5.4 branch), the llc error becomes "error: input module is broken!" Additionally after performing llvm::StripDebugInfo(), a subsequent call to llvm::verifyModule() will not report any errors and debug_compile_units() is empty. However writing the stripped bitcode to a file and then running llvm-dis on said file, the DICompileUnits are clearly visible in the Debug Metadata. I've attached a reproducible source file that can compiled with: clang++ spirit.cpp -c -g -emit-llvm -isysroot "" spirit.o opt spirit.o -strip-debug -o spirit.stripped.o lld spirit.stripped.o -o spirit.out Also I'm sorry the source file is rather large, but it's the only thing I've found to consistently reproduce the problem. -- 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 49523] New: Generalize constrained placeholder types for NTTPs
https://bugs.llvm.org/show_bug.cgi?id=49523 Bug ID: 49523 Summary: Generalize constrained placeholder types for NTTPs Product: clang Version: trunk Hardware: PC URL: https://godbolt.org/z/7TPTz5 OS: Linux Status: NEW Keywords: compile-fail Severity: enhancement Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: johel...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, johel...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk See https://godbolt.org/z/7TPTz5. ```C++ templateconcept C=true; templatebool v; ``` -- 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 49524] New: [llvm-mca][in-order processors] Missing RCU checks, and issues with how OoO instructions are tracked.
https://bugs.llvm.org/show_bug.cgi?id=49524 Bug ID: 49524 Summary: [llvm-mca][in-order processors] Missing RCU checks, and issues with how OoO instructions are tracked. Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-mca Assignee: unassignedb...@nondot.org Reporter: andrea.dibia...@gmail.com CC: andrea.dibia...@gmail.com, llvm-bugs@lists.llvm.org, matthew.da...@sony.com In-order processor like cortex-a55 allow out-of-order execution of a few FP/NEON instructions to avoid compulsory stalls due to their long latency. In particular, the scheduling model for cortex-a55 declares a reorder buffer with 64 entries. ``` def A55RCU : RetireControlUnit<64, 0>; ``` When issuing instructions, the new InOrderIssueStage doesn't perform any checks on the availability of the RCU. We should always check whether the RCU is available before attempting to issue a new instruction. If the RCU is unavailable, then we should stall the issue logic until RCU slots become available again. -- I might be wrong, but I think that there is another important issue with how the RCU is currently simulated for in-order processors. The way how it works now, is a bit counter-intuitive (at least in my opinion). Basically, the RCU only seem to track instructions that CANNOT execute out-of-order. We probably don't need to do that (unless we want to limit the number of instructions in-flight). I don't have a cortex-a55 to do some tests, but my opinion is that the RCU should probably _only_ track instructions that are executed OoO, to ensure that writes are always architecturally committed in program order. By construction, normal instructions that cannot execute OoO, are guaranteed to issue and retire in program order. I left a comment in https://bugs.llvm.org/show_bug.cgi?id=41796 explaining how I think there is a bug due to the lack of checks for structural hazards which would be normally required to prevent reaching the write-back stage out-of-order. -- 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 38320] Debugging in Visual Studio 2015 doesn't display locals if ghash is used
https://bugs.llvm.org/show_bug.cgi?id=38320 Reid Kleckner changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #11 from Reid Kleckner --- It sounds like we were never able to repro this, and I see that the related PCH issue was fixed. Maybe there was PCH usage in the original example. In any case, feel free to reopen with new information if this persists. In the meantime, we have made lots of ghash performance improvements. -- 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 49525] New: 'P' inline assembly operand modifier should obey -fno-plt
https://bugs.llvm.org/show_bug.cgi?id=49525
Bug ID: 49525
Summary: 'P' inline assembly operand modifier should obey
-fno-plt
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: thi...@kde.org
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
Unlike GCC, Clang seems not to print the "@PLT" suffix for the 'P' constraint
in PIC mode:
$ cat test.c
extern void f(void);
void g() { asm("call %P0 # asm" : : "X" (f)); }
int h() { f(); return 0; }
$ clang -fno-pic -S -o - -O2 test.c | grep call
callq f # asm
callq f
$ clang -fPIC -S -o - -O2 test.c | grep call
callq f # asm
callq f@PLT
$ gcc -fPIC -S -o - -O2 test.c | grep call
call f@PLT # asm
callf@PLT
That's not a big deal because the linker will generate the PLT anyway if the
function is defined in a shared library being linked.
But the call violates -fno-plt:
$ clang -fno-pic -S -o - -O2 test.c | grep call
callq f # asm
callq *f@GOTPCREL(%rip)
$ clang -fPIC -S -o - -O2 test.c | grep call
callq f # asm
callq *f@GOTPCREL(%rip)
$ gcc -fPIC -S -o - -O2 test.c | grep call
call f@PLT # asm
call*f@GOTPCREL(%rip)
Equivalent GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99530
--
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 49526] New: "operation not permitted" ferror on recursive_directory_iterator despite skip_permission_denied
https://bugs.llvm.org/show_bug.cgi?id=49526
Bug ID: 49526
Summary: "operation not permitted" ferror on
recursive_directory_iterator despite
skip_permission_denied
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@pobox.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
On POSIX filesystem backend type systems the
std::filesystem::recursive_directory_iterator throws a filesystem_error
exception with "operation not permitted" when the opendir/readdir call returns
EPERM instead of EACCES even if
std::filesystem::directory_options::skip_permission_denied is set.
Given the following code:
#include
#include
int main(int argc, char* argv[])
{
fs::path dir{"."};
if(argc == 2) {
dir = fs::u8path(argv[1]);
}
int totalDirs = 0;
int totalFiles = 0;
try {
for(const auto& de : fs::recursive_directory_iterator(dir,
fs::directory_options::skip_permission_denied)) {
if(de.is_regular_file()) {
++totalFiles;
}
else if(de.is_directory()) {
++totalDirs;
}
}
}
catch(fs::filesystem_error fe) {
std::cerr << "Error: " << fe.what() << std::endl;
exit(1);
}
std::cout << totalFiles << " files in " << totalDirs << " directories" <<
std::endl;
return 0;
}
This fails for example on macOS when called on the user home directory with:
Error: filesystem error: in recursive_directory_iterator::operator++():
attempting recursion into "/Users//Library/Application
Support/MobileSync": Operation not permitted
This is due to System Integrity Protection (since macOS 10.14) on that folder
leading to EPERM.
On Linux, called with / it stops when hitting for example a
"/proc/1/task/1/cwd", resulting in EPERM too.
I don't have examples from other POSIX systems, but I would say handling only
EACCES for the skip_permission_denied option is not enough.
--
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 37652] Can't use EXPENSIVE_CHECKS in TableGen executable
https://bugs.llvm.org/show_bug.cgi?id=37652 Alexander Richardson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Alexander Richardson --- Should be fixed by https://github.com/llvm/llvm-project/commit/35bf23e965508a6ca9ca45ba882d1ba7808c -- 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 49527] New: extraneous dynamic swizzle when all lanes are equal and constant
https://bugs.llvm.org/show_bug.cgi?id=49527 Bug ID: 49527 Summary: extraneous dynamic swizzle when all lanes are equal and constant Product: new-bugs Version: 11.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: danielwatson...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org When the vector being shuffled has equal elements/lanes, LLVM should skip the shuffle/swizzle. As far as I can tell this only affects dynamic swizzles like AVX2's VPERMD and does not affect constant shuffles like SHUFPS. VPERMD: https://godbolt.org/z/eeKWfx shufflevector: https://godbolt.org/z/9b6r7x -- 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 49419] [LLVM-COV] No coverage with "Segmentation fault (core dumped)"
https://bugs.llvm.org/show_bug.cgi?id=49419 Yang Wang changed: What|Removed |Added Resolution|--- |INVALID 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 49528] New: error: no member named 'Kind' in 'mlir::Value'
https://bugs.llvm.org/show_bug.cgi?id=49528
Bug ID: 49528
Summary: error: no member named 'Kind' in 'mlir::Value'
Product: new-bugs
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: nnel...@infowest.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Xubuntu 20.10.
>From the Ubuntu distribution
clang++ --version
Ubuntu clang version 11.0.0-2
git command executed close to 9pm Mar. 9, 2021, Mountain Standard Time.
git clone https://github.com/llvm/llvm-project.git
cd llvm-project
mkdir build
cd build
cmake -G Ninja
-DLLVM_ENABLE_PROJECTS="clang;llvm;clang-tools-extra;compiler-rt;debuginfo-tests;flang;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;parallel-libs;polly;pstl;utils"
-DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD=X86
-DLLVM_ENABLE_LIBPFM=OFF -DRUN_HAVE_GNU_POSIX_REGEX=0
-DLLVM_LIBC_ENABLE_LINTING=ON -Wno-dev ../llvm &> ~/Documents/cmake.log
ninja -j 31 &> ~/Documents/ninja.log
>From ninja.log
/home/nnelson/Documents/llvm-project/debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.cpp:13:33:
error: no member named 'Kind' in 'mlir::Value'
mlir::Value::Kind::TrailingOpResult});
~^
/home/nnelson/Documents/llvm-project/debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.cpp:27:23:
error: no matching function for call to 'get'
auto FileLineColLoc = mlir::FileLineColLoc::get("file", 7, 8, &Context);
^
tools/mlir/include/mlir/IR/BuiltinLocationAttributes.h.inc:50:27: note:
candidate function not viable: no known conversion from 'const char [5]' to
'::mlir::MLIRContext *' for 1st argument
static FileLineColLoc get(::mlir::MLIRContext *context, StringRef filename,
unsigned line, unsigned column);
^
tools/mlir/include/mlir/IR/BuiltinLocationAttributes.h.inc:49:27: note:
candidate function not viable: requires 3 arguments, but 4 were provided
static FileLineColLoc get(Identifier filename, unsigned line, unsigned
column);
^
2 errors 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 49529] New: FAIL: Builtins-i386-linux :: muldc3_test.c
https://bugs.llvm.org/show_bug.cgi?id=49529 Bug ID: 49529 Summary: FAIL: Builtins-i386-linux :: muldc3_test.c Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: nnel...@infowest.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org FAIL: Builtins-i386-linux :: muldc3_test.c (8877 of 89700) TEST 'Builtins-i386-linux :: muldc3_test.c' FAILED Script: -- : 'RUN: at line 1'; /home/nnelson/Documents/llvm-project/build/./bin/clang -gline-tables-only -m32 -fno-builtin -I /home/nnelson/Documents/llvm-project/compiler-rt/lib/builtins -nodefaultlibs /home/nnelson/Documents/llvm-project/compiler-rt/test/builtins/Unit/muldc3_test.c -ffp-contract=off /home/nnelson/Documents/llvm-project/build/./lib/clang/13.0.0/lib/linux/libclang_rt.builtins-i386.a -lc -lm -lm -o /home/nnelson/Documents/llvm-project/build/projects/compiler-rt/test/builtins/Unit/I386LinuxConfig/Output/muldc3_test.c.tmp && /home/nnelson/Documents/llvm-project/build/projects/compiler-rt/test/builtins/Unit/I386LinuxConfig/Output/muldc3_test.c.tmp -- Exit Code: 1 Obtained by the following processing. Xubuntu 20.10. >From the Ubuntu distribution clang++ --version Ubuntu clang version 11.0.0-2 git command executed close to 9pm Mar. 9, 2021, Mountain Standard Time. git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir build cd build cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;llvm;clang-tools-extra;compiler-rt;debuginfo-tests;flang;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;parallel-libs;polly;pstl;utils" -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_LIBPFM=OFF -DRUN_HAVE_GNU_POSIX_REGEX=0 -DLLVM_LIBC_ENABLE_LINTING=ON -Wno-dev ../llvm &> ~/Documents/cmake.log ninja -j 31 &> ~/Documents/ninja.log ninja -j 31 check-all &> ~/Documents/check-all.log >From check-all.log Failed Tests (11): Builtins-i386-linux :: muldc3_test.c HWAddressSanitizer-x86_64 :: TestCases/global.c SanitizerCommon-asan-i386-Linux :: Linux/crypt_r.cpp SanitizerCommon-asan-i386-Linux :: Posix/crypt.cpp SanitizerCommon-lsan-i386-Linux :: Linux/crypt_r.cpp SanitizerCommon-lsan-i386-Linux :: Posix/crypt.cpp SanitizerCommon-ubsan-i386-Linux :: Linux/crypt_r.cpp SanitizerCommon-ubsan-i386-Linux :: Posix/crypt.cpp libomptarget :: offloading/memory_manager.cpp libomptarget :: offloading/parallel_offloading_map.cpp lldb-api :: tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py Testing Time: 467.65s Unsupported : 23487 Passed : 66034 Expectedly Failed: 168 Failed :11 -- 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 49530] New: FAIL: HWAddressSanitizer-x86_64 :: TestCases/global.c
https://bugs.llvm.org/show_bug.cgi?id=49530 Bug ID: 49530 Summary: FAIL: HWAddressSanitizer-x86_64 :: TestCases/global.c Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: nnel...@infowest.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org FAIL: HWAddressSanitizer-x86_64 :: TestCases/global.c (39190 of 89700) TEST 'HWAddressSanitizer-x86_64 :: TestCases/global.c' FAILED Script: -- : 'RUN: at line 1'; /home/nnelson/Documents/llvm-project/build/./bin/clang -m64 -gline-tables-only -fsanitize=hwaddress -fuse-ld=lld -mcmodel=large -mllvm -hwasan-globals -mllvm -hwasan-use-short-granules -mllvm -hwasan-instrument-landing-pads=0 -mllvm -hwasan-instrument-personality-functions /home/nnelson/Documents/llvm-project/compiler-rt/test/hwasan/TestCases/global.c -o /home/nnelson/Documents/llvm-project/build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/global.c.tmp : 'RUN: at line 2'; /home/nnelson/Documents/llvm-project/build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/global.c.tmp 0 : 'RUN: at line 3'; not /home/nnelson/Documents/llvm-project/build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/global.c.tmp 1 2>&1 | FileCheck --check-prefixes=CHECK,RSYM /home/nnelson/Documents/llvm-project/compiler-rt/test/hwasan/TestCases/global.c : 'RUN: at line 4'; not env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:symbolize=0 /home/nnelson/Documents/llvm-project/build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/global.c.tmp 1 2>&1 | FileCheck --check-prefixes=CHECK,RNOSYM /home/nnelson/Documents/llvm-project/compiler-rt/test/hwasan/TestCases/global.c : 'RUN: at line 5'; not /home/nnelson/Documents/llvm-project/build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/global.c.tmp -1 2>&1 | FileCheck --check-prefixes=CHECK,LSYM /home/nnelson/Documents/llvm-project/compiler-rt/test/hwasan/TestCases/global.c : 'RUN: at line 6'; not env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:symbolize=0 /home/nnelson/Documents/llvm-project/build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/global.c.tmp -1 2>&1 | FileCheck --check-prefixes=CHECK,LNOSYM /home/nnelson/Documents/llvm-project/compiler-rt/test/hwasan/TestCases/global.c -- Exit Code: 2 Command Output (stderr): -- /home/nnelson/Documents/llvm-project/compiler-rt/test/hwasan/TestCases/global.c:16:8: warning: implicit declaration of function 'atoi' is invalid in C99 [-Wimplicit-function-declaration] (&x)[atoi(argv[1])] = 1; ^ 1 warning generated. FileCheck error: '' is empty. FileCheck command line: FileCheck --check-prefixes=CHECK,RSYM /home/nnelson/Documents/llvm-project/compiler-rt/test/hwasan/TestCases/global.c -- Obtained by the following processing. Xubuntu 20.10. >From the Ubuntu distribution clang++ --version Ubuntu clang version 11.0.0-2 git command executed close to 9pm Mar. 9, 2021, Mountain Standard Time. git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir build cd build cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;llvm;clang-tools-extra;compiler-rt;flang;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;parallel-libs;polly;pstl;utils" -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_LIBPFM=OFF -DRUN_HAVE_GNU_POSIX_REGEX=0 -DLLVM_LIBC_ENABLE_LINTING=ON -Wno-dev ../llvm &> ~/Documents/cmake.log ninja -j 31 &> ~/Documents/ninja.log ninja -j 31 check-all &> ~/Documents/check-all.log >From check-all.log Failed Tests (11): Builtins-i386-linux :: muldc3_test.c HWAddressSanitizer-x86_64 :: TestCases/global.c SanitizerCommon-asan-i386-Linux :: Linux/crypt_r.cpp SanitizerCommon-asan-i386-Linux :: Posix/crypt.cpp SanitizerCommon-lsan-i386-Linux :: Linux/crypt_r.cpp SanitizerCommon-lsan-i386-Linux :: Posix/crypt.cpp SanitizerCommon-ubsan-i386-Linux :: Linux/crypt_r.cpp SanitizerCommon-ubsan-i386-Linux :: Posix/crypt.cpp libomptarget :: offloading/memory_manager.cpp libomptarget :: offloading/parallel_offloading_map.cpp lldb-api :: tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py Testing Time: 467.65s Unsupported : 23487 Passed : 66034 Expectedly Failed: 168 Failed :11 -- 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 49531] New: FileCheck ignores `-Y` in `[[X-Y]]`
https://bugs.llvm.org/show_bug.cgi?id=49531 Bug ID: 49531 Summary: FileCheck ignores `-Y` in `[[X-Y]]` Product: Test Suite Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: jdenny.o...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org, thomas.preudho...@celest.fr For example: ``` $ cat check CHECK: [[X-Y]] $ FileCheck -vv -dump-input=always -DX=5 -DY=6 check < input |& tail -5 << 1: 5 check:1'0 ^ check:1'1with "X" equal to "5" >> ``` I would expect a directive parse error instead. -- 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 49532] New: FAIL: libomptarget :: offloading/memory_manager.cpp
https://bugs.llvm.org/show_bug.cgi?id=49532 Bug ID: 49532 Summary: FAIL: libomptarget :: offloading/memory_manager.cpp Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: nnel...@infowest.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org FAIL: libomptarget :: offloading/memory_manager.cpp (84751 of 89700) TEST 'libomptarget :: offloading/memory_manager.cpp' FAILED Script: -- : 'RUN: at line 1'; echo ignored-command : 'RUN: at line 2'; echo ignored-command : 'RUN: at line 3'; echo ignored-command : 'RUN: at line 4'; /home/nnelson/Documents/llvm-project/build/./bin/clang++ -fopenmp -pthread -fno-experimental-isel -I /home/nnelson/Documents/llvm-project/openmp/libomptarget/test -I /home/nnelson/Documents/llvm-project/build/projects/openmp/runtime/src -L /home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget -L /home/nnelson/Documents/llvm-project/build/lib -fopenmp-targets=x86_64-pc-linux-gnu /home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/memory_manager.cpp -o /home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget/test/offloading/Output/memory_manager.cpp.tmp-x86_64-pc-linux-gnu && /home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget/test/offloading/Output/memory_manager.cpp.tmp-x86_64-pc-linux-gnu | /home/nnelson/Documents/llvm-project/build/./bin/FileCheck /home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/memory_manager.cpp : 'RUN: at line 5'; echo ignored-command -- Exit Code: 2 Command Output (stdout): -- $ ":" "RUN: at line 1" note: command had no output on stdout or stderr $ "echo" "ignored-command" # command output: ignored-command $ ":" "RUN: at line 2" note: command had no output on stdout or stderr $ "echo" "ignored-command" # command output: ignored-command $ ":" "RUN: at line 3" note: command had no output on stdout or stderr $ "echo" "ignored-command" # command output: ignored-command $ ":" "RUN: at line 4" note: command had no output on stdout or stderr $ "/home/nnelson/Documents/llvm-project/build/./bin/clang++" "-fopenmp" "-pthread" "-fno-experimental-isel" "-I" "/home/nnelson/Documents/llvm-project/openmp/libomptarget/test" "-I" "/home/nnelson/Documents/llvm-project/build/projects/openmp/runtime/src" "-L" "/home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget" "-L" "/home/nnelson/Documents/llvm-project/build/lib" "-fopenmp-targets=x86_64-pc-linux-gnu" "/home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/memory_manager.cpp" "-o" "/home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget/test/offloading/Output/memory_manager.cpp.tmp-x86_64-pc-linux-gnu" note: command had no output on stdout or stderr $ "/home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget/test/offloading/Output/memory_manager.cpp.tmp-x86_64-pc-linux-gnu" # command stderr: memory_manager.cpp.tmp-x86_64-pc-linux-gnu: /home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/memory_manager.cpp:37: int main(int, char **): Assertion `buffer[j] == i' failed. error: command failed with exit status: -6 $ "/home/nnelson/Documents/llvm-project/build/./bin/FileCheck" "/home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/memory_manager.cpp" # command stderr: FileCheck error: '' is empty. FileCheck command line: /home/nnelson/Documents/llvm-project/build/./bin/FileCheck /home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/memory_manager.cpp error: command failed with exit status: 2 This bug obtained with the following processing. Xubuntu 20.10. >From the Ubuntu distribution clang++ --version Ubuntu clang version 11.0.0-2 git command executed close to 9pm Mar. 9, 2021, Mountain Standard Time. git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir build cd build cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;llvm;clang-tools-extra;compiler-rt;flang;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;parallel-libs;polly;pstl;utils" -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_LIBPFM=OFF -DRUN_HAVE_GNU_POSIX_REGEX=0 -DLLVM_LIBC_ENABLE_LINTING=ON -Wno-dev ../llvm &> ~/Documents/cmake.log ninja -j 31 &> ~/Documents/ninja.log ninja -j 31 check-all &> ~/Documents/check-all.log >From check-all.log Failed Tests (11): Builtins-i386-linux :: muldc3_test.c HWAddressSanitizer-x86_64 :: TestCases/global.c SanitizerCommon-asan-i386-Linux :: Linux/crypt_r.cpp SanitizerCommon-asan-i386-Linux :: Posix/crypt.cpp SanitizerCommon-lsan-i386-Linux :: Linux/crypt_r.cpp SanitizerCommon-lsan-i386-Linux :: Posix/crypt.cpp Sanitizer
[llvm-bugs] [Bug 49533] New: FAIL: libomptarget :: offloading/parallel_offloading_map.cpp
https://bugs.llvm.org/show_bug.cgi?id=49533 Bug ID: 49533 Summary: FAIL: libomptarget :: offloading/parallel_offloading_map.cpp Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: nnel...@infowest.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org FAIL: libomptarget :: offloading/parallel_offloading_map.cpp (84762 of 89700) TEST 'libomptarget :: offloading/parallel_offloading_map.cpp' FAILED Script: -- : 'RUN: at line 1'; echo ignored-command : 'RUN: at line 2'; echo ignored-command : 'RUN: at line 3'; echo ignored-command : 'RUN: at line 4'; /home/nnelson/Documents/llvm-project/build/./bin/clang++ -fopenmp -pthread -fno-experimental-isel -I /home/nnelson/Documents/llvm-project/openmp/libomptarget/test -I /home/nnelson/Documents/llvm-project/build/projects/openmp/runtime/src -L /home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget -L /home/nnelson/Documents/llvm-project/build/lib -fopenmp-targets=x86_64-pc-linux-gnu /home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/parallel_offloading_map.cpp -o /home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget/test/offloading/Output/parallel_offloading_map.cpp.tmp-x86_64-pc-linux-gnu && /home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget/test/offloading/Output/parallel_offloading_map.cpp.tmp-x86_64-pc-linux-gnu | /home/nnelson/Documents/llvm-project/build/./bin/FileCheck /home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/parallel_offloading_map.cpp : 'RUN: at line 5'; echo ignored-command -- Exit Code: 2 Command Output (stdout): -- $ ":" "RUN: at line 1" note: command had no output on stdout or stderr $ "echo" "ignored-command" # command output: ignored-command $ ":" "RUN: at line 2" note: command had no output on stdout or stderr $ "echo" "ignored-command" # command output: ignored-command $ ":" "RUN: at line 3" note: command had no output on stdout or stderr $ "echo" "ignored-command" # command output: ignored-command $ ":" "RUN: at line 4" note: command had no output on stdout or stderr $ "/home/nnelson/Documents/llvm-project/build/./bin/clang++" "-fopenmp" "-pthread" "-fno-experimental-isel" "-I" "/home/nnelson/Documents/llvm-project/openmp/libomptarget/test" "-I" "/home/nnelson/Documents/llvm-project/build/projects/openmp/runtime/src" "-L" "/home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget" "-L" "/home/nnelson/Documents/llvm-project/build/lib" "-fopenmp-targets=x86_64-pc-linux-gnu" "/home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/parallel_offloading_map.cpp" "-o" "/home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget/test/offloading/Output/parallel_offloading_map.cpp.tmp-x86_64-pc-linux-gnu" note: command had no output on stdout or stderr $ "/home/nnelson/Documents/llvm-project/build/projects/openmp/libomptarget/test/offloading/Output/parallel_offloading_map.cpp.tmp-x86_64-pc-linux-gnu" # command stderr: parallel_offloading_map.cpp.tmp-x86_64-pc-linux-gnu: /home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/parallel_offloading_map.cpp:35: int main(int, char **): Assertion `array[i] == ref' failed. error: command failed with exit status: -6 $ "/home/nnelson/Documents/llvm-project/build/./bin/FileCheck" "/home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/parallel_offloading_map.cpp" # command stderr: FileCheck error: '' is empty. FileCheck command line: /home/nnelson/Documents/llvm-project/build/./bin/FileCheck /home/nnelson/Documents/llvm-project/openmp/libomptarget/test/offloading/parallel_offloading_map.cpp error: command failed with exit status: 2 This bug obtained with the following sequence. Xubuntu 20.10. >From the Ubuntu distribution clang++ --version Ubuntu clang version 11.0.0-2 git command executed close to 9pm Mar. 9, 2021, Mountain Standard Time. git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir build cd build cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;llvm;clang-tools-extra;compiler-rt;flang;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;parallel-libs;polly;pstl;utils" -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_LIBPFM=OFF -DRUN_HAVE_GNU_POSIX_REGEX=0 -DLLVM_LIBC_ENABLE_LINTING=ON -Wno-dev ../llvm &> ~/Documents/cmake.log ninja -j 31 &> ~/Documents/ninja.log ninja -j 31 check-all &> ~/Documents/check-all.log >From check-all.log Failed Tests (11): Builtins-i386-linux :: muldc3_test.c HWAddressSanitizer-x86_64 :: TestCases/global.c SanitizerCommon-asan-i386-Linux :: Linux/crypt_r.cpp SanitizerCommon-asan
[llvm-bugs] [Bug 45369] Missing symbols when llvm is build with LTO
https://bugs.llvm.org/show_bug.cgi?id=45369 Yuanfang Chen changed: What|Removed |Added CC||yuanfang.c...@sony.com Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Yuanfang Chen --- You need to build LLVM with `LLVM_ENABLE_RTTI` if that's what you want; otherwise, you should use `-fno-rtti` for mesa. Feel free to reopen if this does not solve your issue. -- 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 48139] [VPlan] Unreachable instruction executed during VPlan execution
https://bugs.llvm.org/show_bug.cgi?id=48139 Mauri Mustonen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Mauri Mustonen --- Fixed by this: https://reviews.llvm.org/rG0de8aeae7249d314f25b5188c91b04b9a24003ad and this: https://reviews.llvm.org/rG494b5ba364a9c02da1b7b67fe5528d9f66a285e6 -- 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
