[llvm-bugs] Issue 4702 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef
Updates: Labels: ClusterFuzz-Top-Crash Comment #4 on issue 4702 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4702#c4 Testcase 5258363341373440 is a top crash on ClusterFuzz for linux platform. Please prioritize fixing this crash. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36187] New: ThinLTO inlines variables that should be discarded
https://bugs.llvm.org/show_bug.cgi?id=36187 Bug ID: 36187 Summary: ThinLTO inlines variables that should be discarded Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Linker Assignee: unassignedb...@nondot.org Reporter: gri...@accesssoftek.com CC: llvm-bugs@lists.llvm.org Created attachment 19790 --> https://bugs.llvm.org/attachment.cgi?id=19790&action=edit testcase It is similar PR35938, but about variables now. In the attached testcase (based on testcase from PR mentioned) each file has a different weak variable foo. The first file is compiled to ELF. The second one is compiled to bitcode. The linker selects the variable foo from the first (ELF) object and LTO is expected to drop the second one. Instead of that it inlines it currently. -- 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 36188] New: Merge r323643 into the 6.0 branch : [Sparc] Account for bias in stack readjustment
https://bugs.llvm.org/show_bug.cgi?id=36188 Bug ID: 36188 Summary: Merge r323643 into the 6.0 branch : [Sparc] Account for bias in stack readjustment Product: new-bugs Version: 6.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jdevliegh...@apple.com CC: llvm-bugs@lists.llvm.org Blocks: 35804 Is it OK to merge the following revision(s) to the 6.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.0.0 Release Blockers -- 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 36189] New: Crash during ParseAST
https://bugs.llvm.org/show_bug.cgi?id=36189 Bug ID: 36189 Summary: Crash during ParseAST Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: martin.sjol...@liu.se CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 19791 --> https://bugs.llvm.org/attachment.cgi?id=19791&action=edit The backtrace, source code and script to reproduce Attached is the pre-processed source code that on clang++ 4.0.1 crashes (when using -g and otherwise works) and on clang++ 5.0.1 seems to go into an infinite loop (regardless of -g flag). -- 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 33011] MVN instruction "Upredictable" bit patterns incorrect
https://bugs.llvm.org/show_bug.cgi?id=33011 Yvan Roux changed: What|Removed |Added Resolution|--- |FIXED CC||yvan.r...@linaro.org Status|NEW |RESOLVED --- Comment #2 from Yvan Roux --- Patch proposed: https://reviews.llvm.org/D41905 Fixed by r323954 -- 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 32690] [X86] SBB/AND used instead of XOR/ADC
https://bugs.llvm.org/show_bug.cgi?id=32690 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- Resolving - register dependency is fixed -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25557] clang accepts implicit conversion between vector types
https://bugs.llvm.org/show_bug.cgi?id=25557 Andrew V. Tischenko changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew V. Tischenko --- Finally, I found that it's a well know and old issue described here: Bug 17164 - do not allow implicit conversions between unrelated vector types Because of that I'll mark this bug as a duplicate of Bug 17164. *** This bug has been marked as a duplicate of bug 17164 *** -- 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 36190] New: Fix assertion for symbol-ordering-file + some linker scripts
https://bugs.llvm.org/show_bug.cgi?id=36190
Bug ID: 36190
Summary: Fix assertion for symbol-ordering-file + some linker
scripts
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: jh7370.2...@my.bristol.ac.uk
CC: llvm-bugs@lists.llvm.org
Regression caused by r323779. If --symbol-ordering-file is specified and a
linker script includes one more than one sub-command for any output section,
then LLD fires the following assertion:
Assertion failed: SectionCommands.size() == 1, file
C:\llvm\llvm\tools\lld\ELF\OutputSections.cpp, line 163
I will upload an example test extension to Phabricator to demonstrate. An
example script would be either of the following:
SECTIONS { .foo : { *(.foo); *(.foo.*) } }
SECTIONS { .foo : { BYTE(0x33); *(.foo); BYTE(0x44) } }
The sorting should be applied on each InputSectionDescription individually
within an OutputSection, and the sort() function should not assume only one
Command in an OutputSection.
--
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] Issue 5876 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-01 Type: Bug New issue 5876 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5876 Detailed report: https://oss-fuzz.com/testcase?key=5273888381468672 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::TargetRegisterInfo::getNoPreservedMask llvm::LiveIntervals::computeRegMasks Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5273888381468672 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36191] New: [X86][AVX512] Failure to fold broadcast into 'zmm' instruction for fake xmm/ymm (NoVLX) instructions
https://bugs.llvm.org/show_bug.cgi?id=36191
Bug ID: 36191
Summary: [X86][AVX512] Failure to fold broadcast into 'zmm'
instruction for fake xmm/ymm (NoVLX) instructions
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
zvi.racko...@intel.com
define <4 x i64> @mul_19(<4 x i64>) {
%2 = mul <4 x i64> %0,
ret <4 x i64> %2
}
Without AVX512VL, we cheat and perform many AVX512 xmm/ymm instructions on the
ZMM register. Unfortunately we fail to fold broadcast loads into these,
increasing register pressure:
llc -mattr=+avx512dq,+avx512vl
.LCPI0_0:
.quad 19 # 0x13
_Z6mul_19Dv4_x: # @_Z6mul_19Dv4_x
vpmullq .LCPI0_0(%rip){1to4}, %ymm0, %ymm0
retq
llc -mattr=+avx512dq
.LCPI0_0:
.quad 19 # 0x13
_Z6mul_19Dv4_x: # @_Z6mul_19Dv4_x
vpbroadcastq .LCPI0_0(%rip), %ymm1 # ymm1 = [19,19,19,19]
vpmullq %zmm1, %zmm0, %zmm0
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 36192] New: Assertion failed: Ill-formed basic block
https://bugs.llvm.org/show_bug.cgi?id=36192
Bug ID: 36192
Summary: Assertion failed: Ill-formed basic block
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: tras...@gmail.com
CC: llvm-bugs@lists.llvm.org
struct a {
template static void ad(b);
};
using ah = int;
template ai e(d, ai f, ac) {
try {
for (;; ++f)
a::ad(f);
} catch (...) {
}
return f;
}
template void g(d h, ai f, ac i) { e(h, f, i); }
int j, k, m;
class o {
public:
o(o &) try { g(j, 0, k); } catch (...) {
}
};
class p {
o c;
};
class {
public:
p &be(ah);
} l;
p n = l.be(m);
$ clang-cl /c /Z7 /O2 /EHsc test.cpp
Assertion failed: InsertionPt != Parent->end() && "Ill-formed basic block",
file ..\lib\Transforms\Utils\Local.cpp, line 1377
LLVMSymbolizer: error reading file: PDB Error: Unable to load PDB. Make sure
the file exists and is readable. Calling loadDataForExe
#6 0x7ff76da1f888 llvm::insertDebugValuesForPHIs(class llvm::BasicBlock
*,class llvm::SmallVectorImpl &)
transforms\utils\local.cpp:1378:0
#7 0x7ff76d9fa059 llvm::formLCSSAForInstructions(class
llvm::SmallVectorImpl &,class llvm::DominatorTree
&,class llvm::LoopInfo &) transforms\utils\lcssa.cpp:228:0
#8 0x7ff76d9f8814 llvm::formLCSSA(class llvm::Loop &,class
llvm::DominatorTree &,class llvm::LoopInfo *,class llvm::ScalarEvolution *)
transforms\utils\lcssa.cpp:324:0
#9 0x7ff76d9fa3e1 llvm::formLCSSARecursively(class llvm::Loop &,class
llvm::DominatorTree &,class llvm::LoopInfo *,class llvm::ScalarEvolution *)
transforms\utils\lcssa.cpp:348:0
#10 0x7ff76d9fa301 formLCSSAOnAllLoops transforms\utils\lcssa.cpp:355:0
#11 0x7ff76d4b657d llvm::FPPassManager::runOnFunction(class llvm::Function
&) ir\legacypassmanager.cpp:1520:0
#12 0x7ff76d183206 CGPassManager::RunPassOnSCC
analysis\callgraphsccpass.cpp:156:0
#13 0x7ff76d182f89 CGPassManager::RunAllPassesOnSCC
analysis\callgraphsccpass.cpp:423:0
#14 0x7ff76d183e69 CGPassManager::runOnModule
analysis\callgraphsccpass.cpp:479:0
#15 0x7ff76d4b69ef MPPassManager::runOnModule
ir\legacypassmanager.cpp:1597:0
#16 0x7ff76d4b5dfb llvm::legacy::PassManagerImpl::run(class llvm::Module &)
ir\legacypassmanager.cpp:1701:0
#17 0x7ff76dbd485e EmitAssemblyHelper::EmitAssembly
codegen\backendutil.cpp:802:0
#18 0x7ff76dbd63a1 clang::EmitBackendOutput(class clang::DiagnosticsEngine
&,class clang::HeaderSearchOptions const &,class clang::CodeGenOptions const
&,class clang::TargetOptions const &,class clang::LangOptions const &,class
llvm::DataLayout const &,class llvm::Module *,enum clang::BackendAction,class
std::unique_ptr >) codegen\backendutil.cpp:1184:0
#19 0x7ff76f4da92d clang::BackendConsumer::HandleTranslationUnit(class
clang::ASTContext &) codegen\codegenaction.cpp:296:0
#20 0x7ff76e6626b6 clang::ParseAST(class clang::Sema &,bool,bool)
clang version 7.0.0 (trunk 323966) (llvm/trunk 323965)
Target: x86_64-pc-windows-msvc
Thread model: posix
--
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 36193] New: LoadUnloadTestCase.test_lldb_process_load_and_unload_commands_dwarf fails when debugging from windows to android
https://bugs.llvm.org/show_bug.cgi?id=36193 Bug ID: 36193 Summary: LoadUnloadTestCase.test_lldb_process_load_and_unload_c ommands_dwarf fails when debugging from windows to android Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org This happens because the path in the "process load --install=" command is parsed as a host path, so we end up sending the file name to the target with backslashes and everything, and things go south from there. -- 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 36193] LoadUnloadTestCase.test_lldb_process_load_and_unload_commands_dwarf fails when debugging from windows to android
https://bugs.llvm.org/show_bug.cgi?id=36193 lab...@google.com changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from lab...@google.com --- Actually, this seems to be a duplicate of 25805. It's not clear to me why this started failing on some configurations only after the out-of-tree patch landed, but in any case, the root cause seems to be the same. *** This bug has been marked as a duplicate of bug 25805 *** -- 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 36194] New: SIGABRT on wasm disassemble
https://bugs.llvm.org/show_bug.cgi?id=36194 Bug ID: 36194 Summary: SIGABRT on wasm disassemble Product: tools Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: accounts-l...@holbrook.no CC: llvm-bugs@lists.llvm.org Created attachment 19792 --> https://bugs.llvm.org/attachment.cgi?id=19792&action=edit source and wasm binary wasm was generated with: wat2wasm then linked with: lld -flavor wasm Using release_60 branch with linux 4.14.15-1-ARCH wast sources and linked wasm attached. -- Error output: $ /mnt/data/src/llvm/llvm.org-llvm/build/bin/llvm-objdump a.wasm -d a.wasm: file format WASM Disassembly of section CODE: CODE: llvm-objdump: /mnt/data/src/llvm/llvm.org-llvm/include/llvm/ADT/ArrayRef.h:180: llvm::ArrayRef llvm::ArrayRef::slice(size_t, size_t) const [with T = unsigned char; size_t = long unsigned int]: Assertion `N+M <= size() && "Invalid specifier"' failed. #0 0x55d521951a2d llvm::sys::PrintStackTrace(llvm::raw_ostream&) /mnt/data/src/llvm/llvm.org-llvm/lib/Support/Unix/Signals.inc:398:0 #1 0x55d521951ac0 PrintStackTraceSignalHandler(void*) /mnt/data/src/llvm/llvm.org-llvm/lib/Support/Unix/Signals.inc:462:0 #2 0x55d52194fc95 llvm::sys::RunSignalHandlers() /mnt/data/src/llvm/llvm.org-llvm/lib/Support/Signals.cpp:49:0 #3 0x55d521951299 SignalHandler(int) /mnt/data/src/llvm/llvm.org-llvm/lib/Support/Unix/Signals.inc:252:0 #4 0x7fd72589bdd0 __restore_rt (/usr/lib/libpthread.so.0+0x11dd0) #5 0x7fd7243ce860 __GI_raise (/usr/lib/libc.so.6+0x34860) #6 0x7fd7243cfec9 __GI_abort (/usr/lib/libc.so.6+0x35ec9) #7 0x7fd7243c70bc __assert_fail_base (/usr/lib/libc.so.6+0x2d0bc) #8 0x7fd7243c7133 (/usr/lib/libc.so.6+0x2d133) #9 0x55d52135affa llvm::ArrayRef::slice(unsigned long, unsigned long) const /mnt/data/src/llvm/llvm.org-llvm/include/llvm/ADT/ArrayRef.h:180:0 #10 0x55d521348895 DisassembleObject(llvm::object::ObjectFile const*, bool) /mnt/data/src/llvm/llvm.org-llvm/tools/llvm-objdump/llvm-objdump.cpp:1595:0 #11 0x55d52134b5eb DumpObject(llvm::object::ObjectFile*, llvm::object::Archive const*) /mnt/data/src/llvm/llvm.org-llvm/tools/llvm-objdump/llvm-objdump.cpp:2050:0 #12 0x55d52134bfe9 DumpInput(llvm::StringRef) /mnt/data/src/llvm/llvm.org-llvm/tools/llvm-objdump/llvm-objdump.cpp:2140:0 #13 0x55d5213697b2 void (*std::for_each<__gnu_cxx::__normal_iterator, std::allocator >*, std::vector, std::allocator >, std::allocator, std::allocator > > > >, void (*)(llvm::StringRef)>(__gnu_cxx::__normal_iterator, std::allocator >*, std::vector, std::allocator >, std::allocator, std::allocator > > > >, __gnu_cxx::__normal_iterator, std::allocator >*, std::vector, std::allocator >, std::allocator, std::allocator > > > >, void (*)(llvm::StringRef)))(llvm::StringRef) /usr/include/c++/7.2.1/bits/stl_algo.h:3883:0 #14 0x55d521360266 void (*llvm::for_each, std::allocator >, bool, llvm::cl::parser, std::allocator > > >&, void (*)(llvm::StringRef)>(llvm::cl::list, std::allocator >, bool, llvm::cl::parser, std::allocator > > >&, void (*)(llvm::StringRef)))(llvm::StringRef) /mnt/data/src/llvm/llvm.org-llvm/include/llvm/ADT/STLExtras.h:808:0 #15 0x55d52134c6d2 main /mnt/data/src/llvm/llvm.org-llvm/tools/llvm-objdump/llvm-objdump.cpp:2202:0 #16 0x7fd7243baf4a __libc_start_main (/usr/lib/libc.so.6+0x20f4a) #17 0x55d5213410ba _start (/mnt/data/src/llvm/llvm.org-llvm/build/bin/llvm-objdump+0x34a0ba) Stack dump: 0. Program arguments: /mnt/data/src/llvm/llvm.org-llvm/build/bin/llvm-objdump a.wasm -d Aborted (core dumped) -- 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 36195] New: Assertion `!hasScalarValue(Key, Instance) && "Scalar value already set"' failed.
https://bugs.llvm.org/show_bug.cgi?id=36195
Bug ID: 36195
Summary: Assertion `!hasScalarValue(Key, Instance) && "Scalar
value already set"' failed.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: karl-johan.karls...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19793
--> https://bugs.llvm.org/attachment.cgi?id=19793&action=edit
llasm reproducer
Let's consider the following code (also attached):
@a = local_unnamed_addr global [4 x i16] zeroinitializer
@b = local_unnamed_addr global i32 0
; Function Attrs: norecurse nounwind
define void @f1() local_unnamed_addr {
store i32 0, i32* @b, align 1
br label %bb1
bb1: ; preds = %0, %bb1
%cse1.1.0 = phi i32 [ 0, %0 ], [ %_tmp13, %bb1 ]
%_tmp8 = and i32 %cse1.1.0, 65535
%1 = trunc i32 %cse1.1.0 to i16
%_tmp10 = getelementptr [4 x i16], [4 x i16]* @a, i16 0, i16 %1
store i16 1, i16* %_tmp10, align 1
%_tmp13 = add nuw nsw i32 %_tmp8, 1
%_tmp17 = trunc i32 %_tmp13 to i16
%_tmp19 = icmp ult i16 %_tmp17, 4
br i1 %_tmp19, label %bb1, label %bb3
bb3: ; preds = %bb1
store i32 4, i32* @b, align 1
ret void
}
Running the loop vectorizer on this input give this assert:
$ ./opt -mtriple=x86-linux -loop-vectorize -S -o /dev/null foo.ll
opt: ../lib/Transforms/Vectorize/VPlan.h:173: void
llvm::VectorizerValueMap::setScalarValue(llvm::Value *, const llvm::VPIteration
&, llvm::Value *): Assertion `!hasScalarValue(Key, Instance) && "Scalar value
already set"' failed.
#0 0x01ebe0f4 PrintStackTraceSignalHandler(void*) (./opt+0x1ebe0f4)
#1 0x01ebe866 SignalHandler(int) (./opt+0x1ebe866)
#2 0x7f9f2bbe2330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#3 0x7f9f2a7d1c37 gsignal
/build/eglibc-ripdx6/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#4 0x7f9f2a7d5028 abort
/build/eglibc-ripdx6/eglibc-2.19/stdlib/abort.c:91:0
#5 0x7f9f2a7cabf6 __assert_fail_base
/build/eglibc-ripdx6/eglibc-2.19/assert/assert.c:92:0
#6 0x7f9f2a7caca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#7 0x01fbc673 llvm::VectorizerValueMap::setScalarValue(llvm::Value*,
llvm::VPIteration const&, llvm::Value*) (./opt+0x1fbc673)
#8 0x01fbd443 llvm::InnerLoopVectorizer::buildScalarSteps(llvm::Value*,
llvm::Value*, llvm::Value*, llvm::InductionDescriptor const&) (./opt+0x1fbd443)
#9 0x01fbcf41
llvm::InnerLoopVectorizer::widenIntOrFpInduction(llvm::PHINode*,
llvm::TruncInst*) (./opt+0x1fbcf41)
#10 0x0202827e llvm::VPBasicBlock::execute(llvm::VPTransformState*)
(./opt+0x202827e)
#11 0x0202925d llvm::VPlan::execute(llvm::VPTransformState*)
(./opt+0x202925d)
#12 0x01fde247
llvm::LoopVectorizationPlanner::executePlan(llvm::InnerLoopVectorizer&,
llvm::DominatorTree*) (./opt+0x1fde247)
#13 0x01fe792d llvm::LoopVectorizePass::processLoop(llvm::Loop*)
(./opt+0x1fe792d)
#14 0x01fe99b3 llvm::LoopVectorizePass::runImpl(llvm::Function&,
llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&,
llvm::DominatorTree&, llvm::BlockFrequencyInfo&, llvm::TargetLibraryInfo*,
llvm::DemandedBits&, llvm::AAResults&, llvm::AssumptionCache&,
std::function&,
llvm::OptimizationRemarkEmitter&) (./opt+0x1fe99b3)
#15 0x01ff36cb (anonymous
namespace)::LoopVectorize::runOnFunction(llvm::Function&) (./opt+0x1ff36cb)
#16 0x01975598 llvm::FPPassManager::runOnFunction(llvm::Function&)
(./opt+0x1975598)
#17 0x019757d8 llvm::FPPassManager::runOnModule(llvm::Module&)
(./opt+0x19757d8)
#18 0x01975cb5 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(./opt+0x1975cb5)
#19 0x00729b63 main (./opt+0x729b63)
#20 0x7f9f2a7bcf45 __libc_start_main
/build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:321:0
#21 0x00714a0d _start (./opt+0x714a0d)
Stack dump:
0. Program arguments: ./opt -mtriple=x86-linux -loop-vectorize -S -o
/dev/null foo.ll
1. Running pass 'Function Pass Manager' on module 'foo.ll'.
2. Running pass 'Loop Vectorization' on function '@f1'
Aborted (core dumped)
--
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 36196] New: lld produces malformed PDB
https://bugs.llvm.org/show_bug.cgi?id=36196 Bug ID: 36196 Summary: lld produces malformed PDB Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: stefan.reinal...@molecular-matters.com CC: llvm-bugs@lists.llvm.org I wanted to investigate PDB files created by lld, but noticed that they seem to be malformed. If you run the attached PDB through Microsoft's DIA2Dump sample (part of the DIA SDK found under VSPATH/DIA SDK/Samples/DIA2Dump) using -all as command line argument, DIA2Dump will crash inside msdia140.dll with the following callstack: msdia140.dll!CLineByAddrTrav::nextMod(void) Unknown Non-user code. Symbols loaded. msdia140.dll!CLineByAddrTrav::next(void)Unknown Non-user code. Symbols loaded. msdia140.dll!CDiaEnumTraversal >::Next(unsigned long,struct IDiaLineNumber * *,unsigned long *) Unknown Non-user code. Symbols loaded. > Dia2Dump.exe!PrintLines(IDiaEnumLineNumbers * pLines) Line 2097 C++ > Symbols loaded. Dia2Dump.exe!PrintLines(IDiaSession * pSession, IDiaSymbol * pFunction) Line 2063 C++ Symbols loaded. Dia2Dump.exe!DumpAllLines(IDiaSession * pSession, IDiaSymbol * pGlobal) Line 1122 C++ Symbols loaded. Dia2Dump.exe!DumpAllPdbInfo(IDiaSession * pSession, IDiaSymbol * pGlobal) Line 718 C++ Symbols loaded. Dia2Dump.exe!wmain(int argc, wchar_t * * argv) Line 62 C++ Symbols loaded. Dia2Dump.exe!invoke_main() Line 90 C++ Non-user code. Symbols loaded. Dia2Dump.exe!__scrt_common_main_seh() Line 283 C++ Non-user code. Symbols loaded. Dia2Dump.exe!__scrt_common_main() Line 326 C++ Non-user code. Symbols loaded. Dia2Dump.exe!wmainCRTStartup() Line 17 C++ Non-user code. Symbols loaded. kernel32.dll!@BaseThreadInitThunk@12() Unknown Non-user code. Symbols loaded. ntdll.dll!__RtlUserThreadStart()Unknown Non-user code. Symbols loaded. ntdll.dll!__RtlUserThreadStart@8() Unknown Non-user code. Symbols loaded. -- 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 36197] New: Missing public symbols in PDB produced by lld
https://bugs.llvm.org/show_bug.cgi?id=36197 Bug ID: 36197 Summary: Missing public symbols in PDB produced by lld Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: stefan.reinal...@molecular-matters.com CC: llvm-bugs@lists.llvm.org The PDB file produced by lld seems to be missing the stream for public symbols, i.e. all symbols that have external linkage. Usually, those symbols are found in the PDB by their decorated/mangled name. The attached PDB was created using: clang-cl.exe -c -Z7 -MTd -o main.obj main.cpp clang-cl.exe -c -Z7 -MTd -o SimpleFunction.obj SimpleFunction.cpp lld-link.exe /libpath:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64" /libpath:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\ucrt\x64" /libpath:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x64" -debug main.obj SimpleFunction.obj -- 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 36198] New: PDB produced by lld doesn't store compiland environments
https://bugs.llvm.org/show_bug.cgi?id=36198 Bug ID: 36198 Summary: PDB produced by lld doesn't store compiland environments Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: stefan.reinal...@molecular-matters.com CC: llvm-bugs@lists.llvm.org At the moment, PDB files produced by lld do not contain compiland environment data stored with compilands. PDBs created by Microsoft's toolchain contain extra data known as "compiland environment" which stores info like the following for each compiland: CompilandEnv : obj = "C:\Development\Projects\LiveCode\Code\temp\Win32\Debug\ExeForDll\main.obj" CompilandDetails: Language: C++ Target processor: Pentium III Compiled for edit and continue: yes Compiled without debugging info: no Compiled with LTCG: no Compiled with /bzalign: no Managed code present: no Compiled with /GS: yes Compiled with /sdl: no Compiled with /hotpatch: yes Converted by CVTCIL: no MSIL module: no Frontend Version: Major = 19, Minor = 12, Build = 25834, QFE = 0 Backend Version: Major = 19, Minor = 12, Build = 25834, QFE = 0 Version string: Microsoft (R) Optimizing Compiler CompilandEnv : cwd = "C:\Development\Projects\LiveCode\Code\build" CompilandEnv : cl = "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX86\x86\CL.exe" CompilandEnv : cmd = "-c -ZI -nologo -W3 -WX- -diagnostics:classic -Od -Oy- -DWIN32 -D_DEBUG -D_CONSOLE -DIMPORT_FUNCTIONS_FROM_DLL -D_UNICODE -DUNICODE -Gm -EHs -EHc -RTC1 -MDd -GS -fp:precise -hotpatch -Zc:wchar_t -Zc:forScope -Zc:inline -FoC:\Development\Projects\LiveCode\Code\temp\Win32\Debug\ExeForDll\ -FdC:\Development\Projects\LiveCode\Code\temp\Win32\Debug\ExeForDll\vc141.pdb -Gd -TP -analyze- -errorreport:prompt -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\atlmfc\include" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\VS\include" -I"C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\VS\UnitTest\include" -I"C:\Program Files (x86)\Windows Kits\8.1\Include\um" -I"C:\Program Files (x86)\Windows Kits\8.1\Include\shared" -I"C:\Program Files (x86)\Windows Kits\8.1\Include\winrt" -X" CompilandEnv : src = "..\src\Tests\main.cpp" CompilandEnv : pdb = "C:\Development\Projects\LiveCode\Code\temp\Win32\Debug\ExeForDll\vc141.pdb" The compiland environment stores information like working directory, the compiler that built the .obj, the source file, PDB path. This information is really useful for certain tools and it would be nice if lld could also produce this extra information. The above output can be reproduced by using DIA2Dump on any PDB produced by Visual Studio. -- 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 36199] New: [SKX] fatal error: error in backend: "LLVM ERROR: Cannot select 0x*: v8f32 = bitcast 0x*"
https://bugs.llvm.org/show_bug.cgi?id=36199
Bug ID: 36199
Summary: [SKX] fatal error: error in backend: "LLVM ERROR:
Cannot select 0x*: v8f32 = bitcast 0x*"
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org
This test fails with "LLVM ERROR: Cannot select: 0x23f5068: v8f32 = bitcast
0x23f4848" in backend:
= nice.ll ==
define void @foo() unnamed_addr #0 {
%1 = fadd <16 x float> undef, undef
%bc256 = bitcast <16 x float> %1 to <4 x i128>
%2 = extractelement <4 x i128> %bc256, i32 0
%3 = bitcast i128 %2 to <4 x float>
%4 = shufflevector <4 x float> %3, <4 x float> undef, <16 x i32>
store <16 x float> %4, <16 x float>* undef, align 4
ret void
}
attributes #0 = { nounwind uwtable "target-cpu"="skylake-avx512"}
===
>>> clang -v
clang version 7.0.0 (trunk 323949)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
>>> llc nice.ll
LLVM ERROR: Cannot select: 0x36f84a8: v8f32 = bitcast 0x36f7c88
0x36f7c88: v16f32 = fadd undef:v16f32, undef:v16f32
0x36f7c20: v16f32 = undef
0x36f7c20: v16f32 = undef
In function: foo
--
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 36200] New: [Formatter/ObjC] Formatter incorrectly pulls selector component to previous line if parenthesized ternary is present
https://bugs.llvm.org/show_bug.cgi?id=36200
Bug ID: 36200
Summary: [Formatter/ObjC] Formatter incorrectly pulls selector
component to previous line if parenthesized ternary is
present
Product: clang
Version: trunk
Hardware: Macintosh
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: bhamilto...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
% cat test-objc-ternary-parens.m
[objc methodCall:foo
arg1:(a ? b : c)
arg2:anotherArg];
% clang-format -style="{BasedOnStyle: llvm, ColumnLimit: 40}"
test-objc-ternary-parens.m
[objc methodCall:foo
arg1:(a ? b : c)arg2
:anotherArg];
% cat test-objc-ternary-no-parens.m
[objc methodCall:foo
arg1:a ? b : c
arg2:anotherArg];
% clang-format -style="{BasedOnStyle: llvm, ColumnLimit: 40}"
test-objc-ternary-no-parens.m
[objc methodCall:foo
arg1:a ? b : c
arg2:anotherArg];
--
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 36190] Fix assertion for symbol-ordering-file + some linker scripts
https://bugs.llvm.org/show_bug.cgi?id=36190 Rafael Ávila de Espíndola changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Rafael Ávila de Espíndola --- r323993 -- 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 36157] Crash when building .c file containing C++ code
https://bugs.llvm.org/show_bug.cgi?id=36157
Richard Smith changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Richard Smith ---
Reduced to a rejects-valid:
struct A { int n : 1 ? 1 : f(); };
(Well, valid-ish, C89 is not entirely clear about what such code would mean.)
Fixed in r323998.
--
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 36103] LLVM overwrites spilled xmm registers in crash handler
https://bugs.llvm.org/show_bug.cgi?id=36103 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Reid Kleckner --- *** This bug has been marked as a duplicate of bug 32507 *** -- 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 36068] [PowerPC] VSX splat instruction bug (xxspltw)
https://bugs.llvm.org/show_bug.cgi?id=36068 Nemanja Ivanovic changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Nemanja Ivanovic --- Committed revision 324005. -- 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 36201] New: [X86] Replace kortest intrinsic with icmp+bitcast+or emitted from clang
https://bugs.llvm.org/show_bug.cgi?id=36201 Bug ID: 36201 Summary: [X86] Replace kortest intrinsic with icmp+bitcast+or emitted from clang Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: llvm-bugs@lists.llvm.org Once D42772 and D42817 are commited, we should be able to directly emit KORTEST in IR by using an vXi1 or, bitcasted to scalar, and then compare to -1 or 0 depending on whether its the C or Z builtin. -- 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 36202] New: llvm-mc doesn't accept AVX512 instructions using %zmm16+
https://bugs.llvm.org/show_bug.cgi?id=36202 Bug ID: 36202 Summary: llvm-mc doesn't accept AVX512 instructions using %zmm16+ Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: benny@gmail.com CC: llvm-bugs@lists.llvm.org $ echo vpaddd %zmm1, %zmm2, %zmm3 | llvm-mc .text vpaddd %zmm1, %zmm2, %zmm3 $ echo vpaddd %zmm16, %zmm17, %zmm18 | llvm-mc .text :1:8: error: register %zmm16 is only available with AVX512 It does accept them with -mcpu=skx, but it should always accept them. -- 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 36203] New: lld may create duplicate .build-id's
https://bugs.llvm.org/show_bug.cgi?id=36203 Bug ID: 36203 Summary: lld may create duplicate .build-id's Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org If a build-id is included in an input object file, lld may adds a new one, and as a result, the output contains more than one .build-id. Most tools don't expect such executables and don't work well. This is a test case to create an executable with two .build-id's. We probably should strip .build-id sections from input files if --build-id is specified. # REQUIRES: x86 # RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t1.o # RUN: ld.lld --build-id=0xcafebabe -o %t2.o %t1.o # RUN: ld.lld --build-id=0xdeadbeef -o %t.exe %t2.o # RUN: llvm-objdump -s %t.exe | FileCheck %s # CHECK-NOT: cafebabe .global _start _start: ret -- 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] Issue 5884 in oss-fuzz: llvm: Stack-overflow in maybeDiagnoseUTF8Homoglyph
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-01 Type: Bug New issue 5884 by ClusterFuzz-External: llvm: Stack-overflow in maybeDiagnoseUTF8Homoglyph https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5884 Detailed report: https://oss-fuzz.com/testcase?key=5495354209337344 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc84ffbff8 Crash State: maybeDiagnoseUTF8Homoglyph clang::Lexer::LexTokenInternal clang::Lexer::Lex Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801310659:201802010703 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5495354209337344 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 22101] At -O2, debug info says variable has constant value
https://bugs.llvm.org/show_bug.cgi?id=22101 Matt Davis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||matthew.da...@sony.com --- Comment #2 from Matt Davis --- This seems to be resolved, closing this out. It seems that a recent change, perhaps r323570, was the fix. I was looking at a similar issue. Around the time the aforementioned patch went into play, this issue seemed to be 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 36204] New: Cherry pick r324039 to 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=36204 Bug ID: 36204 Summary: Cherry pick r324039 to 6.0 branch Product: libraries Version: 4.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org r324039 fixes a register allocation bug that could in principle hit anyone (though you probably need some unusually large code to hit it). This should be low risk and fixes a compiler bug so I think we should pick it for the 6.0 branch. Reviewed by Quentin in https://reviews.llvm.org/D42667. -- 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 36149] Assertion failure in clang::ento::MemRegion::getAsOffset
https://bugs.llvm.org/show_bug.cgi?id=36149 George Karpenkov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from George Karpenkov --- Fixed in trunk -- 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 35146] dllexported classes don't emit typeinfo (often enough) in the itanium ABI
https://bugs.llvm.org/show_bug.cgi?id=35146 Martin Storsjö changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Martin Storsjö --- The actual root cause (not being able to build Qt as DLLs) has been fixed in SVN r324059, thus resolving it. The other difference to GCC that I originally minimized the issue down to still remains but doesn't seem to cause problems in building Qt yet/right now at least. -- 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
