[llvm-bugs] [Bug 31756] XRay crashes when rtdscp access is disabled
https://llvm.org/bugs/show_bug.cgi?id=31756 Dean Michael Berris changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Dean Michael Berris --- Now fixed in https://reviews.llvm.org/rL293870 -- we're explicitly not installing the XRay log handling routine that depends on rdtscp if we detect that rdtscp couldn't be used. We can track work on how we work-around that in another bug if we want to do that as well. It's an open question as to whether we want to back-port this into the 4.0 release. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31847] New: After r288115: Assertion failed: (isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant!"), function getAddRecExpr, file lib/Analysis/ScalarEvol
https://llvm.org/bugs/show_bug.cgi?id=31847
Bug ID: 31847
Summary: After r288115: Assertion failed:
(isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr
operand is not loop-invariant!"), function
getAddRecExpr, file lib/Analysis/ScalarEvolution.cpp,
line 2963.
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
>From https://bugs.freebsd.org/216718, building ffmpeg targeting Haswell or
higher results in an assertion:
Assertion failed: (isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand
is not loop-invariant!"), function getAddRecExpr, file
lib/Analysis/ScalarEvolution.cpp, line 2963.
This still happens with trunk r293557. Bisection shows that this started
appearing after r288115:
r288115 | abataev | 2016-11-29 09:21:14 +0100 (Tue, 29 Nov 2016) | 8 lines
[SLPVectorizer] Improved support of partial tree vectorization.
Currently SLP vectorizer tries to vectorize a binary operation and dies
immediately after unsuccessful the first unsuccessfull attempt. Patch
tries to improve the situation, trying to vectorize all binary
operations of all children nodes in the binop tree.
Differential Revision: https://reviews.llvm.org/D25517
Reduced test case:
/* clang -cc1 -triple i386 -S -target-cpu haswell -O2 -w -vectorize-loops
-vectorize-slp testcase.c */
typedef struct {
int ncomp;
int shift_w[]
} WaveformContext;
a, b, e, f, g;
*c;
WaveformContext d;
char *h;
fn1() {
int i;
unsigned char *j = 1, *k = 1;
for (;;) {
int l = (j[b >> d.shift_w[g + 1 % e]] - 128 >= 0
? j[b >> d.shift_w[g + 1 % e]] - 128
: -j[b >> d.shift_w[g + 1 % e]]) +
(k[b >> d.shift_w[g + 2 % e]] - 128 >= 0
? k[b >> d.shift_w[g + 2 % e]] - 128
: -k[b >> d.shift_w[g + 2 % e]]);
c = h - l;
*c = 0;
c = h + l;
if (c)
*c = 0;
else
*c = 1;
h += 1;
}
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31848] New: Segfault/Memory corruption in DependenceAnalysis
https://llvm.org/bugs/show_bug.cgi?id=31848 Bug ID: 31848 Summary: Segfault/Memory corruption in DependenceAnalysis Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: philip.pfa...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17927 --> https://llvm.org/bugs/attachment.cgi?id=17927&action=edit lit testcase triggering the bug It's possible for DependenceAnalysis to run into a heap buffer overflow. The attached testcase triggers the bug for current trunk, but I'm positive this has been defective in previous versions as well. The bug occurs within the banerjeeMIV-test, in the function collectCoeffInfo(). This function allocates a new array on the heap with MaxLevels+1 elements. MaxLevels is the maximum loop depth either of the two Instructions being tested are found in. This array is then filled by walking the AddRecExprs in the SCEV-Expr describing the access subscript. The problem with this is that the SCEV-Expr can contain AddRecExprs that do not correspond to loops surrounding the tested Instruction. And if those AddRecExprs belong to a loop that's deeper than MaxLevels, we're accessing the array outside of its bounds. In summary, I don't think that this is really a problem with the banerjeeMIV-test, and I strongly suspect there are other inputs for which AddRecExprs are being treated as index variables even if they actually are not. The fix for the memory corruption could be straightforward, by (correctly) classifying the subscript pair as NonLinear. However I am not sure whether this is overly pessimistic or even sound in general. - Philip -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31849] New: Improper alignment in pointer cast in unordered_map of std::aligned_storage
https://llvm.org/bugs/show_bug.cgi?id=31849
Bug ID: 31849
Summary: Improper alignment in pointer cast in unordered_map of
std::aligned_storage
Product: libc++
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: da...@doublewise.net
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
This might be related to https://llvm.org/bugs/show_bug.cgi?id=22634
#include
struct S {
void emplace() {
m_map.emplace(
std::piecewise_construct,
std::forward_as_tuple(0),
std::forward_as_tuple()
);
}
private:
std::int64_t x;
// std::int64_t y;
using mapped_type = typename std::aligned_storage<3*sizeof(void*)>::type;
std::unordered_map m_map;
};
int main() {
S s;
s.emplace();
}
clang++ -stdlib=libc++ -fsanitize=address -fsanitize=undefined -std=c++1z
main.cpp && ./a.out
include/c++/v1/__hash_table:2152:29: runtime error: downcast of misaligned
address 0x7ff2d6c62f8 for type
'std::__1::__hash_node::type, void *>', which requires 16 byte
alignment
However, unlike with bug 22634 this can result from no particular use of
alignment specifiers in user code. This exact sanitizer error can also be
triggered by using std::function as the mapped_type, as
it contains std::aligned_storage in it.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 18344] llc doesn't optimize load from XMM well enough.
https://llvm.org/bugs/show_bug.cgi?id=18344 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Simon Pilgrim --- Added a test case for this at rL293907 but it seems to have been fixed since clang 3.6 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31188] opt crashes with "opt -globals-aa -lcssa -inline": UNREACHABLE executed at /tmp/llvm-builder/llvm-source-trunk/lib/IR/Value.cpp:822!
https://llvm.org/bugs/show_bug.cgi?id=31188 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Blocks|31622 | Resolution|--- |FIXED --- Comment #3 from Hans Wennborg --- The Clang repro stopped working after r292928, but works with -O1 -Xclang -disable-llvm-optzns. The assert from the .bc repro went away in r292928. Since it was asserting on 3.9 and the change doesn't look trivial, I don't think this is a candidate for merging. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31850] New: Revisit how we handle conflicts with section symbols
https://llvm.org/bugs/show_bug.cgi?id=31850
Bug ID: 31850
Summary: Revisit how we handle conflicts with section symbols
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: MC
Assignee: unassignedb...@nondot.org
Reporter: rafael.espind...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The gnu assembler rejects
.section foo,"a",@progbits
foo:
.data
.quad foo
and accepts
foo:
.section foo,"a",@progbits
.data
.quad foo
producing a relocation with the section foo.
clang accepts both and produces relocations with the symbol.
The gas behaviour really doesn't seem intentional. There is no good reason to
prefer a section name over another symbol or vice versa.
The current clang behaviour was implemented in bug 26941, but I think the
diagnostic there is incorrect. The only reason gcc accepts
int xxx;
__attribute__((section("xxx"))) int f() { return xxx; }
is that gcc print ".comm xxx" before ".section xxx". The gnu assembler rejects
the current clang produced .s.
What bug 26941 is really about is a IR linker bug. From comment 5 we see that
the section is from one file and the symbol from another. Just like with any
other local symbol, the IR linker should detect that it conflicts with a symbol
(the section symbol) in another module and rename it.
And I think MC should just reject both cases listed in this bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31851] New: Forming and verifying LCSSA can take forever due to updater speed
https://llvm.org/bugs/show_bug.cgi?id=31851 Bug ID: 31851 Summary: Forming and verifying LCSSA can take forever due to updater speed Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: dber...@dberlin.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Attached is a testcase where forming and verifying LCSSA accounts for 80+% of the time, and several minutes. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31622] [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug 31622 depends on bug 31626, which changed state. Bug 31626 Summary: [DAGCombine] enableAggressiveFMAFusion incorrectly uses associativity of addition https://llvm.org/bugs/show_bug.cgi?id=31626 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31626] [DAGCombine] enableAggressiveFMAFusion incorrectly uses associativity of addition
https://llvm.org/bugs/show_bug.cgi?id=31626 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Hans Wennborg --- Merged in r293940. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31845] Apply r 292167 / 292169 / 292170 to 4.0 release branch
https://llvm.org/bugs/show_bug.cgi?id=31845 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED CC||h...@chromium.org Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- This doesn't seem like it's fixing a regression, but it looks pretty harmless so OK. Merged in r293942. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31622] [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug 31622 depends on bug 31845, which changed state. Bug 31845 Summary: Apply r 292167 / 292169 / 292170 to 4.0 release branch https://llvm.org/bugs/show_bug.cgi?id=31845 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30879, which changed state. Bug 30879 Summary: libunwind on i386: cannot deal with absence of frame pointers, even though libgcc can https://llvm.org/bugs/show_bug.cgi?id=30879 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31622] [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug 31622 depends on bug 30879, which changed state. Bug 30879 Summary: libunwind on i386: cannot deal with absence of frame pointers, even though libgcc can https://llvm.org/bugs/show_bug.cgi?id=30879 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30879] libunwind on i386: cannot deal with absence of frame pointers, even though libgcc can
https://llvm.org/bugs/show_bug.cgi?id=30879 Ed Schouten changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #35 from Ed Schouten --- Nice! I just installed libunwind 3.9.1 with r292723 applied and I can confirm this makes libunwind work for Sjors Gielen and me. As it's already going to be part of 4.0, marking this as fixed. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28180] [LTO] Global is external, but doesn't have external or weak linkage! failure while building mozjs
https://llvm.org/bugs/show_bug.cgi?id=28180 dmitry.miku...@sony.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #12 from dmitry.miku...@sony.com --- Appears to be fixed. See comment #10. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
