[llvm-bugs] [Bug 43582] New: Assert "Non-zero loop cost expected" failed (since "[SLP] avoid reduction transform on patterns that the backend can load-combine")
https://bugs.llvm.org/show_bug.cgi?id=43582 Bug ID: 43582 Summary: Assert "Non-zero loop cost expected" failed (since "[SLP] avoid reduction transform on patterns that the backend can load-combine") Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Global Analyses Assignee: unassignedb...@nondot.org Reporter: mar...@martin.st CC: a.bat...@hotmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Created attachment 22636 --> https://bugs.llvm.org/attachment.cgi?id=22636&action=edit Sample reproduction file Since SVN r373833, "[SLP] avoid reduction transform on patterns that the backend can load-combine", I'm seeing large regressions in building lots of different projects (Qt, freetype, orc jit, libav/ffmpeg, SDL_image) across 4 architectures (i386, x86_64, arm and aarch64). $ clang -target x86_64-w64-mingw32 -c -O2 cff-x86_64.c clang-10: ../lib/Transforms/Vectorize/LoopVectorize.cpp:5179: unsigned int llvm::LoopVectorizationCostModel::selectInterleaveCount(unsigned int, unsigned int): Assertion `LoopCost && "Non-zero loop cost expected"' failed. Stack dump: 0. Program arguments: /home/martin/clang-nightly-mon/bin/clang-10 -cc1 -triple x86_64-w64-windows-gnu -emit-obj -disable-free -main-file-name cff-x86_64.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=none -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -resource-dir /home/martin/clang-nightly-mon/lib/clang/10.0.0 -internal-isystem /home/martin/clang-nightly-mon/lib/clang/10.0.0/include -internal-isystem /home/martin/clang-nightly/x86_64-w64-mingw32/sys-root/mingw/include -internal-isystem /home/martin/clang-nightly/x86_64-w64-mingw32/include -internal-isystem /home/martin/clang-nightly/include -O2 -fdebug-compilation-dir /home/martin -ferror-limit 19 -fmessage-length 0 -fno-use-cxa-atexit -fobjc-runtime=gcc -fseh-exceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -o cff-x86_64.o -x c cff-x86_64.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'Function Pass Manager' on module 'cff-x86_64.c'. 4. Running pass 'Loop Vectorization' on function '@cff_index_get_pointers' #0 0x55743caa22da llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/martin/clang-nightly-mon/bin/clang-10+0x202f2da) #1 0x55743ca9ffb4 llvm::sys::RunSignalHandlers() (/home/martin/clang-nightly-mon/bin/clang-10+0x202cfb4) #2 0x55743caa00f2 (/home/martin/clang-nightly-mon/bin/clang-10+0x202d0f2) #3 0x7f56ce68d890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x7f56cd33ee97 raise /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #5 0x7f56cd340801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0 #6 0x7f56cd33039a __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0 #7 0x7f56cd330412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412) #8 0x55743cc06f15 llvm::LoopVectorizationCostModel::selectInterleaveCount(unsigned int, unsigned int) (/home/martin/clang-nightly-mon/bin/clang-10+0x2193f15) #9 0x55743cc0955f llvm::LoopVectorizePass::processLoop(llvm::Loop*) (/home/martin/clang-nightly-mon/bin/clang-10+0x219655f) #10 0x55743cc0b361 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&, llvm::ProfileSummaryInfo*) (/home/martin/clang-nightly-mon/bin/clang-10+0x2198361) #11 0x55743cc0ba14 (/home/martin/clang-nightly-mon/bin/clang-10+0x2198a14) #12 0x55743c512dc9 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/martin/clang-nightly-mon/bin/clang-10+0x1a9fdc9) #13 0x55743c512e99 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/martin/clang-nightly-mon/bin/clang-10+0x1a9fe99) #14 0x55743c512021 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/martin/clang-nightly-mon/bin/clang-10+0x1a9f021) #15 0x55743ccb92a7 (/home/martin/clang-nightly-mon/bin/clang-10+0x22462a7) #16 0x55743ccbabac clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/home/martin/clang-nightly-mon/bin/clang-10+0x2247bac) #17 0x55743d74aa2d (/home/martin/clang-nightly-mon/bin/clang-10+0x2cd7a2d) #18 0x55743e152a09
[llvm-bugs] [Bug 43217] [X86][SSE] Access a scalar float/double as a free extract from a broadcast load
https://bugs.llvm.org/show_bug.cgi?id=43217 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||r373871 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- (In reply to Simon Pilgrim from comment #2) > Candidate Patch: https://reviews.llvm.org/D68544 Committed at rL373871 -- 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 43584] New: clang-cl preprocesses variadic macros differently than clang and msvc
https://bugs.llvm.org/show_bug.cgi?id=43584
Bug ID: 43584
Summary: clang-cl preprocesses variadic macros differently than
clang and msvc
Product: clang
Version: 9.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: bergle...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
For all version of clang I've tested (7.0.0, 8.0.0 and 9.0.0),
#define THIRD(ARG_1, ARG_2, ARG_3, ...) ARG_3
#define DEMO(...) THIRD(__VA_ARGS__, 3, 4, 5)
int main() {
return DEMO(,);
}
turns into
int main() {
return 3;
}
when preprocessed with `clang -E demo.cpp`, but turns into
int main() {
return 4;
}
when preprocessed with `clang-cl /E demo.cpp`, regardless of whether clang-cl
is run on Linux or on Windows.
My first assumption was that clang-cl is using some kind of MSVC compatibility
mode for the preprocessor, but as it turns out it isn't doing the same thing as
msvc either: DEMO(1, 2) expands to 4 with MSVC, but to 3 with clang-cl.
Note in particular that DEMO(,) and DEMO(1, 2) expand to different results with
clang-cl, while that does not happen with MSVC.
This bug currently breaks googletest's MOCK_METHOD macro with clang-cl (see
https://github.com/google/googletest/issues/2490)
--
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 15623 in oss-fuzz: llvm: Build failure
Comment #29 on issue 15623 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15623#c29 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-066ef7bf-d7fc-416f-aab4-cc843c1e2c5c.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43585] New: Handling C++ exceptions on Windows x64 corrupts local variables
https://bugs.llvm.org/show_bug.cgi?id=43585
Bug ID: 43585
Summary: Handling C++ exceptions on Windows x64 corrupts local
variables
Product: clang
Version: 9.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: brian.a...@oxfordsemantic.tech
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Created attachment 22638
--> https://bugs.llvm.org/attachment.cgi?id=22638&action=edit
x64 Disassembly
I see segmentation faults in my product when switching from Clang 8 to Clang 9.
Sometimes local variables are incorrectly initialised after an exception has
been successfully caught. With certain input this can lead to a crash at a
later point. For one of our unit tests this crash is 100% repeatable.
After some investigation I'm confident this is a Windows only issue with
exception funclets incorrectly spilling XMM registers. I can confirm this issue
does not occur when I use the master branch of Clang because of the change
https://reviews.llvm.org/D66596 ([WinEH] Allocate space in funclets stack to
save XMM CSRs). This issue is a bit of showstopper for me because it leaves me
worried that there are similar problems in our product code that we have not
found through testing. I'm raising this issue in the hope of getting the D66596
change incorporated into a future clang 9 release.
It's hard to come up with a simple example. The code below demonstrates the
corruption problem (but not the crash). It shows how a constant data member is
initialised to the wrong value.
When the following code is compiled with:
clang-cl /O2 /Ob1 /EHsc code.cpp
and run it prints "This shouldn't happen to Two, value of a is 1". I would
expect the code to run without showing this message.
#include
struct One {
const size_t a = 1;
const size_t b = 0;
~One() {
if (a != 1)
std::cout << "This shouldn't happen to One, value of a is " << a <<
"." << std::endl;
}
};
struct Two {
const size_t a = 2;
const size_t b = 0;
~Two() {
if (a != 2)
std::cout << "This shouldn't happen to Two, value of a is " << a <<
"." << std::endl;
}
};
void throwIt() {
throw std::string();
}
bool mytest() {
for (int i = 0; i < 2; ++i) {
try {
One one;
throwIt();
}
catch (const std::string& s) {
return true;
}
}
return false;
}
int main(int argc, char* argv[]) {
for (int i = 0; i < 2; ++i) {
Two two;
mytest();
}
return 0;
}
For more details see annotated attached disassembly it shows how mytest()
overwrites the CSR slot for XMM6 in both the unwinding and catch handling
funclets.
--
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 18061 in oss-fuzz: llvm:llvm-special-case-list-fuzzer: Heap-buffer-overflow in p_ere
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-Medium Reported-2019-10-07 Type: Bug-Security New issue 18061 by ClusterFuzz-External: llvm:llvm-special-case-list-fuzzer: Heap-buffer-overflow in p_ere https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18061 Detailed Report: https://oss-fuzz.com/testcase?key=5717405149429760 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-special-case-list-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Heap-buffer-overflow READ 8 Crash Address: 0x62003e60 Crash State: p_ere p_ere p_ere Sanitizer: address (ASAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201711070608:201711090621 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5717405149429760 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 43587] New: LeakSanitizer fails based on stack layout
https://bugs.llvm.org/show_bug.cgi?id=43587 Bug ID: 43587 Summary: LeakSanitizer fails based on stack layout Product: compiler-rt Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: asan Assignee: unassignedb...@nondot.org Reporter: mhaeu...@outlook.de CC: llvm-bugs@lists.llvm.org Created attachment 22639 --> https://bugs.llvm.org/attachment.cgi?id=22639&action=edit demonstration and further details LeakSanitizer may fail to catch leaked memory based on stack layout. While I did not perform any extensive research, I did verify that stack layout is the only changing factor in my compiled binaries by disassembly comparison. I did not verify whether the underlying issue can cause other problems than the one described by this report. Please find attached a C program with comments about the verified environments and different ways to reproduce. -- 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 43588] New: argv[0] is always passed as absolute
https://bugs.llvm.org/show_bug.cgi?id=43588
Bug ID: 43588
Summary: argv[0] is always passed as absolute
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: jan.kratoch...@redhat.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
echo 'int main(int argc,char **argv){}'|clang -g -x c
-;~/redhat/llvm-monorepo-clangassert/bin/lldb -batch ./a.out -o 'b main' -o r
-o 'p argv[0]'
Actual:
(char *) $0 = "/tmp/a.out"
Expected:
(char *) $0 = "./a.out"
Some debuggee issues being debugged may depend on its argv[0].
--
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 43589] New: libclang C API is exporting C++ symbols
https://bugs.llvm.org/show_bug.cgi?id=43589 Bug ID: 43589 Summary: libclang C API is exporting C++ symbols Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: sylves...@debian.org CC: kli...@google.com, llvm-bugs@lists.llvm.org, mgo...@gentoo.org, richard-l...@metafoo.co.uk In Debian/Ubuntu packages, I have been maintaining the list of symbols. https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/blob/9/debian/libclang1-X.Y.symbols.in Since October 2nd (I don't have the exact revision), in master, the library also export C++ symbols. libclang-10.so.1 libclang1-10 #MINVER# (optional)LLVM_10@LLVM_10 1:5.0~svn298832-1~ + _ZN4llvm10TimeRecord14getCurrentTimeEb@Base 1:10~svn373870-1~exp1+0~20191006201134.2786~1.gbp2b7b74 + _ZN4llvm10TimerGroupC1ENS_9StringRefES1_@Base 1:10~svn373870-1~exp1+0~20191006201134.2786~1.gbp2b7b74 + _ZN4llvm10TimerGroupD1Ev@Base 1:10~svn373870-1~exp1+0~20191006201134.2786~1.gbp2b7b74 + _ZN4llvm10hash_valueENS_9StringRefE@Base 1:10~svn373870-1~exp1+0~20191006201134.2786~1.gbp2b7b74 + _ZN4llvm11APFloatBase10IEEEdoubleEv@Base 1:10~svn373870-1~exp1+0~20191006201134.2786~1.gbp2b7b74 + _ZN4llvm11APFloatBase10IEEEsingleEv@Base 1:10~svn373870-1~exp1+0~20191006201134.2786~1.gbp2b7b74 + _ZN4llvm11APFloatBase15EnumToSemanticsENS0_9SemanticsE@Base 1:10~svn373870-1~exp1+0~20191006201134.2786~1.gbp2b7b74 Full log here: https://llvm-jenkins.debian.net/view/Debian%2011%20-%20unstable/job/llvm-toolchain-binaries/1734/architecture=amd64,distribution=unstable/console Not sure what changed -- 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 18062 in oss-fuzz: llvm:clangd-fuzzer: ASSERT: hasIRSupport() && "This action does not have IR file support!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-10-07 Type: Bug New issue 18062 by ClusterFuzz-External: llvm:clangd-fuzzer: ASSERT: hasIRSupport() && "This action does not have IR file support!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18062 Detailed Report: https://oss-fuzz.com/testcase?key=5672161628389376 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clangd-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: hasIRSupport() && "This action does not have IR file support!" clang::FrontendAction::BeginSourceFile clang::clangd::ParsedAST::build Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201909020324:201909060434 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5672161628389376 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 43590] New: Compilation and run time failure with UBSan std::filesystem libstdc++fs
https://bugs.llvm.org/show_bug.cgi?id=43590
Bug ID: 43590
Summary: Compilation and run time failure with UBSan
std::filesystem libstdc++fs
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: vak...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Arch Linux
$ clang++ --version
clang version 8.0.1 (tags/RELEASE_801/final)
Target: x86_64-pc-linux-gnu
$ g++ --version
g++ (GCC) 9.2.0
---
#include
int main()
{
std::filesystem::recursive_directory_iterator iterator{"."};
// Without this line the error is not triggered.
for (const auto& _: iterator) {}
}
---
This program compiles correctly with
$ clang++ -std=c++17 -lstdc++fs -fsanitize=undefined main.cpp
but it reports an error when running:
$ ./a.out
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../include/c++/9.2.0/bits/shared_ptr_base.h:737:11:
runtime error: member call on address 0x563f879b8f20 which does not point to an
object of type 'std::_Sp_counted_base<__gnu_cxx::_S_atomic>'
0x563f879b8f20: note: object is of type
'std::_Sp_counted_ptr_inplace,
(__gnu_cxx::_Lock_policy)2>'
00 00 00 00 38 ca 25 4b 3c 7f 00 00 01 00 00 00 01 00 00 00 90 8f 9b 87 3f
56 00 00 08 00 00 00
^~~
vptr for
'std::_Sp_counted_ptr_inplace,
(__gnu_cxx::_Lock_policy)2>'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../include/c++/9.2.0/bits/shared_ptr_base.h:139:43:
runtime error: member access within address 0x563f879b8f20 which does not point
to an object of type 'std::_Sp_counted_base<__gnu_cxx::_S_atomic>'
0x563f879b8f20: note: object is of type
'std::_Sp_counted_ptr_inplace,
(__gnu_cxx::_Lock_policy)2>'
00 00 00 00 38 ca 25 4b 3c 7f 00 00 01 00 00 00 01 00 00 00 90 8f 9b 87 3f
56 00 00 08 00 00 00
^~~
vptr for
'std::_Sp_counted_ptr_inplace,
(__gnu_cxx::_Lock_policy)2>'
--
If -O1 or higher is specified then it does not compile:
$ clang++ -std=c++17 -lstdc++fs -fsanitize=undefined -O1 main.cpp
/usr/bin/ld: /tmp/main-72a5a0.o: in function
`std::filesystem::__cxx11::recursive_directory_iterator::recursive_directory_iterator(std::filesystem::__cxx11::recursive_directory_iterator&&)':
main.cpp:(.text._ZNSt10filesystem7__cxx1128recursive_directory_iteratorC2EOS1_[_ZNSt10filesystem7__cxx1128recursive_directory_iteratorC2EOS1_]+0x2d):
undefined reference to
`std::__shared_ptr::__shared_ptr(std::__shared_ptr&&)'
With verbose:
$ clang++ -std=c++17 -lstdc++fs -fsanitize=undefined -O1 -v main.cpp
clang version 8.0.1 (tags/RELEASE_801/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/9.2.0
Found candidate GCC installation:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/9.2.0
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
"/usr/bin/clang-8" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name main.cpp
-mrelocation-model pic -pic-level 2 -pic-is-pie -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 -v -resource-dir /usr/lib/clang/8.0.1
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../include/c++/9.2.0
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../include/c++/9.2.0/x86_64-pc-linux-gnu
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../include/c++/9.2.0/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/lib/clang/8.0.1/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O1 -std=c++17 -fdeprecated-macro
-fdebug-compilation-dir /home/lvk/temp2 -ferror-limit 19 -fmessage-length 133
-fsanitize=alignment,array-bounds,bool,builtin,enum,float-cast-overflow,float-divide-by-zero,function,integer-divide-by-zero,nonnull-attribute,null,object-size,pointer-overflow,return,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-overflow,unreachable,vla-bound,vptr
-fsanitize-recover=alignment,array-bounds,bool,builtin,enum,float-cast-overflow,float-divide-by-zero,function,integer-divide-by-zero,nonnull-attribute,null,object-size,pointer-overflow,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-over
[llvm-bugs] [Bug 43146] Compiler fails to optimize big endian load since clang 8.0
https://bugs.llvm.org/show_bug.cgi?id=43146 Sanjay Patel changed: What|Removed |Added Resolution|FIXED |--- See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=43582 Status|RESOLVED|REOPENED --- Comment #17 from Sanjay Patel --- Reopening - the patch was reverted because it caused loop vectorizer asserts: https://reviews.llvm.org/rL373882 -- 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 42708] Vectorization of 8 byte load prevents load merging
https://bugs.llvm.org/show_bug.cgi?id=42708 Sanjay Patel changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #9 from Sanjay Patel --- Reopening - the patch that would have fixed this was reverted because it caused loop vectorizer asserts: https://reviews.llvm.org/rL373882 Also, this isn't an exact duplicate of bug 43146, so it's worth tracking separately just in case it requires a different fix (although I'm hoping we'll again solve it with a variation from D67841). -- 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 42885] optimization bug with -march=haswell/skylake
https://bugs.llvm.org/show_bug.cgi?id=42885 Sanjay Patel changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #3 from Sanjay Patel --- Reopening - the patch was reverted because it caused loop vectorizer asserts: https://reviews.llvm.org/rL373882 -- 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 12226 in oss-fuzz: llvm/clang-fuzzer: ASSERT: ResultKind != Found || Decls.size() == 1
Updates: Status: WontFix Comment #6 on issue 12226 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: ResultKind != Found || Decls.size() == 1 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12226#c6 ClusterFuzz testcase 5122400224542720 is flaky and no longer crashes, so closing issue. 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12128 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-guard_widening: ASSERT: Index < Length && "Invalid index!"
Updates: Status: WontFix Comment #6 on issue 12128 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-guard_widening: ASSERT: Index < Length && "Invalid index!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12128#c6 ClusterFuzz testcase 5652880376201216 is flaky and no longer crashes, so closing issue. 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12189 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isIntPredicate() && "Invalid ICmp predicate value"
Updates: Status: WontFix Comment #6 on issue 12189 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isIntPredicate() && "Invalid ICmp predicate value" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12189#c6 ClusterFuzz testcase 5697875745439744 is flaky and no longer crashes, so closing issue. 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 15885 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-licm: ASSERT: V && "Unexpected null Value"
Updates: Labels: Deadline-Approaching Comment #1 on issue 15885 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-licm: ASSERT: V && "Unexpected null Value" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15885#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 15924 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E
Updates: Labels: Deadline-Approaching Comment #1 on issue 15924 by sheriff...@chromium.org: llvm/llvm-dwarfdump-fuzzer: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15924#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 15913 in oss-fuzz: llvm/clang-fuzzer: Null-dereference READ in clang::Preprocessor::LexHeaderName
Updates: Labels: Deadline-Approaching Comment #1 on issue 15913 by sheriff...@chromium.org: llvm/clang-fuzzer: Null-dereference READ in clang::Preprocessor::LexHeaderName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15913#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 15910 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"
Updates: Labels: Deadline-Approaching Comment #1 on issue 15910 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15910#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 43582] Assert "Non-zero loop cost expected" failed (since "[SLP] avoid reduction transform on patterns that the backend can load-combine")
https://bugs.llvm.org/show_bug.cgi?id=43582 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sanjay Patel --- Thank you for posting the tests. I reduced the 1st example in: https://reviews.llvm.org/rL373913 And the change that caused the regression was reverted: https://reviews.llvm.org/rL373882 So I think we can close this report. The patch that caused the bug is modified and up for re-review at: https://reviews.llvm.org/D67841 -- 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 31422] ICE in frontend
https://bugs.llvm.org/show_bug.cgi?id=31422 Mark de Wever changed: What|Removed |Added Status|CONFIRMED |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43591] New: sign mismatch for getArithmeticInstrCost() definitions/usage
https://bugs.llvm.org/show_bug.cgi?id=43591
Bug ID: 43591
Summary: sign mismatch for getArithmeticInstrCost()
definitions/usage
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Follow-up to bug 43582:
In class TargetTransformInfo::Model final : public TargetTransformInfo::Concept
(in TargetTransformInfo.h), we have:
/// This is an approximation of reciprocal throughput of a math/logic op.
/// A higher cost indicates less expected throughput.
/// From Agner Fog's guides, reciprocal throughput is "the average number of
/// clock cycles per instruction when the instructions are not part of a
/// limiting dependency chain."
/// Therefore, costs should be scaled to account for multiple execution units
/// on the target that can process this type of instruction. For example, if
/// there are 5 scalar integer units and 2 vector integer units that can
/// calculate an 'add' in a single cycle, this model should indicate that the
/// cost of the vector add instruction is 2.5 times the cost of the scalar
/// add instruction.
/// \p Args is an optional argument which holds the instruction operands
/// values so the TTI can analyze those values searching for special
/// cases or optimizations based on those values.
int getArithmeticInstrCost(
unsigned Opcode, Type *Ty, OperandValueKind Opd1Info = OK_AnyValue,
OperandValueKind Opd2Info = OK_AnyValue,
OperandValueProperties Opd1PropInfo = OP_None,
OperandValueProperties Opd2PropInfo = OP_None,
ArrayRef Args = ArrayRef()) const;
In class BasicTTIImplBase : public TargetTransformInfoImplCRTPBase (in
BasicTTIImpl.h), we have:
unsigned getArithmeticInstrCost(
unsigned Opcode, Type *Ty,
TTI::OperandValueKind Opd1Info = TTI::OK_AnyValue,
TTI::OperandValueKind Opd2Info = TTI::OK_AnyValue,
TTI::OperandValueProperties Opd1PropInfo = TTI::OP_None,
TTI::OperandValueProperties Opd2PropInfo = TTI::OP_None,
ArrayRef Args = ArrayRef()) {
We're returning a signed value in the first function even though a reciprocal
throughput shouldn't ever be negative. The LoopVectorizer assumes the value is
unsigned. The SLPVectorizer uses these values to compare relative perf and uses
subtraction of signed values when comparing scalar and vector sequences.
Both of these interpretations can't be right?
--
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 42318] Overload resolution and enum promotion
https://bugs.llvm.org/show_bug.cgi?id=42318 Mark de Wever changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43592] New: Several clangd tests fail on Windows
https://bugs.llvm.org/show_bug.cgi?id=43592 Bug ID: 43592 Summary: Several clangd tests fail on Windows Product: clang-tools-extra Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: clangd Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Since at least Sep 18, logs don't go back further: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15596 A trunk build: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15787 FAIL: Clangd:: code-action-request.test FAIL: Clangd:: background-index.test FAIL: Clangd:: request-reply.test FAIL: Clangd:: semantic-highlighting.test FAIL: Clangd:: type-hierarchy.test FAIL: Clangd:: symbols.test FAIL: Clangd:: system-include-extractor.test FAIL: Clangd Unit Tests::ExpandAutoTypeTest.Test FAIL: Clangd Unit Tests::FindExplicitReferencesTest.All FAIL: Clangd Unit Tests::IncludeFixerTest.UnresolvedNameAsSpecifier FAIL: Clangd Unit Tests::IncludeFixerTest.UnresolvedSpecifierWithSemaCorrection FAIL: Clangd Unit Tests::LocateSymbol.All FAIL: Clangd Unit Tests::ParsedASTTest.GetsExplicitInstantiationAndSpecializationTemplateTopDecls FAIL: Clangd Unit Tests::SemanticHighlighting.GetsCorrectTokens FAIL: Clangd Unit Tests::SelectionTest.CommonAncestor -- 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 43072] LLVM ERROR: Cannot select: intrinsic %llvm.ppc.altivec.dss
https://bugs.llvm.org/show_bug.cgi?id=43072 Jinsong Ji changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jinsong Ji --- Should have been fixed in https://reviews.llvm.org/rL370902 -- 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 43584] clang-cl preprocesses variadic macros differently than clang and msvc
https://bugs.llvm.org/show_bug.cgi?id=43584 Reid Kleckner changed: What|Removed |Added Resolution|--- |DUPLICATE CC||r...@google.com Status|NEW |RESOLVED --- Comment #1 from Reid Kleckner --- There are three similar issues: issue 20277 issue 42112 issue 43282 This one looks exactly like the one most recently filed, so I'll dupe it there. I haven't looked closely enough to understand it. *** This bug has been marked as a duplicate of bug 43282 *** -- 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 43175] clang 9 rc2, openmp, regex, Visual Studio: Assertion failed: Ty && "Invalid GetElementPtrInst indices for type!"
https://bugs.llvm.org/show_bug.cgi?id=43175 Eli Friedman changed: What|Removed |Added CC||efrie...@quicinc.com Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Eli Friedman --- (Reopening to track 9.0.1.) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 43175, which changed state. Bug 43175 Summary: clang 9 rc2, openmp, regex, Visual Studio: Assertion failed: Ty && "Invalid GetElementPtrInst indices for type!" https://bugs.llvm.org/show_bug.cgi?id=43175 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42576] aarch64: -march=armv8-a produces armv8.2 'bfc' instruction
https://bugs.llvm.org/show_bug.cgi?id=42576 Eli Friedman changed: What|Removed |Added Resolution|FIXED |--- CC||efrie...@quicinc.com Status|RESOLVED|REOPENED --- Comment #11 from Eli Friedman --- (Reopening to track 9.0.1.) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 42576, which changed state. Bug 42576 Summary: aarch64: -march=armv8-a produces armv8.2 'bfc' instruction https://bugs.llvm.org/show_bug.cgi?id=42576 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 42576, which changed state. Bug 42576 Summary: aarch64: -march=armv8-a produces armv8.2 'bfc' instruction https://bugs.llvm.org/show_bug.cgi?id=42576 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43594] New: [InstCombine] sign bit extract + trunc => icmp + zext?
https://bugs.llvm.org/show_bug.cgi?id=43594
Bug ID: 43594
Summary: [InstCombine] sign bit extract + trunc => icmp + zext?
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
https://godbolt.org/z/iSlCpW
For
int good(unsigned long input) {
return (signed long)input < 0;
}
we produce
define dso_local i32 @_Z4goodm(i64 %0) local_unnamed_addr #0 {
%2 = lshr i64 %0, 63
%3 = trunc i64 %2 to i32
ret i32 %3
}
Should this be instead:
define dso_local i32 @_Z4goodm(i64 %0) local_unnamed_addr #0 {
%2 = icmp slt i64 %0, 0
%3 = zext i1 %2 to i32
ret i32 %3
}
?
--
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 43595] New: [InstCombine] Failure to recognize sign bit test - shift amount reassociation
https://bugs.llvm.org/show_bug.cgi?id=43595 Bug ID: 43595 Summary: [InstCombine] Failure to recognize sign bit test - shift amount reassociation Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: llvm-bugs@lists.llvm.org This is motivated by https://bugs.llvm.org/show_bug.cgi?id=42389 While we succeed to produce sign bit test if we use unsigned: https://godbolt.org/z/iSlCpW We get stuck if we use signed: https://godbolt.org/z/VO1-0F Boo. https://rise4fun.com/Alive/PRU I'm not sure how to approach this yet. We can't treat this just as shift amount reassociation, maybe icmp can be treated as `trunc to i1`. -- 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 42389] InstCombine: lshr + "sext" => ashr canonicalization
https://bugs.llvm.org/show_bug.cgi?id=42389 Roman Lebedev changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||373964 Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |lebedev...@gmail.com --- Comment #3 from Roman Lebedev --- The fold itself added in r373964, but more work is needed to produce said sign-bit checks; and ideally zext-vs-sext, in sub-vs-add. -- 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 43596] New: [MIPS][FreeBSD] clang: default to soft float on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=43596 Bug ID: 43596 Summary: [MIPS][FreeBSD] clang: default to soft float on FreeBSD Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kev...@freebsd.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 22640 --> https://bugs.llvm.org/attachment.cgi?id=22640&action=edit git(1) diff against github.com/llvm/llvm-mirror Hi, FreeBSD-world defaults to soft float for all MIPS flavors/variants. We actually patch GCC to assume soft float as well, but it would be most convenient for the Clang driver to assume soft float for FreeBSD since hard float is actually the odd-ball out and the needed information is readily available. Patch attached as an example... I still do not have a functional test setup, so it's not clear to me if any of the applicable tests break when this default changes. I'll work on that, though... -- 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 43597] New: Reuse flags from shift instruction -> avoid test instruction
https://bugs.llvm.org/show_bug.cgi?id=43597
Bug ID: 43597
Summary: Reuse flags from shift instruction -> avoid test
instruction
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
int foo (int a)
{
int b = 0;
while (a >>= 1)
b++;
return b;
}
foo:
mov eax, -1
.LBB0_1:
sar edi
add eax, 1
testedi, edi
jne .LBB0_1
ret
https://c9x.me/x86/html/file_module_x86_id_285.html
"The SF, ZF, and PF flags are set according to the result. If the count is 0,
the flags are not affected. For a non-zero count, the AF flag is undefined."
So 'test' could be eliminated here.
foo:
mov eax, -1
.LBB0_1:
add eax, 1
sar edi
jne .LBB0_1
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43598] New: -Wunneeded-internal-declaration warned on needed function
https://bugs.llvm.org/show_bug.cgi?id=43598
Bug ID: 43598
Summary: -Wunneeded-internal-declaration warned on needed
function
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: leonardc...@google.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
For this code:
```
1 #include
2
3 namespace {
4
5 // Check if Op is convertible to bool.
6 template
7 using enable_relop_t = std::enable_if_t<(std::is_convertible::value), bool>;
8
9 // Chek if can do == with T and U.
10 template () == std::declval())> =
true>
12 constexpr bool is_comparable(T&&, U&&) {
13 return true;
14 }
15
16 struct comparable_a {};
17
18 constexpr bool operator==(const comparable_a&, const comparable_a&) {
return true; }
19
20 static_assert(is_comparable(comparable_a{}, comparable_a{}));
21
22 }
```
We get this warning on line 18: warning: function 'operator==' is not needed
and will not be emitted [-Wunneeded-internal-declaration]. If the function were
truly unneeded, I would assume I should just be able to comment out line 18 and
everything should still compile, but I would get an `error no matching function
for call to 'is_comparable'` meaning it was used.
Compiled with `bin/clang++ ~/misc/test.cpp -c -std=c++17 -Wall` from ToT clang.
I'm noticing that this compiles without warnings also if I don't wrap
everything in an unnamed namespace or mark operator== with
__attrubute__((used)).
--
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 43599] New: lldb can not print anonymous structs anymore
https://bugs.llvm.org/show_bug.cgi?id=43599
Bug ID: 43599
Summary: lldb can not print anonymous structs anymore
Product: lldb
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: nat-llvmb...@mulle-kybernetik.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 22641
--> https://bugs.llvm.org/attachment.cgi?id=22641&action=edit
Sourcecode
Build with `clang -o foo -g -O0 foo.c.`
Then load foo into lldb and set a breakpoint on main.
Execute until printf. Now say `p x`.
You'll get ((anonymous struct)) $0 = {}
Here's some log output
lldb FindExternalLexicalDecls[2] on (ASTContext*)0x13f1120 in ''
(CXXRecordDecl*)0x1430e48
lldb FELD[2] Original decl (ASTContext*)0x7f9b98005b20
(Decl*)0x7f9b98047638:
lldb struct {
lldb int x;
lldb int y;
lldb }
lldb FELD[2] Adding [to CXXRecordDecl ] lexical FieldDecl int x
lldb FELD[2] Adding [to CXXRecordDecl ] lexical FieldDecl int y
lldb LayoutRecordType[3] on (ASTContext*)0x13f1120 for
(RecordDecl*)0x1430e48 [name = '']
lldb LRT[3] returned:
lldb LRT[3] Original = (RecordDecl*)0x7f9b98047638
lldb LRT[3] Size = 64
lldb LRT[3] Alignment = 32
lldb LRT[3] Fields:
lldb LRT[3] Bases:
lldb EntityVariable::Dematerialize [address = 0x77fcc008,
m_variable_sp = x]
lldb == [UserExpression::Evaluate] Execution completed normally
with result (null) ==
lldb IRMemoryMap::Free (0x77d17000) freed
[0x77d17000..0x77d97007)
lldb IRMemoryMap::Free (0x77fcc000) freed
[0x77fcc000..0x77fcc017)
((anonymous struct)) $1 = {}
Its puzzling, because you can see the expr is actually completing the
record_decl correctly. Bbut then llvm throws the result away in
IRForTarget::CreateResultVariable I believe, by asking the Parser, who returns
an incomplete RecordDecl ?
304} else {
305 m_result_type = lldb_private::TypeFromParser(
306 result_var->getType().getAsOpaquePtr(),
307 lldb_private::ClangASTContext::GetASTContext(
308 &result_decl->getASTContext()));
309}
The same procedure works fine with 8.0.0.
--
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 43600] New: -Wincomplete-setjmp-declaration triggers on typedef
https://bugs.llvm.org/show_bug.cgi?id=43600 Bug ID: 43600 Summary: -Wincomplete-setjmp-declaration triggers on typedef Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C Assignee: unassignedclangb...@nondot.org Reporter: ndesaulni...@google.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, jdoerf...@anl.gov, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk, srhi...@google.com Android's bionic (libc) basically has code like: typedef long jmp_buf[10]; void sigsetjmp(); This triggers the warning: :2:6: warning: declaration of built-in function 'sigsetjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header . [-Wincomplete-setjmp-declaration] void sigsetjmp(); ^ The warning tells me to declare jmp_buf, which I believe I did w/ the typedef? See also r367387. -- 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
