[llvm-bugs] [Bug 44788] New: Function pointer in template argument
https://bugs.llvm.org/show_bug.cgi?id=44788 Bug ID: 44788 Summary: Function pointer in template argument Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: OpenCL Assignee: unassignedclangb...@nondot.org Reporter: dr...@jwdt.org CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org Created attachment 23092 --> https://bugs.llvm.org/attachment.cgi?id=23092&action=edit Testcase The attached testcase fails compilation with C++ for OpenCL Compile command: clang++ -cl-std=clc++ -x cl -emit-llvm --target=spir64-unknown-unknown -O3 -c test.cl -o test.bc Clang version: latest master, commit 12fe9b26ec88bb2dd40d574a644edca302e804b2 Error message: clang-10: warning: Unknown CUDA version 10.2. Assuming the latest supported version 10.1 [-Wunknown-cuda-version] test.cl:11:10: error: taking address of function is not allowed test(foo); ^ 1 error generated. The OpenCL C++ spec says: function pointers ... [are not supported by OpenCL C++] unless they are a compile-time constant expression. I am not sure about clang C++ for OpenCL, but I think this would be an interesting feature to support for using modern C++. -- 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 44791] New: LLDB 10.x (and current master) fails to build with GCC 5.4
https://bugs.llvm.org/show_bug.cgi?id=44791
Bug ID: 44791
Summary: LLDB 10.x (and current master) fails to build with GCC
5.4
Product: lldb
Version: 10.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: mar...@martin.st
CC: apra...@apple.com, h...@chromium.org,
jdevliegh...@apple.com, lab...@google.com,
llvm-bugs@lists.llvm.org
Blocks: 44555
Building the current master with GCC 5.4 (on Ubuntu 16.04) fails like this:
../tools/lldb/source/DataFormatters/LanguageCategory.cpp:71:68: error:
specialization of 'template auto&
lldb_private::LanguageCategory::GetHardcodedFinder()' in different namespace
[-fpermissive]
auto &LanguageCategory::GetHardcodedFinder() {
^
In file included from
../tools/lldb/source/DataFormatters/LanguageCategory.cpp:9:0:
../tools/lldb/include/lldb/DataFormatters/LanguageCategory.h:52:9: error:
from definition of 'template auto&
lldb_private::LanguageCategory::GetHardcodedFinder()' [-fpermissive]
auto &GetHardcodedFinder();
^
../tools/lldb/source/DataFormatters/LanguageCategory.cpp:76:69: error:
specialization of 'template auto&
lldb_private::LanguageCategory::GetHardcodedFinder()' in different namespace
[-fpermissive]
auto &LanguageCategory::GetHardcodedFinder() {
^
In file included from
../tools/lldb/source/DataFormatters/LanguageCategory.cpp:9:0:
../tools/lldb/include/lldb/DataFormatters/LanguageCategory.h:52:9: error:
from definition of 'template auto&
lldb_private::LanguageCategory::GetHardcodedFinder()' [-fpermissive]
auto &GetHardcodedFinder();
^
../tools/lldb/source/DataFormatters/LanguageCategory.cpp:81:71: error:
specialization of 'template auto&
lldb_private::LanguageCategory::GetHardcodedFinder()' in different namespace
[-fpermissive]
auto &LanguageCategory::GetHardcodedFinder() {
^
In file included from
../tools/lldb/source/DataFormatters/LanguageCategory.cpp:9:0:
../tools/lldb/include/lldb/DataFormatters/LanguageCategory.h:52:9: error:
from definition of 'template auto&
lldb_private::LanguageCategory::GetHardcodedFinder()' [-fpermissive]
auto &GetHardcodedFinder();
^
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=44555
[Bug 44555] [meta] 10.0.0 Release Blockers
--
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 44792] New: Dead lock when forking with coverage enabled in multithreaded environment
https://bugs.llvm.org/show_bug.cgi?id=44792 Bug ID: 44792 Summary: Dead lock when forking with coverage enabled in multithreaded environment Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: profile Assignee: unassignedb...@nondot.org Reporter: cdeni...@mozilla.com CC: llvm-bugs@lists.llvm.org When forking, the mutex defined here: https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/profile/GCDAProfiling.c#L67 must be reinitialized in child process else the mutex in a locked stated can be duplicate and then when a thread in child process attempts to lock it then it wait for ever. -- 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 44794] New: -Wmicrosoft-template changed in 10.0.0
https://bugs.llvm.org/show_bug.cgi?id=44794 Bug ID: 44794 Summary: -Wmicrosoft-template changed in 10.0.0 Product: clang Version: 10.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: jva...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk On our code base, we had the -Wmicrosoft-template warning active before. With 10.0.0-RC1, I have to suppress this warning again, because it got changed. Ideally, every warning would have it's own flag, something like: -Wmicrosoft-template-shadowing and be part put in a warning group -Wmicrosoft-template. This eases upgrades to newer releases, as you don't have to disable warnings that were previously active. Not sure if this is feasible within the RC time, however, updating the release note comments to mention changes to this warning should still be feasible. See https://clang.llvm.org/docs/DiagnosticsReference.html#wmicrosoft-template : declaration of A shadows template parameter -- 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 36894] [X86] SLM/Sandy Models don't account for load latency for SSE42/AES/CLMUL classes
https://bugs.llvm.org/show_bug.cgi?id=36894 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)|rGf25a2a3de5b5 |rGf25a2a3de5b5,rG8616bd417f ||7a Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Simon Pilgrim --- SandyBridge fixes - rG8616bd417f7a -- 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 32325] [META][X86] Improve implementation and use of X86 scheduler models
https://bugs.llvm.org/show_bug.cgi?id=32325 Bug 32325 depends on bug 36894, which changed state. Bug 36894 Summary: [X86] SLM/Sandy Models don't account for load latency for SSE42/AES/CLMUL classes https://bugs.llvm.org/show_bug.cgi?id=36894 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44795] New: Use vpshuflb instead of vpshuflw/vpshufhw (AMD Zen)
https://bugs.llvm.org/show_bug.cgi?id=44795 Bug ID: 44795 Summary: Use vpshuflb instead of vpshuflw/vpshufhw (AMD Zen) 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 Orignally reported here: https://www.realworldtech.com/forum/?threadid=176424&curpostid=176424&fbclid=IwAR0P-wuQYtb7X9C8K8cr-axqP4Gwh1ZRSz-yU69bm5-NTZHdud-Nvp5ypec "In above example clang compiler replaced each of 4 vpshuflb instructions, specified in the source code, by pair of instruction vpshuflw/vpshufhw. Since the execution time is bottlenecked by 'Port 5' execution bandwidth, the smart-assness of compiler leads to approximate doubling of execution time. This particular Haswell/Broadwell/Skylake code generation bug is fixed in clang6 (clang6 code looks horrible for other reason), but virtually identical AMD Zen code generation bug is not fixed. I have no Zen to measure, but according to Agner Fog's instruction tables 'Pipe 12 bottleneck' has approximately the same effect as 'Port 5 bottleneck' on Intel parts." https://godbolt.org/g/ZjjCmY -- 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 44796] New: Use movzx instead of mov + shr
https://bugs.llvm.org/show_bug.cgi?id=44796
Bug ID: 44796
Summary: Use movzx instead of mov + shr
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
unsigned char sum2(const void* ptr)
{
const unsigned k = 2;
unsigned char bytes[k], result = 0;
memcpy(bytes, ptr, k);
for(unsigned n=0; nhttps://godbolt.org/z/dTuEJb
--
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 44797] New: [MCA][CodeGenSchedule] Better handling of instructions with zero NumMicroOpcodes.
https://bugs.llvm.org/show_bug.cgi?id=44797 Bug ID: 44797 Summary: [MCA][CodeGenSchedule] Better handling of instructions with zero NumMicroOpcodes. Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-mca Assignee: unassignedb...@nondot.org Reporter: andrea.dibia...@gmail.com CC: andrea.dibia...@gmail.com, llvm-bugs@lists.llvm.org, matthew.da...@sony.com Field NumMicroOpcodes is currently used by mca to model the number of uOPs dispatched from the uOp-Queue to the out of order backend. >From a 'dispatch' point of view, an instruction with zero opcodes is still valid; it simply doesn't consume any dispatch group slots. However, mca doesn't expect an instruction with zero uOPs to consume pipeline resources because it is seen as a contradiction. In practice, it only makes sense if the instruction is eliminated and never really executed. It may be that mca is being too conservative here. However I believe that mca is right, and we should probably check that inconsistency in CodeGenSchedule.cpp (when we also verify scheduling classes in general). In the short term I plan to remove the check for MayLoad and MayStore in mca. That check is probably too conservative: we already check if a zero-uops instruction consumes any processor resources. Also, instructions with unmodelled side-effects tend to also set the MayLoad/MayStore flags even if - theoretically speaking - they might not even consume any hw resources in practice. In future we may want to implement different checks (possibly outside of mca) and potentially revisit the logic in mca that verifies instructions. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44798] New: llvm/test/tools/UpdateTestChecks/update_cc_test_checks use clang but don't depend on clang
https://bugs.llvm.org/show_bug.cgi?id=44798 Bug ID: 44798 Summary: llvm/test/tools/UpdateTestChecks/update_cc_test_checks use clang but don't depend on clang Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: support scripts Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: greg.bedw...@sony.com, i...@maskray.me, llvm-bugs@lists.llvm.org $ ninja check-llvm [1/295] Generating VCSRevision.h -- Found Git: /usr/bin/git (found version "2.25.0") [294/295] Running the LLVM regression tests FAIL: LLVM :: tools/UpdateTestChecks/update_cc_test_checks/def-and-decl.test (33391 of 35753) TEST 'LLVM :: tools/UpdateTestChecks/update_cc_test_checks/def-and-decl.test' FAILED Script: -- : 'RUN: at line 3'; cp /repositories/llvm-project/llvm/test/tools/UpdateTestChecks/update_cc_test_checks/Inputs/def-and-decl.c /builddirs/llvm-project/build-Clang9-unknown/test/tools/UpdateTestChecks/update_cc_test_checks/Output/def-and-decl.test.tmp.c && '/usr/bin/python' /repositories/llvm-project/llvm/utils/update_cc_test_checks.py --clang /builddirs/llvm-project/build-Clang9-unknown/./bin/clang --opt /builddirs/llvm-project/build-Clang9-unknown/./bin/opt /builddirs/llvm-project/build-Clang9-unknown/test/tools/UpdateTestChecks/update_cc_test_checks/Output/def-and-decl.test.tmp.c : 'RUN: at line 4'; diff -u /repositories/llvm-project/llvm/test/tools/UpdateTestChecks/update_cc_test_checks/Inputs/def-and-decl.c.expected /builddirs/llvm-project/build-Clang9-unknown/test/tools/UpdateTestChecks/update_cc_test_checks/Output/def-and-decl.test.tmp.c : 'RUN: at line 6'; '/usr/bin/python' /repositories/llvm-project/llvm/utils/update_cc_test_checks.py --clang /builddirs/llvm-project/build-Clang9-unknown/./bin/clang --opt /builddirs/llvm-project/build-Clang9-unknown/./bin/opt /builddirs/llvm-project/build-Clang9-unknown/test/tools/UpdateTestChecks/update_cc_test_checks/Output/def-and-decl.test.tmp.c : 'RUN: at line 7'; diff -u /repositories/llvm-project/llvm/test/tools/UpdateTestChecks/update_cc_test_checks/Inputs/def-and-decl.c.expected /builddirs/llvm-project/build-Clang9-unknown/test/tools/UpdateTestChecks/update_cc_test_checks/Output/def-and-decl.test.tmp.c -- Exit Code: 1 Command Output (stdout): -- $ ":" "RUN: at line 3" $ "cp" "/repositories/llvm-project/llvm/test/tools/UpdateTestChecks/update_cc_test_checks/Inputs/def-and-decl.c" "/builddirs/llvm-project/build-Clang9-unknown/test/tools/UpdateTestChecks/update_cc_test_checks/Output/def-and-decl.test.tmp.c" $ "/usr/bin/python" "/repositories/llvm-project/llvm/utils/update_cc_test_checks.py" "--clang" "/builddirs/llvm-project/build-Clang9-unknown/./bin/clang" "--opt" "/builddirs/llvm-project/build-Clang9-unknown/./bin/opt" "/builddirs/llvm-project/build-Clang9-unknown/test/tools/UpdateTestChecks/update_cc_test_checks/Output/def-and-decl.test.tmp.c" # command stderr: /builddirs/llvm-project/build-Clang9-unknown/./bin/clang: symbol lookup error: /builddirs/llvm-project/build-Clang9-unknown/bin/../lib/libclangCodeGen.so.11git: undefined symbol: _ZN4llvm20RemarkSetupFileError2IDE WARNING: Could not determine clang builtins directory, some tests might not update correctly. /builddirs/llvm-project/build-Clang9-unknown/./bin/clang: symbol lookup error: /builddirs/llvm-project/build-Clang9-unknown/bin/../lib/libclangCodeGen.so.11git: undefined symbol: _ZN4llvm20RemarkSetupFileError2IDE Traceback (most recent call last): File "/repositories/llvm-project/llvm/utils/update_cc_test_checks.py", line 304, in sys.exit(main()) File "/repositories/llvm-project/llvm/utils/update_cc_test_checks.py", line 265, in main get_function_body(args, filename, clang_args, extra_commands, prefixes, triple_in_cmd, func_dict) File "/repositories/llvm-project/llvm/utils/update_cc_test_checks.py", line 161, in get_function_body raw_tool_output = common.invoke_tool(args.clang, clang_args, filename) File "/repositories/llvm-project/llvm/utils/UpdateTestChecks/common.py", line 50, in invoke_tool stdout = subprocess.check_output([exe] + cmd_args, stdin=ir_file) File "/usr/lib/python2.7/subprocess.py", line 223, in check_output raise CalledProcessError(retcode, cmd, output=output) subprocess.CalledProcessError: Command '['/builddirs/llvm-project/build-Clang9-unknown/./bin/clang', '-cc1', '-triple', 'x86_64-unknown-linux-gnu', '/builddirs/llvm-project/build-Clang9-unknown/test/tools/UpdateTestChecks/update_cc_test_checks/Output/def-and-decl.test.tmp.c', '-emit-llvm', '-o', '-']' returned non-zero exit status 127 error: command failed with exit status: 1 -- Testing Time: 702.24s Failing Tests (1): LLVM :: tools/UpdateTestChecks/update_cc_tes
[llvm-bugs] [Bug 44555] [meta] 10.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=44555 Bug 44555 depends on bug 44600, which changed state. Bug 44600 Summary: [AArch64][ARM] experimental.vector.reduce without FMF asserts https://bugs.llvm.org/show_bug.cgi?id=44600 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44600] [AArch64][ARM] experimental.vector.reduce without FMF asserts
https://bugs.llvm.org/show_bug.cgi?id=44600 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #4 from Hans Wennborg --- (In reply to Nikita Popov from comment #1) > Candidate patch: https://reviews.llvm.org/D73135 Cherry-picked to 10.x in 0b8a540dff86662fc9426bb4dd8797c547db5000 (In reply to Nikita Popov from comment #3) > Additional related fixes were applied in https://reviews.llvm.org/D73854 picked in 99c6a4ea9201f09e8107bb83675f1e7235456b6d > and > https://reviews.llvm.org/D73908. picked in 8195a96595baca8c0141de2a121dcf3f8c0ea616. -- 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 37699] [X86][BMI][TBM] Remove llvm.x86.tbm.bextri.* and always use llvm.x86.bmi.bextr.*
https://bugs.llvm.org/show_bug.cgi?id=37699 Simon Pilgrim changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from Simon Pilgrim --- This doesn't look to be worth it - its simple enough to handle both in IR and we convert both to the X86ISD::BEXTR opcode in DAG. -- 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 44800] New: opt -loop-vectorize fails with 'Assertion `(EdgeMask || NumIncoming == 1) && "Multiple predecessors with one having a full mask"' failed.'
https://bugs.llvm.org/show_bug.cgi?id=44800 Bug ID: 44800 Summary: opt -loop-vectorize fails with 'Assertion `(EdgeMask || NumIncoming == 1) && "Multiple predecessors with one having a full mask"' failed.' Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 23093 --> https://bugs.llvm.org/attachment.cgi?id=23093&action=edit bbi-38415.ll reproducer opt -S -o - bbi-38415.ll -loop-vectorize hits an assertion opt: ../lib/Transforms/Vectorize/LoopVectorize.cpp:6869: llvm::VPBlendRecipe *llvm::VPRecipeBuilder::tryToBlend(llvm::Instruction *, llvm::VPlanPtr &): Assertion `(EdgeMask || NumIncoming == 1) && "Multiple predecessors with one having a full mask"' failed. Stack dump: 0. Program arguments: ../../master/llvm/build-all-builtins/bin/opt -S -o - bbi-38415.ll -loop-vectorize 1. Running pass 'Function Pass Manager' on module 'bbi-38415.ll'. 2. Running pass 'Loop Vectorization' on function '@g' #0 0x03f41904 PrintStackTraceSignalHandler(void*) (../../master/llvm/build-all-builtins/bin/opt+0x3f41904) #1 0x03f3f4ce llvm::sys::RunSignalHandlers() (../../master/llvm/build-all-builtins/bin/opt+0x3f3f4ce) #2 0x03f41d0c SignalHandler(int) (../../master/llvm/build-all-builtins/bin/opt+0x3f41d0c) #3 0x7f1ff0879890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x7f1fef322e97 raise /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #5 0x7f1fef324801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0 #6 0x7f1fef31439a __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0 #7 0x7f1fef314412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412) #8 0x0408d279 llvm::VPRecipeBuilder::tryToBlend(llvm::Instruction*, std::unique_ptr >&) (../../master/llvm/build-all-builtins/bin/opt+0x408d279) #9 0x0408eba3 llvm::VPRecipeBuilder::tryToCreateRecipe(llvm::Instruction*, llvm::VFRange&, std::unique_ptr >&, llvm::VPBasicBlock*) (../../master/llvm/build-all-builtins/bin/opt+0x408eba3) #10 0x0408fbd7 llvm::LoopVectorizationPlanner::buildVPlanWithVPRecipes(llvm::VFRange&, llvm::SmallPtrSetImpl&, llvm::SmallPtrSetImpl&, llvm::DenseMap, llvm::detail::DenseMapPair > const&) (../../master/llvm/build-all-builtins/bin/opt+0x408fbd7) #11 0x0408a2a0 llvm::LoopVectorizationPlanner::buildVPlansWithVPRecipes(unsigned int, unsigned int) (../../master/llvm/build-all-builtins/bin/opt+0x408a2a0) #12 0x040899d2 llvm::LoopVectorizationPlanner::plan(unsigned int) (../../master/llvm/build-all-builtins/bin/opt+0x40899d2) #13 0x04094406 llvm::LoopVectorizePass::processLoop(llvm::Loop*) (../../master/llvm/build-all-builtins/bin/opt+0x4094406) #14 0x04097404 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*) (../../master/llvm/build-all-builtins/bin/opt+0x4097404) #15 0x0409be28 (anonymous namespace)::LoopVectorize::runOnFunction(llvm::Function&) (../../master/llvm/build-all-builtins/bin/opt+0x409be28) #16 0x037dfef4 llvm::FPPassManager::runOnFunction(llvm::Function&) (../../master/llvm/build-all-builtins/bin/opt+0x37dfef4) #17 0x037e01a8 llvm::FPPassManager::runOnModule(llvm::Module&) (../../master/llvm/build-all-builtins/bin/opt+0x37e01a8) #18 0x037e07fd llvm::legacy::PassManagerImpl::run(llvm::Module&) (../../master/llvm/build-all-builtins/bin/opt+0x37e07fd) #19 0x02131ab3 main (../../master/llvm/build-all-builtins/bin/opt+0x2131ab3) #20 0x7f1fef305b97 __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 #21 0x0211902a _start (../../master/llvm/build-all-builtins/bin/opt+0x211902a) Abort (core dumped) This seems to be related to https://bugs.llvm.org/show_bug.cgi?id=44488 which also dealt with a case where we had a conditional branch with the two exits being 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
[llvm-bugs] [Bug 44733] TEST 'libomp :: ompt/synchronization/reduction/tree_reduce.c' FAILED on 32-bit x86
https://bugs.llvm.org/show_bug.cgi?id=44733 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #3 from Hans Wennborg --- (In reply to Joachim Protze from comment #2) > Fix committed as 90e4ebdce55fd3c1f8877f19784a5339b9890f98. > > Please include to 10.x Cherry-picked as 5288d7af5bc1b6775e122df5346f7cde9f65881d. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44555] [meta] 10.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=44555 Bug 44555 depends on bug 44733, which changed state. Bug 44733 Summary: TEST 'libomp :: ompt/synchronization/reduction/tree_reduce.c' FAILED on 32-bit x86 https://bugs.llvm.org/show_bug.cgi?id=44733 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 43462] Null pointer dereference warning inside PrintActions1
https://bugs.llvm.org/show_bug.cgi?id=43462 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||rGe63abde39f53 --- Comment #2 from Simon Pilgrim --- Fixed in rGe63abde39f53 -- 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 35640] Merge r320396 into the 5.0 branch : [Sema] Fix crash in unused-lambda-capture warning for VLAs
https://bugs.llvm.org/show_bug.cgi?id=35640 Malcolm Parsons changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 35640, which changed state. Bug 35640 Summary: Merge r320396 into the 5.0 branch : [Sema] Fix crash in unused-lambda-capture warning for VLAs https://bugs.llvm.org/show_bug.cgi?id=35640 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 42958] -Wunused-lambda-capture too strict with 'this'
https://bugs.llvm.org/show_bug.cgi?id=42958 Malcolm Parsons changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||malcolm.pars...@gmail.com --- Comment #1 from Malcolm Parsons --- *** This bug has been marked as a duplicate of bug 36880 *** -- 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 44802] New: InstCombine unsafely drops zero extensions when combining shifts
https://bugs.llvm.org/show_bug.cgi?id=44802 Bug ID: 44802 Summary: InstCombine unsafely drops zero extensions when combining shifts Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: rsprin...@google.com CC: llvm-bugs@lists.llvm.org Reproducer: https://rise4fun.com/Alive/ne8y In InstCombiner::reassociateShiftAmtsOfTwoSameDirectionShifts(), when identifying two shifts to combine, it does so while ignoring any zero-extensions of those values. In the problematic case above, the values were both i1s zero-extended to i3s. When their zero-extensions are dropped (taking them back to i1s) their sum becomes an xor in SimplifyAddInst(), which causes the shift to basically disappear (and to be dropped in a later pass). I'm not familiar with the history of this code, particularly why the zero extensions are ignored, but changing the code to leave them in place does fix the issue. -- 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 44803] New: "dynamic initialization is not supported" when compiling CUDA + Thrust code
https://bugs.llvm.org/show_bug.cgi?id=44803
Bug ID: 44803
Summary: "dynamic initialization is not supported" when
compiling CUDA + Thrust code
Product: clang
Version: 9.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: CUDA
Assignee: unassignedclangb...@nondot.org
Reporter: daniel.jasin...@gmail.com
CC: llvm-bugs@lists.llvm.org
When compiling the following piece of code with on Windows:
```
#include
#include
#include
#include
using namespace thrust;
int main()
{
int size = 100;
device_vector v(100);
auto counter = make_counting_iterator(0);
copy(counter, counter + size, v.begin());
auto multiply = [] __host__ __device__ (const int&x){ return x * x;};
transform(v.begin(), v.end(), v.begin(), multiply);
}
```
I get the following series of errors:
```
thrust/functional.h:1452:74: error: dynamic initialization is not supported for
__device__, __constant__, and __shared__ variables.
static const __device__ thrust::detail::functional::placeholder<0>::type _1;
thrust/functional.h:1461:74: error: dynamic initialization is not supported for
__device__, __constant__, and __shared__ variables.
static const __device__ thrust::detail::functional::placeholder<1>::type _2;
...
thrust/functional.h:1533:74: error: dynamic initialization is not supported for
__device__, __constant__, and __shared__ variables.
static const __device__ thrust::detail::functional::placeholder<9>::type _10;
```
I used the latest release of Thrust.
I checked the type being initialized and it looks like it has no data and an
empty constructor.
--
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 11969] FreeBSD 9.0 stable i386 build world core dumped (libssp_nonshared)
https://bugs.llvm.org/show_bug.cgi?id=11969 ema...@freebsd.org changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC||ema...@freebsd.org --- Comment #3 from ema...@freebsd.org --- Original submitter reports fixed as of Clang 3.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44682] compiler-rt build broken on mac: 'os/lock.h' file not found
https://bugs.llvm.org/show_bug.cgi?id=44682 David Major changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Major --- This was fixed by https://github.com/llvm/llvm-project/commit/c32d809e9cae8da7d3016b6cb30e2a2a9c9e2762 on the release/10.x branch. -- 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 44555] [meta] 10.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=44555 Bug 44555 depends on bug 44682, which changed state. Bug 44682 Summary: compiler-rt build broken on mac: 'os/lock.h' file not found https://bugs.llvm.org/show_bug.cgi?id=44682 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44804] New: Function merging not enabled at -O2/-Os or higher
https://bugs.llvm.org/show_bug.cgi?id=44804 Bug ID: 44804 Summary: Function merging not enabled at -O2/-Os or higher Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: mik...@digitalcarbide.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk In GCC, `-fipa-icf` is enabled at `-O2` (and higher) and `-Os`. The equivalent functionality, for functions at least, is `-Xclang -fmerge-functions`. It is not, however, enabled at any optimization level. It should be changed to be enabled the same as it is in GCC - at `-O2` or higher, `-Os`, and `-Oz`. See: https://godbolt.org/z/2wLv_w for an example of a lack of folding in Clang as compared to GCC. -- 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 44805] New: `-fmerge-functions` incorrectly overrides __attribute__((always_inline)) and __attribute__((flatten))
https://bugs.llvm.org/show_bug.cgi?id=44805
Bug ID: 44805
Summary: `-fmerge-functions` incorrectly overrides
__attribute__((always_inline)) and
__attribute__((flatten))
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: mik...@digitalcarbide.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
When `-Xclang -fmerge-functions` is supplied to Clang (trunk [10] until 3.6,
before 3.6 does not support `merge-functions`), attributes `always_inline` and
`flatten` are ignored, while GCC with equivalent `-fipa-icf` (supplied via
`-O3` by default) does not do such.
Observe (https://godbolt.org/z/5vJKDF):
```
__attribute__((always_inline))
static int func (int a, int b) {
return a / b;
}
int func_a(int a, int b) {
return func(a, b);
}
int func_b(int a, int b) {
return func(a, b);
}
__attribute__((flatten))
int func_c(int a, int b) {
return func(a, b);
}
```
On GCC with the `-O3` flag, this produces:
```
func_a(int, int):
mov eax, edi
cdq
idiv esi
ret
func_b(int, int):
mov eax, edi
cdq
idiv esi
ret
func_c(int, int):
mov eax, edi
cdq
idiv esi
ret
```
On Clang with only the `-O3` flag, this produces the identical:
```
func_a(int, int): # @func_a(int, int)
mov eax, edi
cdq
idiv esi
ret
func_b(int, int): # @func_b(int, int)
mov eax, edi
cdq
idiv esi
ret
func_c(int, int): # @func_c(int, int)
mov eax, edi
cdq
idiv esi
ret
```
However, when `-Xclang -fmerge-functions` is supplied to match GCC's
`-fipa-icf` (#44804), both `always_inline` _and_ `flatten` are ignored, despite
GCC not ignoring them:
```
func_a(int, int): # @func_a(int, int)
mov eax, edi
cdq
idiv esi
ret
func_b(int, int): # @func_b(int, int)
jmp func_a(int, int) # TAILCALL
func_c(int, int): # @func_c(int, int)
jmp func_a(int, int) # TAILCALL
```
--
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 44388] memcpyopt adds incorrect align to memset
https://bugs.llvm.org/show_bug.cgi?id=44388 Juneyoung Lee changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Juneyoung Lee --- Fixed (https://reviews.llvm.org/D74083) -- 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 44806] New: clang-cl crash running pass 'Frontend instrumentation-based coverage lowering' on module llvm\lib\Support\Parallel.cpp
https://bugs.llvm.org/show_bug.cgi?id=44806 Bug ID: 44806 Summary: clang-cl crash running pass 'Frontend instrumentation-based coverage lowering' on module llvm\lib\Support\Parallel.cpp Product: clang Version: 10.0 Hardware: PC OS: Windows NT Status: NEW Severity: release blocker Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: lgreg...@o2.pl CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 23094 --> https://bugs.llvm.org/attachment.cgi?id=23094&action=edit .sh .cpp .dmp files Assertion failed: !NodePtr->isKnownSentinel(), file llvm\include\llvm/ADT/ilist_iterator.h, line 139 when LLVM_BUILD_INSTRUMENTED:STRING=IR -- 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 44249] [Compile Time] 50% of time spent in Elim phi nodes
https://bugs.llvm.org/show_bug.cgi?id=44249 Jonas Paulsson changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonas Paulsson --- Handled with https://reviews.llvm.org/D73152 (committed as 96ea377). -- 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 44803] "dynamic initialization is not supported" when compiling CUDA + Thrust code
https://bugs.llvm.org/show_bug.cgi?id=44803 Artem Belevich changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from Artem Belevich --- I don't think it's a clang bug. Thrust has changed a lot since the last time I've made it compile-able with clang. Thrust uses fairly elaborate C++ and has fair amount of nvcc-isms that don't work with clang. I've made an attempt to fix the current version around CUDA-10.1 release last summer and gave up. If you need thrust your options are to either use an older version or make an effort to port it to work with clang. In the past NVIDIA did accept pull requests for clang portability fixes. -- 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 44807] New: llvm-objdump cannot understand symbols emitted by wasm reference toolchain
https://bugs.llvm.org/show_bug.cgi?id=44807 Bug ID: 44807 Summary: llvm-objdump cannot understand symbols emitted by wasm reference toolchain Product: tools Version: 10.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: ggr...@gmail.com CC: llvm-bugs@lists.llvm.org I am at 10.0.0-rc1. Wasm reference toolchain is here: https://github.com/WebAssembly/spec/blob/master/interpreter/binary/encode.ml#L459 `llvm-objdump` calls `onSymbolStart` and probably fails. Caller doesn't check return code. Something gets disassembled, but neither symbol names appear, nor " .local". here is what is dumped: Disassembly of section CODE: CODE: # 210 functions in section. 2: 8cf32.neg 3: 80i64.div_u 4: 80i64.div_u 5: 80i64.div_u 6: 00 7: 00 8: 20 00 local.get 0 a: 41 03 i32.const 3 c: 6ai32.add d: 41 04 i32.const 4 f: 6ei32.div_u 10: 10 53 call83 12: 0bend 13: a0f64.add 14: 80i64.div_u 15: 80i64.div_u 16: 80i64.div_u 17: 00 18: 00 19: 23 00 global.get 0 1b: 41 7f i32.const -1 1d: 6ai32.add 1e: 20 00 local.get 0 20: 41 04 i32.const 4 22: 6ci32.mul 23: adi64.extend_i32_u 24: 23 01 global.get 1 26: 7ci64.add 27: 24 01 global.set 1 29: 23 00 global.get 0 2b: 20 00 local.get 0 2d: 41 04 i32.const 4 2f: 6ci32.mul 30: 6ai32.add 31: 24 00 global.set 0 33: 23 00 global.get 0 35: 10 54 call84 37: 0bend 38: aai32.trunc_f64_s 39: 80i64.div_u 3a: 80i64.div_u 3b: 80i64.div_u 3c: 00 3d: 01nop 3e: 01nop 3f: 7fi64.div_s 40: 20 00 local.get 0 42: 41 80 80 04 i32.const 65536 46: 6ei32.div_u 47: 41 01 i32.const 1 49: 6ai32.add 4a: 3f 00 memory.size 0 4c: 6bi32.sub 4d: 22 01 local.tee 1 4f: 41 00 i32.const 0 51: 4ai32.gt_s 52: 04 40 if 54: 20 01 local.get 1 56: 40 00 memory.grow 0 58: 41 00 i32.const 0 5a: 48i32.lt_s 5b: 04 40 if 5d: 41 ff ff 03 i32.const 65535 61: 10 55 call85 63: 00 64: 0bend 65: 0bend 66: 0bend As you can see the `wasm` suite doesn't use shortest uleb128 encoding for the symbol size. This is because the bytes get backpatched on emission when the full buffer is already built. This is why the uleb128 size is 5 bytes for the symbol size. Maybe I am completely wrong, I cannot put my finger onto a sleb128 decoder bug after cursory inspection. Here is the binary dump of the section head: Contents of section CODE: d2018c80 8080 20004103 6a41046e .A.jA.n 0010 10530ba0 80808000 00230041 7f6a2000 .S...#.A.j . 0020 4
[llvm-bugs] [Bug 44808] New: unused variable: Target/ARM/ARMConstantIslandPass.cpp:333
https://bugs.llvm.org/show_bug.cgi?id=44808 Bug ID: 44808 Summary: unused variable: Target/ARM/ARMConstantIslandPass.cpp:333 Product: libraries Version: 10.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: ggr...@gmail.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, ties.st...@arm.com /tmp/nix-build-llvm-10.0.0rc1.drv-0/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp:333:17: warning: unused variable 'BBInfo' [-Wunused-variable] BBInfoVector &BBInfo = BBUtils->getBBInfo(); ^ Should be an easy fix. -- 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 44809] New: Constraint ignored in function template of class template when using terse syntax
https://bugs.llvm.org/show_bug.cgi?id=44809
Bug ID: 44809
Summary: Constraint ignored in function template of class
template when using terse syntax
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: da...@doublewise.net
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following invalid code:
```
template
concept false_ = false;
template
struct s {
static bool f(false_ auto);
};
auto x = s::f(1);
```
is accepted in clang 93dc8bd26708ba5fb8b83b65c40ed840ef76730d. It seems that
all such concepts are ignored, which leads to ambiguities in code that relies
on partial ordering, too. This example was properly rejected in earlier
revisions, and has broken in the past few days (I think some time between now
and Saturday?).
--
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
