[llvm-bugs] [Bug 28779] New: Wrong relocation emitted using lld -r
https://llvm.org/bugs/show_bug.cgi?id=28779 Bug ID: 28779 Summary: Wrong relocation emitted using lld -r Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@rink.nu CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16842 --> https://llvm.org/bugs/attachment.cgi?id=16842&action=edit Example code to trigger the bug (make LD=clang-lld) When working on crt1 code for my own OS Ananas, I noticed the following (refer to the attached archive): when you use 'lld -r' to combine object files, the wrong offset is used. The attached example contains: start.S: startup code, calls func() and exits func.c: contains func() which initializes some value on stack and increments it Makefile: compiles start.S -> start.o, func.c -> func.o, combines them to 'combined.o' and build 't' using 'combined.o' Using LLD, the resulting program 't' crashes. This is because the offset of 'func' is wrong, as you can see when using objdump -d: Disassembly of section .text: 00011000 <_start>: 11000:e8 11 00 00 00 callq 11016 <-- WRONG 11005:48 c7 c0 3c 00 00 00 mov$0x3c,%rax 1100c:48 31 ff xor%rdi,%rdi 1100f:0f 05syscall 11011:c3 retq 00011012 : 11012:55 push %rbp 11013:48 89 e5 mov%rsp,%rbp 11016:c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp) 1101d:83 45 fc 01 addl $0x1,-0x4(%rbp) 11021:90 nop 11022:5d pop%rbp 11023:c3 retq Where GNU LD yields: Disassembly of section .text: 004000b0 <_start>: 4000b0:e8 0d 00 00 00 callq 4000c2 4000b5:48 c7 c0 3c 00 00 00 mov$0x3c,%rax 4000bc:48 31 ff xor%rdi,%rdi 4000bf:0f 05syscall 4000c1:c3 retq 004000c2 : 4000c2:55 push %rbp 4000c3:48 89 e5 mov%rsp,%rbp 4000c6:c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp) 4000cd:83 45 fc 01 addl $0x1,-0x4(%rbp) 4000d1:90 nop 4000d2:5d pop%rbp 4000d3:c3 retq Note: I understand this is a silly example, but in my actual case combined.o calls 'main' so I need to use -r because I want to build crt1.o. -- 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 17899] vector comparison 'less than' miscompiled on avx2
https://llvm.org/bugs/show_bug.cgi?id=17899 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED CC||llvm-...@redking.me.uk Resolution|--- |FIXED --- Comment #4 from Simon Pilgrim --- Fixed in trunk and has been for some time. -- 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 14760] DAGCombiner generates illegal vector INT_TO_FP nodes
https://llvm.org/bugs/show_bug.cgi?id=14760 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED CC||llvm-...@redking.me.uk Resolution|--- |FIXED --- Comment #2 from Simon Pilgrim --- Closing this - as of rL277271 the x86 tests are enabled for x32/x64 and confirmed that the results are the same for the entire range of u32 values for the two different codegens on x86. -- 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 28780] New: "edit distance" algorithm is wrong
https://llvm.org/bugs/show_bug.cgi?id=28780
Bug ID: 28780
Summary: "edit distance" algorithm is wrong
Product: compiler-rt
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: jia...@mail.ustc.edu.cn
CC: llvm-bugs@lists.llvm.org, nicolaswe...@gmx.de
Classification: Unclassified
In "llvm/include/llvm/ADT/edit_distance.h:ComputeEditDistance()" function, if
two strings(or arrays) are both empty, the result would be a random value, but
expected zero.
The current version on 2016.07.29 is:
template
unsigned ComputeEditDistance(ArrayRef FromArray, ArrayRef ToArray,
bool AllowReplacements = true,
unsigned MaxEditDistance = 0) {
// The algorithm implemented below is the "classic"
// dynamic-programming algorithm for computing the Levenshtein
// distance, which is described here:
//
// http://en.wikipedia.org/wiki/Levenshtein_distance
//
// Although the algorithm is typically described using an m x n
// array, only one row plus one element are used at a time, so this
// implementation just keeps one vector for the row. To update one
entry,
// only the entries to the left, top, and top-left are needed. The left
// entry is in Row[x-1], the top entry is what's in Row[x] from the last
// iteration, and the top-left entry is stored in Previous.
typename ArrayRef::size_type m = FromArray.size();
typename ArrayRef::size_type n = ToArray.size();
const unsigned SmallBufferSize = 64;
unsigned SmallBuffer[SmallBufferSize];
std::unique_ptr Allocated;
unsigned *Row = SmallBuffer;
if (n + 1 > SmallBufferSize) {
Row = new unsigned[n + 1];
Allocated.reset(Row);
}
for (unsigned i = 1; i <= n; ++i)
Row[i] = i;
for (typename ArrayRef::size_type y = 1; y <= m; ++y) {
Row[0] = y;
unsigned BestThisRow = Row[0];
unsigned Previous = y - 1;
for (typename ArrayRef::size_type x = 1; x <= n; ++x) {
int OldRow = Row[x];
if (AllowReplacements) {
Row[x] = std::min(
Previous + (FromArray[y-1] == ToArray[x-1] ? 0u : 1u),
std::min(Row[x-1], Row[x])+1);
}
else {
if (FromArray[y-1] == ToArray[x-1]) Row[x] = Previous;
else Row[x] = std::min(Row[x-1], Row[x]) + 1;
}
Previous = OldRow;
BestThisRow = std::min(BestThisRow, Row[x]);
}
if (MaxEditDistance && BestThisRow > MaxEditDistance)
return MaxEditDistance + 1;
}
unsigned Result = Row[n];
return Result;
}
The above algorithm was first introduced on 2015.07.13: git-svn-id:
https://llvm.org/svn/llvm-project/llvm/trunk@242069
91177308-0d34-0410-b5e6-96231b3b80d8. And the last right version is git-svn-id:
https://llvm.org/svn/llvm-project/llvm/trunk@240390
91177308-0d34-0410-b5e6-96231b3b80d8.
The above `ComputeEditDistance` function is used in
"llvm/lib/Support/StringRef.cpp:StringRef::edit_distance()". So you can
reproduce the bug via calling `StringRef::edit_distance()`. NOTE that the
returned random value may be zero.
How to fix it? The simple solution is to initialize the stack-based array
explictly: `unsigned SmallBuffer[SmallBufferSize]{};`. The safer solution is to
use RAII-style container, however, at the cost for allocating memory dynamicly
even if small number of elements.
Accordingly, unit test can be strengthened in
"llvm/unittests/ADT/StringRefTest.cpp":
diff --git a/unittests/ADT/StringRefTest.cpp
b/unittests/ADT/StringRefTest.cpp
index 66e5944..306dc23 100644
--- a/unittests/ADT/StringRefTest.cpp
+++ b/unittests/ADT/StringRefTest.cpp
@@ -390,6 +390,11 @@ TEST(StringRefTest, Count) {
}
TEST(StringRefTest, EditDistance) {
+ StringRef StrNull;
+ StringRef StrEmpty("");
+ EXPECT_EQ(0U, StrNull.edit_distance(""));
+ EXPECT_EQ(0U, StrEmpty.edit_distance(""));
+
StringRef Str("hello");
EXPECT_EQ(2U, Str.edit_distance("hill"));
}
That's all.
Gang JIANG
jia...@mail.ustc.edu.cn
http://justme0.com/
University of Science and Technology of China
--
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 13871] Assertion failed: (Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"), function getFPReg, file X86FloatingPoint.cpp, line 332.
https://llvm.org/bugs/show_bug.cgi?id=13871 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED CC||llvm-...@redking.me.uk Resolution|--- |FIXED --- Comment #2 from Simon Pilgrim --- Resolving - the test case works in trunk and I've added a nosse-vector tests case for i686/x86_64 to check similar x87 codegen. -- 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 28781] New: Dwarf-related crash with clang & llvm-link
https://llvm.org/bugs/show_bug.cgi?id=28781 Bug ID: 28781 Summary: Dwarf-related crash with clang & llvm-link Product: new-bugs Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ro...@icir.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16844 --> https://llvm.org/bugs/attachment.cgi?id=16844&action=edit Source code Compiling & linking the attached code as follows: # clang -emit-llvm -g -O2 -o a.o -c a.c && llvm-link -o a.bc a.o && clang a.bc results in the output below. If I remove either -O2 or -g, the crash goes away. I also couldn't get the C code any smaller, if I remove more code, the problem disappears. Interestingly, it also goes aways if I just run clang-format on the file to break up the one long line in there (this came out of the preprocessor). This is with LLVM/clang 3.9 as of commit 4105790f1549. #0 0x018edb65 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/Support/Unix/Signals.inc:406:0 #1 0x018ebd8e llvm::sys::RunSignalHandlers() /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/Support/Signals.cpp:45:0 #2 0x018ebec8 SignalHandler(int) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/Support/Unix/Signals.inc:246:0 #3 0x7f5d9ca13a00 __restore_rt (/lib64/libpthread.so.0+0x10a00) #4 0x01db7373 llvm::DwarfUnit::addDIEEntry(llvm::DIE&, llvm::dwarf::Attribute, llvm::DIEEntry) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/CodeGen/AsmPrinter/DwarfUnit.cpp:294:0 #5 0x01db73cc llvm::DwarfUnit::addDIEEntry(llvm::DIE&, llvm::dwarf::Attribute, llvm::DIE&) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/CodeGen/AsmPrinter/DwarfUnit.cpp:267:0 #6 0x01da8939 llvm::DwarfDebug::finishVariableDefinitions() /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/CodeGen/AsmPrinter/DwarfDebug.cpp:506:0 #7 0x01da8a37 __gnu_cxx::__normal_iterator*, std::vector, std::allocator > > >::__normal_iterator(std::pair* const&) /usr/include/c++/5.3.1/bits/stl_iterator.h:741:0 #8 0x01da8a37 std::vector, std::allocator > >::end() /usr/include/c++/5.3.1/bits/stl_vector.h:566:0 #9 0x01da8a37 llvm::MapVector, llvm::detail::DenseMapPair >, std::vector, std::allocator > > >::end() /opt/llvm39-RelWithDebugInfo/src/llvm/build/../include/llvm/ADT/MapVector.h:48:0 #10 0x01da8a37 llvm::DwarfDebug::finalizeModuleInfo() /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/CodeGen/AsmPrinter/DwarfDebug.cpp:543:0 #11 0x01db1410 llvm::DwarfDebug::endModule() /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/CodeGen/AsmPrinter/DwarfDebug.cpp:622:0 #12 0x01d9ccee llvm::AsmPrinter::doFinalization(llvm::Module&) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1170:0 #13 0x01567389 llvm::FPPassManager::doFinalization(llvm::Module&) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/IR/LegacyPassManager.cpp:1565:0 #14 0x01572535 runOnModule /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/IR/LegacyPassManager.cpp:1621:0 #15 0x01572535 llvm::legacy::PassManagerImpl::run(llvm::Module&) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../lib/IR/LegacyPassManager.cpp:1706:0 #16 0x01a3593f llvm::PrettyStackTraceString::~PrettyStackTraceString() /opt/llvm39-RelWithDebugInfo/src/llvm/build/../include/llvm/Support/PrettyStackTrace.h:51:0 #17 0x01a3593f EmitAssembly /opt/llvm39-RelWithDebugInfo/src/llvm/build/../tools/clang/lib/CodeGen/BackendUtil.cpp:738:0 #18 0x01a3593f clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../tools/clang/lib/CodeGen/BackendUtil.cpp:751:0 #19 0x01f90040 std::unique_ptr >::~unique_ptr() /usr/include/c++/5.3.1/bits/unique_ptr.h:235:0 #20 0x01f90040 clang::CodeGenAction::ExecuteAction() [clone .part.99] [clone .constprop.100] /opt/llvm39-RelWithDebugInfo/src/llvm/build/../tools/clang/lib/CodeGen/CodeGenAction.cpp:846:0 #21 0x01d07ab6 clang::FrontendAction::Execute() /opt/llvm39-RelWithDebugInfo/src/llvm/build/../tools/clang/lib/Frontend/FrontendAction.cpp:457:0 #22 0x01cdbb66 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../tools/clang/lib/Frontend/CompilerInstance.cpp:868:0 #23 0x01d800f2 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /opt/llvm39-RelWithDebugInfo/src/llvm/build/../tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:241:0 #24 0x00914fe0 cc1_main(llvm::Arra
[llvm-bugs] [Bug 28782] New: possible ms extension: declaration after label
https://llvm.org/bugs/show_bug.cgi?id=28782
Bug ID: 28782
Summary: possible ms extension: declaration after label
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: jay.f...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I noticed this difference between cl (VS 2015 update 3) and clang-cl (3.8.1):
$ cat lab.c
void f(int i) {
foo: int n;
switch(i) {
case 0: int m;
}
}
$ cl /c lab.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
lab.c
$ clang-cl /c lab.c
lab.c(2,6) : error: expected expression
foo: int n;
^
lab.c(4,9) : error: expected expression
case 0: int m;
^
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28783] New: A cast<> failed in ExtractLoops()
https://llvm.org/bugs/show_bug.cgi?id=28783 Bug ID: 28783 Summary: A cast<> failed in ExtractLoops() Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: bugpoint Assignee: unassignedb...@nondot.org Reporter: feishenni...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16845 --> https://llvm.org/bugs/attachment.cgi?id=16845&action=edit The input .ll file that triggered the bug I tried to use bugpoint to help me pinpoint a miscompilation bug in loop optimizers, yet bugpoint itself crashes when trying to extract loops from the miscompiled function. The source of the error can be narrowed down to the ExtractLoops() function inside Miscompilation.cpp. Around line 339 there's a statement "MiscompiledFunctions[i] = cast(VMap[MiscompiledFunctions[i]]);". The right-hand-side of this statement, i.e. VMap[...], turns out to be an empty WeakVH rather than a Function*. This is how I invoked bugpoint: > bugpoint -run-llc -safe-run-llc test.ll -loop-unroll -gcc=clang++ This is what I got back from the invocation: Read input file : 'test.ll' *** All input ok Running selected passes on program to test for crash: Success! Initializing execution environment: Found llc: /home/grieve/LLVM/GSoC/Testing/debugBuild/bin/llc Running the code generator to test for a crash: Generating reference output from raw program: Reference output is: bugpoint.reference.out-17cf006 *** Checking the code generator... *** Output matches: Debugging miscompilation! Checking to see if '' compiles correctly: yup. Checking to see if '-loop-unroll' compiles correctly: nope. *** Found miscompiling pass: -loop-unroll Emitted bitcode to 'bugpoint-passinput.bc' *** You can reproduce the problem with: opt bugpoint-passinput.bc -loop-unroll Checking to see if the program is misoptimized when these functions are run through the pass: main _ZNSt5dequeIdSaIdEE18_M_fill_initializeERKd _ZNSt11_Deque_baseIdSaIdEE17_M_initialize_mapEm _ZNSt11_Deque_baseIdSaIdEE15_M_create_nodesEPPdS3_ __clang_call_terminate Optimizing functions being tested: done. Checking to see if the merged program executes correctly: nope. Checking to see if the program is misoptimized when these functions are run through the pass: _ZNSt11_Deque_baseIdSaIdEE17_M_initialize_mapEm _ZNSt11_Deque_baseIdSaIdEE15_M_create_nodesEPPdS3_ __clang_call_terminate Optimizing functions being tested: done. Checking to see if the merged program executes correctly: yup. Checking to see if the program is misoptimized when these functions are run through the pass: main _ZNSt5dequeIdSaIdEE18_M_fill_initializeERKd Optimizing functions being tested: done. Checking to see if the merged program executes correctly: nope. Checking to see if the program is misoptimized when this function is run through the pass: _ZNSt5dequeIdSaIdEE18_M_fill_initializeERKd Optimizing functions being tested: done. Checking to see if the merged program executes correctly: yup. Checking to see if the program is misoptimized when this function is run through the pass: main Optimizing functions being tested: done. Checking to see if the merged program executes correctly: nope. *** The following function is being miscompiled: main Extracted a loop from the breaking portion of the program. bugpoint: /home/grieve/LLVM/GSoC/Testing/llvm/include/llvm/Support/Casting.h:81: static bool llvm::isa_impl_cl::doit(const From*) [with To = llvm::Function; >From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed. #0 0x7f55eba74f38 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/grieve/LLVM/GSoC/Testing/llvm/lib/Support/Unix/Signals.inc:402:0 #1 0x7f55eba75298 PrintStackTraceSignalHandler(void*) /home/grieve/LLVM/GSoC/Testing/llvm/lib/Support/Unix/Signals.inc:470:0 #2 0x7f55eba73548 llvm::sys::RunSignalHandlers() /home/grieve/LLVM/GSoC/Testing/llvm/lib/Support/Signals.cpp:44:0 #3 0x7f55eba74896 SignalHandler(int) /home/grieve/LLVM/GSoC/Testing/llvm/lib/Support/Unix/Signals.inc:256:0 #4 0x7f55ea594cb0 (/lib/x86_64-linux-gnu/libc.so.6+0x36cb0) #5 0x7f55ea594c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #6 0x7f55ea598028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #7 0x7f55ea58dbf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #8 0x7f55ea58dca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #9 0x00483bc4 (bugpoint+0x483bc4) #10 0x0047fd31 (bugpoint+0x47fd31) #11 0x0047bc43 (bugpoint+0x47bc43) #12 0x00476bd0 (bugpoint+0x476bd0) #13 0x0046fbcc (bugpoint+0x46fbcc) #14 0x0049ca8d (bugpoint+0x49ca8d) #15 0x0049e540 (bugpoint+0x49e540) #16 0x0049eca3 (bugpoint+0x49eca3
[llvm-bugs] [Bug 28784] New: Missing -Wpragma diagnostic
https://llvm.org/bugs/show_bug.cgi?id=28784 Bug ID: 28784 Summary: Missing -Wpragma diagnostic Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified While building with GCC 6.1: [156/201] Building CXX object unittests/Support/CMakeFiles/SupportTests.dir/AlignOfTest.cpp.o ../unittests/Support/AlignOfTest.cpp:38:32: warning: ‘-w’ is not an option that controls warnings [-Wpragmas] #pragma GCC diagnostic warning "-w" ^~~~ clang doesn't seem to warn on the same case. -- 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 28785] New: 'LLVM ERROR: branch size exceeds simm16' when using libclc/Clover under Blender
https://llvm.org/bugs/show_bug.cgi?id=28785 Bug ID: 28785 Summary: 'LLVM ERROR: branch size exceeds simm16' when using libclc/Clover under Blender Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: rafael.ristov...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When using latest libclc with added vstore_half4 support (https://github.com/jvesely/libclc/) Blender crashes while compiling the OpenCL kernels with "LLVM ERROR: branch size exceeds simm16". Sysinfo: - Gentoo Linux - llvm 4.0.0svn (rev. from Jul 22nd) - libclc master with jvesely's patch to add vstore_half4 I don't really know where to look for more info, comments appreciated. -- 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 28786] New: Long hang (infinite loop?) with -msan-keep-going
https://llvm.org/bugs/show_bug.cgi?id=28786 Bug ID: 28786 Summary: Long hang (infinite loop?) with -msan-keep-going Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: sph...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Attempting to compile the attached file with this command line: clang++ -std=gnu++11 -x c++ -o hang-regalloc.o hang-regalloc.i -fPIC -fsanitize=memory -fsanitize-recover=memory -fsanitize-memory-track-origins -mllvm -msan-keep-going -fno-rtti -fno-exceptions -fno-math-errno -Qunused-arguments -pthread -pipe -gline-tables-only -O3 -fno-omit-frame-pointer -Wno-invalid-offsetof hangs for as long as I've ever bothered to wait (at least half an hour). Attaching with gdb shows that it is doing stuff, but the call llvm::RegAllocBase::allocatePhysRegs() never finishes. % clang++ --version clang version 3.8.0 (tags/RELEASE_380/final) (llvm/tags/RELEASE_380/final 262557) Target: x86_64-unknown-linux-gnu Thread model: posix I have not tried with any other version. -- 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
