[llvm-bugs] [Bug 48596] New: [AMDGPU][MC] Insufficient diagnostic messages for invalid v_interp operands
https://bugs.llvm.org/show_bug.cgi?id=48596 Bug ID: 48596 Summary: [AMDGPU][MC] Insufficient diagnostic messages for invalid v_interp operands Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Invalid interpretation slots, attributes and channels result in "failed parsing operand" or "invalid operand for instruction" error messages. These messages should be more specific. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48597] New: [AMDGPU][MC][GFX8+] VOP3 v_interp incorrectly handles constants and literals
https://bugs.llvm.org/show_bug.cgi?id=48597 Bug ID: 48597 Summary: [AMDGPU][MC][GFX8+] VOP3 v_interp incorrectly handles constants and literals Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org VOP3 INTERP instructions with src3 being a constant or a literal result in /*invalid immediate*/. Examples: v_interp_p2_f16 v5, v2, attr0.x, 0 v_interp_p2_f16 v5, v2, attr0.x, 1 v_interp_p2_f16 v5, v2, attr0.x, 1234 v_interp_p2_f16 v5, v2, attr0.x, 1.0 These instructions are assembled fine but operands cannot be printed: v_interp_p2_f16 v5, v2, attr0.x, /*invalid immediate*/ v_interp_p2_f16 v5, v2, attr0.x, /*invalid immediate*/ v_interp_p2_f16 v5, v2, attr0.x, /*invalid immediate*/ v_interp_p2_f16 v5, v2, attr0.x, /*invalid immediate*/ VOP3 INTERP instructions with src1 being a constant or a literal result in an exception. An example of failed test: v_interp_p2_f16 v5, 0, attr0.x, v0 Note that sp3 does not allow constants and literals for src operands of these instructions. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48598] New: Incorrect overload resolution when performing direct initialization
https://bugs.llvm.org/show_bug.cgi?id=48598
Bug ID: 48598
Summary: Incorrect overload resolution when performing direct
initialization
Product: clang
Version: 11.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: ka...@mail.ru
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Consider direct initialization of an object of type B with an lvalue of type A
as an initializer. The following example compiles successfully as C++14 but
fails to compile as C++17 (https://godbolt.org/z/dhs3Wv):
---
struct A;
struct B
{
B(const A&) { }
B(const B&) { }
};
struct A
{
operator B () = delete;
};
int main()
{
A a;
B&& b = B(a);
}
---
In C++17 mode clang reports the access to deleted operator and presents a list
of candidate functions:
---
:17:13: error: functional-style cast from 'A' to 'B' uses deleted
function
B&& b = B(a);
^~~
:11:5: note: candidate function has been explicitly deleted
operator B () = delete;
^
:5:5: note: candidate constructor
B(const A&) { }
^
:6:5: note: candidate constructor
B(const B&) { }
^
---
According to [over.match.ctor]:
"When objects of class type are direct-initialized, ..., overload resolution
selects the constructor. For direct-initialization ... the candidate functions
are all the constructors of the class of the object being initialized".
Therefore, the operator in the above example should not be included in the
candidate list. When considering constructors, the first one (taking const A&)
should win, since it doesn't require user-defined conversion.
A similar problem occurs when using an rvalue of type A as an initializer.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48599] New: -memcpyopt moves alloca struct load past stackrestore
https://bugs.llvm.org/show_bug.cgi?id=48599
Bug ID: 48599
Summary: -memcpyopt moves alloca struct load past stackrestore
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: default_357-f...@yahoo.de
CC: llvm-bugs@lists.llvm.org
See https://godbolt.org/z/38nqh6
Consider the following IR:
declare i8* @llvm.stacksave()
declare void @llvm.stackrestore(i8*)
declare i8* @xmalloc(i64)
define i8* @bug() {
%stack = tail call i8* @llvm.stacksave()
%alloc = alloca { i64 }, align 8
%v0 = insertvalue { i64 } undef, i64 1, 0
store { i64 } %v0, { i64 }* %alloc, align 8
; load before restoring stack
%loaded = load { i64 }, { i64 }* %alloc, align 8
tail call void @llvm.stackrestore(i8* %stack)
%mem = tail call i8* @xmalloc(i64 8)
%mem.i64x1 = bitcast i8* %mem to { i64 }*
; loading %alloc here would no longer be valid!
store { i64 } %loaded, { i64 }* %mem.i64x1, align 8
ret i8* %mem
}
When passed to `opt -memcpyopt` on trunk of Dec-25-2020, this "optimizes" the
load followed by store into a memcpy. However, the memcpy is placed after the
stackrestore, leading to it reading stack memory that is no longer valid.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23067] Alias analysis fails to recognize non-zero variable offset
https://bugs.llvm.org/show_bug.cgi?id=23067 Nikita Popov changed: What|Removed |Added CC||nikita@gmail.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Nikita Popov --- We were pretty close to handling this already. With https://github.com/llvm/llvm-project/commit/35676a4f9a536a2aab768af63ddbb15bc722d7f9 and https://github.com/llvm/llvm-project/commit/c795dd19265d80e835ea1137f19f73624d7983e4 BasicAA realizes that these don't alias and the load/store get eliminated. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48600] New: Since version 3.8 calling `std::string::insert` with three `int`s is ambiguous
https://bugs.llvm.org/show_bug.cgi?id=48600 Bug ID: 48600 Summary: Since version 3.8 calling `std::string::insert` with three `int`s is ambiguous Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: boris.stale...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Here's a godbolt link: https://godbolt.org/z/7K5vhh Calling `str.insert(0, 1, 0);` is ambiguous because it can be interpreted in two ways: 1. `insert(size_t pos, size_t count, char value);` 2. `insert(const char*, InputIt, InputIt);` The first `0` argument does indeed equally match `size_t` and `const char*`, but `1` shouldn't be matching `InputIt` according to the standard: https://eel.is/c++draft/string.insert#21 However, libc++ relaxes this constraint with [`__libcpp_string_gets_noexcept_iterator`](https://github.com/llvm/llvm-project/blob/3696227c10f5e5841223c2a2fb63fdd1d50a7930/libcxx/include/string#L1165-L1170). The commit that introduced this relaxation seems to be https://github.com/llvm/llvm-project/commit/76b4afc04051298081c2f46056138b4013c2f49d#diff-534bc2907ddb3b074ded1353d18fd7d578daf1707943b3039bab4ed975aba3b3R1594 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 28983 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm-opt-fuzzer--x86_64-instcombine
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-12-25 Type: Bug New issue 28983 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm-opt-fuzzer--x86_64-instcombine https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28983 Detailed Report: https://oss-fuzz.com/testcase?key=6189136948101120 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 60 secs) Crash Address: Crash State: llvm-opt-fuzzer--x86_64-instcombine Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202012240626:202012250620 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6189136948101120 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48601] New: clang crashes, with automatic repro
https://bugs.llvm.org/show_bug.cgi?id=48601 Bug ID: 48601 Summary: clang crashes, with automatic repro Product: clang Version: 11.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: mizve...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/sbin/clang++ -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DCMAKE_INTDIR="Release" -I../../psx/core -I../../psx/base -I../../psx/ifc -I../../psx/event -I../../miz/base -I../../miz/intrin -I../../psx/cdrom -I../../psx/xa -I../../psx/cif -I../../psx/ctrldeck -I../../miz/sig -I../../miz/dlist -I../../input/manager -I../../psx/rtc -I../../psx/mdec -I../../psx/softrender -I../../psx/gpu -I../../psx/spu -I../../psx/uart -I../../ext/spdlog/inc -I../../ext/fmt/inc -target i686-w64-mingw32 -g -Wall -Wno-gcc-compat -fwrapv -fno-pie -fsplit-lto-unit -fomit-frame-pointer -Wno-overloaded-virtual -O3 -DNDEBUG -fwhole-program-vtables -flto=thin -std=gnu++20 -MD -MT psx/core/CMakeFiles/psx.core.dir/Release/psx.core.cc.obj -MF psx/core/CMakeFiles/psx.core.dir/Release/psx.core.cc.obj.d -o psx/core/CMakeFiles/psx.core.dir/Release/psx.core.cc.obj -c ../../psx/core/psx.core.cc 1. parser at end of file 2. ../../psx/core/psx.core.cc:1595:34: instantiating function definition 'psx::mem_acc<0>' 3. ../../psx/core/psx.core.cc:1554:31: instantiating function definition 'psx::mem_acc>' #0 0x7fec6277615b llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/../lib/libLLVM-11.so+0xa7615b) #1 0x7fec62773e84 llvm::sys::RunSignalHandlers() (/usr/bin/../lib/libLLVM-11.so+0xa73e84) #2 0x7fec626866a9 (/usr/bin/../lib/libLLVM-11.so+0x9866a9) #3 0x7fec619976a0 __restore_rt (/usr/bin/../lib/libc.so.6+0x3d6a0) #4 0x7fec67f4570d clang::ImportError::convertToErrorCode() const (/usr/bin/../lib/libclang-cpp.so.11+0x7e570d) #5 0x7fec68ee86e8 (/usr/bin/../lib/libclang-cpp.so.11+0x17886e8) #6 0x7fec68eea090 (/usr/bin/../lib/libclang-cpp.so.11+0x178a090) #7 0x7fec68eefdee (/usr/bin/../lib/libclang-cpp.so.11+0x178fdee) #8 0x7fec68eeb267 (/usr/bin/../lib/libclang-cpp.so.11+0x178b267) #9 0x7fec68f167e8 (/usr/bin/../lib/libclang-cpp.so.11+0x17b67e8) #10 0x7fec68f1aa7c clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) (/usr/bin/../lib/libclang-cpp.so.11+0x17baa7c) #11 0x7fec68f368bc clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool, bool) (/usr/bin/../lib/libclang-cpp.so.11+0x17d68bc) #12 0x7fec68f34e20 clang::Sema::PerformPendingInstantiations(bool) (/usr/bin/../lib/libclang-cpp.so.11+0x17d4e20) #13 0x7fec68f36105 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool, bool) (/usr/bin/../lib/libclang-cpp.so.11+0x17d6105) #14 0x7fec68f34e20 clang::Sema::PerformPendingInstantiations(bool) (/usr/bin/../lib/libclang-cpp.so.11+0x17d4e20) #15 0x7fec687921b7 (/usr/bin/../lib/libclang-cpp.so.11+0x10321b7) #16 0x7fec68792ac4 clang::Sema::ActOnEndOfTranslationUnit() (/usr/bin/../lib/libclang-cpp.so.11+0x1032ac4) #17 0x7fec6818e8b3 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, bool) (/usr/bin/../lib/libclang-cpp.so.11+0xa2e8b3) #18 0x7fec680becaa clang::ParseAST(clang::Sema&, bool, bool) (/usr/bin/../lib/libclang-cpp.so.11+0x95ecaa) #19 0x7fec69a43539 clang::FrontendAction::Execute() (/usr/bin/../lib/libclang-cpp.so.11+0x22e3539) #20 0x7fec699f2f7e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/bin/../lib/libclang-cpp.so.11+0x2292f7e) #21 0x7fec69ac0e7d clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/bin/../lib/libclang-cpp.so.11+0x2360e7d) #22 0x7fec6aaf9852 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/sbin/clang+++0x12852) #23 0x7fec6aaf6dfc (/usr/sbin/clang+++0xfdfc) #24 0x7fec696be575 (/usr/bin/../lib/libclang-cpp.so.11+0x1f5e575) #25 0x7fec626867c3 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/usr/bin/../lib/libLLVM-11.so+0x9867c3) #26 0x7fec696bf21e (/usr/bin/../lib/libclang-cpp.so.11+0x1f5f21e) #27 0x7fec69694a88 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/usr/bin/../lib/libclang-cpp.so.11+0x1f34a88) #28 0x7fec69695377 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl >&) const (/usr/bin/../lib/libclang-cpp.so.11+0x1f35377) #29 0x7fec696a0e5c clang::driver::Driver::ExecuteCompilation(clang::d
[llvm-bugs] Issue 28997 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in SequenceChecker::VisitSequencedExpressions
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-12-26 Type: Bug New issue 28997 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in SequenceChecker::VisitSequencedExpressions https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28997 Detailed Report: https://oss-fuzz.com/testcase?key=5140399274459136 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc5779cf40 Crash State: SequenceChecker::VisitSequencedExpressions clang::StmtVisitorBase::Visit Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=202012250620 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5140399274459136 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 28998 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in Evaluate
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-12-26 Type: Bug New issue 28998 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in Evaluate https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28998 Detailed Report: https://oss-fuzz.com/testcase?key=5514194438979584 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffdbefaaf08 Crash State: Evaluate EvaluateAsBooleanCondition IntExprEvaluator::VisitCastExpr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011220601:202011230606 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5514194438979584 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
