[llvm-bugs] Issue 10372 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: ASSERT: (Data.getAddressSize() == 4 || Data.getAddressSize() == 8) && "Unsupported addre
Comment #2 on issue 10372 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: ASSERT: (Data.getAddressSize() == 4 || Data.getAddressSize() == 8) && "Unsupported addre https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10372#c2 ClusterFuzz has detected this issue as fixed in range 201809170127:201809180128. Detailed report: https://oss-fuzz.com/testcase?key=5654450669092864 Project: llvm Fuzzer: libFuzzer_llvm_llvm-dwarfdump-fuzzer Fuzz target binary: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (Data.getAddressSize() == 4 || Data.getAddressSize() == 8) && "Unsupported addre llvm::RangeListEntry::extract llvm::DWARFListType::extract Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201809140127:201809150126 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201809170127:201809180128 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5654450669092864 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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] Issue 10372 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: ASSERT: (Data.getAddressSize() == 4 || Data.getAddressSize() == 8) && "Unsupported addre
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 10372 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: ASSERT: (Data.getAddressSize() == 4 || Data.getAddressSize() == 8) && "Unsupported addre https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10372#c3 ClusterFuzz testcase 5654450669092864 is verified as fixed, so closing issue as verified. 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] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #2 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c2 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-ed29db63-40b1-44a3-a3b1-51b8c4e6699a.txt -- 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 38982] New: clang crashes on valid code at -O1 and above on x86_64-linux-gnu while running pass 'Early GVN Hoisting of Expressions'
https://bugs.llvm.org/show_bug.cgi?id=38982 Bug ID: 38982 Summary: clang crashes on valid code at -O1 and above on x86_64-linux-gnu while running pass 'Early GVN Hoisting of Expressions' Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Tested with trunk revision 342457. $ clangpolly -v clang version 8.0.0 (http://llvm.org/git/clang.git 0c965af23bb73e9da25306503ff6f6e92817fa60) (http://llvm.org/git/llvm.git 0a5be7e8d363bebccce1d73696508598c8fa9423) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/su/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clangpolly -O0 -c small.c $ $ clangpolly -O1 -c small.c Stack dump: 0. Program arguments: /home/su/software/tmp/polly/llvm_build/bin/clang-6.0 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -coverage-notes-file /home/su/small.gcno -resource-dir /home/su/software/tmp/polly/llvm_build/lib/clang/8.0.0 -internal-isystem /usr/local/include -internal-isystem /home/su/software/tmp/polly/llvm_build/lib/clang/8.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O1 -fdebug-compilation-dir /home/su -ferror-limit 19 -fmessage-length 127 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c -faddrsig 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Early GVN Hoisting of Expressions' on function '@g' #0 0x0245b40a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0x245b40a) #1 0x024597ac llvm::sys::RunSignalHandlers() (/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0x24597ac) #2 0x02459917 SignalHandler(int) (/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0x2459917) #3 0x7f3fc6b88390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x041ac356 llvm::MemorySSAUpdater::getPreviousDefRecursive(llvm::BasicBlock*, llvm::DenseMap, llvm::DenseMapInfo, llvm::detail::DenseMapPair > >&) (/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0x41ac356) #5 0x041ac37b llvm::MemorySSAUpdater::getPreviousDefRecursive(llvm::BasicBlock*, llvm::DenseMap, llvm::DenseMapInfo, llvm::detail::DenseMapPair > >&) (/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0x41ac37b) #6 0x041ac37b llvm::MemorySSAUpdater::getPreviousDefRecursive(llvm::BasicBlock*, llvm::DenseMap, llvm::DenseMapInfo, llvm::detail::DenseMapPair > >&) (/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0x41ac37b) ... #254 0x041ac37b llvm::MemorySSAUpdater::getPreviousDefRecursive(llvm::BasicBlock*, llvm::DenseMap, llvm::DenseMapInfo, llvm::detail::DenseMapPair > >&) (/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0x41ac37b) #255 0x041ac37b llvm::MemorySSAUpdater::getPreviousDefRecursive(llvm::BasicBlock*, llvm::DenseMap, llvm::DenseMapInfo, llvm::detail::DenseMapPair > >&) (
[llvm-bugs] [Bug 38983] New: Spurious interaction between noexcept specs. for move/copy assignment
https://bugs.llvm.org/show_bug.cgi?id=38983
Bug ID: 38983
Summary: Spurious interaction between noexcept specs. for
move/copy assignment
Product: clang
Version: unspecified
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: oliver.ros...@googlemail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The following (contrived) code appears to indicate a spurious dependency
between the exception specifications for the move/copy assignment operators.
template
class wrapper
{
T& m_Ref;
// Reported problem disappears if reference_wrapper is used instead
public:
wrapper(T& ref) : m_Ref{ref} {}
wrapper(const wrapper&)= default;
wrapper(wrapper&&) noexcept = default;
wrapper& operator=(const wrapper&) noexcept(false){}
// 'false' required to reveal bug;
//removing false fixes compilation
wrapper& operator=(wrapper&&) noexcept = default;
};
template
class thing
{
private:
W m_Member{};
public:
thing(T& ref) : m_Member{ref} {}
thing(const thing&) = default;
thing(thing&&) = default;
thing& operator=(const thing&) = default;
thing& operator=(thing&&) noexcept = default;
};
int x{5};
wrapper w{x}; // fine
thing> foo{x};
Compiler error message:
exception specification of
explicitly defaulted move assignment operator does not match the
calculated one
thing& operator=(thing&&) noexcept = default;
The last line of code fails to compile due to the exception spec of the *move*
assignment operator not matching the calculated one.
Compilation may be fixed by changing the exception spec. of the *copy*
assignment operator.
--
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 38984] New: InstCombine assertion at vector gep/icmp folding
https://bugs.llvm.org/show_bug.cgi?id=38984 Bug ID: 38984 Summary: InstCombine assertion at vector gep/icmp folding Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jesper.antons...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 20886 --> https://bugs.llvm.org/attachment.cgi?id=20886&action=edit reduced reproducer The attached IR fails with: opt: ../lib/IR/Value.cpp:413: void llvm::Value::doRAUW(llvm::Value *, llvm::Value::ReplaceMetadataUses): Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed. when invoking: opt -instcombine -S addr_diff_reduced.ll The reason is that InstCombiner::foldGEPICmp() sees a vector icmp that it knows to be all true and tries to replace it with an i1 true 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 38839] omp_lib.h can't be included by many compilers due to lines too long
https://bugs.llvm.org/show_bug.cgi?id=38839 Andrey Churbanov changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||https://reviews.llvm.org/rL ||341653 --- Comment #2 from Andrey Churbanov --- Fixed by commit rL341653 -- 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 38985] New: lld-link does not work with VS integration if vcpkg is installed.
https://bugs.llvm.org/show_bug.cgi?id=38985 Bug ID: 38985 Summary: lld-link does not work with VS integration if vcpkg is installed. Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: ztur...@google.com Reporter: ztur...@google.com CC: llvm-bugs@lists.llvm.org If you install vcpkg from here: https://github.com/Microsoft/vcpkg And run `vcpkg integrate install` from a command prompt, then the LLVM VS integration stops working with this error message: C:\src\vcpkg\installed\x64...\lib\*.lib: invalid argument error. The error seems to be coming from this file: c:\src\vcpkg\scripts\buildsystems\msbuild\vcpkg.targets %(AdditionalDependencies);$(VcpkgRoot)debug\lib\*.lib If you set the MSBuild project output verbosity to diagnostic level and get the lld-link.exe command line it's running and then paste that into a command prompt, it appears to work, so this appears to be an MSBuild issue. But perhaps there's a workaround we can submit in lld, or alternatively maybe we can fix MSBuild and/or vcpkg. This was reported by user henrik@ on IRC. -- 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 36036] [DAGCombine] Failure to recognise alternative ISD::ABS pattern
https://bugs.llvm.org/show_bug.cgi?id=36036 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Simon Pilgrim --- 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 38849] Redundant Restore of $x0 when memcpy always returns the first argument.
https://bugs.llvm.org/show_bug.cgi?id=38849
Evandro Menezes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #1 from Evandro Menezes ---
It seems that the problem is that the return value from memcpy() is cast to
void*:
%struct.BigStruct = type { [64 x i32] }
define dso_local void @_Z17callStructByValueii9BigStruct(i32 %unused, i32
%unused2, %struct.BigStruct* nocapture readonly %s) local_unnamed_addr #0 {
entry:
%agg.tmp = alloca %struct.BigStruct, align 4
%0 = bitcast %struct.BigStruct* %agg.tmp to i8*
%1 = bitcast %struct.BigStruct* %s to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* nonnull align 4 %0, i8* align 4 %1,
i64 256, i1 false), !tbaa.struct !2
call void @_Z13structByValue9BigStruct(%struct.BigStruct* nonnull %agg.tmp)
ret void
}
--
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 36009] Setting VFP Flag on ELF binaries
https://bugs.llvm.org/show_bug.cgi?id=36009 ema...@freebsd.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from ema...@freebsd.org --- Work committed by Peter Smith, imported into FreeBSD and verified 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 23214] [META] Using LLD as FreeBSD's system linker
https://bugs.llvm.org/show_bug.cgi?id=23214 Bug 23214 depends on bug 36009, which changed state. Bug 36009 Summary: Setting VFP Flag on ELF binaries https://bugs.llvm.org/show_bug.cgi?id=36009 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 38986] New: Poor code generation for masked scalar store
https://bugs.llvm.org/show_bug.cgi?id=38986
Bug ID: 38986
Summary: Poor code generation for masked scalar store
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org
We allow the spelling of predicated scalar stores using the masked.load
intrinsic (by loading a <1 x Y> vector>), but the code generation for such is
terrible. The odd part is the terrible bits don't appear length specific.
$ cat masked-scalar.ll
declare <1 x i32> @llvm.masked.load.v1i32.p0v1i32 (<1 x i32>*, i32, <1 x i1>,
<1 x i32>)
define i32 @test(i1 %c, i32* %p) {
%vc = insertelement <1 x i1> undef, i1 %c, i32 0
%vp = bitcast i32* %p to <1 x i32>*
%L = call <1 x i32> @llvm.masked.load.v1i32.p0v1i32 (<1 x i32>* %vp, i32 4, <1
x i1> %vc, <1 x i32> undef)
%ret = bitcast <1 x i32> %L to i32
ret i32 %ret
}
define i32 @test2(i1 %c, i32* %p) {
br i1 %c, label %taken, label %untaken
taken:
%v = load i32, i32* %p
ret i32 %v
untaken:
ret i32 undef
}
$ ../build/bin/opt -O3 -S masked-scalar.ll | ../build/bin/llc -O3 -mcpu=skylake
.text
.file "masked-scalar.ll"
.globl test# -- Begin function test
.p2align4, 0x90
.type test,@function
test: # @test
# %bb.0:
andb$1, %dil
movl%edi, %eax
negb%al
# implicit-def: $ecx
testb %dil, %dil
jne .LBB0_1
# %bb.2:# %else
testb $1, %al
cmovnel %ecx, %eax
retq
.LBB0_1:# %cond.load
movl(%rsi), %ecx
testb $1, %al
cmovnel %ecx, %eax
retq
.Lfunc_end0:
.size test, .Lfunc_end0-test
# -- End function
.globl test2 # -- Begin function test2
.p2align4, 0x90
.type test2,@function
test2: # @test2
# %bb.0:
testb $1, %dil
# implicit-def: $eax
# implicit-def: $ax
# implicit-def: $al
# implicit-def: $ah
# implicit-def: $hax
je .LBB1_2
# %bb.1:# %taken
movl(%rsi), %eax
.LBB1_2:# %untaken
retq
.Lfunc_end1:
.size test2, .Lfunc_end1-test2
# -- End function
.section".note.GNU-stack","",@progbits
Observations:
1) We should be able to use a simple test/je for the i1 vector test.
2) We don't need the cmovs at all since we're selecting with undef.
--
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 38987] New: Crash in coverage build: error in backend: File exit not handled before popRegions
https://bugs.llvm.org/show_bug.cgi?id=38987 Bug ID: 38987 Summary: Crash in coverage build: error in backend: File exit not handled before popRegions Product: clang Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: mellery...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org compiler is crashing during coverage build. FAILED: ccache /usr/bin/clang++ -DBEAST_CHECK_MEMORY_LEAKS=0 -DBOOST_ASIO_DISABLE_HANDLER_TYPE_REQUIREMENTS -DBOOST_ASIO_HAS_STD_ARRAY -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_COROUTINES_NO_DEPRECATION_WARNING -DBOOST_FILESYSTEM_DEPRECATED -DBOOST_NO_AUTO_PTR -DDEBUG -DLIBARCHIVE_STATIC -DOPENSSL_NO_SSL2 -DOS_LINUX -DRIPPLE_DUMP_LEAKS_ON_EXIT=1 -DRIPPLE_ROCKSDB_AVAILABLE=1 -DROCKSDB_LIB_IO_POSIX -DROCKSDB_PLATFORM_POSIX -DSNAPPY -DSOCI_HAVE_CXX_C11=1 -D_DEBUG -I../../src -Ilz4/include -Isqlite3/include -I../../src/soci/src -I../../src/soci/include -I../../src/sqlite -I../../ -I../../src/snappy/snappy -I../../src/snappy/config -I../../src/rocksdb2/include -I../../src/nudb/include -I../../src/ripple -I../../src/beast/extras -isystem /usr/local/include -isystem ../../.nih_c/ninja/Clang_7.0.0/src/libarchive/libarchive -isystem /opt/boost_1_67_0 -isystem proto_gen -Wall -Wdeprecated -g -fPIE -Werror -frtti -Wnon-virtual-dtor -Wno-sign-compare -Wno-char-subscripts -Wno-format -Wno-unused-local-typedefs -O0 -fprofile-instr-generate -fcoverage-mapping -pthread --system-header-prefix=rocksdb2 -std=gnu++14 -MD -MT CMakeFiles/rippled.dir/src/ripple/app/consensus/RCLConsensus.cpp.o -MF CMakeFiles/rippled.dir/src/ripple/app/consensus/RCLConsensus.cpp.o.d -o CMakeFiles/rippled.dir/src/ripple/app/consensus/RCLConsensus.cpp.o -c ../../src/ripple/app/consensus/RCLConsensus.cpp fatal error: error in backend: File exit not handled before popRegions clang: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 7.0.0-svn341916-1~exp1~20180911120538.25 (branches/release_70) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/RCLConsensus-9c88e7.cpp clang: note: diagnostic msg: /tmp/RCLConsensus-9c88e7.sh clang: note: diagnostic msg: -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38988] New: Failure to thread extractelement through phi w/undef
https://bugs.llvm.org/show_bug.cgi?id=38988
Bug ID: 38988
Summary: Failure to thread extractelement through phi w/undef
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org
$cat test.ll
define i32 @test(i1 %c, i32* nocapture readonly %p) {
br i1 %c, label %cond.load, label %else
cond.load:; preds = %0
%1 = load i32, i32* %p, align 4
%2 = insertelement <1 x i32> undef, i32 %1, i32 0
br label %else
else: ; preds = %0, %cond.load
%res.phi.select = phi <1 x i32> [ %2, %cond.load ], [ undef, %0 ]
%3 = extractelement <1 x i32> %res.phi.select, i32 0
ret i32 %3
}
$opt -O3 test.ll -S
(same as input)
We should be producing:
define i32 @test(i1 %c, i32* nocapture readonly %p) {
br i1 %c, label %cond.load, label %else
cond.load:
%1 = load i32, i32* %p, align 4
br label %else
else:
%ret = phi i32 [%1, %cond.load], [undef, %0]
ret i32 %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] [Bug 38989] New: LICM behaves differently if multiple functions are present.
https://bugs.llvm.org/show_bug.cgi?id=38989
Bug ID: 38989
Summary: LICM behaves differently if multiple functions are
present.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: alina.sbir...@gmail.com
CC: llvm-bugs@lists.llvm.org
Pulling test12 out of sinking.ll into a separate file makes it behave
differently. The store is hoisted all the way out.
The test in question:
; RUN: opt < %s -basicaa -licm -S | FileCheck %s
; Can't sink stores out of exit blocks containing indirectbr instructions
; because loop simplify does not create dedicated exits for such blocks. Test
; that by sinking the store from lab21 to lab22, but not further.
define void @test12() {
; CHECK-LABEL: @test12
br label %lab4
lab4:
br label %lab20
lab5:
br label %lab20
lab6:
br label %lab4
lab7:
br i1 undef, label %lab8, label %lab13
lab8:
br i1 undef, label %lab13, label %lab10
lab10:
br label %lab7
lab13:
ret void
lab20:
br label %lab21
lab21:
; CHECK: lab21:
; CHECK-NOT: store
; CHECK: br i1 false, label %lab21, label %lab22
store i32 36127957, i32* undef, align 4
br i1 undef, label %lab21, label %lab22
lab22:
; CHECK: lab22:
; CHECK: store
; CHECK-NEXT: indirectbr i8* undef
indirectbr i8* undef, [label %lab5, label %lab6, label %lab7]
}
More strange is that if I paste the test twice (change method name), it behaves
like before (i.e. store sunk to lab22 only).
So there is some info/analysis that's not reset properly and leaks between the
processing of two separate functions.
Cause is between r340927-r341031.
--
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 38990] New: llvm-dwarfdump doesn't apply Split DWARF cu_index for debug_loc.dwo
https://bugs.llvm.org/show_bug.cgi?id=38990
Bug ID: 38990
Summary: llvm-dwarfdump doesn't apply Split DWARF cu_index for
debug_loc.dwo
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: wolfgang_p...@playstation.sony.com
Reporter: dblai...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20888
--> https://bugs.llvm.org/attachment.cgi?id=20888&action=edit
Incomplete patch
Dumping large dwps produces a bunch of parse failures on debug_loc because the
cu_index entry for debug_loc is not accounted for when parsing the debug_loc
section.
While this example doesn't produce the error message, it does show the bug:
a.cpp:
void y();
void a(int i) {
y();
asm("" : : : "rdi");
}
b.cpp:
void b(int i) { asm("" : : : "rdi"); }
$ clang++-tot -gsplit-dwarf a.cpp b.cpp -c -O1 && llvm-dwp a.dwo b.dwo -o
ab.dwp && llvm-dwarfdump-tot ab.dwp | grep RDI
Addr idx 0 (w/ length 6): DW_OP_reg5 RDI)
Addr idx 0 (w/ length 6): DW_OP_reg5 RDI)
But run each .dwo file individually through dwarfdump:
$ llvm-dwarfdump-tot a.dwo b.dwo | grep RDI
Addr idx 0 (w/ length 6): DW_OP_reg5 RDI)
Addr idx 0 (w/ length 0): DW_OP_reg5 RDI)
Note the difference in length of these location list entries. This shows that
when dumping b.cpp's CU in ab.dwp, it's reading a.cpp's location list instead
of b.cpp's.
I've attached half a patch that was meant to start plumbing this through. It
isn't quite tied into the actual index lookup/offset yet - in part because of
some issues with the design there, that I'll file in a separate couple of bugs.
There's some other cleanup in this patch too - welcome to commit those parts,
or undo them, etc.
--
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 38991] New: llvm-dwarfdump doesn't dump contents of debug_loc.dwo
https://bugs.llvm.org/show_bug.cgi?id=38991
Bug ID: 38991
Summary: llvm-dwarfdump doesn't dump contents of debug_loc.dwo
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: dblai...@gmail.com
CC: llvm-bugs@lists.llvm.org
take a .dwo file and llvm-dwarfdump -debug-loc and it won't print the
debug_loc.dwo section. Even if you also pass -debug-info to ensure that it
dumps both, or that the info section is parsed so that the loc section can be
parsed (if it's contingent like that - as some of the sections are). Even
though this works with a .o file, even with only -debug-loc.
For a short example with a loc list:
void a(int i) { asm("" : : : "rdi"); }
--
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 38992] New: Crash on ill-formed deduction guide in c++17 mode
https://bugs.llvm.org/show_bug.cgi?id=38992
Bug ID: 38992
Summary: Crash on ill-formed deduction guide in c++17 mode
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: rtr...@google.com
CC: llvm-bugs@lists.llvm.org
$ cat crash.cc
template < int > class b {};
struct S {
b();
};
$ clang -std=c++17 crash.cc
crash.cc:3:3: error: deduction guide must be declared in the same scope as
template 'b'
b();
^
crash.cc:1:24: note: template is declared here
template < int > class b {};
^
crash.cc:3:3: error: deduction guide declaration without trailing return type
b();
^
crash.cc:3:3: error: deduction guide has different access from the
corresponding
member template
crash.cc:1:1: note: member template declared (null) here
template < int > class b {};
^
Stack dump:
...
#4 clang::Sema::ActOnCXXMemberDeclarator(clang::Scope*, clang::AccessSpecifier,
clang::Declarator&, llvm::MutableArrayRef,
clang::Expr*, clang::VirtSpecifiers const&, clang::InClassInitStyle)
#5 clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*)
#6
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType,
clang::Decl*)
#7 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int,
clang::Decl*)
#8 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&)
#9 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
--
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
