[llvm-bugs] [Bug 44961] debug-info tests CMake fails to find python3
https://bugs.llvm.org/show_bug.cgi?id=44961 David Spickett changed: What|Removed |Added CC||david.spick...@linaro.org Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #3 from David Spickett --- This was fixed by https://reviews.llvm.org/D79795 (f829ba60dadb71340318d525708e33b08ad61f8b). -- 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 46816] New: ExecutionEngine/MCJIT/stubs-sm-pic.ll XPASS'es on non-asserts 32-bit x86 builds
https://bugs.llvm.org/show_bug.cgi?id=46816 Bug ID: 46816 Summary: ExecutionEngine/MCJIT/stubs-sm-pic.ll XPASS'es on non-asserts 32-bit x86 builds Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: htmldevelo...@gmail.com, lha...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 46725 For example, in a Visual Studio 32-bit dev prompt: cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=llvm -DLLVM_TARGETS_TO_BUILD=X86 ..\llvm ninja check Testing: 0.. 10.. 20.. 30.. 40.. 50.. XPASS: LLVM :: ExecutionEngine/MCJIT/stubs-sm-pic.ll (23621 of 38498) TEST 'LLVM :: ExecutionEngine/MCJIT/stubs-sm-pic.ll' FAILED Script: -- : 'RUN: at line 1'; c:\src\llvm.monorepo\build.bar\bin\lli.exe -mtriple=i686-pc-windows-msvc-elf -disable-lazy-compilation=false -relocation-model=pic -code-model=small c:\src\llvm.monorepo\llvm\test\ExecutionEngine\MCJIT\stubs-sm-pic.ll -- Exit Code: 0 Command Output (stdout): -- $ ":" "RUN: at line 1" $ "c:\src\llvm.monorepo\build.bar\bin\lli.exe" "-mtriple=i686-pc-windows-msvc-elf" "-disable-lazy-compilation=false" "-relocation-model=pic" "-code-model=small" "c:\src\llvm.monorepo\llvm\test\ExecutionEngine\MCJIT\stubs-sm-pic.ll" -- Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. Unexpectedly Passed Tests (1): LLVM :: ExecutionEngine/MCJIT/stubs-sm-pic.ll The test is marked XFAIL on i386 and i686 Because of this assert: Relocation type not implemented yet! UNREACHABLE executed at C:\src\llvm.monorepo\llvm\lib\ExecutionEngine\RuntimeDyld\RuntimeDyldELF.cpp:362! Maybe the simplest fix for now would be to make it error also in non-asserts builds? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=46725 [Bug 46725] [meta] 11.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 46817] New: Vector load operations vec_xl have non-const pointers in their signature
https://bugs.llvm.org/show_bug.cgi?id=46817
Bug ID: 46817
Summary: Vector load operations vec_xl have non-const pointers
in their signature
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Headers
Assignee: unassignedclangb...@nondot.org
Reporter: alexander.gr...@tu-dresden.de
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I'm getting failed compilations for code using vec_xl on IBM Power architecture
machines where the input is a `const float*`.
GCC happily accepts the same code but on clang it fails to resolved the
function as the clang vec_xl functions use non-const pointers.
>From a semantic PoV using const pointers is more correct as the value is only
read. Example:
static inline __ATTRS_o_ai vector signed long long
vec_xl(signed long long __offset, signed long long *__ptr) {
return *(unaligned_vec_sll *)(__ptr + __offset);
}
Note that changing to const pointers is backward compatible as they can be
converted from non-const pointers implicitly.
--
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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46806, which changed state. Bug 46806 Summary: Backport PCH handling commits to 11.0 https://bugs.llvm.org/show_bug.cgi?id=46806 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 46806] Backport PCH handling commits to 11.0
https://bugs.llvm.org/show_bug.cgi?id=46806 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- Pushed as 3895466e2c336c0797710ae35150ba1ce6bc0b96 and 54eea6127c4d77db03787b7c55765632fb9a6f1c to 11.x. Please let me know if there are any follow-ups. -- 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 46680] ICE in backend: Instruction Combining seems stuck in an infinite loop after 100 iterations
https://bugs.llvm.org/show_bug.cgi?id=46680 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #13 from Hans Wennborg --- Pushed to 11.x as eb3c5db40a1450d50c387f3a42f4c095001220cb -- 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46680, which changed state. Bug 46680 Summary: ICE in backend: Instruction Combining seems stuck in an infinite loop after 100 iterations https://bugs.llvm.org/show_bug.cgi?id=46680 What|Removed |Added Status|REOPENED|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 46807] Merge 5b5dc2442ac7 into 11.0 release branch
https://bugs.llvm.org/show_bug.cgi?id=46807 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED CC||h...@chromium.org Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Pushed to 11.x as 8a2bc9431193026454745d538cf7e5a5a6b6d5be -- 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46807, which changed state. Bug 46807 Summary: Merge 5b5dc2442ac7 into 11.0 release branch https://bugs.llvm.org/show_bug.cgi?id=46807 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 46819] New: [Reduce] argument reduction assumes call inst
https://bugs.llvm.org/show_bug.cgi?id=46819 Bug ID: 46819 Summary: [Reduce] argument reduction assumes call inst Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: llvm-reduce Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: dblai...@gmail.com, llvm-bugs@lists.llvm.org ReduceArguments.cpp replaceFunctionCalls() hard-assumes that all calls as callinst, and crashes when that isn't the case. -- 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 46818] New: [Reduce] basic block reduction assumes callinst
https://bugs.llvm.org/show_bug.cgi?id=46818
Bug ID: 46818
Summary: [Reduce] basic block reduction assumes callinst
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: llvm-reduce
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: dblai...@gmail.com, llvm-bugs@lists.llvm.org
Just so i don't forget later on,
diff --git a/llvm/tools/llvm-reduce/deltas/ReduceBasicBlocks.cpp
b/llvm/tools/llvm-reduce/deltas/ReduceBasicBlocks.cpp
index 002d81a6748..e049c6f405c 100644
--- a/llvm/tools/llvm-reduce/deltas/ReduceBasicBlocks.cpp
+++ b/llvm/tools/llvm-reduce/deltas/ReduceBasicBlocks.cpp
@@ -41,6 +41,7 @@ static void replaceBranchTerminator(BasicBlock &BB,
if (auto IndBI = dyn_cast(Term))
Address = IndBI->getAddress();
+ Term->replaceAllUsesWith(UndefValue::get(Term->getType()));
Term->eraseFromParent();
if (ChunkSucessors.empty()) {
--
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 23570 in oss-fuzz: llvm:clangd-fuzzer: ASSERT: llvm::sys::path::is_absolute(AbsPath) && "the path is relative"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 23570 by ClusterFuzz-External: llvm:clangd-fuzzer: ASSERT: llvm::sys::path::is_absolute(AbsPath) && "the path is relative" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23570#c1 ClusterFuzz testcase 5361911553327104 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202007220207:202007230200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46820] New: Assertion `(Ops[0].getValueType().getVectorElementCount() * Ops.size()) == VT.getVectorElementCount() & & "Incorrect element count in vector concatenation!"' failed
https://bugs.llvm.org/show_bug.cgi?id=46820 Bug ID: 46820 Summary: Assertion `(Ops[0].getValueType().getVectorElementCount() * Ops.size()) == VT.getVectorElementCount() & & "Incorrect element count in vector concatenation!"' failed Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: benny@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Created attachment 23767 --> https://bugs.llvm.org/attachment.cgi?id=23767&action=edit reduced test case Seems to be an AVX512 issue $ llc < bugpoint-reduced-simplified.ll llc: llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:4340: llvm::SDValue foldCONCAT_VECTORS(const llvm::SDLoc &, llv m::EVT, ArrayRef, llvm::SelectionDAG &): Assertion `(Ops[0].getValueType().getVectorElementCount() * Ops.size()) == VT.getVectorElementCount() & & "Incorrect element count in vector concatenation!"' failed. -- 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 24003 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: isRegLoc()
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 24003 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: isRegLoc() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24003#c1 ClusterFuzz testcase 6102691517038592 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202007220207:202007230200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46821] New: Failure to optimize memcpy pattern
https://bugs.llvm.org/show_bug.cgi?id=46821
Bug ID: 46821
Summary: Failure to optimize memcpy pattern
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
void f(char *restrict p, char *restrict q, size_t n)
{
while (n-- > 0)
*p++ = *q++;
}
This can be optimized to `if (n) memcpy(p, q, n);`. This transformation is done
by GCC, but not by LLVM
--
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 46700] Support --gc-sections when partial linking with -r
https://bugs.llvm.org/show_bug.cgi?id=46700 Fangrui Song changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Fangrui Song --- 4e80c768c28fa919aa3d4fd662af8ea99feda4d6 (target: lld 12.0.0) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46822] New: Failure to optimize based on [[noreturn]]
https://bugs.llvm.org/show_bug.cgi?id=46822
Bug ID: 46822
Summary: Failure to optimize based on [[noreturn]]
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
[[noreturn]] void g(int i)
{
if (i > 0)
abort();
}
This can be optimized to `abort();`. This transformation is done by GCC, but
not by LLVM.
--
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 18347] Sparse switches lowered to an else-if chain
https://bugs.llvm.org/show_bug.cgi?id=18347 Nikita Kniazev changed: What|Removed |Added CC||nok.ra...@gmail.com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Nikita Kniazev --- This has been fixed in 3.7 and most likely a duplicate of the linked bug 22262 *** This bug has been marked as a duplicate of bug 22262 *** -- 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 46823] New: Backport RISC-V bitmanip extension commits to 11.0
https://bugs.llvm.org/show_bug.cgi?id=46823 Bug ID: 46823 Summary: Backport RISC-V bitmanip extension commits to 11.0 Product: libraries Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: RISC-V Assignee: unassignedb...@nondot.org Reporter: lewis.rev...@embecosm.com CC: a...@lowrisc.org, llvm-bugs@lists.llvm.org The codegen support for RISC-V's bitmanip extension was committed just after the 11.0 branch point. The support is gated by an experimental flag not enabled by default so backporting the commits into 11.0 will not cause any foreseeable regressions. The commits are the following: https://reviews.llvm.org/rGe2692f0ee7f3 https://reviews.llvm.org/rG31b52b4345e3 https://reviews.llvm.org/rG6144f0a1e52e https://reviews.llvm.org/rGd4be33374c07 https://reviews.llvm.org/rGc9c955ada8e6 -- 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 46824] New: Global declare target pointer cannot be accessed in target region
https://bugs.llvm.org/show_bug.cgi?id=46824 Bug ID: 46824 Summary: Global declare target pointer cannot be accessed in target region Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: OpenMP Assignee: unassignedclangb...@nondot.org Reporter: jennifer...@intel.com CC: llvm-bugs@lists.llvm.org -- 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 46825] New: clang DirectoryWatcherTest unittest hangs on some filesystems, but not others
https://bugs.llvm.org/show_bug.cgi?id=46825
Bug ID: 46825
Summary: clang DirectoryWatcherTest unittest hangs on some
filesystems, but not others
Product: Test Suite
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: lit
Assignee: unassignedb...@nondot.org
Reporter: bfrie...@lbl.gov
CC: dan...@zuster.org, llvm-bugs@lists.llvm.org
Greetings,
I am very close to having a working x86 flang buildbot - everything about the
bot's workflow succeeds except for a single lit test, 'DirectoryWatcherTest'.
This test reads and writes some temporary files/directories in TMPDIR.
On the system where this buildbot is running (a Cray XC40), I have observed the
following behaviors (all results tested on commit 724bf4ee23a of llvm-project):
On "login nodes", the test runs without any issues. TMPDIR is set to `/tmp`,
which is a ramdisk:
```
cori10:DirectoryWatcher> ./DirectoryWatcherTests
[==] Running 8 tests from 1 test case.
[--] Global test environment set-up.
[--] 8 tests from DirectoryWatcherTest
[ RUN ] DirectoryWatcherTest.InitialScanSync
[ OK ] DirectoryWatcherTest.InitialScanSync (7 ms)
[ RUN ] DirectoryWatcherTest.InitialScanAsync
[ OK ] DirectoryWatcherTest.InitialScanAsync (8 ms)
[ RUN ] DirectoryWatcherTest.AddFiles
[ OK ] DirectoryWatcherTest.AddFiles (8 ms)
[ RUN ] DirectoryWatcherTest.ModifyFile
[ OK ] DirectoryWatcherTest.ModifyFile (16 ms)
[ RUN ] DirectoryWatcherTest.DeleteFile
[ OK ] DirectoryWatcherTest.DeleteFile (29 ms)
[ RUN ] DirectoryWatcherTest.DeleteWatchedDir
[ OK ] DirectoryWatcherTest.DeleteWatchedDir (0 ms)
[ RUN ] DirectoryWatcherTest.InvalidatedWatcher
[ OK ] DirectoryWatcherTest.InvalidatedWatcher (7 ms)
[ RUN ] DirectoryWatcherTest.InvalidatedWatcherAsync
[ OK ] DirectoryWatcherTest.InvalidatedWatcherAsync (16 ms)
[--] 8 tests from DirectoryWatcherTest (91 ms total)
[--] Global test environment tear-down
[==] 8 tests from 1 test case ran. (91 ms total)
[ PASSED ] 8 tests.
cori10:DirectoryWatcher> strace -f -e open ./DirectoryWatcherTests 2>&1|grep
open
[pid 49990] open("/tmp/dirwatcher-adcb34/watch",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
open("/tmp/dirwatcher-adcb34", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/tmp/dirwatcher-adcb34/watch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
= 4
[pid 49995] open("/tmp/dirwatcher-0cf5ec/watch",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
open("/tmp/dirwatcher-0cf5ec", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/tmp/dirwatcher-0cf5ec/watch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
= 4
[pid 49990] open("/tmp/dirwatcher-ab6ab0/watch",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
open("/tmp/dirwatcher-ab6ab0", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/tmp/dirwatcher-ab6ab0/watch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
= 4
[pid 49990] open("/tmp/dirwatcher-f06c15/watch",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
open("/tmp/dirwatcher-f06c15", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/tmp/dirwatcher-f06c15/watch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
= 4
[pid 49990] open("/tmp/dirwatcher-3204e2/watch",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
open("/tmp/dirwatcher-3204e2", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/tmp/dirwatcher-3204e2/watch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
= 4
[pid 49990] open("/tmp/dirwatcher-390f43/watch",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
[pid 49990] open("/tmp/dirwatcher-390f43/watch",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
open("/tmp/dirwatcher-390f43", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid 49990] open("/tmp/dirwatcher-34f29d/watch",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
[pid 49990] open("/tmp/dirwatcher-34f29d",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/tmp/dirwatcher-34f29d/watch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
= 4
[pid 50018] open("/tmp/dirwatcher-f385d3/watch",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
[pid 49990] open("/tmp/dirwatcher-f385d3",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/tmp/dirwatcher-f385d3/watch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
= 4
```
However, the same test on an XC "compute node" hangs:
```
nid00049:DirectoryWatcher> ./DirectoryWatcherTests
[==] Running 8 tests from 1 test case.
[--] Global test environment set-up.
[--] 8 tests from DirectoryWatcherTest
[ RUN ] DirectoryWatcherTest.InitialScanSync
[ OK ] DirectoryWatcherTest.InitialScanSync (5 ms)
[ RUN ] DirectoryWatcherTest.InitialScanAsync
[ OK ] DirectoryWatcherTest.InitialScanAsync (8 ms)
[ RUN ] DirectoryWatcherTest.AddFiles
[ OK ] DirectoryWat
[llvm-bugs] [Bug 46814] Crash in IPSCCP when building mesa
https://bugs.llvm.org/show_bug.cgi?id=46814 Nikita Popov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||def48b0e8886ce219b4a77c6e71 ||15a4a86147e04 --- Comment #6 from Nikita Popov --- Should be fixed by https://github.com/llvm/llvm-project/commit/def48b0e8886ce219b4a77c6e7115a4a86147e04. -- 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 46826] New: Rewrite WritingAnLLVMPass to reference NPM
https://bugs.llvm.org/show_bug.cgi?id=46826 Bug ID: 46826 Summary: Rewrite WritingAnLLVMPass to reference NPM Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: aeuba...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 46649 https://llvm.org/docs/WritingAnLLVMPass.html should be rewritten to reference NPM, not legacy PM. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=46649 [Bug 46649] Change default pass manager to new pass manager -- 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 46649] Change default pass manager to new pass manager
https://bugs.llvm.org/show_bug.cgi?id=46649 Bug 46649 depends on bug 46826, which changed state. Bug 46826 Summary: Rewrite WritingAnLLVMPass to reference NPM https://bugs.llvm.org/show_bug.cgi?id=46826 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE -- 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 46826] Rewrite WritingAnLLVMPass to reference NPM
https://bugs.llvm.org/show_bug.cgi?id=46826 Arthur Eubanks changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Arthur Eubanks --- *** This bug has been marked as a duplicate of bug 28319 *** -- 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 46827] New: [X86] Bad machine code: Using an undefined physical register
https://bugs.llvm.org/show_bug.cgi?id=46827 Bug ID: 46827 Summary: [X86] Bad machine code: Using an undefined physical register Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llc Assignee: unassignedb...@nondot.org Reporter: bharathi.sesha...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 23768 --> https://bugs.llvm.org/attachment.cgi?id=23768&action=edit Test case The failure (crash) was observed when building 32-bit code with LTO (both gold and lld). The reduced test case and crash logs are included. $ llc -O2 test.ll *** Bad machine code: Using an undefined physical register *** - function: - basic block: %bb.26 (0x6968630) - instruction: JCC_1 %bb.72, 5, implicit $eflags - operand 2: implicit $eflags LLVM ERROR: Found 1 machine code errors. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: llvm-trunk/build-dbg/bin/llc -O2 test.ll 1. Running pass 'Function Pass Manager' on module 'test.ll'. 2. Running pass 'Machine Instruction Scheduler' on function '@0' #0 0x03d42c08 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm-trunk/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:22 #1 0x03d42c9b PrintStackTraceSignalHandler(void*) llvm-trunk/llvm-project/llvm/lib/Support/Unix/Signals.inc:625:1 #2 0x03d40d2d llvm::sys::RunSignalHandlers() llvm-trunk/llvm-project/llvm/lib/Support/Signals.cpp:68:20 #3 0x03d4264b SignalHandler(int) llvm-trunk/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:1 #4 0x003a9600f7e0 __restore_rt (/lib64/libpthread.so.0+0x3a9600f7e0) #5 0x003a958324f5 raise (/lib64/libc.so.6+0x3a958324f5) #6 0x003a95833cd5 abort (/lib64/libc.so.6+0x3a95833cd5) #7 0x03c9f7e7 llvm::install_bad_alloc_error_handler(void (*)(void*, std::__cxx11::basic_string, std::allocator > const&, bool), void*) llvm-trunk/llvm-project/llvm/lib/Support/ErrorHandling.cpp:130:61 #8 0x030bf22a llvm::MachineFunction::verify(llvm::Pass*, char const*, bool) const llvm-trunk/llvm-project/llvm/lib/CodeGen/MachineVerifier.cpp:312:25 #9 0x02f38410 llvm::LiveRangeCalc::findReachingDefs(llvm::LiveRange&, llvm::MachineBasicBlock&, llvm::SlotIndex, unsigned int, llvm::ArrayRef ) llvm-trunk/llvm-project/llvm/lib/CodeGen/LiveRangeCalc.cpp:225:39 #10 0x02f37a12 llvm::LiveRangeCalc::extend(llvm::LiveRange&, llvm::SlotIndex, unsigned int, llvm::ArrayRef) llvm-trunk/llvm-project/llvm/lib/C odeGen/LiveRangeCalc.cpp:107:23 #11 0x02f3c123 llvm::LiveIntervalCalc::extendToUses(llvm::LiveRange&, llvm::Register, llvm::LaneBitmask, llvm::LiveInterval*) llvm-trunk/llvm-project/llvm/lib/ CodeGen/LiveIntervalCalc.cpp:203:11 #12 0x02f234ad llvm::LiveIntervalCalc::extendToUses(llvm::LiveRange&, llvm::MCRegister) llvm-trunk/llvm-project/llvm/include/llvm/CodeGen/LiveIntervalCalc.h:56 :3 #13 0x02f1e178 llvm::LiveIntervals::computeRegUnitRange(llvm::LiveRange&, unsigned int) llvm-trunk/llvm-project/llvm/lib/CodeGen/LiveIntervals.cpp:298:29#14 0x01a2c3db llvm::LiveIntervals::getRegUnit(unsigned int) llvm-trunk/llvm-project/llvm/include/llvm/CodeGen/LiveIntervals.h:402:15 #15 0x02f23a92 llvm::LiveIntervals::HMEditor::getRegUnitLI(unsigned int) llvm-trunk/llvm-project/llvm/lib/CodeGen/LiveIntervals.cpp:975:34#16 0x02f23f84 llvm::LiveIntervals::HMEditor::updateAllRanges(llvm::MachineInstr*) llvm-trunk/llvm-project/llvm/lib/CodeGen/LiveIntervals.cpp:1034:41 #17 0x02f217a2 llvm::LiveIntervals::handleMove(llvm::MachineInstr&, bool) llvm-trunk/llvm-project/llvm/lib/CodeGen/LiveIntervals.cpp:1491:66#18 0x03080d1d llvm::ScheduleDAGMI::moveInstruction(llvm::MachineInstr*, llvm::MachineInstrBundleIterator) llvm-trunk/llvm-project/l lvm/lib/CodeGen/MachineScheduler.cpp:730:7#19 0x03084e91 llvm::ScheduleDAGMILive::scheduleMI(llvm::SUnit*, bool) llvm-trunk/llvm-project/llvm/lib/CodeGen/MachineScheduler.cpp:1434:21 #20 0x03083e07 llvm::ScheduleDAGMILive::schedule() llvm-trunk/llvm-project/llvm/lib/CodeGen/MachineScheduler.cpp:1232:9#21 0x0308051e (anonymous namespace)::MachineSchedulerBase::scheduleRegions(llvm::ScheduleDAGInstrs&, bool) llvm-trunk/llvm-project/llvm/lib/CodeGen/MachineSch eduler.cpp:582:28#22 0x0307f8c6 (anonymous namespace)::MachineScheduler::runOnMachineFunction(llvm::MachineFunction&) llvm-trunk/llvm-project/llvm/lib/CodeGen/MachineScheduler. cpp:394:3#23 0x02fd7348 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) llvm-trunk/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:73:33 #24 0x0349c109 llvm::FPPassManager::runOnFunction(llvm::Function&) llvm-trunk/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1516:20 #25 0x
[llvm-bugs] [Bug 46828] New: fatal error: error in backend: Cannot select: intrinsic %llvm.aarch64.fjcvtzs
https://bugs.llvm.org/show_bug.cgi?id=46828
Bug ID: 46828
Summary: fatal error: error in backend: Cannot select:
intrinsic %llvm.aarch64.fjcvtzs
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ahata...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
$ cat test.c
int main(int argc, char *argv[]) {
double x = argc;
return __builtin_arm_jcvt(x);
}
$ clang test.c -c -target aarch64-arm-none-eabi
--
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 46829] New: CFI_Parser::findFDE's end-of-section calculation looks broken
https://bugs.llvm.org/show_bug.cgi?id=46829
Bug ID: 46829
Summary: CFI_Parser::findFDE's end-of-section calculation looks
broken
Product: Runtime Libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: libunwind
Assignee: unassignedb...@nondot.org
Reporter: rprich...@google.com
CC: llvm-bugs@lists.llvm.org
CFI_Parser::findFDE scans an .eh_frame section looking for an FDE matching a
PC. The start of .eh_frame is passed as an argument, ehSectionStart, and the
function calculates the end of .eh_frame (ehSectionEnd):
/// Scan an eh_frame section to find an FDE for a pc
template
bool CFI_Parser::findFDE(A &addressSpace, pint_t pc, pint_t
ehSectionStart,
uint32_t sectionLength, pint_t fdeHint,
FDE_Info *fdeInfo, CIE_Info *cieInfo) {
//fprintf(stderr, "findFDE(0x%llX)\n", (long long)pc);
pint_t p = (fdeHint != 0) ? fdeHint : ehSectionStart;
const pint_t ehSectionEnd = p + sectionLength;
while (p < ehSectionEnd) {
There are two problems with the calculation:
* AFAICT, when a hint is provided, ehSectionEnd should still use
ehSectionStart instead of p.
* sectionLength comes from UnwindInfoSections::dwarf_section_length, which on
targets using dl_iterate_phdr, is the length of a PT_LOAD segment, not the
length of .eh_frame.
To expand on the second bullet point, UnwindInfoSections has (among others)
these five fields:
- dso_base
- dwarf_section
- dwarf_section_length
- dwarf_index_section
- dwarf_index_section_length
dwarf_index_section and dwarf_index_section_length are the start and size of
the .eh_frame_hdr section, which indexes into .eh_frame and allows binary
searching.
I'm not sure what dso_base is, generally, but for targets that use
dl_iterate_phdr, it seems to be the start of a PT_LOAD segment associated with
the unwind info.
dwarf_section is always the start of .eh_frame.
For most configurations, dwarf_section_length is the size of .eh_frame, and
UnwindCursor::getInfoFromDwarfSection assumes this is the case when it calls
CFI_Parser::findFDE. For targets using dl_iterate_phdr, however,
dwarf_section_length is instead the size of the PT_LOAD segment indicated by
dso_base.
The recently-added FrameHeaderCache uses (dso_base, dwarf_section_length) to
indicate each cache entry's range of PC values. That happens to match how we're
initializing those fields. (I think initializing dwarf_section_length to the
PT_LOAD size predated the new cache.)
I'm unsure of the practical consequences. I suppose if the unwinder tries to
look up a function with no FDE, then it will enter this .eh_frame linear scan
fallback, and it could read past the end of .eh_frame, unless there's an end
marker (cfiLength == 0, "return false; // end marker").
---
Aside: On targets that use .eh_frame_hdr, it seems like a waste of code to scan
.eh_frame (and a waste of memory in FrameHeaderCache to track .eh_frame
bounds). I think these targets have to locate .eh_frame using .eh_frame_hdr, so
it shouldn't ever find a match. Some Apple targets are different, because the
compact unwind table can defer to using the .eh_frame scan
(compactSaysUseDwarf).
Aside 2: If the .eh_frame scan does find a match, it would add the FDE to
DwarfFDECache, whose entries are not invalidated on module unload (except with
Apple OS's). On Android, the lack of automatic per-module invalidation should
be OK as long as DwarfFDECache is only used for manually-registered FDEs
(__register_frame / __unw_add_dynamic_fde).
Aside 3: The DwarfFDECache offset in getInfoFromDwarfSection is not quite a
"hint". It's used as an offset into .eh_frame, so if it's wrong, we'll try to
decode arbitrary data and may crash. If the hinted-scan ends without a match,
then we try again with a complete .eh_frame scan. If *that* scan turns up an
FDE, then we add it to the end of DwarfFDECache. Adding an entry doesn't remove
the earlier entry, though, so AFAICT, each unwind lookup would find the bad
hint and add another good hint to the end.
--
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 46830] New: Semantic error is not coming for duplicate type specification in type guard statement
https://bugs.llvm.org/show_bug.cgi?id=46830 Bug ID: 46830 Summary: Semantic error is not coming for duplicate type specification in type guard statement Product: flang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedb...@nondot.org Reporter: inderjeet_ka...@hcl.com CC: david.tr...@arm.com, jper...@nvidia.com, kirankuma...@gmail.com, llvm-bugs@lists.llvm.org, sscalp...@nvidia.com Issue: - If selector is unlimited polymorphic object and type guard statement has integer type specification which is already specified by previous type guard statement then semantic error is not coming. Fortran 2018 spec: - C1163 (R1152) For a given select-type-construct, the same type and kind type parameter values shall not be specified in more than one TYPE IS type-guard-stmt and shall not be specified in more than one CLASS IS type-guard-stmt. Kindly refer following 2 test cases. selecttype_intrinsic.f90 has issue and selecttype.f90 returns expected error. [root@localhost Base_compiler]# f18 selecttype_intrinsic.f90 /tmp/f18-56ab.f90:10:11: TYPE IS (INTEGER) 2 TYPE IS (INTEGER) 1 Error: TYPE IS at (1) overlaps with TYPE IS at (2) [root@localhost Base_compiler]# cat -n selecttype_intrinsic.f90 1 type ty 2 integer :: ii 3 end type 4 class(*),allocatable :: cptr_unlim 5 6 call sub1() 7 contains 8 subroutine sub1() 9 select type(cptr_unlim) 10 !ERROR: Type specification 'integer' conflicts with previous type specification 11 type is(integer) 12 type is(integer) 13 end select 14 end 15 end [root@localhost Base_compiler]# - Following case returns expected error: [root@localhost Base_compiler]# f18 selecttype.f90 selecttype.f90:12:2: error: Type specification 'ty' conflicts with previous type specification type is(ty) ^^^ selecttype.f90:11:2: Conflicting type specification 'ty' type is(ty) ^^^ f18: semantic errors in selecttype.f90 [root@localhost Base_compiler]# cat -n selecttype.f90 1 type ty 2 integer :: ii 3 end type 4 class(ty),allocatable :: cptr 5 6 call sub2() 7 contains 8 subroutine sub2() 9 select type(cptr) 10 !ERROR: Type specification 'ty' conflicts with previous type specification 11 type is(ty) 12 type is(ty) 13 end select 14 end 15 end -- 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
