[llvm-bugs] [Bug 23260] DebugInfo: Wrong value for inlined formal_parameters of a function inlined twice
https://bugs.llvm.org/show_bug.cgi?id=23260 David Stenberg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from David Stenberg --- (In reply to David Stenberg from comment #2) > Proposed patch: https://reviews.llvm.org/D55513. Merged as r348837. Running the listed command on t.c now gives: $ clang -g -O2 t.c -S -emit-llvm -o - | grep llvm.dbg.value call void @llvm.dbg.value(metadata i32 undef, metadata !10, metadata !DIExpression()) #3, !dbg !16 call void @llvm.dbg.value(metadata i32 undef, metadata !10, metadata !DIExpression()) #3, !dbg !19 declare void @llvm.dbg.value(metadata, metadata, metadata) #2 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31268] Umbrella: debug info for optimized code
https://bugs.llvm.org/show_bug.cgi?id=31268 Bug 31268 depends on bug 23260, which changed state. Bug 23260 Summary: DebugInfo: Wrong value for inlined formal_parameters of a function inlined twice https://bugs.llvm.org/show_bug.cgi?id=23260 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39922] LLD is missing support for ARMv6M thunks
https://bugs.llvm.org/show_bug.cgi?id=39922 Peter Smith changed: What|Removed |Added Fixed By Commit(s)||349337 Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Peter Smith --- Committed support for v6 Thunks in r349337 resolving for 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #23 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c23 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-4409758c-6dd8-4d16-8291-22c62cc87a27.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40046] New: clang-format fails formatting basic C++11 code
https://bugs.llvm.org/show_bug.cgi?id=40046 Bug ID: 40046 Summary: clang-format fails formatting basic C++11 code Product: clang Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Tooling Assignee: unassignedclangb...@nondot.org Reporter: priv...@bernhard-lindner.de CC: llvm-bugs@lists.llvm.org I evaluated clang-format with one of my projects. Evaluation failed due to following problems 1. There is no way of adding missing empty lines (e.g. between function definitions). There should be explicit options for mandatory empty lines. 2. I was not able to configure correct class indention (public: 3 spaces, class members: 6 spaces, function definition: 3 spaces). There should be separate options for indention of class members and function definitions. 3. Wrapping of constructor initialize lists fails as soon as "BreakConstructorInitializers: AfterColon" is accompanied by a "ColumnLimit: '160'". ColumnLimit seems to break BreakConstructorInitializers completely. See also https://stackoverflow.com/q/53797967/1421332. 4. Wrapping of template specifications seems to work in one direction only. If "template " is in one line with the function, a line break is added properly if required by "AlwaysBreakTemplateDeclarations: Yes". However when having "template " in a separate line, the line break is not removed as required by "AlwaysBreakTemplateDeclarations: No". Please fix these issues. clang-format is very promising. I am eager to evaluate it again. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40047] New: [macOS] TestConcurrentSignalWatchBreak.py fails spuriously
https://bugs.llvm.org/show_bug.cgi?id=40047 Bug ID: 40047 Summary: [macOS] TestConcurrentSignalWatchBreak.py fails spuriously Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: martongab...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 21235 --> https://bugs.llvm.org/attachment.cgi?id=21235&action=edit output of test execution Executing 'ninja check-lldb' produced a fail in TestConcurrentSignalWatchBreak.py. However, when I executed the test with './bin/lldb-dotest -p TestConcurrentSignalWatchBreak.py' the test passed. So, this test sometimes fail, sometimes pass. I suspect some thread synchronization issue or a wait/poll problem here. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40048] New: TestCppNsImport.py fails on Linux
https://bugs.llvm.org/show_bug.cgi?id=40048 Bug ID: 40048 Summary: TestCppNsImport.py fails on Linux Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: martongab...@gmail.com CC: llvm-bugs@lists.llvm.org Ubuntu 16.04, x86_64 (I did not experienced this error on macOS) During the execution of ninja check-lldb: FAIL: lldb-Suite :: lang/cpp/nsimport/TestCppNsImport.py (575 of 1410) TEST 'lldb-Suite :: lang/cpp/nsimport/TestCppNsImport.py' FAILED lldb version 8.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk revision 349316) clang revision 349336 llvm revision 349338 LLDB library dir: /home/egbomrt/WORK/llvm3/build/release_assert/bin LLDB import library dir: /home/egbomrt/WORK/llvm3/build/release_assert/bin The 'lldb-vscode' executable cannot be located. The lldb-vscode tests can not be run as a result. Skipping following debug info categories: ['dsym', 'gmodules'] Session logs for test failures/errors/unexpected successes will go into directory '/home/egbomrt/WORK/llvm3/build/release_assert/lldb-test-traces' Command invoked: /home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 -s /home/egbomrt/WORK/llvm3/build/release_assert/lldb-test-traces --build-dir /home/egbomrt/WORK/llvm3/build/release_assert/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS --executable /home/egbomrt/WORK/llvm3/build/release_assert/./bin/lldb --dsymutil /home/egbomrt/WORK/llvm3/build/release_assert/./bin/dsymutil --filecheck /home/egbomrt/WORK/llvm3/build/release_assert/./bin/FileCheck -C /home/egbomrt/WORK/llvm3/build/release_assert/./bin/clang --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy /home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/nsimport -p TestCppNsImport.py UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_with_run_command_dsym (TestCppNsImport.TestCppNsImport) (test case does not fall in any category of interest for this run) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_with_run_command_dwarf (TestCppNsImport.TestCppNsImport) FAIL: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_with_run_command_dwo (TestCppNsImport.TestCppNsImport) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_with_run_command_gmodules (TestCppNsImport.TestCppNsImport) (test case does not fall in any category of interest for this run) == FAIL: test_with_run_command_dwo (TestCppNsImport.TestCppNsImport) Tests imported namespaces in C++. -- Traceback (most recent call last): File "/home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1743, in test_method return attrvalue(self) File "/home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py", line 112, in test_with_run_command "imported = 99") AssertionError: False is not True : imported = 99 Config=x86_64-/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8 -- Ran 4 tests in 1.797s RESULT: FAILED (1 passes, 1 failures, 0 errors, 2 skipped, 0 expected failures, 0 unexpected successes) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40049] New: TestNamespace.py fails on Linux
https://bugs.llvm.org/show_bug.cgi?id=40049 Bug ID: 40049 Summary: TestNamespace.py fails on Linux Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: martongab...@gmail.com CC: llvm-bugs@lists.llvm.org Ubuntu 16.04, x86_64 (I did not experienced this error on macOS) During the execution of ninja check-lldb: FAIL: lldb-Suite :: lang/cpp/namespace/TestNamespace.py (588 of 1410) TEST 'lldb-Suite :: lang/cpp/namespace/TestNamespace.py' FAILED lldb version 8.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk revision 349316) clang revision 349336 llvm revision 349338 LLDB library dir: /home/egbomrt/WORK/llvm3/build/release_assert/bin LLDB import library dir: /home/egbomrt/WORK/llvm3/build/release_assert/bin The 'lldb-vscode' executable cannot be located. The lldb-vscode tests can not be run as a result. Skipping following debug info categories: ['dsym', 'gmodules'] Session logs for test failures/errors/unexpected successes will go into directory '/home/egbomrt/WORK/llvm3/build/release_assert/lldb-test-traces' Command invoked: /home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 -s /home/egbomrt/WORK/llvm3/build/release_assert/lldb-test-traces --build-dir /home/egbomrt/WORK/llvm3/build/release_assert/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS --executable /home/egbomrt/WORK/llvm3/build/release_assert/./bin/lldb --dsymutil /home/egbomrt/WORK/llvm3/build/release_assert/./bin/dsymutil --filecheck /home/egbomrt/WORK/llvm3/build/release_assert/./bin/FileCheck -C /home/egbomrt/WORK/llvm3/build/release_assert/./bin/clang --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy /home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/namespace -p TestNamespace.py UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_a_func_full_dsym (TestNamespace.NamespaceBreakpointTestCase) (test case does not fall in any category of interest for this run) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_a_func_full_dwarf (TestNamespace.NamespaceBreakpointTestCase) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_a_func_full_dwo (TestNamespace.NamespaceBreakpointTestCase) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_a_func_full_gmodules (TestNamespace.NamespaceBreakpointTestCase) (test case does not fall in any category of interest for this run) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_func_auto_dsym (TestNamespace.NamespaceBreakpointTestCase) (test case does not fall in any category of interest for this run) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_func_auto_dwarf (TestNamespace.NamespaceBreakpointTestCase) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_func_auto_dwo (TestNamespace.NamespaceBreakpointTestCase) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_func_auto_gmodules (TestNamespace.NamespaceBreakpointTestCase) (test case does not fall in any category of interest for this run) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_func_full_dsym (TestNamespace.NamespaceBreakpointTestCase) (test case does not fall in any category of interest for this run) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_func_full_dwarf (TestNamespace.NamespaceBreakpointTestCase) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_func_full_dwo (TestNamespace.NamespaceBreakpointTestCase) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_breakpoints_func_full_gmodules (TestNamespace.NamespaceBreakpointTestCase) (test case does not fall in any category of interest for this run) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_with_run_command_dsym (TestNamespace.NamespaceTestCase) (test case does not fall in any category of interest for this run) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_with_run_command_dwarf (TestNamespace.NamespaceTestCase) FAIL: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_with_run_command_dwo (TestNamespace.NamespaceTestCase) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang
[llvm-bugs] [Bug 40050] New: TestCompDirSymLink.py fails on Linux
https://bugs.llvm.org/show_bug.cgi?id=40050 Bug ID: 40050 Summary: TestCompDirSymLink.py fails on Linux Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: martongab...@gmail.com CC: llvm-bugs@lists.llvm.org Ubuntu 16.04, x86_64 (I did not experienced this error on macOS) During the execution of ninja check-lldb: FAIL: lldb-Suite :: functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.py (209 of 1410) TEST 'lldb-Suite :: functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.py' FAILED lldb version 8.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk revision 349316) clang revision 349336 llvm revision 349338 LLDB library dir: /home/egbomrt/WORK/llvm3/build/release_assert/bin LLDB import library dir: /home/egbomrt/WORK/llvm3/build/release_assert/bin The 'lldb-vscode' executable cannot be located. The lldb-vscode tests can not be run as a result. Skipping following debug info categories: ['dsym', 'gmodules'] Session logs for test failures/errors/unexpected successes will go into directory '/home/egbomrt/WORK/llvm3/build/release_assert/lldb-test-traces' Command invoked: /home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 -s /home/egbomrt/WORK/llvm3/build/release_assert/lldb-test-traces --build-dir /home/egbomrt/WORK/llvm3/build/release_assert/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS --executable /home/egbomrt/WORK/llvm3/build/release_assert/./bin/lldb --dsymutil /home/egbomrt/WORK/llvm3/build/release_assert/./bin/dsymutil --filecheck /home/egbomrt/WORK/llvm3/build/release_assert/./bin/FileCheck -C /home/egbomrt/WORK/llvm3/build/release_assert/./bin/clang --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy /home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/comp_dir_symlink -p TestCompDirSymLink.py UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_set_dsym (TestCompDirSymLink.CompDirSymLinkTestCase) (test case does not fall in any category of interest for this run) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_set_dwarf (TestCompDirSymLink.CompDirSymLinkTestCase) FAIL: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_set_dwo (TestCompDirSymLink.CompDirSymLinkTestCase) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_set_gmodules (TestCompDirSymLink.CompDirSymLinkTestCase) (test case does not fall in any category of interest for this run) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_set_procselfcwd_dsym (TestCompDirSymLink.CompDirSymLinkTestCase) (test case does not fall in any category of interest for this run) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_set_procselfcwd_dwarf (TestCompDirSymLink.CompDirSymLinkTestCase) FAIL: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_set_procselfcwd_dwo (TestCompDirSymLink.CompDirSymLinkTestCase) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_set_procselfcwd_gmodules (TestCompDirSymLink.CompDirSymLinkTestCase) (test case does not fall in any category of interest for this run) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_unset_dsym (TestCompDirSymLink.CompDirSymLinkTestCase) (test case does not fall in any category of interest for this run) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_unset_dwarf (TestCompDirSymLink.CompDirSymLinkTestCase) PASS: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_unset_dwo (TestCompDirSymLink.CompDirSymLinkTestCase) UNSUPPORTED: LLDB (/home/egbomrt/WORK/llvm3/build/release_assert/bin/clang-8-x86_64) :: test_symlink_paths_unset_gmodules (TestCompDirSymLink.CompDirSymLinkTestCase) (test case does not fall in any category of interest for this run) == FAIL: test_symlink_paths_set_dwo (TestCompDirSymLink.CompDirSymLinkTestCase) -- Traceback (most recent call last): File "/home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1743, in test_method return attrvalue(self) File "/home/egbomrt/WORK/llvm3/git/llvm/tools/lldb/packages/Python/lldb
[llvm-bugs] [Bug 40051] New: Incorrect optimisation of memswap routine results in loop crash
https://bugs.llvm.org/show_bug.cgi?id=40051 Bug ID: 40051 Summary: Incorrect optimisation of memswap routine results in loop crash Product: new-bugs Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: aidan.ch...@stfc.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21236 --> https://bugs.llvm.org/attachment.cgi?id=21236&action=edit tar containing the C source, plus .ll and .bc files from running through bugpoint process bash-4.2$ clang -v clang version 6.0.0 (tags/RELEASE_600/final) OS: RedHat 7.4 Platform: x86 (replicated on aarch64) Attached .tar contains: C code: cell.h cell_split.c main.c memswap.h To compile the (crashing code) you just need clang -O1 cell_split.c main.c -O2 and -O3 also result in a seg fault. Code runs correctly with -O0 (program runs, no output is correct). Code also works with gcc8 at all optimisation levels. Adding a __sync_synchronize() statement to memswap.h line 60 and compiling with -std=gnu99 causes the program to run correctly at all optimisation levels we tested (-O3/-Ofast/-O2/-O1/-O0), however this fence should not be needed for this example. I ran bugpoint -llc-safe -O3 cell_split.ll main.ll on the .ll files created by clang It believes that opt bugpoint-reduced-instructions.bc -ee-instrument -tbaa -scoped-noalias -simplifycfg -sroa -early-cse -lower-expect -forceattrs -tbaa -scoped-noalias -inferattrs -ipsccp -called-value-propagation -globalopt -mem2reg -deadargelim -instcombine -simplifycfg -globals-aa -prune-eh -inline -functionattrs -sroa -early-cse-memssa -speculative-execution -jump-threading -correlated-propagation -simplifycfg -instcombine -libcalls-shrinkwrap -pgo-memop-opt -tailcallelim -simplifycfg -reassociate -loop-rotate -licm -loop-unswitch -simplifycfg -instcombine -indvars -loop-idiom -loop-deletion -loop-unroll -mldst-motion -gvn -memcpyopt -sccp -bdce -instcombine -jump-threading -correlated-propagation -dse -licm -adce -simplifycfg -instcombine -barrier -elim-avail-extern -rpo-functionattrs -globalopt -globaldce -globals-aa -float2int -loop-rotate -loop-distribute -loop-vectorize -loop-load-elim -instcombine -simplifycfg -instcombine -loop-unroll -instcombine -licm -alignment-from-assumptions -strip-dead-prototypes -globaldce -constmerge -loop-sink -instsimplify -div-rem-pairs -simplifycfg should replicate the bug with reduced 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11791 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExtProtoInfo
Comment #1 on issue 11791 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExtProtoInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11791#c1 ClusterFuzz has detected this issue as fixed in range 201812160234:201812170233. Detailed report: https://oss-fuzz.com/testcase?key=5636511282757632 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc0f75aac8 Crash State: clang::FunctionProtoType::getExtProtoInfo clang::FunctionProtoType::Profile llvm::ContextualFoldingSetclang::ASTContext&>::NodeEq Sanitizer: address (ASAN) Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812160234:201812170233 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5636511282757632 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11892 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in GetFullTypeForDeclarator
Comment #1 on issue 11892 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in GetFullTypeForDeclarator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11892#c1 ClusterFuzz has detected this issue as fixed in range 201812160234:201812170233. Detailed report: https://oss-fuzz.com/testcase?key=5662291991724032 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd585b3d98 Crash State: GetFullTypeForDeclarator clang::Sema::GetTypeForDeclarator clang::Sema::ActOnBlockArguments Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812130233:201812140233 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812160234:201812170233 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5662291991724032 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11886 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Comment #1 on issue 11886 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11886#c1 ClusterFuzz has detected this issue as fixed in range 201812160234:201812170233. Detailed report: https://oss-fuzz.com/testcase?key=5766131214712832 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc628a1b28 Crash State: clang::DiagnosticIDs::isUnrecoverable clang::DiagnosticIDs::ProcessDiag clang::DiagnosticsEngine::EmitCurrentDiagnostic Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812120232:201812130233 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812160234:201812170233 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5766131214712832 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40052] New: boost::regex match but not std::regex
https://bugs.llvm.org/show_bug.cgi?id=40052 Bug ID: 40052 Summary: boost::regex match but not std::regex Product: libc++ Version: 6.0 Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: georg-...@schorsch-tech.de CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Created attachment 21237 --> https://bugs.llvm.org/attachment.cgi?id=21237&action=edit Testcase I got the attached program. It has a global locale set (de_DE.UTF-8). I think it might be a bug in libc++ because on Windows(MSVC 2013 & MSVC 2017) and on Linux (gcc 8.2 + libstdc++) this regex (from std) matches with the global locale from boost. Also the regex from boost matches (replace std::regex by boost::regex). This bug triggers only (also on my box and only on freebsd with clang and libc++) when i use boost::locale. With std::locale() it matches. I already submitted this bug to FreeBSD and to boost.org. For reference, here are the links https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233994 Boost.locale says: [quote] Boost.Regex and Boost.Locale aren't related, the locale generated by Boost.Locale is "C" locale with addons unrelated to Boost.Regex [/quote] https://github.com/boostorg/locale/issues/35 FreeBSD says, it is a bug in boost.locale. As both of my direct upstream bugtrackers seem to "dislike" this bug, i report it to clang/libc++ directly. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11791 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExtProtoInfo
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 11791 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExtProtoInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11791#c2 ClusterFuzz testcase 5636511282757632 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11892 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in GetFullTypeForDeclarator
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 11892 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in GetFullTypeForDeclarator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11892#c2 ClusterFuzz testcase 5662291991724032 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11886 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 11886 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11886#c2 ClusterFuzz testcase 5766131214712832 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40053] New: _mm_adds_epu8 and _mm_subs_epu8 with constant operand don't generate paddusb/psubusb
https://bugs.llvm.org/show_bug.cgi?id=40053
Bug ID: 40053
Summary: _mm_adds_epu8 and _mm_subs_epu8 with constant operand
don't generate paddusb/psubusb
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: aman...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
It seems that instruction selection can't see through the transformations done
on the constants.
This is a regression from 7.0 where these intrinsics would compile to a single
instruction.
Source:
#include
__m128i test_add(__m128i x) {
__m128i c = _mm_set1_epi8(1);
return _mm_adds_epu8(x, c);
}
__m128i test_sub(__m128i x) {
__m128i c = _mm_set1_epi8(1);
return _mm_subs_epu8(x, c);
}
Assembly (trunk):
test_add:
pcmpeqd xmm1, xmm1
movdqa xmm2, xmm0
psubb xmm2, xmm1
pcmpeqb xmm0, xmm1
por xmm0, xmm2
ret
.LCPI1_0:
.zero 16,1
test_sub:
pmaxub xmm0, xmmword ptr [rip + .LCPI1_0]
pcmpeqd xmm1, xmm1
paddb xmm0, xmm1
ret
Assembly (7.0):
.LCPI0_0:
.zero 16,1
test_add:
paddusb .LCPI0_0(%rip), %xmm0
retq
.LCPI1_0:
.zero 16,1
test_sub:
psubusb .LCPI1_0(%rip), %xmm0
retq
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11901 in oss-fuzz: llvm/clang-format-fuzzer: ASSERT: Changes[i - 1].OriginalWhitespaceRange.getBegin() != C.OriginalWhitespaceRange.g
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@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 Proj-llvm Reported-2018-12-17 Type: Bug New issue 11901 by ClusterFuzz-External: llvm/clang-format-fuzzer: ASSERT: Changes[i - 1].OriginalWhitespaceRange.getBegin() != C.OriginalWhitespaceRange.g https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11901 Detailed report: https://oss-fuzz.com/testcase?key=5746022781812736 Project: llvm Fuzzer: libFuzzer_llvm_clang-format-fuzzer Fuzz target binary: clang-format-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Changes[i - 1].OriginalWhitespaceRange.getBegin() != C.OriginalWhitespaceRange.g clang::format::WhitespaceManager::generateChanges clang::format::WhitespaceManager::generateReplacements Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201711100614:20170618 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5746022781812736 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md 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. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10631 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (!RS || !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out
Updates: Labels: Deadline-Approaching Comment #4 on issue 10631 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (!RS | | !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10631#c4 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40033] Unittest Sema/./SemaTests.exe/PreferredTypeTest.BinaryExpr failing when host and target have differing sizes for types
https://bugs.llvm.org/show_bug.cgi?id=40033 ibiryu...@google.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from ibiryu...@google.com --- r349362 should fix this, sorry about the inconvenience. > I tried to figure out how to set the target to something fixed. I've also thought about this at first, but I'm not sure if any targets are available unconditionally, so ended up propagating the type of ptrdiff_t from the compiler invocation to the test instead. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40054] New: llvm-readelf/readobj: add support for demangling
https://bugs.llvm.org/show_bug.cgi?id=40054 Bug ID: 40054 Summary: llvm-readelf/readobj: add support for demangling Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org llvm-readelf (and llvm-readobj) produces symbol names in various locations, such as in the symbol table dump. These names are simply the raw symbol name, i.e. the mangled name. It would be useful if llvm-readelf had an option to print the demangled name instead. GNU readelf does not have an equivalent switch, but I would recommend -C/--demangle, since that is the same name as for GNU objdump, nm, and addr2line. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40055] New: [AArch64] Suboptimal immediate encoding with add/sub
https://bugs.llvm.org/show_bug.cgi?id=40055 Bug ID: 40055 Summary: [AArch64] Suboptimal immediate encoding with add/sub Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: aman...@gmail.com CC: arnaud.degrandmai...@arm.com, llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, ties.st...@arm.com This IR: %2 = sub i64 %0, 72340172838076673 ; 0x0101010101010101 Generates the following assembly: mov x8, #-72340172838076674 movkx8, #65279 add x0, x0, x8 However the immediate can be encoded in a single instruction if it is not negated: mov x8, #72340172838076673 sub x0, x0, x8 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40056] New: [X86][SSE] Replace X86ISD ADD\SUB saturation opcodes with ISD generics
https://bugs.llvm.org/show_bug.cgi?id=40056 Bug ID: 40056 Summary: [X86][SSE] Replace X86ISD ADD\SUB saturation opcodes with ISD generics Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, nikita@gmail.com, spatel+l...@rotateright.com As mentioned on [Bug #40053] we now should be able to replace the X86 specific ADDS/SUBS/ADDUS/SUBUS opcodes+intrinsics with the generic add/sub saturations equivalents - both in the frontend and the backend. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40032] instcombine forms illegal <2 x i64> multiply with trunc/zext
https://bugs.llvm.org/show_bug.cgi?id=40032
Sanjay Patel changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #6 from Sanjay Patel ---
Should be fixed after:
https://reviews.llvm.org/rL349389
ARM v7a +neon codegen looks something like this now for the example in the
description:
vmovd19, r2, r3
mov r12, sp
vld1.64 {d16, d17}, [r12]
vmovd18, r0, r1
vmovn.i64 d16, q8
vmovn.i64 d17, q9
vmla.i32d17, d16, d16
vmovl.u32 q8, d17
vmovr0, r1, d16
vmovr2, r3, d17
bx lr
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34924] Remove 'zero shift' guards from rotation patterns
https://bugs.llvm.org/show_bug.cgi?id=34924 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Sanjay Patel --- Should be fixed (at -O3) after: https://reviews.llvm.org/rL349396 Asm for x86-64 target is: _rotl: ## @rotl movl%esi, %ecx movl%edi, %eax roll%cl, %eax retq _rotr: ## @rotr movl%esi, %ecx movl%edi, %eax rorl%cl, %eax retq -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39384] br_table is not supported in WebAssemblyAsmParser
https://bugs.llvm.org/show_bug.cgi?id=39384 Wouter van Oortmerssen 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40057] New: Emit longjmp target tables under /guard:cf, nochecks so users don't need /guard:cf, nolongjmp
https://bugs.llvm.org/show_bug.cgi?id=40057 Bug ID: 40057 Summary: Emit longjmp target tables under /guard:cf,nochecks so users don't need /guard:cf,nolongjmp Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: amcca...@google.com, dma...@mozilla.com, h...@chromium.org, llvm-bugs@lists.llvm.org Both Firefox and Chromium link with /guard:cf,nolongjmp right now because clang-cl doesn't emit the control flow guard tables of setjmp return addresses. Eventually, we may want to implement full control flow guard, but at the very least, we can emit every setjmp return address to make it so that users don't have to pass this extra linker flag. Hans added the "nochecks" option back in https://reviews.llvm.org/D50513 / r339420. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40058] New: Failure to detect bswap at the end of a bitreverse sequence
https://bugs.llvm.org/show_bug.cgi?id=40058
Bug ID: 40058
Summary: Failure to detect bswap at the end of a bitreverse
sequence
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org
We should recognize that these two sequences end in a bswap.
unsigned long lreverse(unsigned long x)// swap all bits
{
x = ((x & 0xUL) >> 1)
| ((x & ~0xUL) << 1);
x = ((x & 0xUL) >> 2)
| ((x & ~0xUL) << 2);
x = ((x & 0xF0F0F0F0UL) >> 4)
| ((x & ~0xF0F0F0F0UL) << 4);
x = ((x & 0xFF00FF00UL) >> 8)
| ((x & ~0xFF00FF00UL) << 8);
x = ((x & 0xUL) >> 16)
| ((x & ~0xUL) << 16);
return x;
}
unsigned long long llreverse(unsigned long long x)
{
x = ((x & 0xULL) >> 1)
| ((x & ~0xULL) << 1);
x = ((x & 0xULL) >> 2)
| ((x & ~0xULL) << 2);
x = ((x & 0xF0F0F0F0F0F0F0F0ULL) >> 4)
| ((x & ~0xF0F0F0F0F0F0F0F0ULL) << 4);
x = ((x & 0xFF00FF00FF00FF00ULL) >> 8)
| ((x & ~0xFF00FF00FF00FF00ULL) << 8);
x = ((x & 0xULL) >> 16)
| ((x & ~0xULL) << 16);
x = ((x & 0xULL) >> 32)
| ((x & ~0xULL) << 32);
return x;
}
https://godbolt.org/z/K0FuOg
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40059] New: Error in static libraries for LLVM 7 on Debian 9
https://bugs.llvm.org/show_bug.cgi?id=40059 Bug ID: 40059 Summary: Error in static libraries for LLVM 7 on Debian 9 Product: Packaging Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: maxime.arth...@nasa.gov CC: llvm-bugs@lists.llvm.org Hello, It looks like there is something wrong with the static libraries provided by llvm-7-dev on Debian 9.6 I'm getting link errors when I try to compile my tool. root@f67f01e4d08f:~/ikos/build# make all [...] [ 35%] Linking CXX executable ikos-pp /usr/bin/ld: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriterPass.cpp.o): SHT_GROUP section [index 24] has no SHF_GROUP sections /usr/bin/ld: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriterPass.cpp.o): SHT_GROUP section [index 25] has no SHF_GROUP sections /usr/bin/ld: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriterPass.cpp.o): SHT_GROUP section [index 26] has no SHF_GROUP sections /usr/bin/ld: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriterPass.cpp.o): SHT_GROUP section [index 24] has no SHF_GROUP sections /usr/bin/ld: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriterPass.cpp.o): SHT_GROUP section [index 25] has no SHF_GROUP sections /usr/bin/ld: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriterPass.cpp.o): SHT_GROUP section [index 26] has no SHF_GROUP sections /usr/lib/llvm-7/lib/libLLVMBitWriter.a: error adding symbols: File format not recognized collect2: error: ld returned 1 exit status frontend/llvm/CMakeFiles/ikos-pp.dir/build.make:134: recipe for target 'frontend/llvm/ikos-pp' failed make[2]: *** [frontend/llvm/ikos-pp] Error 1 CMakeFiles/Makefile2:1547: recipe for target 'frontend/llvm/CMakeFiles/ikos-pp.dir/all' failed make[1]: *** [frontend/llvm/CMakeFiles/ikos-pp.dir/all] Error 2 Makefile:138: recipe for target 'all' failed make: *** [all] Error 2 It seems like all the .a have an invalid format: root@f67f01e4d08f:~/ikos/build# nm /usr/lib/llvm-7/lib/libLLVMBitWriter.a BitWriter.cpp.o: T LLVMWriteBitcodeToFD T LLVMWriteBitcodeToFile T LLVMWriteBitcodeToFileHandle T LLVMWriteBitcodeToMemoryBuffer U _ZN4llvm11raw_ostream14flush_nonemptyEv U _ZN4llvm12MemoryBuffer16getMemBufferCopyENS_9StringRefERKNS_5TwineE U _ZN4llvm14raw_fd_ostreamC1ENS_9StringRefERSt10error_codeNS_3sys2fs9OpenFlagsE U _ZN4llvm14raw_fd_ostreamC1Eibb U _ZN4llvm14raw_fd_ostreamD1Ev U _ZN4llvm18WriteBitcodeToFileERKNS_6ModuleERNS_11raw_ostreamEbPKNS_18ModuleSummaryIndexEbPSt5arrayIjLm5EE U _ZN4llvm18raw_string_ostreamD1Ev U _ZN4llvm24DisableABIBreakingChecksE V _ZN4llvm30VerifyDisableABIBreakingChecksE U _ZNSt3_V215system_categoryEv U _ZTVN4llvm18raw_string_ostreamE U _ZdlPv U strlen nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriter.cpp.o): SHT_GROUP section [index 179] has no SHF_GROUP sections nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriter.cpp.o): SHT_GROUP section [index 180] has no SHF_GROUP sections nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriter.cpp.o): SHT_GROUP section [index 181] has no SHF_GROUP sections [...] nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriter.cpp.o): SHT_GROUP section [index 277] has no SHF_GROUP sections nm: BitcodeWriter.cpp.o: File format not recognized nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriterPass.cpp.o): SHT_GROUP section [index 24] has no SHF_GROUP sections nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriterPass.cpp.o): SHT_GROUP section [index 25] has no SHF_GROUP sections nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(BitcodeWriterPass.cpp.o): SHT_GROUP section [index 26] has no SHF_GROUP sections [...] nm: BitcodeWriterPass.cpp.o: File format not recognized nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(ValueEnumerator.cpp.o): SHT_GROUP section [index 94] has no SHF_GROUP sections nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(ValueEnumerator.cpp.o): SHT_GROUP section [index 95] has no SHF_GROUP sections nm: /usr/lib/llvm-7/lib/libLLVMBitWriter.a(ValueEnumerator.cpp.o): SHT_GROUP section [index 96] has no SHF_GROUP sections [...] nm: ValueEnumerator.cpp.o: File format not recognized To reproduce: # echo "deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch-7 main" >> /etc/apt/sources.list # apt-get update # apt-get install -y --allow-unauthenticated llvm-7-dev # nm /usr/lib/llvm-7/lib/libLLVMBitWriter.a Bug report on IKOS: https://github.com/NASA-SW-VnV/ikos/issues/23 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mai
[llvm-bugs] Issue 11904 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Preprocessor::PeekAhead
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@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 Proj-llvm Reported-2018-12-18 Type: Bug New issue 11904 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Preprocessor::PeekAhead https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11904 Detailed report: https://oss-fuzz.com/testcase?key=5699682097954816 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffde0e4ded8 Crash State: clang::Preprocessor::PeekAhead clang::Parser::isCXX11AttributeSpecifier clang::Parser::ParseDeclarationSpecifiers Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812160234:201812170233 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5699682097954816 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md 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. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40043] Multibyte NOPs not used for padding
https://bugs.llvm.org/show_bug.cgi?id=40043 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r349436 Status|NEW |RESOLVED --- Comment #4 from Reid Kleckner --- r349436 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40043] Multibyte NOPs not used for padding
https://bugs.llvm.org/show_bug.cgi?id=40043 Peter Collingbourne changed: What|Removed |Added CC||pe...@pcc.me.uk Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #5 from Peter Collingbourne --- I don't think this is fixed yet, I see no code in the clang driver that produces an lld-link argument like /mllvm:-mcpu=something. I guess we could add code that does that if -fuse-ld=lld is passed, but the real fix would be to cause clang-cl to add a function attribute that causes multi-byte nops to be emitted. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40060] New: [X86] optimizeCompareInstr can use the S flag from the BEXTR instruction which is undefined
https://bugs.llvm.org/show_bug.cgi?id=40060
Bug ID: 40060
Summary: [X86] optimizeCompareInstr can use the S flag from the
BEXTR instruction which is undefined
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
With BMI1 this code will use the BEXTR instruction and use the S flag from the
BEXTR instruction directly. But BEXTR doesn't update the S flag with a
meaningful value.
define dso_local void @_Z3foojj(i32, i32) local_unnamed_addr #0 {
%3 = sub i32 32, %1
%4 = lshr i32 -1, %3
%5 = and i32 %4, %0
%6 = icmp sgt i32 %5, -1
br i1 %6, label %7, label %8
tail call void @_Z3barv()
br label %8
ret void
}
Output
foo(unsigned int, unsigned int): # @foo(unsigned
int, unsigned int)
shl esi, 8
bextr eax, edi, esi
js .LBB0_1
jmp bar() # TAILCALL
.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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40061] New: Greedy Register Allocator fires an assert
https://bugs.llvm.org/show_bug.cgi?id=40061 Bug ID: 40061 Summary: Greedy Register Allocator fires an assert Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: serguei.kat...@azul.com CC: llvm-bugs@lists.llvm.org, quentin.colom...@gmail.com Created attachment 21240 --> https://bugs.llvm.org/attachment.cgi?id=21240&action=edit Reproducer The following assert is fired in Greedy Register allocator after the commit https://reviews.llvm.org/rL339035: $ ~/work/llvm/build/buildDA/bin/llc -late-remat-update-threshold=0 -code-model=large 1.ll -o /dev/null llc: /home/skatkov/work/llvm/src/include/llvm/ADT/IntervalMap.h:631: unsigned int llvm::IntervalMapImpl::LeafNode::insertFrom(unsigned int&, unsigned int, KeyT, KeyT, ValT) [with KeyT = llvm::SlotIndex; ValT = unsigned int; unsigned int N = 9u; Traits = llvm::IntervalMapInfo]: Assertion `!Traits::stopLess(b, a) && "Invalid interval"' failed. Stack dump: 0. Program arguments: /home/skatkov/work/llvm/build/buildDA/bin/llc -late-remat-update-threshold=0 -code-model=large 1.ll -o /dev/null 1. Running pass 'Function Pass Manager' on module '1.ll'. 2. Running pass 'Greedy Register Allocator' on function '@test' #0 0x7fe0eebbdbc5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/skatkov/work/llvm/src/lib/Support/Unix/Signals.inc:495:0 #1 0x7fe0eebbdc56 PrintStackTraceSignalHandler(void*) /home/skatkov/work/llvm/src/lib/Support/Unix/Signals.inc:559:0 #2 0x7fe0eebbbc91 llvm::sys::RunSignalHandlers() /home/skatkov/work/llvm/src/lib/Support/Signals.cpp:67:0 #3 0x7fe0eebbd669 SignalHandler(int) /home/skatkov/work/llvm/src/lib/Support/Unix/Signals.inc:358:0 #4 0x7fe0ebacd6d0 __restore_rt (/lib64/libpthread.so.0+0xf6d0) #5 0x7fe0eaef7277 __GI_raise /usr/src/debug/glibc-2.17-c758a686/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #6 0x7fe0eaef8968 __GI_abort /usr/src/debug/glibc-2.17-c758a686/stdlib/abort.c:92:0 #7 0x7fe0eaef0096 __assert_fail_base /usr/src/debug/glibc-2.17-c758a686/assert/assert.c:92:0 #8 0x7fe0eaef0142 (/lib64/libc.so.6+0x2f142) #9 0x7fe0ef34e0c4 llvm::IntervalMapImpl::LeafNode >::insertFrom(unsigned int&, unsigned int, llvm::SlotIndex, llvm::SlotIndex, unsigned int) /home/skatkov/work/llvm/src/include/llvm/ADT/IntervalMap.h:634:0 #10 0x7fe0ef34c89f llvm::IntervalMap >::insert(llvm::SlotIndex, llvm::SlotIndex, unsigned int) /home/skatkov/work/llvm/src/include/llvm/ADT/IntervalMap.h:1089:0 #11 0x7fe0ef34423c llvm::SplitEditor::useIntv(llvm::SlotIndex, llvm::SlotIndex) /home/skatkov/work/llvm/src/lib/CodeGen/SplitKit.cpp:755:0 #12 0x7fe0ef349321 llvm::SplitEditor::splitSingleBlock(llvm::SplitAnalysis::BlockInfo const&) /home/skatkov/work/llvm/src/lib/CodeGen/SplitKit.cpp:1580:0 #13 0x7fe0ef289da0 (anonymous namespace)::RAGreedy::splitAroundRegion(llvm::LiveRangeEdit&, llvm::ArrayRef) /home/skatkov/work/llvm/src/lib/CodeGen/RegAllocGreedy.cpp:1708:0 #14 0x7fe0ef28ba26 (anonymous namespace)::RAGreedy::doRegionSplit(llvm::LiveInterval&, unsigned int, bool, llvm::SmallVectorImpl&) /home/skatkov/work/llvm/src/lib/CodeGen/RegAllocGreedy.cpp:1995:0 #15 0x7fe0ef28a959 (anonymous namespace)::RAGreedy::tryRegionSplit(llvm::LiveInterval&, llvm::AllocationOrder&, llvm::SmallVectorImpl&) /home/skatkov/work/llvm/src/lib/CodeGen/RegAllocGreedy.cpp:1856:0 #16 0x7fe0ef28e6a2 (anonymous namespace)::RAGreedy::trySplit(llvm::LiveInterval&, llvm::AllocationOrder&, llvm::SmallVectorImpl&) /home/skatkov/work/llvm/src/lib/CodeGen/RegAllocGreedy.cpp:2483:0 #17 0x7fe0ef290a78 (anonymous namespace)::RAGreedy::selectOrSplitImpl(llvm::LiveInterval&, llvm::SmallVectorImpl&, llvm::SmallSet >&, unsigned int) /home/skatkov/work/llvm/src/lib/CodeGen/RegAllocGreedy.cpp:3082:0 #18 0x7fe0ef28f814 (anonymous namespace)::RAGreedy::selectOrSplit(llvm::LiveInterval&, llvm::SmallVectorImpl&) /home/skatkov/work/llvm/src/lib/CodeGen/RegAllocGreedy.cpp:2762:0 #19 0x7fe0ef279e0c llvm::RegAllocBase::allocatePhysRegs() /home/skatkov/work/llvm/src/lib/CodeGen/RegAllocBase.cpp:113:0 #20 0x7fe0ef291eb3 (anonymous namespace)::RAGreedy::runOnMachineFunction(llvm::MachineFunction&) /home/skatkov/work/llvm/src/lib/CodeGen/RegAllocGreedy.cpp:3243:0 #21 0x7fe0ef128390 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /home/skatkov/work/llvm/src/lib/CodeGen/MachineFunctionPass.cpp:74:0 #22 0x7fe0eedd9b5c llvm::FPPassManager::runOnFunction(llvm::Function&) /home/skatkov/work/llvm/src/lib/IR/LegacyPassManager.cpp:1644:0 #23 0x7fe0eedd9d99 llvm::FPPassManager::runOnModule(llvm::Module&) /home/skatkov/work/llvm/src/lib/IR/LegacyPassManager.cpp:1679:0 #24 0x7fe0eedda181 (anonymous namespace)::MPPassManager::runOnMo
[llvm-bugs] [Bug 34920] __builtin_mul_overflow unsupported for mixed-sign 64-bit operands on 32-bit architectures
https://bugs.llvm.org/show_bug.cgi?id=34920
Tom Stellard changed:
What|Removed |Added
Resolution|FIXED |---
CC||tstel...@redhat.com
Status|RESOLVED|REOPENED
--- Comment #11 from Tom Stellard ---
I've found a new test case where we still emit an i65 overflow intrinsic with
64-bit operands.
#include
void mul(size_t a, int b) {
size_t res;
__builtin_mul_overflow(a, b, &res);
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
