[llvm-bugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 30268, which changed state. Bug 30268 Summary: lld treats "operator delete[]" as a wildcard https://llvm.org/bugs/show_bug.cgi?id=30268 What|Removed |Added Status|ASSIGNED|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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30268] lld treats "operator delete[]" as a wildcard
https://llvm.org/bugs/show_bug.cgi?id=30268 George Rimar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from George Rimar --- r281038 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30336] New: Front end crash while compiling file
https://llvm.org/bugs/show_bug.cgi?id=30336 Bug ID: 30336 Summary: Front end crash while compiling file Product: clang Version: 3.8 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangb...@nondot.org Reporter: alexander.ro...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified I was compiling a C++ file when I got the following output: ``` clang++-3.8 -DPACKAGE_NAME=\"MesosModules\" -DPACKAGE_TARNAME=\"mesosmodules\" -DPACKAGE_VERSION=\"0.1\" "-DPACKAGE_STRING=\"MesosModules 0.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesosmodules\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_OPENSSL_SSL_H=1 -DHAVE_LIBSSL=1 -DHAVE_LIBCRYPTO=1 -DHAVE_BOOST_LEXICAL_CAST_HPP=1 -DHAVE_BOOST_FUNCTIONAL_HASH_HPP=1 -I. -I.. -I/Users/alexander/Documents/workspace/pmesos/include -I/Users/alexander/Documents/workspace/pmesos/src -I/Users/alexander/Documents/workspace/pmesos/3rdparty/libprocess/include -I/Users/alexander/Documents/workspace/pmesos/3rdparty/stout/include -I/Users/alexander/Documents/workspace/pmesos/build/include -I/Users/alexander/Documents/workspace/pmesos/build/src -I/usr/local/opt/openssl/include -DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -I../include -I.. -DUSE_SSL_SOCKET=1 -Wall -Werror -I./dcos_auth -g -O0 -I/Users/alexander/Documents/workspace/pmesos/build/3rdparty/picojson-1.3.0/ -std=c++11 -MT dcos_auth/libdcos_security_la-dcos_http_auth_mod.lo -MD -MP -MF dcos_auth/.deps/libdcos_security_la-dcos_http_auth_mod.Tpo -c ../dcos_auth/dcos_http_auth_mod.cpp -fno-common -DPIC -o dcos_auth/.libs/libdcos_security_la-dcos_http_auth_mod.o ../dcos_auth/authorizer.cpp:833:23: error: use of undeclared identifier 'Retrier' Retrier retrier(downloadToken, Seconds(5), 5); ^ ../dcos_auth/authorizer.cpp:833:31: error: unexpected type name 'string': expected expression Retrier retrier(downloadToken, Seconds(5), 5); ^ ../dcos_auth/authorizer.cpp:833:39: error: use of undeclared identifier 'retrier' Retrier retrier(downloadToken, Seconds(5), 5); ^ ../dcos_auth/authorizer.cpp:834:30: error: use of undeclared identifier 'retrier' return retrier.execute(); ^ Invalid operator call kind UNREACHABLE executed at /private/tmp/llvm3820160429-71251-1dezcnt/llvm-3.8.0.src/tools/clang/lib/AST/StmtProfile.cpp:898! 0 libLLVM-3.8.dylib0x00010dd58ccb llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 43 1 libLLVM-3.8.dylib0x00010dd58625 llvm::sys::RunSignalHandlers() + 44 2 libLLVM-3.8.dylib0x00010dd591c1 SignalHandler(int) + 165 3 libsystem_platform.dylib 0x7fff981fe52a _sigtramp + 26 4 libLLVM-3.8.dylib0x00010e58ccd7 (anonymous namespace)::StripDeadDebugInfo::ID + 125932 5 libLLVM-3.8.dylib0x00010dd59084 abort + 22 6 libLLVM-3.8.dylib0x00010dd44e75 LLVMInstallFatalErrorHandler + 0 7 clang0x00010cfd5cd1 clang::LazyGenerationalUpdatePtr::makeValue(clang::ASTContext const&, clang::Decl*) + 1209267 8 clang0x00010cfd46ee clang::LazyGenerationalUpdatePtr::makeValue(clang::ASTContext const&, clang::Decl*) + 1203664 9 clang0x00010ce90876 clang::CodeGen::CGBuilderInserter::InsertHelper(llvm::Instruction*, llvm::Twine const&, llvm::BasicBlock*, llvm::ilist_iterator) const + 7944166 10 clang0x00010cb099da clang::CodeGen::CGBuilderInserter::InsertHelper(llvm::Instruction*, llvm::Twine const&, llvm::BasicBlock*, llvm::ilist_iterator) const + 4245834 11 clang0x00010cb0c264 clang::CodeGen::CGBuilderInserter::InsertHelper(llvm::Instruction*, llvm::Twine const&, llvm::BasicBlock*, llvm::ilist_iterator) const + 4256212 12 clang0x00010cb37a0c clang::CodeGen::CGBuilderInserter::InsertHelper(llvm::Instruction*, llvm::Twine const&, llvm::BasicBlock*, llvm::ilist_iterator) const + 4434300 13 clang0x00010cb36a6c clang::CodeGen::CGBuilderInserter::InsertHelper(llvm::Instruction*, llvm::Twine const&, llvm::BasicBlock*, llvm::ilist_iterator) const + 4430300 14 clang0x00010cb3831c clang::CodeGen::CGBuilderInserter::InsertHelper(llvm::Instruction*, llvm::Twine const&, llvm::BasicBlock*, llvm::ilist_iterator) const + 4436620 15 clang0x00010caddeff clang::CodeGen::CGBuilderInserter::InsertHelper(llvm::In
[llvm-bugs] [Bug 30219] [OpenCL 2.0] Wrong implicit cast from pipe built-in functions.
https://llvm.org/bugs/show_bug.cgi?id=30219 bader changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from bader --- Fixed by https://reviews.llvm.org/rL280800. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30337] New: Don't emit Win64 pdata/xdata for "leaf" functions
https://llvm.org/bugs/show_bug.cgi?id=30337 Bug ID: 30337 Summary: Don't emit Win64 pdata/xdata for "leaf" functions Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org Blocks: 26299 Classification: Unclassified >From https://msdn.microsoft.com/en-us/library/ms235286.aspx: "Leaf functions are functions that do not change any non-volatile registers. .. Leaf functions can be unwound simply by simulating a return, so pdata and xdata are not required." Not emitting these would be good for binary size. Note that such functions can still tail-call others, so they're not really leafs in the call-graph sense. If we hook up a way to determine whether a function is a leaf in this sense, we can also use it to do conditional tail-calls for Win64. Such calls would generally confuse the unwinder, but in leaf functions they are fine. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30338] New: functionDecl->getLocation of specializations incorrectly points at template definition
https://llvm.org/bugs/show_bug.cgi?id=30338
Bug ID: 30338
Summary: functionDecl->getLocation of specializations
incorrectly points at template definition
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: luka...@chromium.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This is almost, but not quite similar to
https://llvm.org/bugs/show_bug.cgi?id=29145
Expected behavior:
1. The FunctionDecl corresponding to
template void foo(const int& i);
should have getLocation point at line 5.
2. Iterating/matching over all FunctionDecls and generating replacements
for f>getLocation() should cover all occurrences of the function name.
Actual behavior:
1. There are 2 FunctionDecls.
Dump of one of them corresponds to line 3 of the input.
Dump of second of them corresponds to line 5 of the input, but
getLocation incorrectly says "input.cc:3"
2. Generating replacements based on FunctionDecl::getLocation() would
result in:
template
void RenamedFoo(const T& t) {} // <- rename happens correctly here.
// No rename below, because of wrong source locations in the AST:
template void foo(const int& i);
3. Output of the repro program below:
-
parm->getName() : t
parm->getLocation() : 'input.cc:3:25'
func->getLocation() : 'input.cc:3:12'
func->dump():
FunctionDecl 0x3a20ca0 col:12 foo 'void (const T
&)'
|-ParmVarDecl 0x3a20b98 col:25 t 'const T &'
`-CompoundStmt 0x3a20de0
-
parm->getName() : t
parm->getLocation() : 'input.cc:3:25'
func->getLocation() : 'input.cc:3:12'
func->dump():
FunctionDecl 0x3a21190 col:12 foo 'void (const
int &)'
|-TemplateArgument type 'int'
|-ParmVarDecl 0x3a21108 col:25 t 'const int &'
`-CompoundStmt 0x3a20de0
Repro:
#include
#include "clang/AST/ASTContext.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"
#include "clang/ASTMatchers/ASTMatchers.h"
#include "clang/ASTMatchers/ASTMatchersMacros.h"
#include "clang/Basic/CharInfo.h"
#include "clang/Frontend/FrontendActions.h"
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Refactoring.h"
#include "clang/Tooling/Tooling.h"
#include "llvm/Support/CommandLine.h"
#include "llvm/Support/TargetSelect.h"
using namespace clang::ast_matchers;
class ReproMatchCallback : public MatchFinder::MatchCallback {
public:
void run(const MatchFinder::MatchResult& result) override {
const clang::FunctionDecl* func =
result.Nodes.getNodeAs("func");
const clang::ParmVarDecl* parm =
result.Nodes.getNodeAs("parm");
if (!func || !parm)
return;
llvm::outs() << "-\n";
llvm::outs() << "parm->getName() : " << parm->getNameAsString() <<
"\n";
llvm::outs() << "parm->getLocation() : '"
<< parm->getLocation().printToString(
result.Context->getSourceManager())
<< "'\n";
llvm::outs() << "func->getLocation() : '"
<< func->getLocation().printToString(
result.Context->getSourceManager())
<< "'\n";
llvm::outs() << "func->dump():\n";
func->dump();
}
};
int main(int argc, const char* argv[]) {
llvm::InitializeNativeTarget();
llvm::InitializeNativeTargetAsmParser();
llvm::cl::OptionCategory category("Repro.");
clang::tooling::CommonOptionsParser options(argc, argv, category);
clang::tooling::ClangTool tool(options.getCompilations(),
options.getSourcePathList());
const char* code = R"code( // line 1
template // line 2
void foo(const T& t) {}// line 3
// line 4
template void foo(const int& i); // line 5
)code";
auto matcher =
id("func", functionDecl(hasAnyParameter(id("parm", parmVarDecl();
MatchFinder match_finder;
ReproMatchCallback match_callback;
match_finder.addMatcher(matcher, &match_callback);
std::unique_ptr factory =
clang::tooling::newFrontendActionFactory(&match_finder);
clang::tooling::runToolOnCode(factory->create(), code);
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30339] New: Regression: unnecessary mov in a tight loop
https://llvm.org/bugs/show_bug.cgi?id=30339 Bug ID: 30339 Summary: Regression: unnecessary mov in a tight loop Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kra...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17231 --> https://llvm.org/bugs/attachment.cgi?id=17231&action=edit loop.cc Recently, Chrome observed a significant (~15%) regression after rolling the new version of Clang (r280106, trunk at the time), see https://crbug.com/643724. A minimal repro has been extracted (attached). To reproduce the issue: clang++ -o loop loop.cc -fuse-ld=gold -O2 -flto Note that using LTO seems to be the trigger for the bug (but not necessarily the reason). Before regression, r278861: 004006e0 <_Z31absoluteColumnToEffectiveColumnj>: 4006e0: 48 8b 15 61 19 00 00mov0x1961(%rip),%rdx# 402048 4006e7: 4c 8b 05 52 19 00 00mov0x1952(%rip),%r8# 402040 4006ee: 4c 29 c2sub%r8,%rdx 4006f1: 48 c1 ea 02 shr$0x2,%rdx 4006f5: 31 c0 xor%eax,%eax 4006f7: 85 d2 test %edx,%edx 4006f9: 74 2e je 400729 <_Z31absoluteColumnToEffectiveColumnj+0x49> 4006fb: 89 d2 mov%edx,%edx 4006fd: 31 c0 xor%eax,%eax 4006ff: 31 f6 xor%esi,%esi 400701: 66 66 66 66 66 66 2edata32 data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 400708: 0f 1f 84 00 00 00 00 40070f: 00 400710: 41 8b 3c 80 mov(%r8,%rax,4),%edi # <=== Everything is good here 400714: 8d 4c 37 ff lea-0x1(%rdi,%rsi,1),%ecx 400718: 83 f9 0acmp$0xa,%ecx 40071b: 73 0c jae400729 <_Z31absoluteColumnToEffectiveColumnj+0x49> 40071d: 01 f7 add%esi,%edi 40071f: 48 ff c0inc%rax 400722: 48 39 d0cmp%rdx,%rax 400725: 89 fe mov%edi,%esi 400727: 72 e7 jb 400710 <_Z31absoluteColumnToEffectiveColumnj+0x30> 400729: c3 retq 40072a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) After regression, r280106: 004006e0 <_Z31absoluteColumnToEffectiveColumnj>: 4006e0: 48 8b 0d 61 19 00 00mov0x1961(%rip),%rcx# 402048 4006e7: 4c 8b 05 52 19 00 00mov0x1952(%rip),%r8# 402040 4006ee: 4c 29 c1sub%r8,%rcx 4006f1: 48 c1 e9 02 shr$0x2,%rcx 4006f5: 31 c0 xor%eax,%eax 4006f7: 85 c9 test %ecx,%ecx 4006f9: 74 1e je 400719 <_Z31absoluteColumnToEffectiveColumnj+0x39> 4006fb: 31 f6 xor%esi,%esi 4006fd: 31 c0 xor%eax,%eax 4006ff: 90 nop 400700: 89 c7 mov%eax,%edi # <== unnecessary mov 400702: 41 8b 3c b8 mov(%r8,%rdi,4),%edi 400706: 8d 54 37 ff lea-0x1(%rdi,%rsi,1),%edx 40070a: 83 fa 0acmp$0xa,%edx 40070d: 73 0a jae400719 <_Z31absoluteColumnToEffectiveColumnj+0x39> 40070f: 01 f7 add%esi,%edi 400711: ff c0 inc%eax 400713: 39 c8 cmp%ecx,%eax 400715: 89 fe mov%edi,%esi 400717: 72 e7 jb 400700 <_Z31absoluteColumnToEffectiveColumnj+0x20> 400719: c3 retq 40071a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) As you can see, there's an unnecessary mov in the newer code. I have also verified that the issue persists in the current trunk (r280929): 004006c0 <_Z31absoluteColumnToEffectiveColumnj>: 4006c0: 48 8b 0d 81 19 00 00mov0x1981(%rip),%rcx# 402048 4006c7: 4c 8b 05 72 19 00 00mov0x1972(%rip),%r8# 402040 4006ce: 4c 29 c1sub%r8,%rcx 4006d1: 48 c1 e9 02 shr$0x2,%rcx 4006d5: 31 c0 xor%eax,%eax 4006d7: 85 c9 test %ecx,%ecx 4006d9: 74 1e je 4006f9 <_Z31absoluteColumnToEffectiveColumnj+0x39> 4006db: 31 f6 xor%esi,%esi 4006dd: 31 c0 xor
[llvm-bugs] [Bug 24345] [Meta] ChromeOs+Clang platform support
https://llvm.org/bugs/show_bug.cgi?id=24345 Bug 24345 depends on bug 25416, which changed state. Bug 25416 Summary: clang hangs when compile a large c file. https://llvm.org/bugs/show_bug.cgi?id=25416 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25416] clang hangs when compile a large c file.
https://llvm.org/bugs/show_bug.cgi?id=25416 Nick Lewycky changed: What|Removed |Added Status|NEW |RESOLVED CC||nlewy...@google.com Resolution|--- |FIXED --- Comment #6 from Nick Lewycky --- This was fixed by the reporter back in r255198. Thanks for the patch! -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 22601] defaulted class template parameters dropped when rededucing template template parameter
https://llvm.org/bugs/show_bug.cgi?id=22601 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Smith --- *** This bug has been marked as a duplicate of bug 10147 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30340] New: Poor diagnostics when an explicitly defaulted move assignment operator can't be generated
https://llvm.org/bugs/show_bug.cgi?id=30340
Bug ID: 30340
Summary: Poor diagnostics when an explicitly defaulted move
assignment operator can't be generated
Product: clang
Version: 3.9
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: john.fireba...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Test case:
#include
struct Immovable {
Immovable& operator=(Immovable&&) = delete;
};
struct Foo {
Foo();
Foo& operator=(Foo&&) = default;
Immovable immovable;
};
int main() {
Foo foo1;
Foo foo2;
foo1 = std::move(foo2);
}
Clang output (https://godbolt.org/g/yyhU39):
16 : error: object of type 'Foo' cannot be assigned because its copy assignment
operator is implicitly deleted
foo1 = std::move(foo2);
^
9 : note: copy assignment operator is implicitly deleted because 'Foo' has a
user-declared move assignment operator
Foo& operator=(Foo&&) = default;
This error message gives no hint as to the actual issue, the fact that the
explicitly defaulted move assignment operator for Foo could not be generated.
Compare GCC's output (https://godbolt.org/g/IVx9xU):
16 : error: use of deleted function 'Foo& Foo::operator=(Foo&&)'
foo1 = std::move(foo2);
^
9 : note: 'Foo& Foo::operator=(Foo&&)' is implicitly deleted because the
default definition would be ill-formed:
Foo& operator=(Foo&&) = default;
^~~~
9 : error: use of deleted function 'Immovable&
Immovable::operator=(Immovable&&)'
4 : note: declared here
Immovable& operator=(Immovable&&) = delete;
^~~~
Compilation failed
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30341] New: Alias must point to a definition
https://llvm.org/bugs/show_bug.cgi?id=30341 Bug ID: 30341 Summary: Alias must point to a definition Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: aizat...@chromium.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17232 --> https://llvm.org/bugs/attachment.cgi?id=17232&action=edit Reproducer script This happens on the sanitizer-x86_64-linux-bootstrap bot. Reproducer attached. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/12886 [255/2434] Building CXX object tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/NeonEmitter.cpp.o FAILED: tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/NeonEmitter.cpp.o /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin/clang++ -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_OBJC_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/utils/TableGen -I/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/utils/TableGen -I/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/include -Itools/clang/include -Iinclude -I/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/include -nostdinc++ -isystem /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/libcxx_build_msan/include -isystem /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/libcxx_build_msan/include/c++/v1 -lc++abi -Wl,--rpath=/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/libcxx_build_msan/lib -L/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/libcxx_build_msan/lib -fsanitize=memory -w -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -fno-omit-frame-pointer -gline-tables-only -fsanitize=memory -fcolor-diagnostics -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types -O3 -UNDEBUG -fno-exceptions -fno-rtti -MMD -MT tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/NeonEmitter.cpp.o -MF tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/NeonEmitter.cpp.o.d -o tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/NeonEmitter.cpp.o -c /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/utils/TableGen/NeonEmitter.cpp Alias must point to a definition void (%"class.(anonymous namespace)::TypeSpec"*)* @_ZN12_GLOBAL__N_18TypeSpecD2Ev fatal error: error in backend: Broken module found, compilation aborted! clang-3.9: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 4.0.0 (trunk 280954) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build0/bin clang-3.9: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.9: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.9: note: diagnostic msg: /tmp/NeonEmitter-5211df.cpp clang-3.9: note: diagnostic msg: /tmp/NeonEmitter-5211df.sh clang-3.9: note: diagnostic msg: -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30342] New: [ppc] LLVM generates an extra loop
https://llvm.org/bugs/show_bug.cgi?id=30342
Bug ID: 30342
Summary: [ppc] LLVM generates an extra loop
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: car...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Compile the following code with options
--target=powerpc64le-grtev4-linux-gnu -m64 -O2 -mvsx -mcpu=power8
typedef unsigned short T;
int foo(T* array_a, T* array_b, int size_a, int size_b, T* buf) {
int i_a = 0, i_b = 0, idx = 0;
while (i_a < size_a && i_b < size_b) {
if (array_a[i_a] == array_b[i_b]) {
buf[idx++] = array_a[i_a];
i_a++;
i_b++;
} else if (array_a[i_a] > array_b[i_b]) {
i_b++;
} else {
i_a++;
}
}
return idx;
}
Trunk llvm generates:
9 # BB#0: # %entry
10 li 12, 0
11 cmpwi5, 0
12 std 28, -32(1) # 8-byte Folded Spill
13 std 29, -24(1) # 8-byte Folded Spill
14 std 30, -16(1) # 8-byte Folded Spill
15 cmpwi 1, 6, 0
16 crand 20, 1, 5
17 bc 4, 20, .LBB0_10
18 # BB#1: # %while.body.lr.ph.lr.ph.preheader
19 extsw 8, 6
20 extsw 9, 5
21 addi 4, 4, -2
22 li 11, 0
23 li 10, 0
24 li 30, 0
25 .LBB0_2:# %while.body.lr.ph.lr.ph
26 # =>This Loop Header: Depth=1
27 # Child Loop BB0_3 Depth 2
28 # Child Loop BB0_4 Depth 3
29 extsw 12, 30
30 .LBB0_3:# %while.body.lr.ph
31 # Parent Loop BB0_2 Depth=1
32 # => This Loop Header: Depth=2
33 # Child Loop BB0_4 Depth 3
34 extsw 11, 11
35 sldi 0, 12, 1
36 addi 30, 11, 1
37 lhzx 0, 3, 0
38 sldi 29, 11, 1
39 cmpd 30, 8
40 isel 30, 30, 8, 1
41 sub 28, 30, 11
42 add 30, 4, 29
43 mtctr 28
44 .p2align5
45 .LBB0_4:# %while.body
46 # Parent Loop BB0_2 Depth=1
47 # Parent Loop BB0_3 Depth=2
48 # =>This Inner Loop Header:
Depth=3
49 lhzu 29, 2(30)
50 cmplw0, 29
51 beq 0, .LBB0_8
52 # BB#5: # %if.else
53 # in Loop: Header=BB0_4 Depth=3
54 ble 0, .LBB0_7
55 # BB#6: # %if.then21
56 # in Loop: Header=BB0_4 Depth=3
57 addi 11, 11, 1
58 bdnz .LBB0_4
59 b .LBB0_9
60 .p2align4
61 .LBB0_7:# %if.else23
62 # in Loop: Header=BB0_3 Depth=2
63 addi 12, 12, 1
64 cmpw 1, 11, 6
65 cmpd 12, 9
66 crand 20, 0, 4
67 bc 12, 20, .LBB0_3
68 b .LBB0_9
69 .p2align4
70 .LBB0_8:# %if.then
71 # in Loop: Header=BB0_2 Depth=1
72 addi 30, 12, 1
73 addi 11, 11, 1
74 addi 12, 10, 1
75 sldi 10, 10, 1
76 sthx 0, 7, 10
77 mr 10, 12
78 cmpw 30, 5
79 cmpw 1, 11, 6
80 crand 20, 0, 4
81 bc 12, 20, .LBB0_2
82 b .LBB0_10
83 .LBB0_9:
84 mr 12, 10
85 .LBB0_10: # %while.end
86 extsw 3, 12
87 ld 30, -16(1) # 8-byte Folded Reload
88 ld 29, -24(1) # 8-byte Folded Reload
89 ld 28, -32(1) # 8-byte Folded Reload
90 blr
Although there is only loop in the source code, llvm generates an extra loop
start from .LBB0_4. And the loop preparation work in .LBB0_3 is very slow
because of isel and mtctr.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30247] Clang prohibits friendship based on typedefs
https://llvm.org/bugs/show_bug.cgi?id=30247 mattreecebent...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from mattreecebent...@gmail.com --- Well, that's okay, if you don't want to acknowledge where you're wrong that's fine. Bye. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30343] New: clang crashes on C++ code with incorrect copy constructor
https://llvm.org/bugs/show_bug.cgi?id=30343 Bug ID: 30343 Summary: clang crashes on C++ code with incorrect copy constructor Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified It seems to affect at least all versions 2.9 and later. $ clang++ -v clang version 4.0.0 (trunk 280978) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/clang-trunk/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.1.1 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ $ clang++ -c small.cpp #0 0x01e787e5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-4.0+0x1e787e5) #1 0x01e768ce llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-4.0+0x1e768ce) #2 0x01e76a30 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-4.0+0x1e76a30) #3 0x7f68e60fa340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x0308f7f3 clang::Sema::RequireCompleteTypeImpl(clang::SourceLocation, clang::QualType, clang::Sema::TypeDiagnoser*) (/usr/local/clang-trunk/bin/clang-4.0+0x308f7f3) #5 0x02e87a33 TryConstructorInitialization(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType, clang::InitializationSequence&, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x2e87a33) #6 0x02e89382 clang::InitializationSequence::InitializeFrom(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x2e89382) #7 0x02e92f50 clang::Sema::PerformCopyInitialization(clang::InitializedEntity const&, clang::SourceLocation, clang::ActionResult, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x2e92f50) #8 0x02de7c3e clang::Sema::GatherArgumentsForCall(clang::SourceLocation, clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int, llvm::ArrayRef, llvm::SmallVectorImpl&, clang::Sema::VariadicCallType, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x2de7c3e) ... #34 0x02e92f72 clang::Sema::PerformCopyInitialization(clang::InitializedEntity const&, clang::SourceLocation, clang::ActionResult, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x2e92f72) #35 0x02de7c3e clang::Sema::GatherArgumentsForCall(clang::SourceLocation, clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int, llvm::ArrayRef, llvm::SmallVectorImpl&, clang::Sema::VariadicCallType, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x2de7c3e) #36 0x02d2b77f clang::Sema::CompleteConstructorCall(clang::CXXConstructorDecl*, llvm::MutableArrayRef, clang::SourceLocation, llvm::SmallVectorImpl&, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x2d2b77f) #37 0x02e905ea clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/usr/local/clang-trunk/bin/clangsica [131] % tail out clang-4.0: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-4.0: note: diagnostic msg: /tmp/small-445b51.cpp clang-4.0: note: diagnostic msg: /tmp/small-445b51.sh clang-4.0: note: diagnostic msg:
[llvm-bugs] [Bug 30326] Firefox -flto=thin build failure
https://llvm.org/bugs/show_bug.cgi?id=30326 Teresa Johnson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Teresa Johnson --- Should be fixed by r281134 (and test case added with r281135). -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
