[llvm-bugs] Issue 6490 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_predication: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_predication
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-21 Type: Bug New issue 6490 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_predication: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_predication https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6490 Detailed report: https://oss-fuzz.com/testcase?key=6577825835384832 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_predication Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_predication Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-loop_predication Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802190622:201802200626 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6577825835384832 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36464] New: LTO with ASan is causing ODR violation
https://bugs.llvm.org/show_bug.cgi?id=36464
Bug ID: 36464
Summary: LTO with ASan is causing ODR violation
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: lto
Assignee: unassignedb...@nondot.org
Reporter: pho...@chromium.org
CC: llvm-bugs@lists.llvm.org
When compiling YASM re2c with LTO and ASan, we're seeing an ODR violation:
=
==8618==ERROR: AddressSanitizer: odr-violation (0x00218dc0):
[1] size=16 '' ../../third_party/yasm/tools/re2c/main.c:150:8
[2] size=16 '' ../../third_party/yasm/tools/re2c/code.c:68:12
These globals were registered at these points:
[1]:
#0 0x2614ae in __asan_register_globals
/b/s/w/ir/kitchen-workdir/llvm-project/compiler-rt/lib/asan/asan_globals.cc:358:3
#1 0x334289 in asan.module_ctor.84
(/b/s/w/ir/kitchen-workdir/out/release-x86-64/host_x64-asan_no_detect_leaks/re2c+0x334289)
[2]:
#0 0x2614ae in __asan_register_globals
/b/s/w/ir/kitchen-workdir/llvm-project/compiler-rt/lib/asan/asan_globals.cc:358:3
#1 0x329869 in asan.module_ctor.2
(/b/s/w/ir/kitchen-workdir/out/release-x86-64/host_x64-asan_no_detect_leaks/re2c+0x329869)
==8618==HINT: if you don't care about these errors you may set
ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global '' at
../../third_party/yasm/tools/re2c/main.c:150:8
==8618==ABORTING
According to the error message, this is caused by:
https://github.com/yasm/yasm/blob/master/tools/re2c/main.c#L150
https://github.com/yasm/yasm/blob/master/tools/re2c/code.c#L68
However, both of these lines only do `fputs("Out of memory.\n", stderr);` so
this appears to be a compiler error, not a legit ODR violation.
--
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 36463] New: Wrong constant folding
https://bugs.llvm.org/show_bug.cgi?id=36463
Bug ID: 36463
Summary: Wrong constant folding
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ishiura-compi...@ml.kwansei.ac.jp
CC: llvm-bugs@lists.llvm.org
LLVM + clang 7.0 for x86_64 miscompiles the following code.
% cat test.c
short a = 0;
int main (void)
{
volatile int b = 0;
volatile int c = 0x102;
int d = (unsigned char)((a^0x101)^(0x101%c))+b;
if (d != 0) __builtin_abort();
return 0;
}
% clang-7.0 -O1 test.c
% ./a.out
zsh: abort (core dumped) ./a.out
% clang-7.0 -v
clang version 7.0.0 (trunk 323624)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/hiroki-maeda/opt/clang-7.0/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
--
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 36280] [SLPVectorizer] 2-way parallel vectorization hurts perf on x86
https://bugs.llvm.org/show_bug.cgi?id=36280 Sanjay Patel changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #11 from Sanjay Patel --- Had to revert, so reopening: https://reviews.llvm.org/rL325658 -- 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 36332] R9285 Unreal tournament game hang since [AMDGPU] Suppress redundant waitcnt instrs.
https://bugs.llvm.org/show_bug.cgi?id=36332 Andy Furniss changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andy Furniss --- That fixes my test case, thanks. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36462] New: Merge r325654 and r325655 into 6.0 branch: [X86] Disable CLWB on Cannon Lake
https://bugs.llvm.org/show_bug.cgi?id=36462 Bug ID: 36462 Summary: Merge r325654 and r325655 into 6.0 branch: [X86] Disable CLWB on Cannon Lake Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: llvm-bugs@lists.llvm.org As the last release before Cannon Lake CPUs start appearing the wild (at least I'm guessing that will be the case), I'd like to make sure we have an accurate set of features enabled for -march=cannonlake -- 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 36461] New: llvm-mc on SPARC cannot parse TLS sequences
https://bugs.llvm.org/show_bug.cgi?id=36461 Bug ID: 36461 Summary: llvm-mc on SPARC cannot parse TLS sequences Product: tools Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: llvmc Assignee: unassignedb...@nondot.org Reporter: jrt...@jrtc27.com CC: llvm-bugs@lists.llvm.org Created attachment 19918 --> https://bugs.llvm.org/attachment.cgi?id=19918&action=edit Example Whilst LLVM supports TLS on SPARC when using the integrated as or the system as, llvm-mc itself cannot parse the related code sequences, as it does not allow call, ld[x] and add instructions to have an extra parameter with relocation information as required; a test case is attached. -- 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 33038] [PBQP] Assertion `!empty() && "empty range"'
https://bugs.llvm.org/show_bug.cgi?id=33038 Lang Hames changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Lang Hames --- Huh. It looks like while spilling one VReg (call it V1) the spiller can cause the live range for another VReg to become empty. I'm guessing this is an in-spiller coalescing optimization or something like that. I've modified initializeGraph to prune such empty intervals in r325632. That should fix this. -- 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 35420] DOOM GPU hang after "AMDGPU: Select s_buffer_load_dword with a non-constant SGPR offset"
https://bugs.llvm.org/show_bug.cgi?id=35420 nota...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from nota...@gmail.com --- Fixed by r324353, merged to 6.0 branch as r325497. -- 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 35135] [Unittests] Failures uncovered by randomly shuffling containers before sorting
https://bugs.llvm.org/show_bug.cgi?id=35135 Eli Friedman changed: What|Removed |Added Status|RESOLVED|REOPENED 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 36460] trailing comma in inializer list confuses formatter
https://bugs.llvm.org/show_bug.cgi?id=36460 Daniel Jasper changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from Daniel Jasper --- Yes. That's the intended behavior. Over time, enough people have requested to use the trailing comma to control this behavior. People commonly use it to have easily extensible and copy-and-pastable lists. -- 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 36460] New: trailing comma in inializer list confuses formatter
https://bugs.llvm.org/show_bug.cgi?id=36460
Bug ID: 36460
Summary: trailing comma in inializer list confuses formatter
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: andy.somervi...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Created attachment 19917
--> https://bugs.llvm.org/attachment.cgi?id=19917&action=edit
minimal example of trailing comma issue
including trailing comma in initializer list causes formatter to switch
indentation style and splits short parameters one per line.
// BEGIN minimal example input //
#include
void someFunction( std::set & someSet )
{
// initializer lists inside a constructor
std::set> firstSet{
{ 1, 2, 3, 5,}, // final comma internal initializer
{ 6, 7, 8,9}
};
std::set> otherSet = {
{ 1, 2, 3, 5}, // no final comma internal initializer
{ 6, 7, 8,9}
};
auto middleSet = std::set>{
{ 1, 2, 3, 5, }, // final comma external initializer
{ 6, 7, 8,9},
};
auto finalSet = std::set>({
{ 1, 2, 3, 5 }, // final comma external initializer
{ 6, 7, 8,9},
});
}
// END minimal example input //
$ clang-format-5.0 -style=llvm ./minimal_initializer_test.cpp
// BEGIN minimal example output //
#include
void someFunction(std::set &someSet) {
// initializer lists inside a constructor
std::set> firstSet{{
1,
2,
3,
5,
}, // final comma internal initializer
{6, 7, 8, 9}};
std::set> otherSet = {
{1, 2, 3, 5}, // no final comma internal initializer
{6, 7, 8, 9}};
auto middleSet = std::set>{
{
1,
2,
3,
5,
}, // final comma external initializer
{6, 7, 8, 9},
};
auto finalSet = std::set>({
{1, 2, 3, 5}, // final comma external initializer
{6, 7, 8, 9},
});
}
// END minimal example output //
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6486 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_vectorize
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-20 Type: Bug New issue 6486 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_vectorize https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6486 Detailed report: https://oss-fuzz.com/testcase?key=5459483057717248 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_vectorize Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-loop_vectorize Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802190622:201802200626 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5459483057717248 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36459] New: MIR: Stack object without alignment causes div by 0 in estimateStackSize
https://bugs.llvm.org/show_bug.cgi?id=36459 Bug ID: 36459 Summary: MIR: Stack object without alignment causes div by 0 in estimateStackSize Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: franci...@yahoo.com CC: llvm-bugs@lists.llvm.org Created attachment 19916 --> https://bugs.llvm.org/attachment.cgi?id=19916&action=edit mir-crash The parser accepts it as the alignment is not mandatory. We should come up with some default alignment or something similar. AArch64FrameLowering::determineCalleeSaves MachineFrameInfo::estimateStackSize -> 153 Offset = (Offset+Align-1)/Align*Align; -- 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 36454] IRBuilder:: CreateMaxNum calls min when it should call max
https://bugs.llvm.org/show_bug.cgi?id=36454 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||325607 Status|NEW |RESOLVED --- Comment #2 from Sanjay Patel --- https://reviews.llvm.org/rL325607 -- 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 36079] Miscompilation in code which LLVM partially vectorizes
https://bugs.llvm.org/show_bug.cgi?id=36079 Mikhail Maltsev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Mikhail Maltsev --- Fixed in https://reviews.llvm.org/D43282 -- 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 36219] [ThinLTO] link asserts 'BA && "Refcount and block address map disagree!"'
https://bugs.llvm.org/show_bug.cgi?id=36219 Dmitry Mikulin changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Dmitry Mikulin --- Fixed with https://reviews.llvm.org/rL324658 -- 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 36442] -fsplit-dwarf-inlining help message is wrong
https://bugs.llvm.org/show_bug.cgi?id=36442 David Blaikie changed: What|Removed |Added Resolution|--- |FIXED CC||dblai...@gmail.com Status|NEW |RESOLVED --- Comment #1 from David Blaikie --- Thanks - fixed in r325594: "Provide gmlt-like debug info in the object/executable to facilitate online symbolication/stack traces in the absence of .dwo/.dwp files when using Split DWARF" -- 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 36345] [AArch64][GlobalISel] struct passing with fp16 members
https://bugs.llvm.org/show_bug.cgi?id=36345 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #17 from Hans Wennborg --- I started by merging r324110 in r325584 to unblock the others. Merged r325463 in r325586. r325550 was tricky; I merged it in r325591 but couldn't get the fp16-copy-gpr.mir test to work after merging so I deleted. Perhaps you could take a look at fixing 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 36345, which changed state. Bug 36345 Summary: [AArch64][GlobalISel] struct passing with fp16 members https://bugs.llvm.org/show_bug.cgi?id=36345 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36458] New: Assertion failure in clang::ento::ElementRegion::ElementRegion
https://bugs.llvm.org/show_bug.cgi?id=36458
Bug ID: 36458
Summary: Assertion failure in
clang::ento::ElementRegion::ElementRegion
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: ale...@google.com
CC: ekarpen...@apple.com, llvm-bugs@lists.llvm.org
$ cat test-ElementRegion__ElementRegion.c
typedef struct {
void *a
} b;
c(*e) {
b *d = g();
*e = d->a;
int *f;
c(&f);
*f = 1;
}
$ clang-tidy -checks=-*,clang-analyzer* test-ElementRegion__ElementRegion.c --
assert.h assertion failed at
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1083
in clang::ento::ElementRegion::ElementRegion(clang::QualType,
clang::ento::NonLoc, const clang::ento::SubRegion *): !elementType.isNull() &&
!elementType->isVoidType() && "Invalid region type!"
@ 0x5600957f9b76 __assert_fail
@ 0x5600942c0f60 clang::ento::ElementRegion::ElementRegion()
@ 0x5600942c0de5 clang::ento::MemRegionManager::getElementRegion()
@ 0x56009426f19e (anonymous namespace)::RegionStoreManager::bind()
@ 0x560094264e58 (anonymous namespace)::RegionStoreManager::Bind()
@ 0x5600942a1f45 clang::ento::ProgramState::bindLoc()
@ 0x5600942f47a0 clang::ento::ExprEngine::evalBind()
@ 0x5600942fc855 clang::ento::ExprEngine::evalStore()
@ 0x56009431725f clang::ento::ExprEngine::VisitBinaryOperator()
@ 0x5600942f41ae clang::ento::ExprEngine::Visit()
@ 0x5600942ef89e clang::ento::ExprEngine::ProcessStmt()
@ 0x5600942ef59b clang::ento::ExprEngine::processCFGElement()
@ 0x560094311095 clang::ento::CoreEngine::HandlePostStmt()
@ 0x56009431034d clang::ento::CoreEngine::ExecuteWorkList()
@ 0x5600933389a2 (anonymous
namespace)::AnalysisConsumer::ActionExprEngine()
@ 0x560093338526 (anonymous namespace)::AnalysisConsumer::HandleCode()
@ 0x5600933228d4 (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit()
--
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 36457] New: Wrong Output for AllowShortFunctionsOnASingleLine when ColumnLimit changes
https://bugs.llvm.org/show_bug.cgi?id=36457
Bug ID: 36457
Summary: Wrong Output for AllowShortFunctionsOnASingleLine when
ColumnLimit changes
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: gnue...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Formatting the file with the config below:
class A{
#ifndef ASD
A& GetMask() { return a; }
const A& GetMask() const { return a; }
#endif
};
results in weird behavior when:
ColumnLimit: 0
is changed to
ColumnLimit: 500
which should not make any difference.
ColumnLimit: 0
---
class A
{
#ifndef ASD
A& GetMask()
{
return a;
}
const A& GetMask() const { return a; }
#endif
};
--
ColumnLimit: 500
-
class A
{
#ifndef ASD
A& GetMask() { return a; }
const A& GetMask() const { return a; }
#endif
};
--
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 36284] False positive unneeded internal declaration for constant expression literal used in template
https://bugs.llvm.org/show_bug.cgi?id=36284 Pavel Kryukov changed: What|Removed |Added Hardware|Other |All Assignee|unassignedclangbugs@nondot. |dcough...@apple.com |org | CC||llvm-bugs@lists.llvm.org OS|other |All Component|C++'1z |Static Analyzer -- 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 35135] [Unittests] Failures uncovered by randomly shuffling containers before sorting
https://bugs.llvm.org/show_bug.cgi?id=35135 hiraditya changed: What|Removed |Added CC||hiradi...@msn.com Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 36456] New: #pragma comment(lib) with relative path does not work in LLD
https://bugs.llvm.org/show_bug.cgi?id=36456 Bug ID: 36456 Summary: #pragma comment(lib) with relative path does not work in LLD Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: alexandre.ga...@ubisoft.com CC: llvm-bugs@lists.llvm.org We've got a case where a #pragma comment(lib...) directive is used in a compilation unit, however with a relative path. Such as: #define LIB_PATH "..\\..\\..\\..\\..\\extern\\OpenExr220\\lib\\" #pragma comment(lib, LIB_PATH "IlmImf-2_2.lib") This works happily with link.exe, however lld doesn't like it and reports the library as "not found". The path is relative to the compilation unit. I'm not sure if link.exe uses that, or the fact that /LIBPATH: already specifies a path to the correct lib. -- 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 36455] New: lld crashes in GlobalTypeTableBuilder::getType
https://bugs.llvm.org/show_bug.cgi?id=36455
Bug ID: 36455
Summary: lld crashes in GlobalTypeTableBuilder::getType
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: tras...@gmail.com
CC: llvm-bugs@lists.llvm.org
Tried building llvm with clang-cl and lld-link (and -mllvm
-emit-codeview-ghash-section / -DEBUG:GHASH).
$ "C:\Program Files\LLVM\msbuild-bin\link.exe" /nologo
tools\llvm-symbolizer\CMakeFiles\llvm-symbolizer.dir\llvm-symbolizer.cpp.obj
tools\llvm-symbolizer\CMakeFiles\llvm-symbolizer.dir\__\__\resources\windows_version_resource.rc.res
/out:bin\llvm-symbolizer.exe /implib:lib\llvm-symbolizer.lib
/pdb:bin\llvm-symbolizer.pdb /version:0.0 /machine:x64 /DEBUG:GHASH /OPT:REF
/OPT:ICF /STACK:1000 /INCREMENTAL:NO /subsystem:console
lib\LLVMDebugInfoDWARF.lib lib\LLVMDebugInfoPDB.lib lib\LLVMObject.lib
lib\LLVMSupport.lib lib\LLVMSymbolize.lib lib\LLVMDebugInfoDWARF.lib
lib\LLVMDebugInfoPDB.lib lib\LLVMDebugInfoCodeView.lib lib\LLVMDebugInfoMSF.lib
"C:\PROGRA~2\MICROS~2\2017\Professional\DIA SDK\lib\amd64\diaguids.lib"
lib\LLVMObject.lib lib\LLVMBitReader.lib lib\LLVMCore.lib
lib\LLVMBinaryFormat.lib lib\LLVMMCParser.lib lib\LLVMMC.lib
lib\LLVMSupport.lib psapi.lib shell32.lib ole32.lib uuid.lib
lib\LLVMDemangle.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib
ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST
/MANIFESTFILE:bin\llvm-symbolizer.exe.manifest
0xC005: Access violation reading location 0x020239B71DC:
llvm::codeview::GlobalTypeTableBuilder::getType(llvm::codeview::TypeIndex
Index={...}) Line 62
=> Type.Type = static_cast(uint16_t(P->RecordKind));
[Inline Frame]
llvm::codeview::TypeCollection::ForEachRecord(addTypeInfo::__l2::void
(llvm::codeview::TypeIndex, const llvm::codeview::CVRecord &) Func=void (llvm::codeview::TypeIndex
TI, const llvm::codeview::CVRecord &
Type){...}) Line 40
addTypeInfo(llvm::pdb::TpiStreamBuilder & TpiBuilder,
llvm::codeview::TypeCollection & TypeTable={...}) Line 227
PDBLinker::addObjectsToPDB() Line 929
lld::coff::createPDB(lld::coff::SymbolTable * Symtab=0x020224e962a0,
llvm::ArrayRef OutputSections={...},
llvm::ArrayRef SectionTable={...}, const
llvm::codeview::DebugInfo & BuildId) Line 1032
Writer::run() Line 340
lld::coff::writeResult() Line 179
lld::coff::LinkerDriver::link(llvm::ArrayRef ArgsArr) Line 1449
lld::coff::link(llvm::ArrayRef Args={...}, bool
CanExitEarly=true, llvm::raw_ostream & Diag) Line 74
main(int Argc, const char * * Argv=0x020224e61af0) Line 120
--
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 36454] New: IRBuilder:: CreateMaxNum calls min when it should call max
https://bugs.llvm.org/show_bug.cgi?id=36454
Bug ID: 36454
Summary: IRBuilder:: CreateMaxNum calls min when it should call
max
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Core LLVM classes
Assignee: unassignedb...@nondot.org
Reporter: ces...@loftsoft.co.uk
CC: llvm-bugs@lists.llvm.org
There looks to be a problem in llvm/IR/IRBuilder.h with the implementation of
CreateMaxNum, trunk currently looks like:
/// Create call to the maxnum intrinsic.
CallInst *CreateMaxNum(Value *LHS, Value *RHS, const Twine &Name = "") {
return CreateBinaryIntrinsic(Intrinsic::minnum, LHS, RHS, Name);
}
I'm guessing this is a copy/paste error from CreateMinNum and it should be
calling Intrinsic::maxnum?
--
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 36391] VectorLegalizer::ExpandUINT_TO_FLOAT -- wrong results for v*f64
https://bugs.llvm.org/show_bug.cgi?id=36391 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||325578 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Simon Pilgrim --- Fixed at rL325578 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6482 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-20 Type: Bug New issue 6482 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6482 Detailed report: https://oss-fuzz.com/testcase?key=5730957068861440 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_vectorize Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E llvm::InterleaveGroup::insertMember llvm::LoopVectorizationLegality::canVectorize Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802190622:201802200626 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5730957068861440 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36370] We should produce a R_X86_64_PLT32 for "call foo"
https://bugs.llvm.org/show_bug.cgi?id=36370 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from George Rimar --- r325569 -- 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 36125] Clang-cl /std:c++14 does not inline constexpr constants
https://bugs.llvm.org/show_bug.cgi?id=36125 Hans Wennborg changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Hans Wennborg --- (In reply to Hans Wennborg from comment #5) > (In reply to JVApen from comment #4) > > Will this be available in 6.0.0-rc3? > > Seems low risk, so I've merged it in r325500. This was reverted in r325576 on trunk and r325577 on the 6.0 branch due to PR36453. -- 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 36453] New: Win clang bootstrap crashes with "Call parameter type does not match function signature!"
https://bugs.llvm.org/show_bug.cgi?id=36453 Bug ID: 36453 Summary: Win clang bootstrap crashes with "Call parameter type does not match function signature!" 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: llvm-bugs@lists.llvm.org See e.g. this bot: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/8818 -- 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 36452] New: Building of blender_r using release_60 aborts if -fno-slp-vectorize is not specified
https://bugs.llvm.org/show_bug.cgi?id=36452 Bug ID: 36452 Summary: Building of blender_r using release_60 aborts if -fno-slp-vectorize is not specified Product: libraries Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: balarishi.bhog...@amd.com CC: llvm-bugs@lists.llvm.org Created attachment 19912 --> https://bugs.llvm.org/attachment.cgi?id=19912&action=edit The config file for building blender_r benchmark with release_60 compiler. When used the latest release_60 branch to build 526.blender_r benchmark of CPU2017, it allocated >50 GB and then aborted with message "clang-6.0: error: unable to execute command: Killed". This issue occurs for flagset: -m64 -O3 -flto But, NOT occurs for flagset : -m64 -O3 -flto -fno-slp-vectorize However, this issue is not seen with the latest trunk. -- Attaching the config file for building the benchmark. Command used to build: runcpu --rebuild --noreportable -I --NoRatios --config cpu2017_llvm60-release.cfg --action=build --tune base 526.blender_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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36451] New: Аmbiguous type of 'this'
https://bugs.llvm.org/show_bug.cgi?id=36451
Bug ID: 36451
Summary: Аmbiguous type of 'this'
Product: lldb
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: danti...@nvidia.com
CC: llvm-bugs@lists.llvm.org
Test program...
class T0
{
protected:
int x, y;
public:
T0 (int a, int b) { x = a, y = b; }
virtual int func (void) { return x + y; }
int oops (void) { return x - y; }
};
class T1: public T0
{
public:
T1 (int a, int b) : T0 (a, b) {}
virtual int func (void) { return x + y + 1; }
};
class T2: public T1
{
int z;
public:
T2 (int a, int b) : T1 (a, b) { z = 111; }
virtual int func (void) { return x + y + z + 2; }
};
int
main (int argc, char *argv[])
{
T2 t (1, 2);
return t.func () + t.oops ();
}
... in LLDB:
$ /home/dantipov/.local/llvm-6.0.0/bin/lldb t-class
(lldb) target create "t-class"
Current executable set to 't-class' (x86_64).
(lldb) b T0::oops
Breakpoint 1: where = t-class`T0::oops() at t-class.cc:8, address =
0x0040069c
(lldb) run
Process 8743 launched: '/home/dantipov/tmp/t-class' (x86_64)
Process 8743 stopped
* thread #1, name = 't-class', stop reason = breakpoint 1.1
frame #0: 0x0040069c t-class`T0::oops(this=0x7fffe1b0) at
t-class.cc:8
5public:
6 T0 (int a, int b) { x = a, y = b; }
7 virtual int func (void) { return x + y; }
-> 8 int oops (void) { return x - y; }
9};
10
11 class T1: public T0
(lldb) p *this
(T0) $0 = (x = 1, y = 2) ;; '*this' is an instance of T0
(lldb) p this
(T2 *) $1 = 0x7fffe1b0;; 'this' is a pointer to an
instance of T2, but...
(lldb) p this->x
(int) $4 = 1
(lldb) p this->y
(int) $5 = 2
(lldb) p this->z
error: no member named 'z' in 'T0';; ...if so, where is this->z?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6477 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: VPlans.size() == 1 && "Best VF has not a single VPlan."
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-02-20 Type: Bug New issue 6477 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: VPlans.size() == 1 && "Best VF has not a single VPlan." https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6477 Detailed report: https://oss-fuzz.com/testcase?key=5765686711287808 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_vectorize Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: VPlans.size() == 1 && "Best VF has not a single VPlan." llvm::LoopVectorizationPlanner::setBestPlan llvm::LoopVectorizePass::processLoop Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802190622:201802200626 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5765686711287808 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36446] Hidden /d1PP flag is ignored by clang-cl
https://bugs.llvm.org/show_bug.cgi?id=36446 Hans Wennborg changed: 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 36383] .inl files ignored by Visual Studio extension
https://bugs.llvm.org/show_bug.cgi?id=36383 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Well spotted! Fixed in r325566. I'll try to get a new version of the plugin out with that later today. -- 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 36058] CLAMR compilation failure
https://bugs.llvm.org/show_bug.cgi?id=36058 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Hans Wennborg --- Merged in r325565. -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 36058, which changed state. Bug 36058 Summary: CLAMR compilation failure https://bugs.llvm.org/show_bug.cgi?id=36058 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 36345, which changed state. Bug 36345 Summary: [AArch64][GlobalISel] struct passing with fp16 members https://bugs.llvm.org/show_bug.cgi?id=36345 What|Removed |Added Status|RESOLVED|REOPENED 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 36345] [AArch64][GlobalISel] struct passing with fp16 members
https://bugs.llvm.org/show_bug.cgi?id=36345 Hans Wennborg changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #16 from Hans Wennborg --- (In reply to Amara Emerson from comment #15) > Second patch committed in r325550. > > Hans, can we merge r325463 and r325550 to 6.0 please. As for GISel itself, > m2c is that I think we should leave it enabled especially at this late > stage. We've had it enabled by default coming up to two months now, and ARM > and others have been very helpful in finding the most critical issues so I > think we're in a reasonably good state. I don't know of any other serious > problems at this point in time. Makes sense, thanks. I'll let the new patch bake a few more hours in trunk and merge it later today. (Keeping the bug open until then to not lose track of 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 36450] New: SIGSEGV on 'thread until' for an exited thread
https://bugs.llvm.org/show_bug.cgi?id=36450
Bug ID: 36450
Summary: SIGSEGV on 'thread until' for an exited thread
Product: lldb
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: danti...@nvidia.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19911
--> https://bugs.llvm.org/attachment.cgi?id=19911&action=edit
Sample program
If all thread's stack frames are forced to return from with
'thread return', next 'thread until' causes LLDB to crash:
$ /home/dantipov/.local/llvm-6.0.0/bin/lldb t-thread3
(lldb) target create "t-thread3"
Current executable set to 't-thread3' (x86_64).
(lldb) b t-thread3.cc:6
Breakpoint 1: where = t-thread3`f() + 4 at t-thread3.cc:7, address =
0x00400a3b
(lldb) run
Process 29546 launched: '/home/dantipov/tmp/t-thread3' (x86_64)
Process 29546 stopped
* thread #2, name = 't-thread3', stop reason = breakpoint 1.1
frame #0: 0x00400a3b t-thread3`f() at t-thread3.cc:7
4f (void)
5{
6 (void) f;
-> 7}
8
9int
10 main (int argc, char *argv[])
(lldb) thread return
* thread #2, name = 't-thread3', stop reason = breakpoint 1.1
frame #0: 0x00400d2a t-thread3`void std::__invoke_impl((null)=__invoke_other @ 0x76edee10, __f=0x00416e78)())
at invoke.h:60
57 template
58 constexpr _Res
59 __invoke_impl(__invoke_other, _Fn&& __f, _Args&&... __args)
-> 60 { return std::forward<_Fn>(__f)(std::forward<_Args>(__args)...); }
61
62 template
63 constexpr _Res
(lldb) thread return
* thread #2, name = 't-thread3', stop reason = breakpoint 1.1
frame #0: 0x00400b68 t-thread3`std::__invoke_result::type std::__invoke(void (*&&)()) at
invoke.h:95
92 using __result = __invoke_result<_Callable, _Args...>;
93 using __type = typename __result::type;
94 using __tag = typename __result::__invoke_type;
-> 95 return std::__invoke_impl<__type>(__tag{},
std::forward<_Callable>(__fn),
96
std::forward<_Args>(__args)...);
97 }
98
(lldb) thread return
* thread #2, name = 't-thread3', stop reason = breakpoint 1.1
frame #0: 0x004011d6 t-thread3`decltype(this=0x00416e78,
(null)=_Index_tuple<0> @ 0x76edee80)))
std::thread::_Invoker
>::_M_invoke<0ul>(std::_Index_tuple<0ul>) at thread:234
231_M_invoke(_Index_tuple<_Ind...>)
232noexcept(noexcept(std::__invoke(_S_declval<_Ind>()...)))
233-> decltype(std::__invoke(_S_declval<_Ind>()...))
-> 234{ return std::__invoke(std::get<_Ind>(std::move(_M_t))...); }
235
236 using _Indices
237= typename
_Build_index_tuple::value>::__type;
(lldb) thread return
* thread #2, name = 't-thread3', stop reason = breakpoint 1.1
frame #0: 0x004011a7
t-thread3`std::thread::_Invoker
>::operator(this=0x00416e78)() at thread:243
240 operator()()
241
noexcept(noexcept(std::declval<_Invoker&>()._M_invoke(_Indices(
242 -> decltype(std::declval<_Invoker&>()._M_invoke(_Indices()))
-> 243 { return _M_invoke(_Indices()); }
244};
245
246 // Alias for _Invoker>
(lldb) thread return
* thread #2, name = 't-thread3', stop reason = breakpoint 1.1
frame #0: 0x00401186
t-thread3`std::thread::_State_impl
> >::_M_run(this=0x00416e70) at thread:186
183 { }
184
185 void
-> 186 _M_run() { _M_func(); }
187};
188
189 void
(lldb) thread return
* thread #2, name = 't-thread3', stop reason = breakpoint 1.1
frame #0: 0x77b0a14f libstdc++.so.6`execute_native_thread_routine +
15
libstdc++.so.6`execute_native_thread_routine:
-> 0x77b0a14f <+15>: movq (%rbx), %rax
0x77b0a152 <+18>: movq %rbx, %rdi
0x77b0a155 <+21>: callq *0x8(%rax)
0x77b0a158 <+24>: addq $0x8, %rsp
(lldb) thread return
* thread #2, name = 't-thread3', stop reason = breakpoint 1.1
frame #0: 0x772ca61b
libpthread.so.0`start_thread(arg=0x76edf700) at pthread_create.c:465
462LIBC_PROBE (pthread_start, 3, (pthread_t) pd, pd->start_routine,
pd->arg);
463
464/* Run the code the user provided. */
-> 465THREAD_SETMEM (pd, result, pd->start_routine (pd->arg));
466 }
467
468/* Call destructors for the thread_local TLS variables. */
(lldb) thread return
* thread #2, name = 't-thread3', stop reason = breakpoint 1.1
frame #0: 0x76ff798f libc.so.6`clone at clone.S:97
94 popq%rdi/* Argument. */
95 call*%rax
96 /* Call ex
[llvm-bugs] [Bug 36013] LLDB: StandardStartupTest.TestStopReplyContainsThreadPcs fails on (32-bit) x86
https://bugs.llvm.org/show_bug.cgi?id=36013 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Hans Wennborg --- (In reply to labath from comment #3) > Fixed by r325511 (there was nothing wrong with the debugger, just the test > was not 32bit-compatible). Nice! Merged r324722 in r325562 to avoid merge conflicts, and then merged r325511 in r325563. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3656 in oss-fuzz: llvm: Stack-overflow in clang::format::UnwrappedLineParser::parseBlock
Updates: Status: WontFix Comment #7 on issue 3656 by ClusterFuzz-External: llvm: Stack-overflow in clang::format::UnwrappedLineParser::parseBlock https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3656#c7 ClusterFuzz testcase 4513473020035072 is flaky and no longer crashes, so closing issue. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3665 in oss-fuzz: llvm: Stack-overflow in clang::format::TokenAnnotator::annotate
Updates: Status: WontFix Comment #7 on issue 3665 by ClusterFuzz-External: llvm: Stack-overflow in clang::format::TokenAnnotator::annotate https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3665#c7 ClusterFuzz testcase 6145908082212864 is flaky and no longer crashes, so closing issue. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 5753 in oss-fuzz: llvm: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Updates: Status: WontFix Comment #2 on issue 5753 by ClusterFuzz-External: llvm: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5753#c2 ClusterFuzz testcase 4910517941436416 is flaky and no longer crashes, so closing issue. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4585 in oss-fuzz: llvm: Stack-overflow in EvaluateValue
Updates: Status: WontFix Comment #7 on issue 4585 by ClusterFuzz-External: llvm: Stack-overflow in EvaluateValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4585#c7 ClusterFuzz testcase 4781498155663360 is flaky and no longer crashes, so closing issue. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36449] New: Implement non-pipelined 'cat' command for lit internal shell.
https://bugs.llvm.org/show_bug.cgi?id=36449 Bug ID: 36449 Summary: Implement non-pipelined 'cat' command for lit internal shell. Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: chamal.desi...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org Implement non-pipelined 'cat' command for lit internal shell. This 'cat' command should display contents of a single file or contents of multiple files merged together. -- 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
