[llvm-bugs] [Bug 32046] New: false positive for -Wunused-member-function when in anonymous namespace
https://bugs.llvm.org/show_bug.cgi?id=32046
Bug ID: 32046
Summary: false positive for -Wunused-member-function when in
anonymous namespace
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: we...@wsoptics.de
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Compiling the following code with -Wunused-member-function results in two
warnings. Removing the anonymous namespace around the definition of class
Iterator makes the warnings go away.
#include
#include
#include
#include
namespace {
class Iterator : public boost::iterator_facade
{
public:
Iterator() : pos_(0) {}
std::size_t dereference() const { return pos_; }
bool equal(Iterator const & other) const { return pos_ ==
other.pos_; }
void increment() { ++pos_; }
void decrement() { --pos_; }
private:
friend class boost::iterator_core_access;
std::size_t pos_;
};
}
int main()
{
Iterator i;
std::cout << "i = " << *i << '\n';
return 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30470] ARM backend crash: Unknown addressing mode for CP reference
https://bugs.llvm.org/show_bug.cgi?id=30470 Kristof Beyls changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||kristof.be...@gmail.com --- Comment #2 from Kristof Beyls --- This was fixed by James in r283423, on the 6th of October 2016. -- 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 8852] Definition of friend function inside the class is not working if the function is declared in namespace scope
http://bugs.llvm.org/show_bug.cgi?id=8852 Serge Pavlov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||sepavl...@gmail.com --- Comment #2 from Serge Pavlov --- With ToT this problem is not observed anymore. Regression tests added in r295975. -- 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 9518] Friend function definition not instantiated in certain circumstances
http://bugs.llvm.org/show_bug.cgi?id=9518 Serge Pavlov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||sepavl...@gmail.com --- Comment #1 from Serge Pavlov --- With ToT this problem is not observed anymore. Regression test is added in r295975. -- 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 31836] pp_nonportable_path on absolute paths: broken delimiters
http://bugs.llvm.org/show_bug.cgi?id=31836 Taewook Oh changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Taewook Oh --- Resolved with https://reviews.llvm.org/rL295779 -- 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 32046] false positive for -Wunused-member-function when in anonymous namespace
https://bugs.llvm.org/show_bug.cgi?id=32046 we...@wsoptics.de changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from we...@wsoptics.de --- I'm sorry, I produced an incorrect example. Digging deeper into it, I think I screwed up something else and thought I had produced a correct example, which I hadn't. I apologize for the waste of time! -- 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 32047] New: Program compiled at -O2 results in an infinite loop (Induction Variable Simplification)
https://bugs.llvm.org/show_bug.cgi?id=32047
Bug ID: 32047
Summary: Program compiled at -O2 results in an infinite loop
(Induction Variable Simplification)
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: rob.loug...@gmail.com
CC: llvm-bugs@lists.llvm.org
The following program is a reduced test-case from auto-generated code:
=== foo.cpp ===
extern "C" int printf(const char *, ...);
static void init(unsigned char pred, volatile void *data, unsigned size) {
unsigned char *bytes = (unsigned char *)data;
for (unsigned int i = 0; i != size; ++i) {
bytes[i] = pred + i;
}
}
int main() {
unsigned char alpha;
init(255, &alpha, sizeof(alpha));
int bravo = 1;
printf("pre-loop %d\n", bravo);
for (unsigned char i = 0; i < alpha; ++i) {
bravo = 2;
}
printf("post-loop %d\n", bravo);
}
struct Charlie_ {
Charlie_() { init(48, &*this, sizeof(*this)); }
unsigned int a;
} Charlie;
===
If we compile this program with -O1 it terminates. At -O2, however, it hangs:
$ clang --version
clang version 5.0.0 (trunk 295990)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang foo.cpp -O1 -o foo && ./foo
pre-loop 1
post-loop 2
$ clang foo.cpp -O2 -o foo && ./foo
pre-loop 1
< HANG >
If we look at the assembly output it is obvious why the program hangs as the
loop in main() has been replaced by a jmp to itself:
main: # @main
pushq %rax
movl$.L.str, %edi
movl$1, %esi
xorl%eax, %eax
callq printf
.p2align4, 0x90
.LBB0_1:# %for.cond
# =>This Inner Loop Header: Depth=1
jmp .LBB0_1
There are several steps involved in getting to this position. This is the IR
for main() after inlining of init(). The loop for.body.i is from init, and
for.cond/for.body is the loop in main:
==
define i32 @main() local_unnamed_addr #0 {
entry:
%alpha = alloca i8, align 1
call void @llvm.lifetime.start(i64 1, i8* nonnull %alpha) #4
br label %for.body.i
for.body.i: ; preds = %for.body.i, %entry
%indvars.iv.i = phi i64 [ 0, %entry ], [ %indvars.iv.next.i, %for.body.i ]
%0 = trunc i64 %indvars.iv.i to i8
%add.i = add i8 %0, -1
store i8 %add.i, i8* %alpha, align 1, !tbaa !2
%indvars.iv.next.i = add nuw nsw i64 %indvars.iv.i, 1
%cmp.i = icmp eq i64 %indvars.iv.i, 0
br i1 %cmp.i, label %_ZL4inithPVvj.exit, label %for.body.i
_ZL4inithPVvj.exit: ; preds = %for.body.i
%call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([13 x
i8], [13 x i8]* @.str, i64 0, i64 0), i32 1)
br label %for.cond
for.cond: ; preds = %for.body,
%_ZL4inithPVvj.exit
%bravo.0 = phi i32 [ 1, %_ZL4inithPVvj.exit ], [ 2, %for.body ]
%i.0 = phi i8 [ 0, %_ZL4inithPVvj.exit ], [ %inc, %for.body ]
%1 = load i8, i8* %alpha, align 1, !tbaa !2
%cmp = icmp ult i8 %i.0, %1
br i1 %cmp, label %for.body, label %for.cond.cleanup
for.cond.cleanup: ; preds = %for.cond
%bravo.0.lcssa = phi i32 [ %bravo.0, %for.cond ]
%call2 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([14 x
i8], [14 x i8]* @.str.1, i64 0, i64 0), i32 %bravo.0.lcssa)
call void @llvm.lifetime.end(i64 1, i8* nonnull %alpha) #4
ret i32 0
for.body: ; preds = %for.cond
%inc = add nuw i8 %i.0, 1
br label %for.cond
}
==
The first step is the loop from main() is "rotated" to fold the loop latch
(for.body) into for.cond:
==
for.cond: ; preds = %for.cond,
%_ZL4inithPVvj.exit
%bravo.0 = phi i32 [ 1, %_ZL4inithPVvj.exit ], [ 2, %for.cond ]
%i.0 = phi i8 [ 0, %_ZL4inithPVvj.exit ], [ %inc, %for.cond ]
%1 = load i8, i8* %alpha, align 1, !tbaa !1
%cmp = icmp ult i8 %i.0, %1
%inc = add nuw i8 %i.0, 1
br i1 %cmp, label %for.cond, label %for.cond.cleanup
==
Several other optimisations then occur, which hoists the load out of the loop,
and instruction combining then replaces the store/load leaving the comparison
against %add.i:
==
for.cond: ; preds = %for.cond,
%_ZL4inithPVvj.exit
%bravo.0 = phi i32 [ 1, %_ZL4inithPVvj.exit ]
[llvm-bugs] [Bug 32048] New: Add a warning for implict double truncation to float
https://bugs.llvm.org/show_bug.cgi?id=32048 Bug ID: 32048 Summary: Add a warning for implict double truncation to float Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: jmuizel...@mozilla.com CC: llvm-bugs@lists.llvm.org MSVC has a warning for this and it would be nice to be able catch it when running with other compilers. -- 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 28445] Compilation never end
https://bugs.llvm.org/show_bug.cgi?id=28445 Michael Park changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||mcyp...@gmail.com --- Comment #1 from Michael Park --- *** This bug has been marked as a duplicate of bug 31642 *** -- 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 32049] New: Formatter doesn't wrap things that use alignment directives well
https://bugs.llvm.org/show_bug.cgi?id=32049 Bug ID: 32049 Summary: Formatter doesn't wrap things that use alignment directives well Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: dch...@google.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Before: alignas(DATA_ALIGNMENT) uint8_t data[kSegments * (sizeof(media::AudioInputBufferParameters) + frames * channels * sizeof(float))]; Arguably a bit unreadable already, but the formatted result is this: alignas( DATA_ALIGNMENT) uint8_t data[kSegments * (sizeof(media::AudioInputBufferParameters) + frames * channels * sizeof(float))]; Which I'm not sure is more readable. It'd be nice not to break in the middle of alignas, at the very least. -- 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 32041] X86 xop.vpcmov trips assertion
http://bugs.llvm.org/show_bug.cgi?id=32041 Paul Robinson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Paul Robinson --- I am perfectly willing to believe the test is bogus; it has been lying around untouched for quite a while. Someone here will take a closer look at it to see whether it has any value left at all. We'll call this fixed with your r295930. 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 32050] New: unix.Malloc checker fails for dynamic arrays w/expressions for sizes
https://bugs.llvm.org/show_bug.cgi?id=32050
Bug ID: 32050
Summary: unix.Malloc checker fails for dynamic arrays
w/expressions for sizes
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: kreme...@apple.com
Reporter: marsha...@google.com
CC: llvm-bugs@lists.llvm.org
The unix.Malloc checker crashes while analyzing source code which has dynamic
arrays with expressions that are computed from free variables. (A fix with
regression test is impending shortly.)
Repro: run unix.Malloc over this function (w/o any call sites to prevent
inlining/precomputation):
void AllocateExpr(int a, int b) {
new int[a + b];
}
Expected: no analysis errors, or a warning about a memory leak.
Actual: Clang analyzer crashes with this stack trace.
The unix.Malloc checker crashes while analyzing source code which has dynamic
arrays with expressions that are computed from free variables. (A fix with
regression test is impending shortly.)
Repro: run unix.Malloc over this function (w/o any call sites to prevent
inlining/precomputation):
void AllocateExpr(int a, int b) {
new int[a + b];
}
Expected: no analysis errors, or a warning about a memory leak.
Actual: Clang analyzer crashes with this stack trace.
clang:
/home/marshallk/chrome/src/third_party/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:77:
T clang::ento::SVal::castAs() const [with T = clang::ento::NonLoc]: Assertion
`T::isKind(*this)' failed.
#0 0x01d381f5 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x1d381f5)
#1 0x01d3626e llvm::sys::RunSignalHandlers()
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x1d3626e)
#2 0x01d363d2 SignalHandler(int)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x1d363d2)
#3 0x7f8d9b960330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#4 0x7f8d9a554c37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#5 0x7f8d9a558028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#6 0x7f8d9a54dbf6 __assert_fail_base
/build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#7 0x7f8d9a54dca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#8 0x00a099c8 clang::ento::DefinedOrUnknownSVal
clang::ento::SVal::castAs() const [clone
.part.271]
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0xa099c8)
#9 0x02fc93b9 void
clang::ento::check::PostStmt::_checkStmt<(anonymous
namespace)::MallocChecker>(void*, clang::Stmt const*,
clang::ento::CheckerContext&)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x2fc93b9)
#10 0x03142837 clang::ento::CheckerManager::runCheckersForStmt(bool,
clang::ento::ExplodedNodeSet&, clang::ento::ExplodedNodeSet const&, clang::Stmt
const*, clang::ento::ExprEngine&, bool)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x3142837)
#11 0x0316c036 clang::ento::ExprEngine::Visit(clang::Stmt const*,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x316c036)
#12 0x0316d616 clang::ento::ExprEngine::ProcessStmt(clang::CFGStmt,
clang::ento::ExplodedNode*)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x316d616)
#13 0x0316d8a5
clang::ento::ExprEngine::processCFGElement(clang::CFGElement,
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x316d8a5)
#14 0x031479f4 clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock
const*, unsigned int, clang::ento::ExplodedNode*)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x31479f4)
#15 0x031493f4
clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*,
clang::ProgramPoint, clang::ento::WorkListUnit const&)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x31493f4)
#16 0x031495a6
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, llvm::IntrusiveRefCntPtr)
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x31495a6)
#17 0x028805bc (anonymous
namespace)::AnalysisConsumer::ActionExprEngine(clang::Decl*, bool,
clang::ento::ExprEngine::InliningModes, llvm::DenseSet >*) [clone .part.4582]
(/home/marshallk/chrome/src/third_party/llvm-build/Release+Asserts/./bin/clang+0x28805bc)
#18 0x02880f7b (anonymous
namespace)::AnalysisConsumer::HandleCode(clan
[llvm-bugs] [Bug 32044] tools/clang/lib/AST/Expr.cpp:1876: bool clang::InitListExpr::isTransparent() const: Assertion `getNumInits() == 1 && "multiple inits in glvalue init list"' failed
https://bugs.llvm.org/show_bug.cgi?id=32044 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Smith --- Fixed in r296033. -- 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 32051] New: LLD doesn't define __bss_start
http://bugs.llvm.org/show_bug.cgi?id=32051 Bug ID: 32051 Summary: LLD doesn't define __bss_start Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org The GNU linker seems to define __bss_start symbol. LLD doesn't. Due to that incompatibility, mysql cannot be built on Linux. -- 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 32050] unix.Malloc checker fails for dynamic arrays w/expressions for sizes
https://bugs.llvm.org/show_bug.cgi?id=32050 Kevin Marshall changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Kevin Marshall --- Nope, apparently I wasn't. This is indeed a 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31982] llvm-cov show -format html: index removes leading part of file names
https://bugs.llvm.org/show_bug.cgi?id=31982 Vedant Kumar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||v...@apple.com --- Comment #2 from Vedant Kumar --- Thanks for the report, fixed in r296029. -- 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 32052] New: Should have __has_feature for GCC-compatible __auto_type
https://bugs.llvm.org/show_bug.cgi?id=32052
Bug ID: 32052
Summary: Should have __has_feature for GCC-compatible
__auto_type
Product: clang
Version: 3.9
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: m-l...@bodyfour.com
CC: llvm-bugs@lists.llvm.org
In 2015 (r252690), clang added support for GCC 4.9's "__auto_type" but as far
as I can tell there is no __has_feature() test to determine if the compiler
version you're using supports it or not. i.e. the following compiles fine with
the latest Xcode:
#if __has_feature(__auto_type)
#error "has feature"
#endif
#if __has_extension(__auto_type)
#error "has extension"
#endif
#if __has_attribute(__auto_type)
#error "has attribute"
#endif
int main()
{
__auto_type x = 5;
return x;
}
Right now I don't have a source clang build handy (I am just using Xcode's
clang) but I grepped around the cfe-3.9.1 code and I couldn't find it there
either. There is of course __has_feature(cxx_auto_type), but that's for the
C++11 "auto", not the GNU C __auto_type. Perhaps can you add a
__has_feature(c_auto_type) or __has_feature(gnu_auto_type) in the future?
--
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 31980] llvm-cov show -format html: index says 0/0 lines covered for a source file with some non-0 line counts
http://bugs.llvm.org/show_bug.cgi?id=31980
Vedant Kumar changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW |RESOLVED
CC||v...@apple.com
--- Comment #1 from Vedant Kumar ---
llvm-cov attributes the coverage for each function to a single file. We'd need
to break this policy to report additional coverage for cov.h, resulting in
double-counting in the coverage totals.
If you don't mind the double-counting, here's a patch you can use to see
additional statistics for cov.h:
diff --git a/lib/ProfileData/Coverage/CoverageMapping.cpp
b/lib/ProfileData/Coverage/CoverageMapping.cpp
index 6d907c7098e..d28b8b153a3 100644
--- a/lib/ProfileData/Coverage/CoverageMapping.cpp
+++ b/lib/ProfileData/Coverage/CoverageMapping.cpp
@@ -176,8 +176,13 @@ Expected CounterMappingContext::evaluate(const
Counter &C) const {
}
void FunctionRecordIterator::skipOtherFiles() {
+ auto ContainsFilename = [this](const FunctionRecord &FR) {
+return std::find(FR.Filenames.begin(), FR.Filenames.end(), Filename) !=
+ FR.Filenames.end();
+ };
+
while (Current != Records.end() && !Filename.empty() &&
- Filename != Current->Filenames[0])
+ !ContainsFilename(*Current))
++Current;
if (Current == Records.end())
*this = FunctionRecordIterator();
--
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 31992] PGO: complete constructors that don't call base constructors aren't instrumented
https://bugs.llvm.org/show_bug.cgi?id=31992 Vedant Kumar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vedant Kumar --- Fixed in clang/r296062. -- 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 32053] New: lldb-mi outputs extra =thread-group-exited after -gdb-exit
http://bugs.llvm.org/show_bug.cgi?id=32053
Bug ID: 32053
Summary: lldb-mi outputs extra =thread-group-exited after
-gdb-exit
Product: lldb
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: malape...@gmail.com
CC: llvm-bugs@lists.llvm.org
Reproduced on macOS 10.12 with latest SVN trunk and Ubuntu 16.04 with lldb 3.8
For example, if I start debugging this simple program:
int main() {
}
lldb-mi ./a.out
-exec-run
...
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)
-gdb-exit
^exit
=thread-group-exited,id="i1"
(gdb)
(Here back to terminal)
I don't think there should be any "=thread-group-exited" after the exit.
The GDB output looks like this:
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)
-gdb-exit
^exit
(Here back to terminal)
--
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 32054] New: function-sections-are-bad test failure
https://bugs.llvm.org/show_bug.cgi?id=32054 Bug ID: 32054 Summary: function-sections-are-bad test failure Product: compiler-rt Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: santosh.zanju...@amd.com CC: llvm-bugs@lists.llvm.org function-sections-are-bad test started failing from svn r293220. Using gold linker version 2.26.51.20151123, however test passes. I am not sure if we need to have the gold linker to build the compiler. This bug report can be closed if it is so. -- 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
