[llvm-bugs] [Bug 26250] New: BreakConstructorInitializersBeforeComma problem with noexcept
https://llvm.org/bugs/show_bug.cgi?id=26250
Bug ID: 26250
Summary: BreakConstructorInitializersBeforeComma problem with
noexcept
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: alessandro.pezz...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15688
--> https://llvm.org/bugs/attachment.cgi?id=15688&action=edit
clang-format configuration
When constructor has noexcept operator, formatting doesn't follow the
"BreakConstructorInitializersBeforeComma: true" rule.
My .clang-format is attached
Expected:
Fooxx::Fooxx(
int )
noexcept
: aaa{0}
, bbb{1}
, ccc{2} {
}
Actual:
Fooxx::Fooxx(
int )
noexcept
: aaa{0},
bbb{1},
ccc{2} {
}
Without noexcept:
Fooxx::Fooxx(
int )
: aaa{0}
, bbb{1}
, ccc{2} {
}
--
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 26251] New: [WinEH] bad codegen AllocAInst inside cleanup pad
https://llvm.org/bugs/show_bug.cgi?id=26251 Bug ID: 26251 Summary: [WinEH] bad codegen AllocAInst inside cleanup pad Product: new-bugs Version: 3.8 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: r.sagita...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Not sure if this is meant to be supported, but adding an AllocAInst inside a cleanuppad generates code that does not restore the stack correctly. This cleanup IR: cleanuppad: ; preds = %0 %1 = cleanuppad within none [] ; [#uses = 4] %cleanup.frame = alloca [40 x i8] ; [#uses = 1, size/byte = 40] %2 = bitcast [40 x i8]* %cleanup.frame to i8* ; [#uses = 2] %3 = call i1 @_d_enter_cleanup(i8* %2) [ "funclet"(token %1) ] ; [#uses = 1] br i1 %3, label %finally1, label %cleanupret finally1: ; preds = %cleanuppad call x86_stdcallcc void @"\01__D7cleanup5sexitFZv"() #0 [ "funclet"(token %1) ] br label %cleanupret cleanupret: ; preds = %cleanuppad, %finally1 call void @_d_leave_cleanup(i8* %2) [ "funclet"(token %1) ] cleanupret from %1 unwind to caller is translated to this x86-asm: "?dtor$2@?0?__D7cleanup7cleanupFZv@4HA": LBB0_2: pushl%ebp pushl%eax addl$12, %ebp movl$40, %eax calll__chkstk movl%esp, %eax movl$-1, -16(%ebp) subl$4, %esp movl%eax, (%esp) movl%eax, -32(%ebp) calll__d_enter_cleanup addl$4, %esp testb$1, %al jneLBB0_3 jmpLBB0_4 LBB0_3: movl$-1, -16(%ebp) calll__D7cleanup5sexitFZv LBB0_4: movl$-1, -16(%ebp) movl-32(%ebp), %eax pushl%eax calll__d_leave_cleanup addl$8, %esp popl%ebp retl Please note that %esp is changed by the "calll __chkstk; movl %esp, %eax" sequence, but never restored. I'll attach the full IR and asm files. -- 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 25909] [Polly] Schedule does not model irreducible control flow
https://llvm.org/bugs/show_bug.cgi?id=25909 Tobias Grosser changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Grosser --- Since r258497 Polly refuses irregular control flow. -- 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 26252] New: Tests fail when en_US-UTF-8 locale is missing
https://llvm.org/bugs/show_bug.cgi?id=26252 Bug ID: 26252 Summary: Tests fail when en_US-UTF-8 locale is missing Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: daniel.sand...@imgtec.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified Other missing locales cause the relevant tests to be 'UNSUPPORTED' instead of failing. The failures that occurred for me are fixed in r258403 and a few additional ones are fixed in D16408. -- 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 26253] New: libomp fails runtime/test/barrier/omp_barrier.c for X86
https://llvm.org/bugs/show_bug.cgi?id=26253 Bug ID: 26253 Summary: libomp fails runtime/test/barrier/omp_barrier.c for X86 Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: daniel.sand...@imgtec.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15691 --> https://llvm.org/bugs/attachment.cgi?id=15691&action=edit Pre-processed source I don't know OpenMP or X86 very well so I'd appreciate some help debugging this. I've attached the pre-processed source and I'll attach the assembly shortly (bugzilla only allows one attachment during submit). Here's the llvm-lit output: /home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/./bin/clang -fopenmp=libomp -I /home/das-local/llvm-release-3.8/release/rc1/llvm.src/projects/openmp/runtime/test -I /home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/projects/openmp/runtime/src -L /home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/lib /home/das-local/llvm-release-3.8/release/rc1/openmp.src/runtime/test/barrier/omp_barrier.c -o /home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/projects/openmp/runtime/test/barrier/Output/omp_barrier.c.tmp -lm && /home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/projects/openmp/runtime/test/barrier/Output/omp_barrier.c.tmp -- Exit Code: 10 Command Output (stdout): -- Command 0: "/home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/./bin/clang" "-fopenmp=libomp" "-I" "/home/das-local/llvm-release-3.8/release/rc1/llvm.src/projects/openmp/runtime/test" "-I" "/home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/projects/openmp/runtime/src" "-L" "/home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/lib" "/home/das-local/llvm-release-3.8/release/rc1/openmp.src/runtime/test/barrier/omp_barrier.c" "-o" "/home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/projects/openmp/runtime/test/barrier/Output/omp_barrier.c.tmp" "-lm" Command 0 Result: 0 Command 0 Output: Command 0 Stderr: Command 1: "/home/das-local/llvm-release-3.8/release/rc1/Phase3/Release/llvmCore-3.8.0-rc1.obj/projects/openmp/runtime/test/barrier/Output/omp_barrier.c.tmp" Command 1 Result: 10 Command 1 Output: Command 1 Stderr: -- 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 26254] New: clang_codeCompleteGetContexts suggests CXCompletionContext_DotMemberAccess for "Foo::"
https://llvm.org/bugs/show_bug.cgi?id=26254
Bug ID: 26254
Summary: clang_codeCompleteGetContexts suggests
CXCompletionContext_DotMemberAccess for "Foo::"
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: nikolai.kos...@theqtcompany.com
CC: kli...@google.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Ubuntu clang version 3.8.0-svn257311-1~exp1 (trunk) (based on LLVM 3.8.0)
For a *.cpp file with the contents
1 void f()
2 {
3 Foo::
4 }
...and a completion right after the second colon (line 3, column 10), libclang
will suggest CXCompletionContext_DotMemberAccess. Foo is unknown, but still
this shouldn't suggest CXCompletionContext_DotMemberAccess?
Tested with the following code:
#include
#undef NDEBUG
#include
#include
#include
int main(int argc, char *argv[])
{
if (argc != 4) {
fprintf(stderr, "Usage: $0 \n");
return 0;
}
const char *filePath = argv[1];
const unsigned line = unsigned(atoi(argv[2]));
const unsigned column = unsigned(atoi(argv[3]));
// Parse
CXIndex index = clang_createIndex(0, /*displayDiagnostics*/ 1); // ...to
compare
CXTranslationUnit tu = clang_parseTranslationUnit(index, argv[1], 0, 0,
NULL, 0, 0);
// Complete
CXCodeCompleteResults *completeResults = clang_codeCompleteAt(tu,
filePath, line, column, NULL, 0, 0);
// Test
const unsigned long long contexts =
clang_codeCompleteGetContexts(completeResults);
const bool wasDotMemberCompletion = contexts &
CXCompletionContext_DotMemberAccess;
assert(!wasDotMemberCompletion);
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 26227] hasAncestor matcher crashes on certain constructs
https://llvm.org/bugs/show_bug.cgi?id=26227 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nico Weber --- r258503 -- 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 26255] New: Checks for UserLabelPrefix in freestanding mode are incorrect (?)
https://llvm.org/bugs/show_bug.cgi?id=26255 Bug ID: 26255 Summary: Checks for UserLabelPrefix in freestanding mode are incorrect (?) Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: andreybokha...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Rafael believes (http://reviews.llvm.org/D16295#329929) that the following checks for __USER_LABEL_PREFIX_ macro in tools/clang/test/Preprocessor/init.c are incorrect: init.c:5216 // PPC603E:#define __USER_LABEL_PREFIX__ _ init.c:4837 // NVPTX32:#define __USER_LABEL_PREFIX__ _ init.c:2402 // I386:#define __USER_LABEL_PREFIX__ _ init.c:7343 // X86_64:#define __USER_LABEL_PREFIX__ _ init.c:1376 // ARM:#define __USER_LABEL_PREFIX__ _ init.c:418 // AARCH64:#define __USER_LABEL_PREFIX__ _ init.c:6970 // SPARC:#define __USER_LABEL_PREFIX__ _ init.c:6785 // S390X:#define __USER_LABEL_PREFIX__ _ init.c:4649 // MSP430:#define __USER_LABEL_PREFIX__ _ init.c:7149 // TCE:#define __USER_LABEL_PREFIX__ _ init.c:2993 // MIPS32BE:#define __USER_LABEL_PREFIX__ _ They are added by: hfinkel (PPC603E) nobled (NVPTX32) lattner (I386, X86_64, ARM, SPARC, MSP430, TCE) kevinqin (AARCH64) uweigand (S390X) atanasyan (MIPS32BE) I CCed all of you to this PR; if you believe your check is correct, please add a note. If you agree it's not, let me know -- I will change it (or do this yourself, if you have a free minute). Andrey -- 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 26256] New: wrong code at -O2 and -O3 on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=26256
Bug ID: 26256
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code is miscompiled by the current clang trunk (and 3.7.x) on
x86_64-linux-gnu at -O2 and -O3 in both 32-bit and 64-bit modes.
This is a regression from 3.6.x.
$ clang-trunk -v
clang version 3.9.0 (trunk 258416)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/tools/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.2.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
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.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.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.2.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang-trunk -Os small.c; ./a.out
$ clang-3.6 -O2 small.c; ./a.out
$
$ clang-trunk -O2 small.c
$ ./a.out
0
$ clang-3.7 -O2 small.c
$ ./a.out
0
$
int printf (const char *, ...);
int a = 8, b, d, e, f;
short c;
void
fn1 ()
{
char g = c, h = c = c | 195;
if (d)
;
if ((!a && c > d) || c < d)
for (g = 0; g < 20; g++)
e ^= f;
a = 2 & g;
if (h >= c || g)
printf ("%d\n", b);
if (a)
{
fn1 ();
for (;;)
;
}
}
int
main ()
{
fn1 ();
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 26257] New: Assertion `!Parents.empty() && "Found node that is not in the parent map."' failed in ast matcher
https://llvm.org/bugs/show_bug.cgi?id=26257
Bug ID: 26257
Summary: Assertion `!Parents.empty() && "Found node that is not
in the parent map."' failed in ast matcher
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Add this to ASTMatchersTests.cpp, it'll crash because it can't find a parent
for
ParmVarDecl 0x2675740 col:32 used count 'int'
(which is the "count" param in the int-instantiated copy of the quantizedSize
template).
TEST(HasAncestor, FIXMEbettername) {
EXPECT_TRUE(matches("struct PartitionAllocator {\n"
" template\n"
" static int quantizedSize(int count) {\n"
"return count;\n"
" }\n"
" void f() { quantizedSize(10); }\n"
"};",
declRefExpr(to(decl(hasAncestor(decl()));
}
>From a spurious look, RecursiveASTVisitor visits ParmVarDecls through the
TypeSourceInformation, and it looks like the TypeSourceInformation for the
instantiation points to the template's ParmVarDecl, not to the instantiation's.
--
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 26258] New: wrong feature suggested when using AVX maskstore intrinsic
https://llvm.org/bugs/show_bug.cgi?id=26258
Bug ID: 26258
Summary: wrong feature suggested when using AVX maskstore
intrinsic
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
It would be better if the error message gave me the correct advice the first
time. :)
$ ./clang -v
clang version 3.9.0 (trunk 258513) (llvm/trunk 258512)
Target: x86_64-apple-darwin15.2.0
Thread model: posix
$ cat juke.c
#include
void juke(float *f, __m128i mask, __m128 v) {
_mm_maskstore_ps(f, mask, v);
}
$ ./clang -O1 juke.c -S
juke.c:4:3: error: always_inline function '_mm_maskstore_ps' requires target
feature 'sse4.2', but would be inlined into function 'juke' that is compiled
without support for 'sse4.2'
_mm_maskstore_ps(f, mask, v);
^
1 error generated.
$ ./clang -O1 juke.c -S -msse4.2
juke.c:4:3: error: always_inline function '_mm_maskstore_ps' requires target
feature 'avx', but would be inlined into function 'juke' that is compiled
without support for 'avx'
_mm_maskstore_ps(f, mask, v);
^
1 error generated.
--
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 25875] differing results between clang-cl and MSVC when preprocessing
https://llvm.org/bugs/show_bug.cgi?id=25875 Ehsan Akhgari [:ehsan] changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Ehsan Akhgari [:ehsan] --- Fixed in r258530. -- 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 26259] New: PPCVSXFMAMutate.cpp assertion failure
https://llvm.org/bugs/show_bug.cgi?id=26259
Bug ID: 26259
Summary: PPCVSXFMAMutate.cpp assertion failure
Product: new-bugs
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: eric.schwe...@pgroup.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15695
--> https://llvm.org/bugs/attachment.cgi?id=15695&action=edit
bugpoint reduced testcase
llc -O2 -o junk.s bug.ll
llc: .../llvm/lib/CodeGen/LiveInterval.cpp:190:
{anonymous}::CalcLiveRangeUtilBase::iterator
{anonymous}::CalcLiveRangeUtilBase::addSegment({anonymous}::CalcLiveRangeUtilBase::Segment) [with ImplT = {anonymous}::CalcLiveRangeUtilVector;
IteratorT = llvm::LiveRange::Segment*; CollectionT =
llvm::SmallVector;
{anonymous}::CalcLiveRangeUtilBase::iterator =
llvm::LiveRange::Segment*; {anonymous}::CalcLiveRangeUtilBase::Segment = llvm::LiveRange::Segment]: Assertion `B->end <= Start
&& "Cannot overlap two segments with differing ValID's" " (did you def the same
reg twice in a MachineInstr?)"' failed.
#0 0x10e613b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/eschweitz/llvm/3.7ppc/bin/llc+0x10e613b0)
#1 0x10e62520 (.../bin/llc+0x10e62520)
#2 0x10e5fdb4 (.../bin/llc+0x10e5fdb4)
0 llc 0x10e613b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
+ 144
1 llc 0x10e62520
2 llc 0x10e5fdb4
30x10040478 __kernel_sigtramp_rt64 + 0
4 libc.so.6 0x103d0a88 gsignal + 72
5 libc.so.6 0x103d693c abort + 620
6 libc.so.6 0x103c65b4
7 libc.so.6 0x103c66a4 __assert_fail + 100
8 llc 0x10744d54
llvm::LiveRange::addSegment(llvm::LiveRange::Segment) + 2708
9 llc 0x103d3ca4
10 llc 0x103d5424
11 llc 0x107abe38
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 280
12 llc 0x10d314a8
llvm::FPPassManager::runOnFunction(llvm::Function&) + 744
13 llc 0x10d31b0c llvm::FPPassManager::runOnModule(llvm::Module&)
+ 76
14 llc 0x10d31f30
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 976
15 llc 0x10d3222c llvm::legacy::PassManager::run(llvm::Module&) +
28
16 llc 0x101bfee8
17 llc 0x1019f2b0 main + 352
18 libc.so.6 0x103b4d00
19 libc.so.6 0x103b4ef8 __libc_start_main + 200
Stack dump:
0. Program arguments: llc -O2 -o junk.s bug.ll
1. Running pass 'Function Pass Manager' on module 'bug.ll'.
2. Running pass 'PowerPC VSX FMA Mutation' on function '@iHaveAnBug'
Aborted
--
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 26186] NVPTX: Cannot select: t46: i64, i64 = umul_lohi t7, t4
https://llvm.org/bugs/show_bug.cgi?id=26186 Jingyue Wu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jingyue Wu --- r258536 -- 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 6713] autotools are not honoring LIBDIR settings
https://llvm.org/bugs/show_bug.cgi?id=6713 Elias Pipping changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #9 from Elias Pipping --- The autotools-based build system is deprecated and scheduled for removal in llvm 3.9. I think there's no point in fixing this now. -- 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 26261] New: gtest failure in PythonDataObjectsTest.TestPythonBytes on OS X 10.11
https://llvm.org/bugs/show_bug.cgi?id=26261 Bug ID: 26261 Summary: gtest failure in PythonDataObjectsTest.TestPythonBytes on OS X 10.11 Product: lldb Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified [ RUN ] PythonDataObjectsTest.TestPythonBytes /Users/tfiala/lldb/tot/git-svn/lldb/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp:212: Failure Value of: python_bytes.GetObjectType() Actual: 4-byte object <05-00 00-00> Expected: PyObjectType::Bytes Which is: 4-byte object <06-00 00-00> This test is causing the gtest run to fail. I'll need to disable it on OS X as soon as I get the OS X Green Dragon buildbot to run (instead of just build) the lldb-gtest target. (I just discovered it was only building and not running it while investigating 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 26262] New: No redeclared exception specification diagnostic for operator new at C++11
https://llvm.org/bugs/show_bug.cgi?id=26262
Bug ID: 26262
Summary: No redeclared exception specification diagnostic for
operator new at C++11
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: charles...@playstation.sony.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
This bug has been discovered while updating Lit test
CXX/basic/basic.stc/basic.stc.dynamic/p2.cpp for C++11 compatibility.
The gist of the bug is that when an operator is declared with a throw() then
redeclared without one, the compiler should issue a diagnostic regardless of
operator.
As we shall see in the test case below,
a diagnostic was issues in every case except for operator new at C++11.
Here is the reduced test case.
//
namespace std {
class bad_alloc { };
typedef __SIZE_TYPE__ size_t;
}
void* operator new(std::size_t) throw(std::bad_alloc);
void* operator new(std::size_t);
void operator delete(void*) throw() ;
void operator delete(void*);
//
In C++98, Clang will issue warnings on both the re-decleration of operator new
and operator delete.
$ clang -c nd.cpp -std=c++98 -Wall -fexceptions -frtti
nd.cpp:7:7: warning: 'operator new' is missing exception specification
'throw(std::bad_alloc)'
void* operator new(std::size_t);
^
throw(std::bad_alloc)
nd.cpp:6:7: note: previous declaration is here
void* operator new(std::size_t) throw(std::bad_alloc);
^
nd.cpp:10:6: warning: 'operator delete' is missing exception specification
'throw()'
void operator delete(void*);
^
throw()
nd.cpp:9:6: note: previous declaration is here
void operator delete(void*) throw() ;
^
2 warnings generated.
In C++11, Clang will only issue a warning on the delete operator.
$ cl -c nd.cpp -std=c++11 -Wall -fexceptions -frtti
nd.cpp:10:6: warning: function previously declared with
an explicit exception specification redeclared with
an implicit exception specification [-Wimplicit-exception-spec-mismatch]
void operator delete(void*);
^
nd.cpp:9:6: note: previous declaration is here
void operator delete(void*) throw() ;
^
1 warning generated.
For comparison, GCC (version 4.9.2) issues diagnostics for both
operator new and operator delete at C++98 and C++11
$ gcc -c nd.cpp -std=c++98 -Wall -fexceptions -frtti
nd.cpp:7:31: error: declaration of ‘void* operator new(std::size_t)’ has a
different exception specifier
void* operator new(std::size_t);
^
nd.cpp:6:7: error: from previous declaration ‘void* operator new(std::size_t)
throw (std::bad_alloc)’
void* operator new(std::size_t) throw(std::bad_alloc);
^
nd.cpp:10:27: error: declaration of ‘void operator delete(void*)’ has a
different exception specifier
void operator delete(void*);
^
nd.cpp:9:6: error: from previous declaration ‘void operator delete(void*) throw
()’
void operator delete(void*) throw() ;
^
$ gcc -c nd.cpp -std=c++11 -Wall -fexceptions -frtti
nd.cpp:7:31: error: declaration of ‘void* operator new(std::size_t)’ has a
different exception specifier
void* operator new(std::size_t);
^
nd.cpp:6:7: error: from previous declaration ‘void* operator new(std::size_t)
throw (std::bad_alloc)’
void* operator new(std::size_t) throw(std::bad_alloc);
^
nd.cpp:10:27: error: declaration of ‘void operator delete(void*)’ has a
different exception specifier
void operator delete(void*);
^
nd.cpp:9:6: error: from previous declaration ‘void operator delete(void*) throw
()’
void operator delete(void*) throw() ;
^
--
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 26263] New: [WinEH] assertion when inlining function into cleanuppad
https://llvm.org/bugs/show_bug.cgi?id=26263
Bug ID: 26263
Summary: [WinEH] assertion when inlining function into
cleanuppad
Product: new-bugs
Version: 3.8
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: r.sagita...@gmx.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15696
--> https://llvm.org/bugs/attachment.cgi?id=15696&action=edit
original IR before reduction by bugpoint
The attached IR produces an assertion when optimized with -O2:
Assertion failed: isa(Val) && "cast() argument of incompatible type!",
file C:\s\d\ldc\llvm\include\llvm/Support/Casting.h, line 223
bugpoint reduces this to:
; ModuleID = 'bugpoint-reduced-simplified.bc'
target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
target triple = "i386-pc-windows-msvc"
define x86_stdcallcc void @"\01__D5sdt123S126__dtorMFZv"() {
ret void
}
define x86_stdcallcc void @"\01__D5sdt125foo12FS5sdt123S12Zv"() {
ret void
}
define x86_stdcallcc void @"\01__D5sdt126test12FZv"() personality i32 (i8*,
i8*, i8*, i8*)* @__CxxFrameHandler3 {
invoke x86_stdcallcc void @"\01__D5sdt125foo12FS5sdt123S12Zv"()
to label %postinvoke unwind label %cleanuppad
postinvoke: ; preds = %0
br i1 undef, label %assertPassed, label %assertFailed
cleanuppad: ; preds = %0
%1 = cleanuppad within none []
br i1 undef, label %finally1, label %cleanupret
finally1: ; preds = %cleanuppad
br label %cleanupret
cleanupret: ; preds = %finally1,
%cleanuppad
cleanupret from %1 unwind to caller
assertPassed: ; preds = %postinvoke
ret void
assertFailed: ; preds = %postinvoke
unreachable
}
declare i32 @__CxxFrameHandler3(i8*, i8*, i8*, i8*)
!llvm.ident = !{!0}
!0 = !{!"ldc version 1598c4"}
and blames the -prune-eh pass. "opt -prune-eh" prints:
CleanupReturnInst needs to be provided a CleanupPad
cleanupret from undef unwind to caller
token undef
LLVM ERROR: Broken function found, compilation aborted!
--
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 26264] New: [x86, avx512] crash lowering masked load intrinsic
https://llvm.org/bugs/show_bug.cgi?id=26264
Bug ID: 26264
Summary: [x86, avx512] crash lowering masked load intrinsic
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This is a test that already exists in llvm/test/CodeGen/X86/masked_memop.ll,
but it isn't tested with the following target attribute:
define <32 x i64> @test_load_32i64(<32 x i64>* %ptrs, <32 x i1> %mask, <32 x
i64> %src0) {
%res = call <32 x i64> @llvm.masked.load.v32i64(<32 x i64>* %ptrs, i32 4, <32
x i1> %mask, <32 x i64> %src0)
ret <32 x i64> %res
}
declare <32 x i64> @llvm.masked.load.v32i64(<32 x i64>* %ptrs, i32, <32 x i1>
%mask, <32 x i64> %src0)
$ ./llc mloadcrash.ll -o - -mattr=avx512bw
.section__TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 11
Assertion failed: ((NumElts == 8 || NumElts == 16) && "Unexected vector
type."), function LowerTruncateVecI1, file
/Users/spatel/myllvm/llvm/lib/Target/X86/X86ISelLowering.cpp, line 13588.
0 llc 0x000107a30f5e
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46
1 llc 0x000107a313a9
PrintStackTraceSignalHandler(void*) + 25
2 llc 0x000107a2db49 llvm::sys::RunSignalHandlers() +
425
3 llc 0x000107a31709 SignalHandler(int) + 345
4 libsystem_platform.dylib 0x7fff9d455eaa _sigtramp + 26
5 llc 0x00010865b507 ErrorCategory + 86135
6 llc 0x000107a313cb raise + 27
7 llc 0x000107a31482 abort + 18
8 llc 0x000107a31461 __assert_rtn + 129
9 llc 0x000106597de8
LowerTruncateVecI1(llvm::SDValue, llvm::SelectionDAG&, llvm::X86Subtarget
const*) + 2312
10 llc 0x000106594dd3
llvm::X86TargetLowering::LowerTRUNCATE(llvm::SDValue, llvm::SelectionDAG&)
const + 1059
11 llc 0x0001065b3390
llvm::X86TargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&)
const + 1520
12 llc 0x00010770a0fe (anonymous
namespace)::VectorLegalizer::LegalizeOp(llvm::SDValue) + 4174
13 llc 0x000107708ed9 (anonymous
namespace)::VectorLegalizer::Run() + 1513
14 llc 0x000107708872
llvm::SelectionDAG::LegalizeVectors() + 66
15 llc 0x000107885d57
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 7431
16 llc 0x00010788403f
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 255
17 llc 0x000107883d28
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 5256
18 llc 0x000107881398
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1624
19 llc 0x00010652fc5b (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 59
20 llc 0x000106cdcb1e
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110
21 llc 0x000107271b6d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 413
22 llc 0x000107271ea5
llvm::FPPassManager::runOnModule(llvm::Module&) + 117
23 llc 0x000107272bfa (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&) + 2010
24 llc 0x00010727218b
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 347
25 llc 0x000107273841
llvm::legacy::PassManager::run(llvm::Module&) + 33
26 llc 0x0001055b8d4c compileModule(char**,
llvm::LLVMContext&) + 19788
27 llc 0x0001055b3f96 main + 230
28 libdyld.dylib0x7fff8a4fa5ad start + 1
29 libdyld.dylib0x0005 start + 1974491737
Stack dump:
0.Program arguments: ./llc mloadcrash.ll -o - -mattr=avx512bw
1.Running pass 'Function Pass Manager' on module 'mloadcrash.ll'.
2.Running pass 'X86 DAG->DAG Instruction Selection' on function
'@test_load_32i64'
Illegal instruction: 4
--
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 26265] New: [Windows] Evaluating arguments gives incorrect values except for frame 0
https://llvm.org/bugs/show_bug.cgi?id=26265 Bug ID: 26265 Summary: [Windows] Evaluating arguments gives incorrect values except for frame 0 Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: amcca...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified TextConditionalBreak.py fails on Windows when trying to evaluate a function argument in frame 1. Manual experiments indicates this is problem for arguments in any frame other than frame 0. This is observable in expression and backtraces. (lldb) thread backtrace * thread #1: tid = 0x1144, 0x0112b08a a.out`c(val=3) + 10 at main.c:39, stop reason = breakpoint 2.1 * frame #0: 0x0112b08a a.out`c(val=3) + 10 at main.c:39 frame #1: 0x0112b03e a.out`a(val=4586500) + 62 at main.c:27 frame #2: 0x0112b12b a.out`main(argc=0, argv=0x0045fc04) + 139 at main.c:50 frame #3: 0x0112b88f a.out`$LN27 + 224 Note that the correct value for val in frame #0 is correct (3), but incorrect in frame #1. (lldb) thread step-out (lldb) Process 9808 stopped * thread #1: tid = 0x1144, 0x0112b03e a.out`a(val=3) + 62 at main.c:27, stop reason = step out frame #0: 0x0112b03e a.out`a(val=3) + 62 at main.c:27 24 if (val <= 1) 25 return b(val); 26 else if (val >= 3) -> 27 return c(val); // Find the line number where c's parent frame is a here. 28 29 return val; 30 } thread back * thread #1: tid = 0x1144, 0x0112b03e a.out`a(val=3) + 62 at main.c:27, stop reason = step out * frame #0: 0x0112b03e a.out`a(val=3) + 62 at main.c:27 frame #1: 0x0112b12b a.out`main(argc=3, argv=0x0003) + 139 at main.c:50 frame #2: 0x0112b88f a.out`$LN27 + 224 After stepping back out to what was frame #1, and val is now correctly shown. -- 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 25997] [WinEH] no-return function in cleanup code not called with -O
https://llvm.org/bugs/show_bug.cgi?id=25997 David Majnemer changed: What|Removed |Added Component|LLVM Codegen|Common Code Generator Code Resolution|WONTFIX |FIXED Assignee|unassignedclangbugs@nondot. |david.majne...@gmail.com |org | Product|clang |libraries --- Comment #5 from David Majnemer --- After quite a bit of thought, I think I figured out a reasonable solution: inject catch-all handlers after cleanups which are post-dominated by unreachable. Fixed in r258580. -- 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 26266] New: wrong code at -O1 and above in 32-bit and 64-bit modes on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=26266
Bug ID: 26266
Summary: wrong code at -O1 and above in 32-bit and 64-bit modes
on x86_64-linux-gnu
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: chengnian...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code is miscompiled by the trunk at -O1 and above in both 32-bit
and 64-bit modes on x86_64-linux-gnu.
$: clang-trunk -v
clang version 3.9.0 (trunk 258508)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.2.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
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.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.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.2.1
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.3
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.4
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$:
$: clang-trunk -w -O0 small.c ; ./a.out
$: clang-trunk small.c -O1 -m32 ; ./a.out
Aborted (core dumped)
$: clang-trunk small.c -O1 -m64 ; ./a.out
Aborted (core dumped)
$:
$: cat small.c
void abort();
char a;
int b, c = 9, d, e;
void fn1() {
unsigned f = 1;
int g = 8, h = 5;
for (; a != 6; a--) {
int *i = &h, *j;
for (;;) {
int k = e, l = ~1;
if (g && h) {
k = g;
l = f;
f = -(~(c && b) | -~(e * ~l));
if (c < f)
abort();
}
g = k;
f = l;
if (d <= 8)
break;
*i = 0;
for (; *j <= 0;)
;
}
}
}
int main() {
fn1();
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 25956] hexagon 3bit .new register fields are not decoded properly
https://llvm.org/bugs/show_bug.cgi?id=25956 Colin LeMahieu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #8 from Colin LeMahieu --- Packet looks to have been assembled incorrectly with an unspecified bit set to 1 when it should be 0. LLVM trunk assembles and disassembles packets correctly. -- 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 26267] New: IncompleteModulesTestCase asserting in clang on Darwin with Xcode 7.3 Beta 1
https://llvm.org/bugs/show_bug.cgi?id=26267 Bug ID: 26267 Summary: IncompleteModulesTestCase asserting in clang on Darwin with Xcode 7.3 Beta 1 Product: lldb Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Exiting test on signal on the testbot, due to clang hitting an exception somewhere in expression evaluation of the module import: Session logs for test failures/errors/unexpected successes will go into directory '2016-01-22-17_48_50' Command invoked: /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/test/dotest.py --apple-sdk macosx --executable=/Users/buildslave/jenkins/sharedspace/lldb@2/lldb-build/Build/Products/Debug/lldb --rerun-all-issues --env TERM=vt100 -s 2016-01-22-17_48_50 --results-port 54304 --inferior -p TestIncompleteModules.py /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test --event-add-entries worker_index=0:int Configuration: arch=x86_64 compiler=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Collected 2 tests Assertion failed: (DeclKind != Decl::LinkageSpec && "Should not perform lookups into linkage specs!"), function lookup, file /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm/tools/clang/lib/AST/DeclBase.cpp, line 1370. [TestIncompleteModules.py FAILED] Command invoked: /usr/bin/python /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/test/dotest.py --apple-sdk macosx --executable=/Users/buildslave/jenkins/sharedspace/lldb@2/lldb-build/Build/Products/Debug/lldb --rerun-all-issues --env TERM=vt100 -s 2016-01-22-17_48_50 --results-port 54304 --inferior -p TestIncompleteModules.py /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test --event-add-entries worker_index=0:int 289 out of 422 test suites processed - TestIncompleteModules.py Sean Callanan is aware of this. I'm just adding this bug to track in the test I skip. -- 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 25844] test rerun logic is hanging on buildbot and Jenkins testbots
https://llvm.org/bugs/show_bug.cgi?id=25844 Todd Fiala changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Todd Fiala --- Fixed this a while back. -- 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 26263] [WinEH] assertion when inlining function into cleanuppad
https://llvm.org/bugs/show_bug.cgi?id=26263 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Component|new bugs|Interprocedural ||Optimizations Version|3.8 |trunk Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |david.majne...@gmail.com Product|new-bugs|libraries --- Comment #1 from David Majnemer --- Thanks for the bug report! Fixed in r258611. Is this the only issue you hit after removing noinline? -- 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
