[llvm-bugs] [Bug 33087] New: declare target fails to emit diagnostic when identifier redeclared
https://bugs.llvm.org/show_bug.cgi?id=33087 Bug ID: 33087 Summary: declare target fails to emit diagnostic when identifier redeclared Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: andrey@gmail.com CC: llvm-bugs@lists.llvm.org The test case shown below should emit the diagnostic "error: 'rc' must not appear in both clauses 'to' and 'link'", but it fails to do so when 'rc' is declared multiple times. Test case: int rc; #pragma omp declare target link(rc) #ifndef OK int rc; #endif #pragma omp declare target to(rc) This has been reproduced in Clang 4.0 for both PowerPC and amd64. The diagnostician is failing to check against all declarations of an identifier in its handling of declare target. -- 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 33089] New: Static value in depended class is treated as non-constant expression.
https://bugs.llvm.org/show_bug.cgi?id=33089
Bug ID: 33089
Summary: Static value in depended class is treated as
non-constant expression.
Product: clang
Version: 3.9
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: tomasz...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
For following code:
#include
template
decltype(U{T::value}) foo(T, int) { return T::value; }
template
U foo(T, ...) = delete;
int main()
{
foo(std::integral_constant{}, 0);
}
Candidate foo(T, int) is ignored with following error:
substitution failure [with U = short, T = std::__1::integral_constant]: non-constant-expression cannot be narrowed from type 'int' to 'short' in
initializer list decltype(U{T::value}) foo(T, int) { return T::value; }
As suggested the T::value is not constexpr expression, despite declared as
constexpr.
If the declaration is changed to us an compile time conversion operator, the
expression is properly regonized as compile time constant, and brace
initialization is well-formed.
template
decltype(U{T{}}) foo(T, int) { return T::value; }
--
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 33088] New: libomp crash in __tls_get_addr when clang is bootstrapped with LTO
https://bugs.llvm.org/show_bug.cgi?id=33088
Bug ID: 33088
Summary: libomp crash in __tls_get_addr when clang is
bootstrapped with LTO
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: ism...@i10z.com
CC: llvm-bugs@lists.llvm.org
I bootstrapped clang with (fat-)lto and the following simple openmp code now
crashes at exit:
havana ~ > cat omp_hello.c
#include
#include
#include
int main (int argc, char *argv[])
{
int nthreads, tid;
/* Fork a team of threads giving them their own copies of variables */
#pragma omp parallel private(nthreads, tid)
{
/* Obtain thread number */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
} /* All threads join master thread and disband */
}
havana ~ > clang-5 -v
openSUSE Linux clang version 5.0.0 (trunk 303241) (based on LLVM 5.0.0svn)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /suse/idoenmez/bin
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/6
Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/6
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
havana ~ > clang-5 -g3 -fsanitize=address -fopenmp omp_hello.c -flto
-Wl,-rpath,/opt/clang/lib64
havana ~ > ./a.out
Hello World from thread = 0
Hello World from thread = 3
Hello World from thread = 7
Hello World from thread = 4
Hello World from thread = 6
Hello World from thread = 5
Hello World from thread = 1
Hello World from thread = 2
Number of threads = 8
ASAN:DEADLYSIGNAL
=
==2830==ERROR: AddressSanitizer: SEGV on unknown address 0x7fb09cd5a000 (pc
0x7fb09cd5a047 bp 0x7ffdb7a451a0 sp 0x7ffdb7a450d8 T0)
==2830==The signal is caused by a WRITE memory access.
#0 0x7fb09cd5a046 in __tls_get_addr (/opt/clang/lib64/libomp.so+0x46)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/opt/clang/lib64/libomp.so+0x46) in
__tls_get_addr
==2830==ABORTING
--
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 31211] [Regression > 3.8] Access to static data member array initialized with template parameter is not a constant expression
https://bugs.llvm.org/show_bug.cgi?id=31211 Tomasz Kamiński changed: What|Removed |Added Status|RESOLVED|REOPENED 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 33074] Rematerialized LEApcrel can address a different literal pool from the original
https://bugs.llvm.org/show_bug.cgi?id=33074 John Brawn changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from John Brawn --- Yes, I think so as well. Marking as a duplicate. *** This bug has been marked as a duplicate of bug 32780 *** -- 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 33090] New: Link error with make_shared and scoped constant expression
https://bugs.llvm.org/show_bug.cgi?id=33090 Bug ID: 33090 Summary: Link error with make_shared and scoped constant expression Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: marcosa...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 18465 --> https://bugs.llvm.org/attachment.cgi?id=18465&action=edit Failing source code Source code attached fails at the linking stage. >From the output, I can see it is calling make_shared using a reference, not a constant. Of course, the constexpr is taken out at compile time, and so fails with undefined reference. marco@Marco-Laptop-PC:/mnt/c/Shared/Dev/Projects/clangbug$ clang++-5.0 --version clang version 5.0.0-svn303316-1~exp1 (trunk) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin marco@Marco-Laptop-PC:/mnt/c/Shared/Dev/Projects/clangbug$ clang++-5.0 -std=c++14 main.cpp -o main /tmp/main-1722a6.o: In function `main': main.cpp:(.text+0x17): undefined reference to `test::sz' clang: error: linker command failed with exit code 1 (use -v to see invocation) marco@Marco-Laptop-PC:/mnt/c/Shared/Dev/Projects/clangbug$ However, using -std=c++1z, the code compiles fine. Sorry if this is not a linker bug but a clang bug. It could also be a GCC bug, which I have used to compare against. Using -std=c++14 works under GCC. (Sorry if it is!) If it matters, I am running Ubuntu 16.04 under the Windows subsystem for Linux. Thanks, Marco. -- 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 33091] New: null pointer dereference in libfuzzer?
https://bugs.llvm.org/show_bug.cgi?id=33091 Bug ID: 33091 Summary: null pointer dereference in libfuzzer? Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: agostino.saru...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 18466 --> https://bugs.llvm.org/attachment.cgi?id=18466&action=edit stacktrace1 This is the first time I tried to use libfuzzer, I'd like to understand if I did something bad on my side. I downloaded this: https://github.com/google/oss-fuzz/blob/master/projects/curl/curl_fuzzer.cc I compiled it with: clang++ -g3 -fsanitize=address,undefined -fsanitize-coverage=trace-pc-guard curl_fuzzer.cc -lcurl /usr/lib64/libFuzzer.a -o curl_libfuzzer while I launch ./curl_libfuzzer I get (see stacktrace1): ==19775==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x bp 0x sp 0x7ffe82b616b8 T0) after that I tried to do the same thing with libfuzzer compiled with asan/ubsan, I get more info but the same result (see stacktrace2). I have clang 4.0.0 and libfuzzer 3.9.1 -- 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 17693] multiplying long long with fsanitize=integer fails with undefined reference to __mulodi4
https://bugs.llvm.org/show_bug.cgi?id=17693 Christian Holler (:decoder) changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED CC||chol...@mozilla.com --- Comment #4 from Christian Holler (:decoder) --- I can perfectly reproduce this on Clang 5 with the testcase from the original comment on x86: $ clang-5.0 -fsanitize=integer -o tst tst.c /tmp/tst-601e90.o: In function `main': tst.c:(.text+0x83): undefined reference to `__mulodi4' clang: error: linker command failed with exit code 1 (use -v to see invocation) $ clang-5.0 --version clang version 5.0.0-svn303223-1~exp1 (trunk) This prevents Firefox from being built with UBSan on 32-bit. -- 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 33062] [OPENMP] positive loop step not recognized as such
https://bugs.llvm.org/show_bug.cgi?id=33062 hst...@ca.ibm.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- 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 388] Put the Core LLVM classes on a diet
https://bugs.llvm.org/show_bug.cgi?id=388 Bug 388 depends on bug 889, which changed state. Bug 889 Summary: Eliminate Virtual Methods In VMCore To Make Value Objects Smaller https://bugs.llvm.org/show_bug.cgi?id=889 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 889] Eliminate Virtual Methods In VMCore To Make Value Objects Smaller
https://bugs.llvm.org/show_bug.cgi?id=889 Reid Kleckner changed: What|Removed |Added Assignee|unassignedb...@nondot.org |r...@google.com Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #24 from Reid Kleckner --- r303362 -- 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 32950] LLD COFF unreferenced imports still added
https://bugs.llvm.org/show_bug.cgi?id=32950 Rui Ueyama changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Rui Ueyama --- Should be fixed in r303304 (which is a re-submission of r303304). -- 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 33091] null pointer dereference in libfuzzer?
https://bugs.llvm.org/show_bug.cgi?id=33091 Kostya Serebryany changed: What|Removed |Added CC||k...@google.com Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Kostya Serebryany --- 1. you are using a very old libFuzzer and much newer clang. This won't work. Please use the fresh and matching versions of both. 2. -lcurl is not going to work. If you want to fuzz curl you need to instrument it itself, not link the system library (that is not instrumented). Take a look at the rest of the files in https://github.com/google/oss-fuzz/tree/master/projects/curl -- 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 33077] [Loop Reduce] Assertion failure due to invalid canonicalization for formula
https://bugs.llvm.org/show_bug.cgi?id=33077 Quentin Colombet changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Quentin Colombet --- Wei fixed it in r303361 -- 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 33092] New: Clang asserts in CodeGen with a lambda default argument function in a template
https://bugs.llvm.org/show_bug.cgi?id=33092
Bug ID: 33092
Summary: Clang asserts in CodeGen with a lambda default
argument function in a template
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: erik.pilking...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Clang trunk (and dating back to 3.8) crashes on the following, compiled with
-std=c++14:
template int algo(F fn) { return fn(); }
template void g(int n) {
int bef(int i = []{ return 1; }());
algo([=]{return n+bef();});
}
int main() { g(0); }
With the stack trace:
Assertion failed: ((isGenericMethod || ((*I)->isVariablyModifiedType() ||
(*I).getNonReferenceType()->isObjCRetainableType() || getContext()
.getCanonicalType((*I).getNonReferenceType()) .getTypePtr() == getContext()
.getCanonicalType((*Arg)->getType()) .getTypePtr())) && "type mismatch in call
argument!"), function EmitCallArgs, file
/Users/erikpilkington/llvm/tools/clang/lib/CodeGen/CodeGenFunction.h, line
3725.
0 clang-5.00x00010d77e3fc
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
1 clang-5.00x00010d77e979
PrintStackTraceSignalHandler(void*) + 25
2 clang-5.00x00010d77a8c9 llvm::sys::RunSignalHandlers() +
425
3 clang-5.00x00010d77ed02 SignalHandler(int) + 354
4 libsystem_platform.dylib 0x7fffb64b4bba _sigtramp + 26
5 libsystem_platform.dylib 00 _sigtramp + 1236579424
6 libsystem_c.dylib0x7fffb633b420 abort + 129
7 libsystem_c.dylib0x7fffb6302893 basename_r + 0
8 clang-5.00x00010dd1c28b void
clang::CodeGen::CodeGenFunction::EmitCallArgs(clang::CodeGen::CallArgList&,
clang::FunctionProtoType const*,
llvm::iterator_range,
clang::CodeGen::CodeGenFunction::AbstractCallee, unsigned int,
clang::CodeGen::CodeGenFunction::EvaluationOrder) + 843
9 clang-5.00x00010dd1b642
clang::CodeGen::CodeGenFunction::EmitCall(clang::QualType,
clang::CodeGen::CGCallee const&, clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot, llvm::Value*) + 4306
10 clang-5.00x00010dd19fe8
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) + 776
11 clang-5.00x00010dd6b5e3 (anonymous
namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) + 163
12 clang-5.00x00010dd65f2b
clang::StmtVisitorBase::Visit(clang::Stmt*) + 2939
13 clang-5.00x00010dd5efa9 (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*) + 73
14 clang-5.00x00010dd70fb8 (anonymous
namespace)::ScalarExprEmitter::EmitBinOps(clang::BinaryOperator const*) + 104
15 clang-5.00x00010dd67448 (anonymous
namespace)::ScalarExprEmitter::VisitBinAdd(clang::BinaryOperator const*) + 40
16 clang-5.00x00010dd654b3
clang::StmtVisitorBase::Visit(clang::Stmt*) + 259
17 clang-5.00x00010dd5efa9 (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*) + 73
18 clang-5.00x00010dd5ef0d
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 189
19 clang-5.00x00010de7edc4
clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) + 948
20 clang-5.00x00010de7bda1
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 993
21 clang-5.00x00010de8bea8
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot) + 136
22 clang-5.00x00010defba52
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&,
clang::Stmt const*) + 146
23 clang-5.00x00010defc62a
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 1418
24 clang-5.00x00010df24b1e
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*) + 574
25 clang-5.00x00010df1c9cc
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) + 588
26 clang-5.00x00010df12669
clang::CodeGen::CodeGenModule::EmitDeferred() + 1097
27 clang-5.00x00010df126c5
clang::CodeGen::CodeGenModule::EmitDeferred() + 1189
28 clang-5.00x00010df126c5
clang::CodeGen::CodeGenModule::EmitDeferred() + 1189
29 clang-5.00x00010df10b06
clang::CodeGen::CodeGenModule::Release() + 54
30 clang-5.00x00010e0e9be6 (anonymous
namespace)::CodeGener
[llvm-bugs] [Bug 33093] New: [ppc] Slow code for reverse bits
https://bugs.llvm.org/show_bug.cgi?id=33093
Bug ID: 33093
Summary: [ppc] Slow code for reverse bits
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: car...@google.com
CC: llvm-bugs@lists.llvm.org
The reverse bits source code is:
unsigned int ReverseBits(unsigned int n) {
n = ((n >> 1) & 0x) | ((n & 0x) << 1);
n = ((n >> 2) & 0x) | ((n & 0x) << 2);
n = ((n >> 4) & 0x0F0F0F0F) | ((n & 0x0F0F0F0F) << 4);
return ((n & 0xff00u) >> 24) | ((n & 0x00ffu) >> 8) | ((n &
0xff00u) << 8) | ((n & 0x00ffu) << 24);
}
LLVM generates:
# BB#0: # %entry
rlwinm 4, 3, 1, 0, 31
rlwimi 4, 3, 3, 30, 30
rlwimi 4, 3, 5, 29, 29
rlwimi 4, 3, 7, 28, 28
rlwimi 4, 3, 9, 27, 27
rlwimi 4, 3, 11, 26, 26
rlwimi 4, 3, 13, 25, 25
rlwimi 4, 3, 15, 24, 24
rlwimi 4, 3, 17, 23, 23
rlwimi 4, 3, 19, 22, 22
rlwimi 4, 3, 21, 21, 21
rlwimi 4, 3, 23, 20, 20
rlwimi 4, 3, 25, 19, 19
rlwimi 4, 3, 27, 18, 18
rlwimi 4, 3, 29, 17, 17
rlwimi 4, 3, 31, 16, 16
rlwimi 4, 3, 3, 14, 14
rlwimi 4, 3, 5, 13, 13
rlwimi 4, 3, 7, 12, 12
rlwimi 4, 3, 9, 11, 11
rlwimi 4, 3, 11, 10, 10
rlwimi 4, 3, 13, 9, 9
rlwimi 4, 3, 15, 8, 8
rlwimi 4, 3, 17, 7, 7
rlwimi 4, 3, 19, 6, 6
rlwimi 4, 3, 21, 5, 5
rlwimi 4, 3, 23, 4, 4
rlwimi 4, 3, 25, 3, 3
rlwimi 4, 3, 27, 2, 2
rlwimi 4, 3, 29, 1, 1
rlwimi 4, 3, 31, 0, 0
mr 3, 4
blr
All of the instructions are in a dependence chain. It is much slower than the
algorithm shown in the source code.
--
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 33090] Link error with make_shared and scoped constant expression
https://bugs.llvm.org/show_bug.cgi?id=33090 Rui Ueyama changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |INVALID --- Comment #1 from Rui Ueyama --- Hi Marco, It doesn't seems like a bug in LLD. Actually you are not even using but the default linker (which is I guess the GNU ld). In order to use LLD, you need to pass `-fuse-ld=lld`, but you are not doing that. If you still have a trouble, please file this against Clang. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33064] Merge IAT and ILT
https://bugs.llvm.org/show_bug.cgi?id=33064 Rui Ueyama changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Rui Ueyama --- Submitted r303374 and r303378 to merge the tables and set IMAGE_DLL_CHARACTERISTICS_NO_BIND. -- 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 33094] New: Infinite loop in object file generation related to branching, aggregates and inlining
https://bugs.llvm.org/show_bug.cgi?id=33094 Bug ID: 33094 Summary: Infinite loop in object file generation related to branching, aggregates and inlining Product: new-bugs Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: benoit@etu.upmc.fr CC: llvm-bugs@lists.llvm.org Created attachment 18469 --> https://bugs.llvm.org/attachment.cgi?id=18469&action=edit Minimal case Trying to generate an object file for the optimised version of the attached minimal case (either via llc or the LLVM API) results in an infinite loop. Here is the deepest debugger backtrace that I've managed to get (from llc): #0 0x757bd642 in llvm::SelectionDAG::TransferDbgValues(llvm::SDValue, llvm::SDValue) () from /usr/bin/../lib/libLLVM-4.0.so #1 0x757be516 in llvm::SelectionDAG::ReplaceAllUsesOfValueWith(llvm::SDValue, llvm::SDValue) () from /usr/bin/../lib/libLLVM-4.0.so #2 0x756986c8 in ?? () from /usr/bin/../lib/libLLVM-4.0.so #3 0x75699a6f in ?? () from /usr/bin/../lib/libLLVM-4.0.so #4 0x7569af2d in llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults&, llvm::CodeGenOpt::Level) () from /usr/bin/../lib/libLLVM-4.0.so #5 0x757c85de in llvm::SelectionDAGISel::CodeGenAndEmitDAG() () from /usr/bin/../lib/libLLVM-4.0.so #6 0x757d10b7 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from /usr/bin/../lib/libLLVM-4.0.so #7 0x757d2d49 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /usr/bin/../lib/libLLVM-4.0.so #8 0x76a09e74 in ?? () from /usr/bin/../lib/libLLVM-4.0.so #9 0x754ae841 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /usr/bin/../lib/libLLVM-4.0.so #10 0x7532eb32 in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /usr/bin/../lib/libLLVM-4.0.so #11 0x7532ebd3 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /usr/bin/../lib/libLLVM-4.0.so #12 0x7532f584 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /usr/bin/../lib/libLLVM-4.0.so #13 0x0041eb46 in ?? () #14 0x00413870 in main () This doesn't seem to happen in the minimal case if either: - All the code is in `f1` - The result of the `icmp` in `f2` is true (can be done e.g. by passing `@B_Inst` to `f2`) - Both aggregates in the `phi` node in `f2` have the same value - The `phi` node operands are numbers instead of aggregates - The `icmp` operands are numbers instead of aggregates For reference, this bug was originally found in the Pony compiler (additional details can be found here: https://github.com/ponylang/ponyc/issues/1919). The attached minimal case wasn't generated by the Pony compiler. -- 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 33095] New: Support the binding feature
https://bugs.llvm.org/show_bug.cgi?id=33095 Bug ID: 33095 Summary: Support the binding feature Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org LLD currently does not support the Binding feature which is similar to prelinking. We might want to support it if it actually speeds up process startup time. Related: https://bugs.llvm.org/show_bug.cgi?id=33064#c1 -- 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 33014] clang crashes with "-mllvm -enable-newgvn": lots of "singleReachablePHIPath" in the stack trace
https://bugs.llvm.org/show_bug.cgi?id=33014 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Davide Italiano --- r303393 -- 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 33096] New: Wrong relocation type in relocatable LTO link
https://bugs.llvm.org/show_bug.cgi?id=33096
Bug ID: 33096
Summary: Wrong relocation type in relocatable LTO link
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: gold-plugin
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
Normally, with -fno-PIC, address of external symbol is generated as R_X86_64_64
relocation to that symbol. During the final link the relocation may be
re-written to PLT if the symbol is not resolved.
This does not work when an IR input is used in relocatable link. The output
contains R_X86_64_GOTPCREL relocation.
This does not reproduce with LLD. The problem is specific to gold-plugin.
This is an issue when building linux kernel modules with LTO. The modules are
relocatable object files, and the runtime loader in the kernel does not do
fancy things like GOT or PLT. It expects all text relocations.
$ cat a.c
void f(void);
void *address_of_f(void) {
return &f;
}
BAD CASE:
$ ./bin/clang a.c -c -flto -fno-PIC && ld.gold --plugin lib/LLVMgold.so -r
a.o -o 2.o && objdump -drl 2.o
...
:
address_of_f():
0: 55 push %rbp
1: 48 89 e5mov%rsp,%rbp
4: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# b
7: R_X86_64_GOTPCRELf-0x4
b: 5d pop%rbp
c: c3 retq
GOOD CASE:
$ ./bin/clang a.c -c -fno-PIC && ld.gold --plugin lib/LLVMgold.so -r a.o -o
2.o && objdump -drl 2.o
...
:
address_of_f():
0: 55 push %rbp
1: 48 89 e5mov%rsp,%rbp
4: 48 b8 00 00 00 00 00movabs $0x0,%rax
b: 00 00 00
6: R_X86_64_64 f
e: 5d pop%rbp
f: c3 retq
--
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 33097] New: IR symbols are not live in relocatable link
https://bugs.llvm.org/show_bug.cgi?id=33097
Bug ID: 33097
Summary: IR symbols are not live in relocatable link
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
$ cat 1.ll
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define void @f() {
entry:
ret void
}
$ bin/llvm-as 1.ll -o 1.bc && bin/ld.lld 1.bc -r -o 2.o && objdump -drl 2.o
2.o: file format elf64-x86-64
The output is an empty object file.
--
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 33098] New: Undefined symbol link-time error with std::make_shared and scoped constexpr value
https://bugs.llvm.org/show_bug.cgi?id=33098 Bug ID: 33098 Summary: Undefined symbol link-time error with std::make_shared and scoped constexpr value Product: clang Version: 3.8 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: marcosa...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 18470 --> https://bugs.llvm.org/attachment.cgi?id=18470&action=edit Failing source code Source code attached fails at the linking stage. >From the output, I can see it is calling make_shared using a reference, not a constant. Of course, the constexpr is taken out at compile time, and so fails with undefined reference. marco@Marco-Laptop-PC:/mnt/c/Shared/Dev/Projects/clangbug$ clang++-5.0 --version clang version 5.0.0-svn303316-1~exp1 (trunk) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin marco@Marco-Laptop-PC:/mnt/c/Shared/Dev/Projects/clangbug$ clang++-5.0 -std=c++14 main.cpp -o main /tmp/main-1722a6.o: In function `main': main.cpp:(.text+0x17): undefined reference to `test::sz' clang: error: linker command failed with exit code 1 (use -v to see invocation) marco@Marco-Laptop-PC:/mnt/c/Shared/Dev/Projects/clangbug$ However, using -std=c++1z, the code compiles fine. I have tested -std=c++14 with clang 3.8, 4.0 and 5.0 (all fail), only tested -std=c++1z with 5.0 (works). It could also be a GCC bug, which I have used to compare against. Using -std=c++14 works under GCC. (Sorry if it is!) If it matters, I am running Ubuntu 16.04 under the Windows subsystem for Linux. Thanks, Marco. -- 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 32688] RegCoalescer asserts during joinSubRanges
https://bugs.llvm.org/show_bug.cgi?id=32688 Matthias Braun changed: What|Removed |Added Assignee|unassignedb...@nondot.org |ma...@braunis.de Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Matthias Braun --- Thanks for the report and esp. the nicely reduced testcase. Fixed in r303396 -- 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 33099] New: Segfault compiling Waterfox 58
https://bugs.llvm.org/show_bug.cgi?id=33099 Bug ID: 33099 Summary: Segfault compiling Waterfox 58 Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: rangu...@archlinux.us CC: llvm-bugs@lists.llvm.org Using clang-4.0 on a fully updated Arch system. The generated reproduction source and script are too large to attach, and so have been uploaded to a public Google Drive link. Let me know if this is inaccessible for anyone. Please do attach it if someone else is able. https://drive.google.com/file/d/0B64kGVYfLeQZa285Z0JkN0UyaUU/view -- 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 32201] Merge r294690 into the 4.0 branch
https://bugs.llvm.org/show_bug.cgi?id=32201 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32061] [meta] 4.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 32201, which changed state. Bug 32201 Summary: Merge r294690 into the 4.0 branch https://bugs.llvm.org/show_bug.cgi?id=32201 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 33086] clang crashes with "-mllvm -enable-newgvn": Assertion `isa(Val) && "cast() argument of incompatible type!"' failed
https://bugs.llvm.org/show_bug.cgi?id=33086 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Davide Italiano --- rL303406. Thanks! -- 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 33100] New: Miscompilation in arm64 backend
https://bugs.llvm.org/show_bug.cgi?id=33100 Bug ID: 33100 Summary: Miscompilation in arm64 backend Product: tools Version: trunk Hardware: Other OS: MacOS X Status: NEW Severity: normal Priority: P Component: llc Assignee: unassignedb...@nondot.org Reporter: hu...@apple.com CC: llvm-bugs@lists.llvm.org Created attachment 18471 --> https://bugs.llvm.org/attachment.cgi?id=18471&action=edit Returns 0 when compiled correctly I came across a miscompilation bug on arm64. I reduced it to a small test case that is successful when compiled with -O0 but miscompiles with -O1. Repro steps: $ llc -relocation-model=pic -mcpu=cyclone -disable-fp-elim -O0 -o reduced_good.s reduced_test_case.ll $ clang -arch arm64 -x assembler -o reduced_good reduced_good.s Execute on any arm64 device: $ ./reduced_good $ echo $? 0 $ llc -relocation-model=pic -mcpu=cyclone -disable-fp-elim -O1 -o reduced_bad.s reduced_test_case.ll $ clang -arch arm64 -x assembler -o reduced_bad reduced_bad.s Execute on any arm64 device: $ ./reduced_good $ echo $? 1 After disassembling both, the bad one shows several 32-bit operations which are somewhat unexpected in a function with only 64-bit operations. The unoptimized assembly also uses only 64-bit operations. Maybe the > 32-bit left shift triggers a mistake in the optimization to overaggressively truncate some values. -- 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
