[llvm-bugs] [Bug 48869] gcc 5.3: fails with error: implicit instantiation of undefined template 'std::hash'
https://bugs.llvm.org/show_bug.cgi?id=48869 Sylvestre Ledru changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Sylvestre Ledru --- I don't think it is fixed. The build of 46b1645e6c4f produces the same issue: cd "/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/build-llvm/tools/clang/stage2-bins/tools/lldb/source/Plugins/TypeSystem/Clang" && "/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/build-llvm/./bin/clang++" -DHAVE_ROUND -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/build-llvm/tools/clang/stage2-bins/tools/lldb/source/Plugins/TypeSystem/Clang" -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/source/Plugins/TypeSystem/Clang" -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/build-llvm/tools/clang/stage2-bins/tools/lldb/source" -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/include" -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/build-llvm/tools/clang/stage2-bins/tools/lldb/include" -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/build-llvm/tools/clang/stage2-bins/include" -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/llvm/include" -I/usr/include/python3.5m -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/clang/include" -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/build-llvm/tools/clang/stage2-bins/tools/lldb/../clang/include" -I"/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/source/." -fuse-ld=gold -fPIC -Wno-unused-command-line-argument -Wno-unknown-warning-option -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O2 -DNDEBUG -g1 -fno-exceptions -std=c++14 -o CMakeFiles/lldbPluginTypeSystemClang.dir/TypeSystemClang.cpp.o -c "/build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp" In file included from /build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:9: In file included from /build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h:30: In file included from /build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/source/./Plugins/ExpressionParser/Clang/ClangPersistentVariables.h:14: In file included from /build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/source/./Plugins/ExpressionParser/Clang/ClangExpressionVariable.h:23: In file included from /build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/include/lldb/Expression/ExpressionVariable.h:17: In file included from /build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/include/lldb/Core/ValueObject.h:16: In file included from /build/llvm-toolchain-snapshot-12~++20210126020814+46b1645e6c4f/lldb/include/lldb/Target/Process.h:21: In file included from /usr/lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/unordered_set:47: In file included from /usr/lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/hashtable.h:35: /usr/lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/hashtable_policy.h:85:11: error: implicit instantiation of undefined template 'std::hash' noexcept(declval()(declval()))> ^ /usr/lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/type_traits:138:14: note: in instantiation of template class 'std::__detail::__is_noexcept_hash>' requested here : public conditional<_B1::value, _B2, _B1>::type ^ /usr/lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/type_traits:148:39: note: in instantiation of template class 'std::__and_>, std::__detail::__is_noexcept_hash>>' requested here : public integral_constant ^ /usr/lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/unordered_map.h:46:34: note: in instantiation of template class 'std::__not_>, std::__detail::__is_noexcept_hash>>>' requested here typename _Tr = __umap_traits<__cache_default<_Key, _Hash>::value>> ^ /usr/lib/gcc/x
[llvm-bugs] [Bug 40862] llvm-readobj GNU output for dynamic table does not match GNU readelf output
https://bugs.llvm.org/show_bug.cgi?id=40862 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||gri...@accesssoftek.com --- Comment #1 from George Rimar --- This was fixed by https://reviews.llvm.org/D62256 -- 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 40866] Improve error message for malformed ELF
https://bugs.llvm.org/show_bug.cgi?id=40866 George Rimar changed: What|Removed |Added CC||gri...@accesssoftek.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from George Rimar --- This is already fixed. `llvm-readobj\ELF\malformed-pt-dynamic.test` contains a lot of tests with nice warning messages for described situations. -- 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 48879] New: [X86][SSE2] Failure to vectorize int16_t[8] to pminsw pattern
https://bugs.llvm.org/show_bug.cgi?id=48879
Bug ID: 48879
Summary: [X86][SSE2] Failure to vectorize int16_t[8] to pminsw
pattern
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, pengfei.w...@intel.com,
spatel+l...@rotateright.com
https://gcc.godbolt.org/z/57nGK3
typedef int16_t T;
constexpr int N = 8;
std::array compute_min(std::array& x, std::array& y) {
std::array result;
for (int i = 0; i != N; ++i) {
result[i] = std::min(x[i], y[i]);
}
return result;
}
This ends up as a horrid mix of scalar and <2 x i16> smin patterns.
Much of the problem seems to be that we end up trying to store the final array
as { i64, i64 } aggregate, resulting in a load of zext+shift+or to pack the
i16's.
Even more impressive with -march=atom we end up with masked gather calls
--
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 48880] New: Confusing error message for unknown argument
https://bugs.llvm.org/show_bug.cgi?id=48880 Bug ID: 48880 Summary: Confusing error message for unknown argument Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-symbolizer Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org Recently, llvm-symbolizer stopped supporting `-i=0` as an option for disabling the -i option (which is enabled by default), in favour of a different option. I forgot about this temporarily, and tried to use the old-style option, and got the following result: PS C:\Work\TempWork> C:\llvm\build\Debug\bin\llvm-symbolizer.exe --obj=foo.elf 0x100 -i=0 error: unknown argument '-=0' Note the lack of the "i" in the output. My suspicion is that because `-i` is a groupable option, it is removed from the list of unknown characters (because it is recognised) and the rest are reported. However, the error message is somewhat confusing, especially for people who might not be aware of the behaviour change. Some more interesting examples show that it is all characters after the first unknown character that gets reported: PS C:\Work\TempWork> C:\llvm\build\Debug\bin\llvm-symbolizer.exe --obj=foo.elf 0x100 -ix=0 error: unknown argument '-x=0' PS C:\Work\TempWork> C:\llvm\build\Debug\bin\llvm-symbolizer.exe --obj=foo.elf 0x100 -ixf=0 error: unknown argument '-xf=0' PS C:\Work\TempWork> C:\llvm\build\Debug\bin\llvm-symbolizer.exe --obj=foo.elf 0x100 -ifx=0 error: unknown argument '-x=0' We should fix this (it's likely an issue in the command-line library). -- 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 40864] Don't abort printing of dynamic table if dynamic string address is invalid
https://bugs.llvm.org/show_bug.cgi?id=40864 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||gri...@accesssoftek.com --- Comment #6 from George Rimar --- This is already fixed. We test handling of DT_STRTAB pointing outside the file's address space here: https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/llvm-readobj/ELF/dynamic-malformed.test#L183 -- 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 38278] llvm-readelf incorrectly reports stackmap version.
https://bugs.llvm.org/show_bug.cgi?id=38278 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||gri...@accesssoftek.com --- Comment #1 from George Rimar --- This is already fixed. The testing for llvm-readelf/obj was introduced by https://reviews.llvm.org/D85208. -- 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 48881] New: [AMDGPU][MC][GFX10] Incorrect NSA error position
https://bugs.llvm.org/show_bug.cgi?id=48881 Bug ID: 48881 Summary: [AMDGPU][MC][GFX10] Incorrect NSA error position Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Missing register in NSA list results in incorrect error position. For example, assembling an instruction image_load_mip v[253:255], [, v254], s[0:7] dmask:0xe dim:1D results in the following error message: error: failed parsing operand image_load_mip v[253:255], [, v254], s[0:7] dmask:0xe dim:1D ^ -- 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 40801] Improve handling of invalid symbol indexes in relocations
https://bugs.llvm.org/show_bug.cgi?id=40801 George Rimar changed: What|Removed |Added CC||gri...@accesssoftek.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from George Rimar --- It is already fixed. Currently we are able to diagnose and report a lot of broken situations related to relocations. Here is the actual test case: https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/llvm-readobj/ELF/relocation-errors.test -- 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 48882] New: Assertion failure if llvm-symbolizer GNU output style with --no-inlines and missing input file
https://bugs.llvm.org/show_bug.cgi?id=48882 Bug ID: 48882 Summary: Assertion failure if llvm-symbolizer GNU output style with --no-inlines and missing input file Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-symbolizer Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org I ran into the following crash when running llvm-symbolizer with --output-style=GNU and --no-inlines when the input file wasn't present. The crash shouldn't happen - just the error message about no input file, and possibly other related output. PS C:\Work\TempWork> c:\llvm\build\debug\bin\llvm-symbolizer.exe "--output-style=GNU" "--obj=blargle.elf" "0x130" "0x120" "-p" --no-inlines LLVMSymbolizer: error reading file: no such file or directory ?? at ??:0 Assertion failed: Index < Frames.size(), file C:\llvm\llvm-project\llvm\include\llvm/DebugInfo/DIContext.h, line 95 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: C:\\llvm\\build\\debug\\bin\\llvm-symbolizer.exe --output-style=GNU --obj=blargle.elf 0x130 0x120 -p --no-inlines 0x7FF6F329E6BC (0x00FB0016 0x 0x7FF6F30F29CD 0x), HandleAbort() + 0xC bytes(s), c:\llvm\llvm-project\llvm\lib\support\windows\signals.inc, line 408 0x7FFC1158C3E1 (0x7FFC0016 0x00FB53F8D4F0 0x00080106 0xFF0100E8), raise() + 0x441 bytes(s) 0x7FFC1158E039 (0x00FB53F8D4F0 0x0240 0x7FFC1168A4E0 0x7FF6F4315678), abort() + 0x39 bytes(s) 0x7FFC11593C65 (0x7FF6F4315678 0x7FF6F43155E0 0x005F 0x), _get_wide_winmain_command_line() + 0x2515 bytes(s) 0x7FFC115937D7 (0x7FF6F4315678 0x7FF6F43155E0 0x00FB005F 0x), _get_wide_winmain_command_line() + 0x2087 bytes(s) 0x7FFC11591841 (0x7FF6F4315678 0x7FF6F43155E0 0x005F 0x7FF6F31EDB39), _get_wide_winmain_command_line() + 0xF1 bytes(s) 0x7FFC115941CF (0x7FF6F4315678 0x7FF6F43155E0 0x005F 0x), _wassert() + 0x2F bytes(s) 0x7FF6F31EDB39 (0x00FB53F8E548 0x00FB 0x00FB53F8DAF8 0x00FB53F8EC90), llvm::DIInliningInfo::getFrame() + 0x59 bytes(s), c:\llvm\llvm-project\llvm\include\llvm\debuginfo\dicontext.h, line 95 + 0x37 byte(s) 0x7FF6F31C8C91 (0x00FB53F8EF98 0x 0x00FB 0x00FB0001), symbolizeInput() + 0x7E1 bytes(s), c:\llvm\llvm-project\llvm\tools\llvm-symbolizer\llvm-symbolizer.cpp, line 184 + 0x4A byte(s) 0x7FF6F31CA35E (0x7FF60007 0x0200267F6970 0x 0x7FF6F430E1D8), main() + 0xBFE bytes(s), c:\llvm\llvm-project\llvm\tools\llvm-symbolizer\llvm-symbolizer.cpp, line 341 0x7FF6F33F5324 (0x7FF6F430D000 0x7FF6F430DC88 0x 0x), invoke_main() + 0x34 bytes(s), d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl, line 79 0x7FF6F33F520E (0x 0x 0x 0x), __scrt_common_main_seh() + 0x12E bytes(s), d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl, line 288 + 0x5 byte(s) 0x7FF6F33F50CE (0x 0x 0x 0x), __scrt_common_main() + 0xE bytes(s), d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl, line 331 0x7FF6F33F53B9 (0x 0x 0x 0x), mainCRTStartup() + 0x9 bytes(s), d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp, line 17 0x7FFC4D2F7C24 (0x 0x 0x 0x), BaseThreadInitThunk() + 0x14 bytes(s) 0x7FFC4D56D4D1 (0x 0x 0x 0x), RtlUserThreadStart() + 0x21 bytes(s) The crash also occurs when using llvm-addr2line in the same manner, unless --inlines is specified. -- 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 40357] Add support for R_AARCH64_LD64_GOTPAGE_LO15 relocation
https://bugs.llvm.org/show_bug.cgi?id=40357 Adhemerval Zanella changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Adhemerval Zanella --- Fixed upstream. -- 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 48883] New: [AMDGPU][MC][GFX10] Incorrect error position for missing dim modifier
https://bugs.llvm.org/show_bug.cgi?id=48883 Bug ID: 48883 Summary: [AMDGPU][MC][GFX10] Incorrect error position for missing dim modifier Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Missing value of dim modifier may result in an incorrect error position. For example, assembling an instruction image_atomic_xor v4, v32, s[96:103] dmask:0x1 dim:, glc results in the following error message: error: failed parsing operand image_atomic_xor v4, v32, s[96:103] dmask:0x1 dim:, glc ^ -- 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 47671] missing loop unrolling and vectorization for loop with peeled branch
https://bugs.llvm.org/show_bug.cgi?id=47671 Florian Hahn changed: What|Removed |Added Fixed By Commit(s)||35b3989a30eefa66cd6edca4c6e ||1ec061c05ad96 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Florian Hahn --- Should be fixed by https://reviews.llvm.org/rG35b3989a30ee -- 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 48546] [LoopVectorization] Invalid code after interleaving add reduction
https://bugs.llvm.org/show_bug.cgi?id=48546 Congzhe Cao changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from Congzhe Cao --- Thanks very much for your reply! And apologies for not being able to get back to you sooner. After further investigation we found that we had internal changes that caused the issue, hence the bug is not relevant to upstream trunk code and we decided to abandon our patch. Thanks 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48884] New: [AMDGPU][MC] Parser may report an incorrect error position when there is no custom handler
https://bugs.llvm.org/show_bug.cgi?id=48884 Bug ID: 48884 Summary: [AMDGPU][MC] Parser may report an incorrect error position when there is no custom handler Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Parser may report an incorrect error position by skipping a comma. This bug manifests itself only in cases when there is no custom errors handler. For example, assembling an instruction image_atomic_xor v4, v32, s[96:103] dmask:0x1 dim:, glc results in the following error message: error: failed parsing operand image_atomic_xor v4, v32, s[96:103] dmask:0x1 dim:, glc ^ -- 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 48885] New: Crash in passing firstprivate args to tasks on Apple M1
https://bugs.llvm.org/show_bug.cgi?id=48885
Bug ID: 48885
Summary: Crash in passing firstprivate args to tasks on Apple
M1
Product: OpenMP
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: jcow...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 24420
--> https://bugs.llvm.org/attachment.cgi?id=24420&action=edit
Simple test code.
Passing threadprivate arguments into a task crashes on the Apple M1 aarch64)
machine.
The attached code demonstrates the problem when compiled with -fopenmp (and no
optimisation; with optimisation it appears to pass, but I think that is because
then the compiler recognises that the firstprivate values are constant and
therefore doesn't bother to pass them!)
$ clang --version
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
975b64b29375cdfb3672fedee4216c6512672fbf)
Target: aarch64-apple-darwin20.2.0
Thread model: posix
InstalledDir: /Users/jcownie/software/clang-12.0.0/arm64/bin
$ clang -fopenmp -g test_taskargs.c
$ lldb ./a.out
(lldb) target create "./a.out"
Current executable set to '/Users/jcownie/PPS_rtl/tests/a.out' (arm64).
(lldb) run
run
Process 72954 launched: '/Users/jcownie/PPS_rtl/tests/a.out' (arm64)
Process 72954 stopped
* thread #5, stop reason = EXC_BAD_ACCESS (code=1, address=0x6150200)
frame #0: 0x00013d6c a.out`.omp_task_entry. [inlined]
.omp_outlined.(.global_tid.=4, .part_id.=0x000108107ed0,
.privates.=0x000108107ee8, .copy_fn.=(a.out`.omp_task_privates_map. at
test_taskargs.c:22), .task_t.=0x000108107ec0, __context=0x000108107ef0)
at test_taskargs.c:25:24
22 #pragma omp task firstprivate(tpvar, tpvar2)
23 {
24 fprintf (stderr, "In task in thread %d tpvar = %d (should be
42), tpvar2 = %d (should be 84)\n", omp_get_thread_num(),
-> 25 tpvar, tpvar2);
^
26 failed = (tpvar != 42) || (tpvar2 != 84);
27 }
28 }
Target 0: (a.out) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
* frame #0: 0x00013d64 a.out`.omp_task_entry. [inlined]
.omp_outlined.(.global_tid.=0, .part_id.=0x000108107ed0,
.privates.=0x000108107ee8, .copy_fn.=(a.out`.omp_task_privates_map. at
test_taskargs.c:22), .task_t.=0x000108107ec0, __context=0x000108107ef0)
at test_taskargs.c:25:17
frame #1: 0x00013d08 a.out`.omp_task_entry.((null)=0,
(null)=0x000108107ec0) at test_taskargs.c:22
frame #2: 0x000100141878 libomp.dylib`__kmp_invoke_task(int, kmp_task*,
kmp_taskdata*) + 308
frame #3: 0x000100144c38 libomp.dylib`int __kmp_execute_tasks_64(kmp_info*, int, kmp_flag_64*, int, int*, void*, int) + 744
frame #4: 0x00010014e308 libomp.dylib`kmp_flag_64::wait(kmp_info*, int, void*) + 596
frame #5: 0x00010014c6b8
libomp.dylib`__kmp_hyper_barrier_gather(barrier_type, kmp_info*, int, int, void
(*)(void*, void*), void*) + 800
frame #6: 0x00010014c090 libomp.dylib`__kmp_join_barrier(int) + 592
frame #7: 0x00010012efd0 libomp.dylib`__kmp_internal_join + 92
frame #8: 0x00010012e848 libomp.dylib`__kmp_join_call + 264
frame #9: 0x000100121ff8 libomp.dylib`__kmpc_fork_call + 220
frame #10: 0x00013b8c a.out`main(argc=1, argv=0x00016fdff6e0)
at test_taskargs.c:15:1
frame #11: 0x00018e1f4f34 libdyld.dylib`start + 4
Note that this may be some issue related to a difference in the way varags
functions are handled by the Apple Aarch64 calling convention from the way
that they're handled on Linux Aarch64.
This code compiles and executes correctly on Linux/Aarch64, and on other
architectures (X86_64, ...)
--
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 48886] New: consteval function not allowed in default argument to constexpr constructor
https://bugs.llvm.org/show_bug.cgi?id=48886
Bug ID: 48886
Summary: consteval function not allowed in default argument to
constexpr constructor
Product: clang
Version: 11.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: s...@andyf.de
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Hello,
the following valid code is currently rejected by Clang 11 and trunk
(https://godbolt.org/z/645McM):
consteval int Fun() { return 0; }
struct Test {
constexpr Test(int loc = Fun()) {}
};
Test t{};
The error is:
:4:28: error: cannot take address of consteval function 'Fun' outside
of an immediate invocation
constexpr Test(int loc = Fun()) {}
^
:1:15: note: declared here
consteval int Fun() { return 0; }
^
1 error generated.
Compiler returned: 1
I had a brief communication with Richard Smith who confirmed that the code
above is valid.
I assume this bug is similar to https://bugs.llvm.org/show_bug.cgi?id=47714
Best,
Andreas
--
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 48887] New: [C++4OpenCL] Missing OpenCL specific diagnostics in templates
https://bugs.llvm.org/show_bug.cgi?id=48887
Bug ID: 48887
Summary: [C++4OpenCL] Missing OpenCL specific diagnostics in
templates
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: anastasia.stul...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
Clang fails to diagnose invalid cases inside the templates that appear after
template parameter substitution:
template
void templ() {
T loc;
}
void foo(){
templ();
templ<__local event_t>();
templ<__local sampler_t>();
templ();
image1d_t img;
__local event_t e;
__local sampler_t s;
half h;
}
'
The diagnostic will appear correctly for 'foo' but no 'templ'. Even if after
the substitution they have identical invalid cases.
See: https://godbolt.org/z/jn8WT3
--
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 48888] New: [X86] MCInst assertion failure "This is not a register operand!"
https://bugs.llvm.org/show_bug.cgi?id=4
Bug ID: 4
Summary: [X86] MCInst assertion failure "This is not a register
operand!"
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: nikita@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define void @test(i64* %p) nounwind {
bb:
%i = load i64, i64* %p, align 8, !range !0
%i1 = and i64 %i, 6
%i2 = icmp eq i64 %i1, 2
br i1 %i2, label %bb3, label %bb5
bb3: ; preds = %bb
%i4 = icmp ne {}* undef, null
br label %bb5
bb5: ; preds = %bb3, %bb
br label %bb6
bb6: ; preds = %bb5
br i1 %i2, label %bb7, label %bb9
bb7: ; preds = %bb6
%i8 = getelementptr inbounds i64, i64* undef, i64 5
br label %bb9
bb9: ; preds = %bb7, %bb6
ret void
}
!0 = !{i64 0, i64 5}
llc %s:
llc: /home/nikic/llvm-project/llvm/include/llvm/MC/MCInst.h:65: unsigned int
llvm::MCOperand::getReg() const: Assertion `isReg() && "This is not a register
operand!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: build/bin/llc -debug test135.ll
1. Running pass 'Function Pass Manager' on module 'test135.ll'.
2. Running pass 'X86 Assembly Printer' on function '@test'
#0 0x55cc218af481 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(build/bin/llc+0x2e80481)
#1 0x55cc218ad054 llvm::sys::RunSignalHandlers() (build/bin/llc+0x2e7e054)
#2 0x55cc218ad1cb SignalHandler(int) (build/bin/llc+0x2e7e1cb)
#3 0x7f4b42be53c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x7f4b4268518b raise
/build/glibc-ZN95T4/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f4b42664859 abort /build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f4b42664729 get_sysdep_segment_value
/build/glibc-ZN95T4/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f4b42664729 _nl_load_domain
/build/glibc-ZN95T4/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f4b42675f36 (/lib/x86_64-linux-gnu/libc.so.6+0x36f36)
#9 0x55cc20715a88 (anonymous
namespace)::X86MCCodeEmitter::emitPrefixImpl(unsigned int&, llvm::MCInst
const&, llvm::MCSubtargetInfo const&, llvm::raw_ostream&) const
(build/bin/llc+0x1ce6a88)
#10 0x55cc2071708f (anonymous
namespace)::X86MCCodeEmitter::encodeInstruction(llvm::MCInst const&,
llvm::raw_ostream&, llvm::SmallVectorImpl&,
llvm::MCSubtargetInfo const&) const (build/bin/llc+0x1ce808f)
#11 0x55cc202229ad
llvm::X86AsmPrinter::StackMapShadowTracker::count(llvm::MCInst&,
llvm::MCSubtargetInfo const&, llvm::MCCodeEmitter*) (.part.0)
(build/bin/llc+0x17f39ad)
#12 0x55cc2022b4f1 llvm::X86AsmPrinter::emitInstruction(llvm::MachineInstr
const*) (build/bin/llc+0x17fc4f1)
#13 0x55cc209bd174 llvm::AsmPrinter::emitFunctionBody()
(build/bin/llc+0x1f8e174)
#14 0x55cc2021c7e3
llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&)
(build/bin/llc+0x17ed7e3)
#15 0x55cc20bee20c
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(build/bin/llc+0x21bf20c)
#16 0x55cc21082d78 llvm::FPPassManager::runOnFunction(llvm::Function&)
(build/bin/llc+0x2653d78)
--
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 48889] New: ScalarExprEmitter::VisitAbstractConditionalOperator(const clang::AbstractConditionalOperator*): Assertion `!RHS && "LHS and RHS types must match"' failed
https://bugs.llvm.org/show_bug.cgi?id=48889
Bug ID: 48889
Summary: ScalarExprEmitter::VisitAbstractConditionalOperator(co
nst clang::AbstractConditionalOperator*): Assertion
`!RHS && "LHS and RHS types must match"' failed
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: mai...@live.de
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
clang++: /root/llvm-project/clang/lib/CodeGen/CGExprScalar.cpp:4543:
llvm::Value*
{anonymous}::ScalarExprEmitter::VisitAbstractConditionalOperator(const
clang::AbstractConditionalOperator*): Assertion `!RHS && "LHS and RHS types
must match"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments:
/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang++ -std=c++17 -pthread
-Wstack-protector -fstack-protector-all -fcf-protection=full
-fstack-clash-protection -Wall -Wextra -Wgnu -Wformat -Wformat-security -Wvla
-Wshadow-field -Wswitch -Wthread-safety -Wrange-loop-analysis -Wredundant-decls
-Wunused-variable -Wunused-member-function -Wdate-time
-Wconditional-uninitialized -Wsign-compare -Woverloaded-virtual
-Wsuggest-override -Wunreachable-code-loop-increment -Wno-unused-parameter
-Wno-self-assign -Wno-unused-local-typedef -Wno-deprecated-register
-Wno-implicit-fallthrough -Wno-deprecated-copy
-fsanitize=address,fuzzer,undefined -fPIE -g -O2 -fcolor-diagnostics
-DHAVE_CONFIG_H -I. -I../src/config -DABORT_ON_FAILED_ASSUME -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -I. -I./secp256k1/include -DBOOST_SP_USE_STD_ATOMIC
-DBOOST_AC_USE_STD_ATOMIC -I/usr/include -I./leveldb/include
-I./leveldb/helpers/memenv -I./univalue/include -DHAVE_BUILD_INFO
-D__STDC_FORMAT_MACROS -c -o test/fuzz/fuzz-banman.o test/fuzz/banman.cpp
1. parser at end of file
2. Per-file LLVM IR generation
3. ./test/fuzz/util.h:40:6: Generating code for declaration 'CallOneOf'
#0 0x557243375ee1 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x34daee1)
#1 0x557243373b94 llvm::sys::RunSignalHandlers()
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x34d8b94)
#2 0x557243373e31 llvm::sys::CleanupOnSignal(unsigned long)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x34d8e31)
#3 0x5572432d2bc8 CrashRecoverySignalHandler(int)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3437bc8)
#4 0x7f8df62a53c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#5 0x7f8df5d6118b raise
/build/glibc-ZN95T4/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#6 0x7f8df5d40859 abort /build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:81:7
#7 0x7f8df5d40729 get_sysdep_segment_value
/build/glibc-ZN95T4/glibc-2.31/intl/loadmsgcat.c:509:8
#8 0x7f8df5d40729 _nl_load_domain
/build/glibc-ZN95T4/glibc-2.31/intl/loadmsgcat.c:970:34
#9 0x7f8df5d51f36 (/lib/x86_64-linux-gnu/libc.so.6+0x36f36)
#10 0x5572439edce0 (anonymous
namespace)::ScalarExprEmitter::VisitAbstractConditionalOperator(clang::AbstractConditionalOperator
const*) (/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3b52ce0)
#11 0x5572439edee3 (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3b52ee3)
#12 0x5572439edeff (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3b52eff)
#13 0x5572439effea
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3b54fea)
#14 0x557243997847 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr
const*, clang::CodeGen::AggValueSlot, bool)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3afc847)
#15 0x5572439ab31e
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3b1031e)
#16 0x5572439eee75 (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3b53e75)
#17 0x5572439eee9b (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3b53e9b)
#18 0x5572439eee9b (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/clang+++0x3b53e9b)
#19 0x5572439eee9b (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
(/root/llvm-project/build_libfuzzer_2021_01_26/bin/
[llvm-bugs] [Bug 48890] New: Incorrect alignment of __attribute__((aligned)) enum
https://bugs.llvm.org/show_bug.cgi?id=48890
Bug ID: 48890
Summary: Incorrect alignment of __attribute__((aligned)) enum
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: ju.o...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Consider
enum __attribute__((aligned(8))) E {
A = 1,
};
int g(void) {
return _Alignof(enum E);
}
gcc returns 4, clang returns 8 on x86_64-unknown-linux-gnu. Gcc appears to
ignored this attribute on enums.
--
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 48891] New: [clang-format] Different formatted output can be produced from varying whitespace
https://bugs.llvm.org/show_bug.cgi?id=48891
Bug ID: 48891
Summary: [clang-format] Different formatted output can be
produced from varying whitespace
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: leonardc...@google.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
As of https://reviews.llvm.org/D93839, clang-format can produce different
formatted files depending on amount of whitespace. For example, given (A):
```
#include
namespace fuzzing {}
```
`clang-format` with this patch would produced (B):
```
#include
namespace fuzzing {
}
```
but given (C):
```
#include
namespace fuzzing {
}
```
would be formatted to (D):
```
#include
namespace fuzzing {
}
```
The invocation specifically is `clang-format --style=google file`. Prior to
this patch, both inputs (A/C) would give the same output:
```
#include
namespace fuzzing {}
```
This seems to be unintended behavior that should be fixed. This doesn't seem to
occur if `#include "stdint.h"` is used.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 29949 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::isSFINAEContext
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-01-26 Type: Bug New issue 29949 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::isSFINAEContext https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29949 Detailed Report: https://oss-fuzz.com/testcase?key=5905401277186048 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc8683aff8 Crash State: clang::Sema::isSFINAEContext clang::Sema::EmitCurrentDiagnostic clang::Sema::ImmediateDiagBuilder::~ImmediateDiagBuilder Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202101240605:202101250607 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5905401277186048 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48892] New: Implement atomic operations for M68k
https://bugs.llvm.org/show_bug.cgi?id=48892 Bug ID: 48892 Summary: Implement atomic operations for M68k Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: M68k Assignee: unassignedb...@nondot.org Reporter: glaub...@physik.fu-berlin.de CC: glaub...@physik.fu-berlin.de, llvm-bugs@lists.llvm.org, miny...@uci.edu The M68k is not implementing any atomic operations yet which include load and store operations and compare_and_swap. Load operations: - atomic_load_8 - using MOV8rm - atomic_load_16 - using MOV16rm - atomic_load_32 - using MOV32rm Store operations: - atomic_store_8 - using MOV8mr - atomic_store_16 - using MOV16mr - atomic_store_32 - using MOV32mr Compare-and-swap: - atomic_cmp_swap_32 - using CAS - atomic_cmp_swap_64 - using CAS2 Without support for atomic operations, compiling some C++ code currently fails with: glaubitz@epyc:..openscad-2019.05/src> /local_scratch/glaubitz/M680x0-mono-repo/build/bin/clang -target m68k-linux-gnu localscope.cc -o localscope.o -I /usr/m68k-linux-gnu/include/c++/10/m68k-linux-gnu/ -I /usr/m68k-linux-gnu/include/ -I /usr/include/glib-2.0 -I /usr/lib/m68k-linux-gnu/glib-2.0/include/ fatal error: error in backend: Cannot select: 0x55f0fc5b1ea8: i8,ch = AtomicLoad<(dereferenceable load acquire 1 from `i8* bitcast (i64* @_ZGVZN5boost6system6detail15to_std_categoryERKNS0_14error_categoryEE4map_ to i8*)`, align 4)> 0x55f0fc31e988, 0x55f0fc5ae8c8 0x55f0fc5ae8c8: i32 = M680x0ISD::WrapperPC TargetGlobalAddress:i32 0 0x55f0fc5aec70: i32 = TargetGlobalAddress 0 In function: _ZN5boost6system6detail15to_std_categoryERKNS0_14error_categoryE clang-12: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 12.0.0 (g...@github.com:M680x0/M680x0-mono-repo.git c5834ffbda019df8c94c669c658d804cb9c19af3) Target: m68k-unknown-linux-gnu Thread model: posix InstalledDir: /local_scratch/glaubitz/M680x0-mono-repo/build/bin clang-12: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-12: note: diagnostic msg: /tmp/localscope-405c82.cpp clang-12: note: diagnostic msg: /tmp/localscope-405c82.sh clang-12: note: diagnostic msg: glaubitz@epyc:..openscad-2019.05/src> -- 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 48893] New: The performance of vector::assign is 100 times worse than that of libstdc++.
https://bugs.llvm.org/show_bug.cgi?id=48893
Bug ID: 48893
Summary: The performance of vector::assign is 100 times worse
than that of libstdc++.
Product: libc++
Version: 8.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: release blocker
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: 2077213...@qq.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Created attachment 24423
--> https://bugs.llvm.org/attachment.cgi?id=24423&action=edit
the testcase
For details about test cases, see the attachment.
./gccO0.out
copy 1610957372.518706
copy1 1610957372.526591
7885
./clangO0.out
copy 1610957377.298682
copy1 1610957378.455563
1156881
./gccO2.out
copy 1610957396.558745
copy1 1610957396.566606
7861
./clangO2.out
copy 1610957407.81578
copy1 1610957407.179067
97489
the test function
int main(int argc, char* argv[])
{
std::vector data;
data.resize(1024UL*1024*24);
std::vector data1;
struct timeval tv,tv1;
gettimeofday(&tv, NULL);
data1.assign(data.begin(), data.end());
gettimeofday(&tv1, NULL);
std::cout << "copy " << tv.tv_sec <<"." << tv.tv_usec << std::endl;
std::cout << "copy1 " << tv1.tv_sec <<"." << tv1.tv_usec << std::endl;
std::cout << tv1.tv_sec * 100 + tv1.tv_usec - (tv.tv_sec*100 +
tv.tv_usec) << std::endl;
return 0;
}
The main function consumed is __construct_range_forward. libcxx use the
__construct_range_forward
Each element is constructed using the construct method, which is constructed
using the placement new method. GCC uses std::uninitialized_copy to copy the
memory. The performance is significantly better than that of libcxx.
--
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 48894] New: clang's integrated assembler doesn't permit setting the target arch via -Wa, -march=armv7-a
https://bugs.llvm.org/show_bug.cgi?id=48894 Bug ID: 48894 Summary: clang's integrated assembler doesn't permit setting the target arch via -Wa,-march=armv7-a Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: ndesaulni...@google.com CC: caij2...@gmail.com, htmldevelo...@gmail.com, kristof.be...@arm.com, lloz...@chromium.org, llvm-bugs@lists.llvm.org, natechancel...@gmail.com, neeil...@live.com, richard-l...@metafoo.co.uk, srhi...@google.com Blocks: 4068 Consider the following file: $ cat foo.s foo: dmb $ clang --target=arm-linux-gnueabi -Wa,-march=armv7-a foo.s -c clang-12: warning: argument unused during compilation: '-Wa,-march=armv7-a' [-Wunused-command-line-argument] foo.s:2:3: error: instruction requires: data-barriers dmb ^ $ cat bar.s .arch armv7-a foo: dmb $ clang --target=arm-linux-gnueabi -Wa,-march=armv7-a bar.s -c clang-12: warning: argument unused during compilation: '-Wa,-march=armv7-a' [-Wunused-command-line-argument] It would seem that clang will only set the target arch via assembler directive and not consuming the command line flag. This is a blocker to using Clang's integrated assembler for the 32b ARM Linux kernel. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=4068 [Bug 4068] [Meta] Compiling the Linux kernel with clang -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 29955 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticsEngine::DiagState::getOrAddMapping
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-01-27 Type: Bug New issue 29955 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticsEngine::DiagState::getOrAddMapping https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29955 Detailed Report: https://oss-fuzz.com/testcase?key=6279429611454464 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc56d56f98 Crash State: clang::DiagnosticsEngine::DiagState::getOrAddMapping clang::DiagnosticIDs::getDiagnosticSeverity clang::DiagnosticIDs::getDiagnosticLevel Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202101240605:202101250607 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6279429611454464 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48895] New: Function with unparenthesized trailing requires-expression always put on a single line
https://bugs.llvm.org/show_bug.cgi?id=48895
Bug ID: 48895
Summary: Function with unparenthesized trailing
requires-expression always put on a single line
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: johel...@gmail.com
CC: djas...@google.com, johel...@gmail.com,
kli...@google.com, llvm-bugs@lists.llvm.org
.clang-format:
```
BasedOnStyle: LLVM
AllowShortFunctionsOnASingleLine: None
```
Input and expected formatted result:
```C++
auto f(int l, int r) requires requires {
l *r;
}
{
return l * r;
}
```
Actual output:
```C++
auto f(int l, int r) requires requires {
l *r;
}
{ return l * r; }
```
Because this works fine as input and actual formatted output:
```C++
auto f(int l, int r) requires requires {
l *r;
}
{
return l * r;
return l * r;
}
```
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 29957 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm-opt-fuzzer--x86_64-instcombine
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-01-27 Type: Bug New issue 29957 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm-opt-fuzzer--x86_64-instcombine https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29957 Detailed Report: https://oss-fuzz.com/testcase?key=5347620182687744 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 60 secs) Crash Address: Crash State: llvm-opt-fuzzer--x86_64-instcombine Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712190608:201712210617 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5347620182687744 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
