[llvm-bugs] [Bug 46956] New: TwoAddressInstructionPass assertion
https://bugs.llvm.org/show_bug.cgi?id=46956 Bug ID: 46956 Summary: TwoAddressInstructionPass assertion Product: clang Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: C Assignee: unassignedclangb...@nondot.org Reporter: u...@polymagelabs.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk This build crashes with an assert. The file in question being built has inline ASM. To reproduce: 1) Obtain tensorflow commit c6023a81d4976f6ff79f957925364d21d7884004 (Jul 30) from https://github.com/tensorflow/tensorflow.git 2) To build, run: (Use the default options with ./configure; shouldn't make a difference anyway.) CXX=/opt/clang-11.0rc1/bin/clang++ CC=/opt/clang-11.0rc1/bin/clang bazel build --config=monolithic --copt=-UNDEBUG --linkopt='-fuse-ld=lld' tensorflow/compiler/mlir:tf-opt This yields the assertion appended below. clang was built from sources with the following configuration: cmake -G Ninja ../llvm -DCMAKE_INSTALL_PREFIX=/opt/clang-11.0rc1 -DLLVM_ENABLE_PROJECTS="clang"-DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_ENABLE_LLD=ON -DLLVM_CCACHE_BUILD=ON The version of clang/clang++ used to build clang/llvm itself was clang version 9.0.1 (Red Hat 9.0.1-2.module_el8.2.0+309+0c7b6b03) on CentOS Linux release 8.2.2004 (Core). bazel --version (3.4.1) <-- shouldn't make a difference. ... clang: /ws/uday/llvm-project-11.0.0rc1/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp:1396: void (anonymous namespace)::TwoAddressInstructionPass::processTiedPairs(llvm::MachineInstr *, (anonymous namespace)::TwoAddressInstructionPass::TiedPairList &, unsigned int &): Assertion `i == DstIdx || !MI->getOperand(i).isReg() || MI->getOperand(i).getReg() != RegA' failed. 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: /opt/clang-11.0rc1/bin/clang -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 -D_FORTIFY_SOURCE=1 -DNDEBUG -ffunction-sections -fdata-sections -MD -MF bazel-out/k8-opt/bin/external/aws-checksums/_objs/aws-checksums/crc32c_sse42_asm.d -frandom-seed=bazel-out/k8-opt/bin/external/aws-checksums/_objs/aws-checksums/crc32c_sse42_asm.o -iquote external/aws-checksums -iquote bazel-out/k8-opt/bin/external/aws-checksums -iquote external/aws-c-common -iquote bazel-out/k8-opt/bin/external/aws-c-common -isystem external/aws-checksums/include -isystem bazel-out/k8-opt/bin/external/aws-checksums/include -isystem external/aws-c-common/include -isystem bazel-out/k8-opt/bin/external/aws-c-common/include -w -DAUTOLOAD_DYNAMIC_KERNELS -UNDEBUG -no-canonical-prefixes -Wno-builtin-macro-redefined -D__DATE__="redacted" -D__TIMESTAMP__="redacted" -D__TIME__="redacted" -c external/aws-checksums/source/intel/crc32c_sse42_asm.c -o bazel-out/k8-opt/bin/external/aws-checksums/_objs/aws-checksums/crc32c_sse42_asm.o 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'external/aws-checksums/source/intel/crc32c_sse42_asm.c'. 4. Running pass 'Two-Address instruction pass' on function '@aws_checksums_crc32c_hw' #0 0x02fc7944 PrintStackTraceSignalHandler(void*) (/opt/clang-11.0rc1/bin/clang+0x2fc7944) #1 0x02fc547e llvm::sys::RunSignalHandlers() (/opt/clang-11.0rc1/bin/clang+0x2fc547e) #2 0x02fc6ab4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/clang-11.0rc1/bin/clang+0x2fc6ab4) #3 0x02f455e3 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) (/opt/clang-11.0rc1/bin/clang+0x2f455e3) #4 0x02f4571c CrashRecoverySignalHandler(int) (/opt/clang-11.0rc1/bin/clang+0x2f4571c) #5 0x7f51c33b3dd0 __restore_rt (/lib64/libpthread.so.0+0x12dd0) #6 0x7f51c20c370f raise (/lib64/libc.so.6+0x3770f) #7 0x7f51c20adb25 abort (/lib64/libc.so.6+0x21b25) #8 0x7f51c20ad9f9 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x219f9) #9 0x7f51c20bbcc6 (/lib64/libc.so.6+0x2fcc6) #10 0x027cca9c (anonymous namespace)::TwoAddressInstructionPass::runOnMachineFunction(llvm::MachineFunction&) (/opt/clang-11.0rc1/bin/clang+0x27cca9c) #11 0x024ac14e llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/opt/clang-11.0rc1/bin/clang+0x24ac14e) #12 0x02914d91 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/clang-11.0rc1/bin/clang+0x2914d91) #13 0x0291b778 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/clang-11.0rc1/bin/clang+0x291
[llvm-bugs] [Bug 46957] New: double free when compiling JSC with afl-clang-lto(clang 12)
https://bugs.llvm.org/show_bug.cgi?id=46957 Bug ID: 46957 Summary: double free when compiling JSC with afl-clang-lto(clang 12) Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: adrian.r.ti...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Hi all, I downloaded llvm12 , compiled and installed it, then I build AFL++ with. I can build simple test programs with afl-clang-lto just fine. When I tried to compile JSC with afl-clang-lto I got the following stacktrace: FAILED: bin/testdfg : && /usr/local/bin/afl-clang-lto++ -fdiagnostics-color=always -fcolor-diagnostics -Wextra -Wall -Wno-noexcept-type -Wno-psabi -Wno-parentheses-equality -Qunused-arguments -Wwrite-strings -Wundef -Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -O3 -lrt -fno-strict-aliasing -fno-exceptions -fno-rtti -g -O3 -lrt Source/JavaScriptCore/shell/CMakeFiles/testdfg.dir/__/dfg/testdfg.cpp.o -o bin/testdfg lib/libJavaScriptCore.a lib/libWTF.a lib/libbmalloc.a /usr/lib/x86_64-linux-gnu/libicudata.so /usr/lib/x86_64-linux-gnu/libicui18n.so /usr/lib/x86_64-linux-gnu/libicuuc.so -ldl -lpthread && : clang-12: warning: '-fuse-ld=' taking a path is deprecated. Use '--ld-path=' instead clang-12: warning: '-fuse-ld=' taking a path is deprecated. Use '--ld-path=' instead free(): double free detected in tcache 2 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/local/bin/ld.lld -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o bin/testdfg /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/9 -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/9/../../.. -L/usr/local/bin/../lib -L/lib -L/usr/lib -plugin-opt=mcpu=x86-64 -plugin-opt=O3 -lc++ --allow-multiple-definition -mllvm=-load=/usr/local/lib/afl/afl-llvm-lto-instrumentation.so -lrt -lrt Source/JavaScriptCore/shell/CMakeFiles/testdfg.dir/__/dfg/testdfg.cpp.o lib/libJavaScriptCore.a lib/libWTF.a lib/libbmalloc.a /usr/lib/x86_64-linux-gnu/libicudata.so /usr/lib/x86_64-linux-gnu/libicui18n.so /usr/lib/x86_64-linux-gnu/libicuuc.so -ldl -lpthread /usr/local/lib/afl/afl-llvm-rt.o /usr/local/lib/afl/afl-llvm-rt-lto.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/9/crtend.o /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o 1. Running pass 'afl++ LTO instrumentation pass' on module 'ld-temp.o'. #0 0x55ac5ffd4e6e llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/bin/ld.lld+0x898e6e) #1 0x55ac5ffd2d04 llvm::sys::RunSignalHandlers() (/usr/local/bin/ld.lld+0x896d04) #2 0x55ac5ffd2e48 SignalHandler(int) (/usr/local/bin/ld.lld+0x896e48) #3 0x7fe820db73c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0) #4 0x7fe82085718b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618b) #5 0x7fe820836859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25859) #6 0x7fe8208a13ee (/lib/x86_64-linux-gnu/libc.so.6+0x903ee) #7 0x7fe8208a947c (/lib/x86_64-linux-gnu/libc.so.6+0x9847c) #8 0x7fe8208ab0ed (/lib/x86_64-linux-gnu/libc.so.6+0x9a0ed) #9 0x7fe820896043 fclose (/lib/x86_64-linux-gnu/libc.so.6+0x85043) #10 0x7fe820dd83ed (anonymous namespace)::AFLLTOPass::runOnModule(llvm::Module&) /home/adrian/Downloads/AFLplusplus/llvm_mode/afl-llvm-lto-instrumentation.so.cc:0:23 #11 0x55ac62dc8210 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/bin/ld.lld+0x368c210) #12 0x55ac61982664 (anonymous namespace)::opt(llvm::lto::Config const&, llvm::TargetMachine*, unsigned int, llvm::Module&, bool, llvm::ModuleSummaryIndex*, llvm::ModuleSummaryIndex const*) (/usr/local/bin/ld.lld+0x2246664) #13 0x55ac619837e0 llvm::lto::backend(llvm::lto::Config const&, std::function > (unsigned int)>, unsigned int, std::unique_ptr >, llvm::ModuleSummaryIndex&) (/usr/local/bin/ld.lld+0x22477e0) #14 0x55ac61976a83 llvm::lto::LTO::runRegularLTO(std::function > (unsigned int)>) (/usr/local/bin/ld.lld+0x223aa83) #15 0x55ac619771d2 llvm::lto::LTO::run(std::function > (unsigned int)>, std::function > (unsigned int)> (unsigned int, llvm::StringRef)>) (/usr/local/bin/ld.lld+0x223b1d2) #16 0x55ac60148ea5 lld::elf::BitcodeCompiler::compile() (/usr/local/bin/ld.lld+0xa0cea5) #17 0x55ac600bfab5 void lld::elf::LinkerDriver::compileBitcodeFil
[llvm-bugs] Issue 24619 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: Null-dereference WRITE in llvm::AArch64FrameLowering::processFunctionBeforeFrameFinalized
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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-2020-08-02 Type: Bug New issue 24619 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-O2: Null-dereference WRITE in llvm::AArch64FrameLowering::processFunctionBeforeFrameFinalized https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24619 Detailed Report: https://oss-fuzz.com/testcase?key=5156057794740224 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference WRITE Crash Address: 0x02c0 Crash State: llvm::AArch64FrameLowering::processFunctionBeforeFrameFinalized PEI::runOnMachineFunction llvm::MachineFunctionPass::runOnFunction Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201810170227:20181623 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5156057794740224 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 46958] New: Out of boundary read in Unwind-EHABI.cpp
https://bugs.llvm.org/show_bug.cgi?id=46958
Bug ID: 46958
Summary: Out of boundary read in Unwind-EHABI.cpp
Product: Runtime Libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: libunwind
Assignee: unassignedb...@nondot.org
Reporter: leadro...@qq.com
CC: llvm-bugs@lists.llvm.org
File: llvm/llvm-project/blob/master/libunwind/src/Unwind-EHABI.cpp
Function: _Unwind_VRS_Interpret
Length of one bytecode can be 1 or 2 or more. There has been a boundary check
during interpreting in some of them, but still forget the others.
For example:
Intercept with check:
```
case 0xb1: {
if (offset >= len)
return _URC_FAILURE;
uint8_t registers = getByte(data, offset++);
if (registers & 0xf0 || !registers)
return _URC_FAILURE;
_Unwind_VRS_Pop(context, _UVRSC_CORE, registers, _UVRSD_UINT32);
break;
}
```
Intercept without check:
```
case 0xb3: {
uint8_t v = getByte(data, offset++);
_Unwind_VRS_Pop(context, _UVRSC_VFP,
RegisterRange(static_cast(v >> 4),
v & 0x0f), _UVRSD_VFPX);
break;
}
```
I think case 0xb3 needs a boundary check. The same situation: 0xc6, 0xc7, 0xc8,
0xc9.
--
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 46960] New: Templated "constexpr auto" variable cannot be used for SFINAE
https://bugs.llvm.org/show_bug.cgi?id=46960
Bug ID: 46960
Summary: Templated "constexpr auto" variable cannot be used for
SFINAE
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: d25fe...@outlook.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Not sure if they're the same, but it looks like that this one is related to Bug
43459 .
The following snippet compiles on Clang 8, but fails on Clang 9+ (up to trunk),
complaining "value of type 'const auto' is not implicitly convertible to
'bool'":
```cpp
#include
template struct C {
template
static constexpr auto constant_bool_v = sizeof(U) <= 4;
template >>
C(U) {}
};
C vvv('c');
```
Live demo: https://wandbox.org/permlink/b3r89SL8wZ8xyrzc
--
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 24625 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: !Result || (LHS.isSentinel() && LHS.Inst == RHS.Inst) || getHashValueImpl(LHS) =
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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-2020-08-02 Type: Bug New issue 24625 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: !Result || (LHS.isSentinel() && LHS.Inst == RHS.Inst) || getHashValueImpl(LHS) = https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24625 Detailed Report: https://oss-fuzz.com/testcase?key=5651973777653760 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-earlycse Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !Result || (LHS.isSentinel() && LHS.Inst == RHS.Inst) || getHashValueImpl(LHS) = llvm::DenseMapInfo::isEqual bool llvm::DenseMapBasehttps://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202007300603:202007310621 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5651973777653760 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 46961] New: clangd + clang-tidy + modernize-loop-convert = crash
https://bugs.llvm.org/show_bug.cgi?id=46961 Bug ID: 46961 Summary: clangd + clang-tidy + modernize-loop-convert = crash Product: clang-tools-extra Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: clangd Assignee: unassignedclangb...@nondot.org Reporter: marz...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 23808 --> https://bugs.llvm.org/attachment.cgi?id=23808&action=edit game.cc and game.hh, the minimal testcase This was tested on latest version available for Windows 10 x64. For some reason, the version field only allowed me to select "unspecified". The attached files (game.cc and game.hh), along with the following .clang-tidy, form a minimal case that reproduces the crash: Checks: "-*,modernize-loop-convert" A compilation database makes no difference; the crash happens with or without it. clangd is started, in my case, by VSCode using the official llvm clangd extension with the following option active: --clang-tidy Other options can be added at will, but they make no difference. Options I have tried: --background-index --header-insertion=iwyu --header-insertion-decorators --suggest-missing-includes -j=1 --log=verbose When checking the file with these (rather broad) settings, the attached code causes a crash in clangd with the following stack trace: #0 0x0076f51c (C:\msys64\mingw64\bin\clangd.exe+0x36f51c) #1 0x0076f59c (C:\msys64\mingw64\bin\clangd.exe+0x36f59c) #2 0x0076a39b (C:\msys64\mingw64\bin\clangd.exe+0x36a39b) #3 0x00c8fd10 (C:\msys64\mingw64\bin\clangd.exe+0x88fd10) #4 0x00c91c03 (C:\msys64\mingw64\bin\clangd.exe+0x891c03) #5 0x01bd4c1d (C:\msys64\mingw64\bin\clangd.exe+0x17d4c1d) #6 0x01bfd5df (C:\msys64\mingw64\bin\clangd.exe+0x17fd5df) #7 0x01bd618f (C:\msys64\mingw64\bin\clangd.exe+0x17d618f) #8 0x01bf4f74 (C:\msys64\mingw64\bin\clangd.exe+0x17f4f74) #9 0x01bf5b70 (C:\msys64\mingw64\bin\clangd.exe+0x17f5b70) #10 0x01bf5017 (C:\msys64\mingw64\bin\clangd.exe+0x17f5017) #11 0x01beca28 (C:\msys64\mingw64\bin\clangd.exe+0x17eca28) #12 0x01bed50d (C:\msys64\mingw64\bin\clangd.exe+0x17ed50d) #13 0x00956418 (C:\msys64\mingw64\bin\clangd.exe+0x556418) #14 0x00957f78 (C:\msys64\mingw64\bin\clangd.exe+0x557f78) #15 0x0099a7e4 (C:\msys64\mingw64\bin\clangd.exe+0x59a7e4) #16 0x0099777f (C:\msys64\mingw64\bin\clangd.exe+0x59777f) #17 0x0098a49c (C:\msys64\mingw64\bin\clangd.exe+0x58a49c) #18 0x6fd40541 atomic_flag_test_and_set_explicit (C:\msys64\mingw64\bin\libstdc++-6.dll+0x100541) #19 0x64944f2e pthread_create_wrapper (C:\msys64\mingw64\bin\libwinpthread-1.dll+0x4f2e) #20 0x7fff0230b04a (C:\WINDOWS\System32\msvcrt.dll+0x3b04a) #21 0x7fff0230b11c (C:\WINDOWS\System32\msvcrt.dll+ I tried to compile a debug version to get a more usable stack trace, but I gave up after two days of linking. This stack trace was obtained with the "official" msys2 package, but the crash also happens with the official LLVM version. Running clang-tidy on its own does not reproduce the crash. If the checks are inverted (Checks: "*,-modernize-loop-convert"), there is no crash in clangd. Any of the following changes to the test case make the crash go away: - putting everything in only one file; - changing the map's key type to std::string; - manually converting the loop to a range-based for; - using a set instead of a map. Other changes proved to be more irrelevant, and still led to the crash. -- 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 46962] New: Remove impossible branches
https://bugs.llvm.org/show_bug.cgi?id=46962
Bug ID: 46962
Summary: Remove impossible branches
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
unsigned deadbranches(bool A, bool B)
{
if (A || B) {
if (A && B) {
return foo1();
}
else if (A) {
return foo2();
}
else if (B) {
return foo3();
}
else {
return foo5();
}
}
return foo4();
}
else branch: return foo5(); is dead, but Clang does not remove it.
Clang:
deadbranches(bool, bool): # @deadbranches(bool, bool)
testedi, edi
jne .LBB0_2
testsil, sil
jne .LBB0_2
jmp foo4()# TAILCALL
.LBB0_2:
testdil, dil
je .LBB0_4
testsil, sil
je .LBB0_4
jmp foo1()# TAILCALL
.LBB0_4:
testdil, dil
je .LBB0_5
jmp foo2()# TAILCALL
.LBB0_5:
testsil, sil
je .LBB0_6
jmp foo3()# TAILCALL
.LBB0_6:
jmp foo5()# TAILCALL
GCC:
deadbranches(bool, bool):
testdil, dil
jne .L7
testsil, sil
je .L9
.L5:
jmp foo3()
.L9:
jmp foo4()
.L7:
testsil, sil
je .L4
jmp foo1()
.L4:
testdil, dil
je .L5
jmp foo2()
https://godbolt.org/z/Es5z1x
--
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 41638] [X86] Avoid XOR $0, %al in parity generation
https://bugs.llvm.org/show_bug.cgi?id=41638 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||64516ec7c129 --- Comment #2 from Simon Pilgrim --- Craig fixed this in https://reviews.llvm.org/rG64516ec7c1298a4cb16980db49c2f9466f0f3ab5 -- 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 24634 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: RefExpr->isImplicitProperty()
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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-2020-08-02 Type: Bug New issue 24634 by ClusterFuzz-External: llvm:clang-objc-fuzzer: ASSERT: RefExpr->isImplicitProperty() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24634 Detailed Report: https://oss-fuzz.com/testcase?key=5744572131704832 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: RefExpr->isImplicitProperty() clang::Sema::checkPseudoObjectIncDec clang::Sema::BuildUnaryOp Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201910210337:201910220425 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5744572131704832 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 23020] MC misassembles data in .eh_frame with big endian aarch64
https://bugs.llvm.org/show_bug.cgi?id=23020 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||i...@maskray.me --- Comment #1 from Fangrui Song --- GNU as uses big-endian data now.. % aarch64-linux-gnu-as -EB a.s -o a.o % objdump -s a.o a.o: file format elf64-big Contents of section foo: 0004 -- 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 15549] [mc assembler] "b = a + 1" doesn't work right
https://bugs.llvm.org/show_bug.cgi?id=15549 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@maskray.me Resolution|--- |FIXED --- Comment #1 from Fangrui Song --- Works now. -- 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 16525] Drop StripSpaces() function
https://bugs.llvm.org/show_bug.cgi?id=16525 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Fangrui Song --- Removed by rL203429 -- 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 22275] ELF writer corrupts symbol names
https://bugs.llvm.org/show_bug.cgi?id=22275 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27818] MC doesn't produce R_386_GOT32X
https://bugs.llvm.org/show_bug.cgi?id=27818 Fangrui Song changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |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 46963] New: Then-branch and else-branch of the same if-statement should not be the same.（llvm-project/clang/lib/Analysis/ThreadSafety.cpp:2042）
https://bugs.llvm.org/show_bug.cgi?id=46963
Bug ID: 46963
Summary: Then-branch and else-branch of the same if-statement
should not be the
same.（llvm-project/clang/lib/Analysis/ThreadSafety.cpp
:2042）
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: i...@ustchcs.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Then-branch and else-branch of the same if-statement should not be the same.
Same then- and else-statements are found on line 2040 and 2042. Same problem is
found on line 2045 and 2047.
commit e3546c78cabfbf670391a57766872f0a8e28a423
2037 if (ME && MD) {
2038if (ME->isArrow()) {
2039 if (MD->isConst())
2040checkPtAccess(CE->getImplicitObjectArgument(), AK_Read);
2041 else // FIXME -- should be AK_Written
2042checkPtAccess(CE->getImplicitObjectArgument(), AK_Read);
2043} else {
2044 if (MD->isConst())
2045checkAccess(CE->getImplicitObjectArgument(), AK_Read);
2046 else // FIXME -- should be AK_Written
2047checkAccess(CE->getImplicitObjectArgument(), AK_Read);
2048}
2049 }
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-2.1: Then-branch and else-branch of the same if-statement should not
be the same.)
--
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
