From bugzilla-daemon at llvm.org Wed Sep 1 02:04:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 04:04:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 8049] New: [PATCH] Add support for mingw gcc 4.5.0 headers Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8049 Summary: [PATCH] Add support for mingw gcc 4.5.0 headers Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Headers AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ismail at namtrac.org CC: llvmbugs at cs.uiuc.edu Mingw gcc 4.5.0 is out for some time now, it would be nice to support it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 04:53:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 06:53:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8050] New: --experimental-checks: Assertion `D && "Cannot get layout of forward declarations!" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8050 Summary: --experimental-checks: Assertion `D && "Cannot get layout of forward declarations!" Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: dimhen at gmail.com CC: llvmbugs at cs.uiuc.edu $ clang --version clang version 2.8 (trunk 112697) Target: x86_64-unknown-linux-gnu Thread model: posix $ cat tst.c #include struct S; void foo(struct S **arg) { *arg = malloc(1); } $ clang -cc1 tst.c -analyze -analyzer-check-objc-mem -analyzer-experimental-internal-checks -analyzer-experimental-checks clang: RecordLayoutBuilder.cpp:1502: const clang::ASTRecordLayout& clang::ASTContext::getASTRecordLayout(const clang::RecordDecl*): Assertion `D && "Cannot get layout of forward declarations!"' failed. 0 clang 0x000000000134c74f 1 clang 0x000000000134e7ba 2 libpthread.so.0 0x00000032c4e0f0f0 3 libc.so.6 0x00000032c46326c5 gsignal + 53 4 libc.so.6 0x00000032c4633ea5 abort + 373 5 libc.so.6 0x00000032c462b7b5 __assert_fail + 245 6 clang 0x0000000000bdeb53 clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) + 1523 7 clang 0x0000000000b5c54f clang::ASTContext::getTypeInfo(clang::Type const*) + 1807 8 clang 0x0000000000b5c823 clang::ASTContext::getTypeSizeInChars(clang::QualType) + 51 9 clang 0x0000000000af7cc2 10 clang 0x0000000000a7e5ef clang::GRExprEngine::CheckerVisit(clang::Stmt const*, clang::ExplodedNodeSet&, clang::ExplodedNodeSet&, clang::GRExprEngine::CallbackKind) + 575 11 clang 0x0000000000a89cab clang::GRExprEngine::VisitCast(clang::CastExpr const*, clang::Expr const*, clang::ExplodedNode*, clang::ExplodedNodeSet&, bool) + 1867 12 clang 0x0000000000a81a46 clang::GRExprEngine::Visit(clang::Stmt const*, clang::ExplodedNode*, clang::ExplodedNodeSet&) + 566 13 clang 0x0000000000a86543 clang::GRExprEngine::VisitBinaryOperator(clang::BinaryOperator const*, clang::ExplodedNode*, clang::ExplodedNodeSet&, bool) + 691 14 clang 0x0000000000a82015 clang::GRExprEngine::Visit(clang::Stmt const*, clang::ExplodedNode*, clang::ExplodedNodeSet&) + 2053 15 clang 0x0000000000a8b79e clang::GRExprEngine::ProcessStmt(clang::CFGElement, clang::GRStmtNodeBuilder&) + 846 16 clang 0x0000000000a77147 clang::GRCoreEngine::HandlePostStmt(clang::PostStmt const&, clang::CFGBlock const*, unsigned int, clang::ExplodedNode*) + 167 17 clang 0x0000000000a77698 clang::GRCoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned int, clang::GRState const*) + 952 18 clang 0x0000000000a1ec48 19 clang 0x0000000000a1f851 20 clang 0x0000000000a1fbf2 21 clang 0x0000000000811fdd clang::ParseAST(clang::Sema&, bool) + 301 22 clang 0x00000000006077dd clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 349 23 clang 0x00000000005e8d8c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 24 clang 0x00000000005dfb91 cc1_main(char const**, char const**, char const*, void*) + 417 25 clang 0x00000000005e7883 main + 4051 26 libc.so.6 0x00000032c461eb1d __libc_start_main + 253 27 clang 0x00000000005df7f9 Stack dump: 0. Program arguments: clang -cc1 tst.c -analyze -analyzer-check-objc-mem -analyzer-experimental-internal-checks -analyzer-experimental-checks 1. parser at end of file 2. tst.c:6:5: Error evaluating statement 3. tst.c:6:5: Error evaluating statement 4. tst.c:6:12: Error evaluating statement Aborted (core dumped) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 07:37:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 09:37:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 8051] New: Linear Scan Register Allocator crash / invalid memory usage Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8051 Summary: Linear Scan Register Allocator crash / invalid memory usage Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5436) --> (http://llvm.org/bugs/attachment.cgi?id=5436) testcase .ll The attached testcase causes llc to crash: $ llc -relocation-model=pic -disable-fp-elim linearscan.ll llc: llvm/lib/CodeGen/RegAllocLinearScan.cpp:1177: void::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*): Assertion `false && "Ran out of registers during register allocation!"' failed. Valgrind says: Invalid read of size 4 at 0xA57721: (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*) (LiveInterval.h:281) by 0xA59F40: (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*) (RegAllocLinearScan.cpp:1175) by 0xA5AE5E: (anonymous namespace)::RALinScan::linearScan() (RegAllocLinearScan.cpp:564) by 0xA5BFC9: (anonymous namespace)::RALinScan::runOnMachineFunction(llvm::MachineFunction&) (RegAllocLinearScan.cpp:490) by 0xCBB68C: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1443) by 0xCBB78A: llvm::FPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1463) by 0xCBB216: llvm::MPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1517) by 0xCBB396: llvm::PassManagerImpl::run(llvm::Module&) (PassManager.cpp:1598) by 0x51A6AF: main (llc.cpp:325) Address 0x5e8c928 is not stack'd, malloc'd or (recently) free'd Conditional jump or move depends on uninitialised value(s) at 0xB13D22: llvm::LiveInterval::overlapsFrom(llvm::LiveInterval const&, llvm::LiveRange const*) const (LiveInterval.cpp:129) by 0xA5776C: (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*) (RegAllocLinearScan.cpp:1042) by 0xA59F40: (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*) (RegAllocLinearScan.cpp:1175) by 0xA5AE5E: (anonymous namespace)::RALinScan::linearScan() (RegAllocLinearScan.cpp:564) by 0xA5BFC9: (anonymous namespace)::RALinScan::runOnMachineFunction(llvm::MachineFunction&) (RegAllocLinearScan.cpp:490) by 0xCBB68C: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1443) by 0xCBB78A: llvm::FPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1463) by 0xCBB216: llvm::MPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1517) by 0xCBB396: llvm::PassManagerImpl::run(llvm::Module&) (PassManager.cpp:1598) by 0x51A6AF: main (llc.cpp:325) ... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 08:52:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 10:52:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 8049] [PATCH] Add support for mingw gcc 4.5.0 headers In-Reply-To: References: Message-ID: <20100901155226.7B2B92A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8049 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-09-01 10:52:26 CDT --- Thanks, applied in r112710. Please just send patches to cfe-commits in the future. Thanks again! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 10:48:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 12:48:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 8052] New: analyzer asserts with "Do not get the object type of a CodeTextRegion" when analyzing DragonflyBSD Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8052 Summary: analyzer asserts with "Do not get the object type of a CodeTextRegion" when analyzing DragonflyBSD Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: kremenek at apple.com CC: llvmbugs at cs.uiuc.edu This was reported on cfe-dev: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-September/010727.html Here is a delta-reduced test case: $ cat reduced.c typedef unsigned int __uint32_t; typedef unsigned long vm_offset_t; typedef __uint32_t pd_entry_t; typedef unsigned char u_char; typedef unsigned int u_int; typedef unsigned long u_long; extern int bootMP_size; void bootMP(void); static void install_ap_tramp(u_int boot_addr) { int x; int size = *(int *) ((u_long) & bootMP_size); u_char *src = (u_char *) ((u_long) bootMP); u_char *dst = (u_char *) boot_addr + ((vm_offset_t) ((((((((1 << 12) / (sizeof(pd_entry_t))) - 1) - 1) - (260 - 2))) << 22) | ((0) << 12))); for (x = 0; x < size; ++x) *dst++ = *src++; } $ clang --analyze reduced.c Assertion failed: (0 && "Do not get the object type of a CodeTextRegion."), function getValueType, file /Users/kremenek/llvm/tools/clang/include/clang/Checker/PathSensitive/MemRegion.h, line 382. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 12:03:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 14:03:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 8053] New: LLVM JIT code emitter fails to encode the S bit in some instructions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8053 Summary: LLVM JIT code emitter fails to encode the S bit in some instructions Product: new-bugs Version: trunk Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sliao at google.com CC: llvmbugs at cs.uiuc.edu LLVM JIT code emitter fails to encode the S bit in some instructions. According to ARM Architecture Reference Manual, in A8.6.212 SUB (immediate), "If S is present, the instruction updates the flags. Otherwise, the flags are not updated." An isolated, cleaned test case will be provided soon. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 12:30:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 14:30:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 5936] [LLVMPoly] Convert scalar evolution results to linear expression In-Reply-To: References: Message-ID: <20100901193003.5B3A82A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5936 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #9 from Dan Gohman 2010-09-01 14:30:02 CDT --- We can close this PR now. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 13:00:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 15:00:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 8054] New: clang drops volatile from struct on assignment from call Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8054 Summary: clang drops volatile from struct on assignment from call Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: gohman at apple.com CC: llvmbugs at cs.uiuc.edu On this C code: struct T { int i; int j; int k; int l; int m; }; extern volatile struct T t; struct T foo(void); void bar(void) { t = foo(); } clang emits this: call void @foo(%struct.T* sret @t) The volatile qualifier has not been preserved. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 13:36:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 15:36:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 8050] crash in CastSizeChecker when pointee is an incomplete type In-Reply-To: References: Message-ID: <20100901203609.B6E272A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8050 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Ted Kremenek 2010-09-01 15:36:09 CDT --- Fixed: http://llvm.org/viewvc/llvm-project?view=rev&revision=112738 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 14:03:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 16:03:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 944] Unrolling loop creates register pressure In-Reply-To: References: Message-ID: <20100901210316.272452A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=944 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |wendling at apple.com Resolution| |FIXED --- Comment #3 from Bill Wendling 2010-09-01 16:03:15 CDT --- This no longer appears to be a problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 14:58:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 16:58:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 5373] loop-unswitch miscompilation In-Reply-To: References: Message-ID: <20100901215817.36F0E2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5373 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #8 from Dan Gohman 2010-09-01 16:58:16 CDT --- Loop unswitching was not reasoning about infinite loops properly. Fixed in r112745. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 15:13:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 17:13:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8042] loop unswitch fails to preserve lcssa In-Reply-To: References: Message-ID: <20100901221301.D30152A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8042 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Dan Gohman 2010-09-01 17:13:01 CDT --- Apparently the attachment didn't get attached, and I no longer have the testcase. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 15:49:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 17:49:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 8055] New: using declaration not adding template candidates? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8055 Summary: using declaration not adding template candidates? Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com We think this program is valid: struct Base { template static void Foo() {} static void Bar(int) {} }; struct Derived : Base { using Base::Foo; template static void Foo() {} }; void Test2() { Derived::Foo<1>(); } but clang gives the diagnostic: b2944320.cc:12:3: error: no matching function for call to 'Foo' Derived::Foo<1>(); ^~~~~~~~~~~~~~~ b2944320.cc:8:31: note: candidate template ignored: invalid explicitly-specified argument for 1st template parameter template static void Foo() {} ^ 1 error generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 16:01:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 18:01:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 8056] New: missing fixit to add parens to function call Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8056 Summary: missing fixit to add parens to function call Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com For this code: struct Foo { int blah() { return 42; } void foo(int x) {} void bar() { foo(blah); } }; the user deserves a fixit adding the missing () to call blah(). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 16:01:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 18:01:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 8052] analyzer asserts when analyzed code does a byte load from a function's address In-Reply-To: References: Message-ID: <20100901230146.997262A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8052 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Ted Kremenek 2010-09-01 18:01:46 CDT --- Fixed: http://llvm.org/viewvc/llvm-project?view=rev&revision=112761 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 16:29:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 18:29:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 8015] False use of undefined value warning due to not handling "array[symbolic value]" correctly In-Reply-To: References: Message-ID: <20100901232920.C98742A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8015 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Ted Kremenek 2010-09-01 18:29:20 CDT --- (In reply to comment #2) > Created an attachment (id=5423) --> (http://llvm.org/bugs/attachment.cgi?id=5423) [details] > Use UnknownVal for stack-based ElementRegions with non-constant indexes > I've gone ahead and applied this, since I think this is a good working base to suppress the false positive. We then should improve on from there. Patch applied here: http://llvm.org/viewvc/llvm-project?view=rev&revision=112766 In the patch I included a test case showing how this approach *doesn't* do the right thing: +// FIXME: This is a false positive due to not reasoning about symbolic +// array indices correctly. Discussion in PR 8015. +void pr8015_D_FIXME() { + int number = pr8015_A(); + const char *numbers[] = { "zero" }; + if (number == 0) { + if (numbers[number] == numbers[0]) + return; + int *p = 0; + *p = 0xDEADBEEF; // expected-warning{{Dereference of null pointer}} + } +} + Here we actually flag a bogus null dereference warning. I'm going to file a follow-up bug to track this one, and mark this as fixed since the false positive is gone. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 16:31:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 18:31:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 8057] New: (follow-up PR 8015): false null dereference because of inaccurate reasoning of perfectly constrained array indices Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8057 Summary: (follow-up PR 8015): false null dereference because of inaccurate reasoning of perfectly constrained array indices Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: kremenek at apple.com CC: llvmbugs at cs.uiuc.edu >From PR 8015: +// FIXME: This is a false positive due to not reasoning about symbolic +// array indices correctly. Discussion in PR 8015. +void pr8015_D_FIXME() { + int number = pr8015_A(); + const char *numbers[] = { "zero" }; + if (number == 0) { + if (numbers[number] == numbers[0]) + return; + int *p = 0; + *p = 0xDEADBEEF; // expected-warning{{Dereference of null pointer}} + } +} + Here we flag a bogus null dereference because 'numbers[number]' resolves to UnknownVal, and not the region for "zero". -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 17:39:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 19:39:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 8058] New: clang permits invalid &Base::ProtectedNonTemplateMemF Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8058 Summary: clang permits invalid &Base::ProtectedNonTemplateMemF Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5441) --> (http://llvm.org/bugs/attachment.cgi?id=5441) testcase The attached testcase is a cute example showing two invalid address-of operations: F = &Base::TmpF; F = &Base::NonTmpF; where both TmpF and NonTmpF are protected members, but TmpF is a template and NonTmpF is not. Neither is static. They should both be rejected, but clang accepts the &NonTmpF while correctly issuing an error on &TmpF. For amusement, GCC does the opposite. Comeau correctly flags both as wrong. A fixit to correct Base to Derived would be even better. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 18:12:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 20:12:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 7999] Warning about stack returns doesn't account for reference type members In-Reply-To: References: Message-ID: <20100902011231.C41542A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7999 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Ted Kremenek 2010-09-01 20:12:31 CDT --- Looks good to me. Applied: r112792 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 19:28:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 21:28:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 8059] New: Fails to build MC with -Werror Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8059 Summary: Fails to build MC with -Werror Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu [ 43%] Building CXX object lib/MC/CMakeFiles/LLVMMC.dir/WinCOFFObjectWriter.cpp.o cc1plus: warnings being treated as errors /home/ryuta/devel/llvm/src/llvm/lib/MC/WinCOFFObjectWriter.cpp: In member function ‘virtual void::WinCOFFObjectWriter::RecordRelocation(const llvm::MCAssembler&, const llvm::MCAsmLayout&, const llvm::MCFragment*, const llvm::MCFixup&, llvm::MCValue, uint64_t&)’: /home/ryuta/devel/llvm/src/llvm/lib/MC/WinCOFFObjectWriter.cpp:609:3: error: case value ‘131’ not in enumerated type ‘llvm::MCFixupKind’ /home/ryuta/devel/llvm/src/llvm/lib/MC/WinCOFFObjectWriter.cpp:610:3: error: case value ‘132’ not in enumerated type ‘llvm::MCFixupKind’ make[2]: *** [lib/MC/CMakeFiles/LLVMMC.dir/WinCOFFObjectWriter.cpp.o] Error 1 make[1]: *** [lib/MC/CMakeFiles/LLVMMC.dir/all] Error 2 make: *** [all] Error 2 Aborting... Here's how I configured and built: cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr \ -DCMAKE_CXX_FLAGS:STRING="-O2 -march=native -pipe" \ -DCMAKE_C_FLAGS:STRING="-O2 -march=native -pipe" \ -DBUILD_SHARED_LIBS:BOOL=ON \ -DLLVM_BUILD_EXAMPLES:BOOL=OFF \ -DLLVM_BUILD_TOOLS:BOOL=ON \ -DLLVM_ENABLE_THREADS:BOOL=ON \ -DLLVM_ENABLE_PEDANTIC:BOOL=ON \ -DLLVM_ENABLE_WARNINGS:BOOL=ON \ -DLLVM_ENABLE_WERROR:BOOL=ON \ -DLLVM_TARGETS_TO_BUILD:STRING="X86" \ ../$_svnmod -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 1 21:20:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 1 Sep 2010 23:20:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 8059] Fails to build MC with -Werror In-Reply-To: References: Message-ID: <20100902042015.DAB9D2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8059 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Chris Lattner 2010-09-01 23:20:15 CDT --- Please send information about warnings to llvm-commits, along with suggested fixes. Building with -Werror obviously won't work the compiler is producing them :-) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 05:51:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 07:51:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 4701] Definitions of id and Class ignored In-Reply-To: References: Message-ID: <20100902125108.960012A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4701 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from David Chisnall 2010-09-02 07:51:07 CDT --- Fixed ages ago (sometime in the 2.6ish timeframe), but no one got around to closing the bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 05:56:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 07:56:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 6131] clang crashes on assignment of ObjC @protocol() object to runtime structure In-Reply-To: References: Message-ID: <20100902125617.4CFD22A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6131 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from David Chisnall 2010-09-02 07:56:16 CDT --- Not sure when this was fixed, but this construct works now, raising a warning that there is a missing cast. I think that warnings that the results of @encode(), @protocol(), and @selector() expressions are spurious, but this may be an implementation issue (they're all constant with the GNU runtime, at least), rather than a language issue. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 06:24:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 08:24:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 1875] Found a case where llvm-g++ 2.1 (or TOT) produces worse code than 2.0 In-Reply-To: References: Message-ID: <20100902132410.4D8852A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=1875 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #11 from Duncan Sands 2010-09-02 08:24:09 CDT --- The reporter can no longer reproduce the problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 07:04:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 09:04:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 4869] clang x86-32 doesn't implement ABI on FreeBSD In-Reply-To: References: Message-ID: <20100902140450.216802A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4869 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from David Chisnall 2010-09-02 09:04:49 CDT --- Tentatively closing this. I think we've fixed them now. ABITest is full of GNUisms, so doesn't work out of the box on FreeBSD, but tweaking it so that it does at least run doesn't seem to give anything that looks like a failure (although, impressively, it did cause sh to consume all of my RAM and swap space before dying). Perhaps if it were not totally undocumented, it might be more use... I've not come across any issues with FreeBSD ABI compatibility mixing gcc and clang code for quite a while, so I'm closing this unless someone can point to some specific failures. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 08:28:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 10:28:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 8060] New: JumpThreading miscompilation on whole-program SPEC CINT2000 v1.3 255.vortex Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8060 Summary: JumpThreading miscompilation on whole-program SPEC CINT2000 v1.3 255.vortex Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: luked at cs.rochester.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5443) --> (http://llvm.org/bugs/attachment.cgi?id=5443) the tooptimize half of the bugpoint reduction I'm using the LTO/gold infrastructure with cvs binutils and llvm/llvm-gcc-4.2 from svn. I use -O4 -m32 to compile all of the object files into bitcode, and then link with -use-gold-plugin. The resulting executable fails to work. I can avoid the problem either by compiling bitvec.c with -O3 -m32 or suppressing jump-threading during the link phase. I've done a bugpoint reduction of the miscompilation. I've done a bugpoint reduction using the standard LTO passes which also pinpoints jump-threading as the problem. $bugpoint -llc-safe -preverify -domtree -verify -internalize -ipsccp -globalopt -constmerge -deadargelim -instcombine -basiccg -inline -prune-eh -globalopt -globaldce -basiccg -argpromotion -instcombine -lazy-value-info -jump-threading -domtree -domfrontier -scalarrepl -basiccg -functionattrs -globalsmodref-aa -domtree -loops -loopsimplify -licm -memdep -gvn -memdep -memcpyopt -dse -instcombine -lazy-value-info -jump-threading -simplifycfg -globaldce -preverify -domtree -verify 255.vortex.bc -args lendian1.raw -output=vortex1.out -enable-valgrind Read input file : '255.vortex.bc' *** All input ok Running selected passes on program to test for crash: Success! Initializing execution environment: Found gcc: /usr/bin/gcc Running the code generator to test for a crash: Generating reference output from raw program: Reference output is: bugpoint.reference.out *** Checking the code generator... *** Output matches: Debugging miscompilation! Checking to see if '' compiles correctly: yup. Checking to see if '-preverify -domtree -verify -internalize -ipsccp -globalopt -constmerge -deadargelim -instcombine -basiccg -inline -prune-eh -globalopt -globaldce -basiccg -argpromotion -instcombine -lazy-value-info -jump-threading -domtree -domfrontier -scalarrepl -basiccg -functionattrs -globalsmodref-aa -domtree -loops -loopsimplify -licm -memdep -gvn -memdep -memcpyopt -dse -instcombine -lazy-value-info -jump-threading -simplifycfg -globaldce -preverify -domtree -verify' compiles correctly: nope. Checking to see if '-scalarrepl -basiccg -functionattrs -globalsmodref-aa -domtree -loops -loopsimplify -licm -memdep -gvn -memdep -memcpyopt -dse -instcombine -lazy-value-info -jump-threading -simplifycfg -globaldce -preverify -domtree -verify' compiles correctly: yup. Checking to see if '-preverify -domtree -verify -internalize -ipsccp -globalopt -constmerge -deadargelim -instcombine -basiccg -inline -prune-eh -globalopt -globaldce -basiccg -argpromotion -instcombine -lazy-value-info -jump-threading -domtree -domfrontier' compiles correctly: nope. Checking to see if '-inline -prune-eh -globalopt -globaldce -basiccg -argpromotion -instcombine -lazy-value-info -jump-threading -domtree -domfrontier' compiles correctly: nope. Checking to see if '-argpromotion -instcombine -lazy-value-info -jump-threading -domtree -domfrontier' compiles correctly: yup. Checking to see if '-inline -prune-eh -globalopt -globaldce -basiccg' compiles correctly: yup. Checking to see if '-argpromotion -instcombine -lazy-value-info -jump-threading -domtree -domfrontier' passes compile correctly after the '-inline -prune-eh -globalopt -globaldce -basiccg' passes: nope. Checking to see if '-jump-threading -domtree -domfrontier' compiles correctly: yup. Checking to see if '-argpromotion -instcombine -lazy-value-info' compiles correctly: yup. Checking to see if '-jump-threading -domtree -domfrontier' passes compile correctly after the '-argpromotion -instcombine -lazy-value-info' passes: nope. Checking to see if '-domtree -domfrontier' compiles correctly: yup. Checking to see if '-jump-threading' compiles correctly: nope. *** Found miscompiling pass: -jump-threading I've attached to tooptimize half of the reduction. The SPEC input is 3.2 megs (and presumably copyrighted by SPEC), and the tonotoptimize half of the reduction is 1.1 megs (I'm also worried about the copyright here, given that with tooptimize and tonotoptimize together you can generate the vortex binary for my configuration). Someone familiar with jump threading, and with access to the SPEC CINT2000 v1.3 source, could probably trace jump threading during LTO with bitvec.o (a small, 2 function object) to detect the bug more quickly than optimizing the 70k tooptimize half alone. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 09:31:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 11:31:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 8061] New: xchgl/in/out instructions unknown to MC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8061 Summary: xchgl/in/out instructions unknown to MC Product: libraries Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu pes ~/mc-elf$ cat xchgl.s xchgl 368(%rax),%ecx outb 123, %al inb %al, 123 pes ~/mc-elf$ llvm-mc xchgl.s .section __TEXT,__text,regular,pure_instructions xchgl.s:1:2: error: unrecognized instruction xchgl 368(%rax),%ecx ^ xchgl.s:3:2: error: unrecognized instruction outb 123, %al ^ xchgl.s:5:2: error: unrecognized instruction inb %al, 123 ^ MC does not know about these instructions although they all seem to be defined in X86GenAsmMatcher.inc -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 09:36:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 11:36:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 6633] Crash with break in statement expression in for loop In-Reply-To: References: Message-ID: <20100902163636.DD7C42A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6633 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Ted Kremenek 2010-09-02 11:36:36 CDT --- This was fixed in r 104375. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 09:55:24 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 11:55:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 6656] indirect goto: emitting reference to label that is not emitted In-Reply-To: References: Message-ID: <20100902165524.676AF2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6656 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2010-09-02 11:55:24 CDT --- Yep, looks fixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 11:21:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 13:21:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 8062] New: 28 tests failing on Linux x86 64 bit system (Ubuntu) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8062 Summary: 28 tests failing on Linux x86 64 bit system (Ubuntu) Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5444) --> (http://llvm.org/bugs/attachment.cgi?id=5444) full test output The full output from running make in the llvm/test directory on a Linux x86 64-bit system is attached. This is the summary: Failing Tests (28): LLVM :: FrontendC++/2009-04-21-DtorNames-dbg.cpp LLVM :: FrontendC++/2010-03-22-empty-baseclass.cpp LLVM :: FrontendC++/2010-04-30-OptimizedMethod-Dbg.cpp LLVM :: FrontendC++/2010-05-11-alwaysinlineinstantiation.cpp LLVM :: FrontendC++/2010-06-22-BitfieldInit.cpp LLVM :: FrontendC++/2010-06-22-ZeroBitfield.cpp LLVM :: FrontendC++/thunk-linkonce-odr.cpp LLVM :: FrontendC/2007-04-11-InlineStorageClassC89.c LLVM :: FrontendC/2007-04-11-InlineStorageClassC99.c LLVM :: FrontendC/2010-05-14-Optimized-VarType.c LLVM :: FrontendC/2010-05-18-asmsched.c LLVM :: FrontendC/2010-05-18-palignr.c LLVM :: FrontendC/2010-05-26-AsmSideEffect.c LLVM :: FrontendC/2010-06-11-SaveExpr.c LLVM :: FrontendC/2010-06-17-asmcrash.c LLVM :: FrontendC/2010-06-28-DbgLocalVar.c LLVM :: FrontendC/2010-07-08-DeclDebugLineNo.c LLVM :: FrontendC/2010-07-14-ref-off-end.c LLVM :: FrontendC/2010-07-27-MinNoFoldConst.c LLVM :: FrontendC/asm-reg-var-local.c LLVM :: FrontendC/crash-invalid-array.c LLVM :: FrontendC/inline-asm-function.c LLVM :: FrontendC/pr2394.c LLVM :: FrontendC/vla-1.c LLVM :: FrontendC/vla-2.c LLVM :: FrontendFortran/2008-11-03-OptionOverride.f90 LLVM :: FrontendFortran/2009-02-09-FloorDivExpr.f90 LLVM :: FrontendFortran/cpow.f90 Expected Passes : 5374 Expected Failures : 38 Unsupported Tests : 66 Unexpected Failures: 28 A couple of weeks ago, there were no unexpected failures. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 13:31:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 15:31:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 8064] New: In FixIt code, valgrind reports "Conditional jump or move depends on uninitialised value" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8064 Summary: In FixIt code, valgrind reports "Conditional jump or move depends on uninitialised value" Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Valgrind noticed a problem in clang when clang processes the existing clang test test/FixIt/fixit-errors.c $ valgrind clang -cc1 -pedantic -verify -fixit -x c fixit-errors.c ==5038== Memcheck, a memory error detector ==5038== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==5038== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==5038== Command: clang -cc1 -pedantic -verify -fixit -x c fixit-errors.c ==5038== 2 errors generated. ==5038== Conditional jump or move depends on uninitialised value(s) ==5038== at 0x64EE21: clang::VerifyDiagnosticsClient::CheckDiagnostics() (VerifyDiagnosticsClient.cpp:491) ==5038== by 0x650178: clang::VerifyDiagnosticsClient::HadErrors() (VerifyDiagnosticsClient.cpp:63) ==5038== by 0x62A75B: clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (CompilerInstance.cpp:557) ==5038== by 0x60A7AB: clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (ExecuteCompilerInvocation.cpp:148) ==5038== by 0x6027ED: cc1_main(char const**, char const**, char const*, void*) (cc1_main.cpp:160) ==5038== by 0x609294: main (driver.cpp:268) ... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 14:19:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 16:19:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 7833] [dagcombine] possible integer wrong code bug on x64 In-Reply-To: References: Message-ID: <20100902211904.F36192A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7833 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Dan Gohman 2010-09-02 16:19:04 CDT --- Fixed in r112861. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 14:40:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 16:40:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 8062] 28 tests failing on Linux x86 64 bit system (Ubuntu) In-Reply-To: References: Message-ID: <20100902214057.C3F132A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8062 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Chris Lattner 2010-09-02 16:40:57 CDT --- Your llvm-gcc probably needs to be updated. Note that these are all the new tests since march. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 15:19:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 17:19:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 8041] licm miscompile - wrongly thinks value is loop invariant In-Reply-To: References: Message-ID: <20100902221930.E4CA22A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8041 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Chris Lattner 2010-09-02 17:19:30 CDT --- Fixed in r112878, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 15:41:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 17:41:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 8065] New: false positive warning due to template meta-programming Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8065 Summary: false positive warning due to template meta-programming Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5446) --> (http://llvm.org/bugs/attachment.cgi?id=5446) testcase I'm getting the warning "conversion function converting ... to itself will never be used" in a case where our class has a conversion function to template parameter T which happens to be itself in this case but not in others. The warning should be suppressed when that happens. nlewycky at ducttape:~$ g++ -Wall -pedantic -fsyntax-only b2971306.cc nlewycky at ducttape:~$ clang++ -Wall -pedantic -fsyntax-only b2971306.cc b2971306.cc:12:3: warning: conversion function converting 'Container' to itself will never be used operator X(void) { return X(); } ^ b2971306.cc:15:16: note: in instantiation of template class 'Container' requested here Container test; ^ 1 warning generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 17:19:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 19:19:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 8060] JumpThreading miscompilation on whole-program SPEC CINT2000 v1.3 255.vortex In-Reply-To: References: Message-ID: <20100903001943.66E372A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8060 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 20:30:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 22:30:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 6892] X86 test failures on Cygwin 1.7 In-Reply-To: References: Message-ID: <20100903033044.43D132A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6892 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from NAKAMURA Takumi 2010-09-02 22:30:43 CDT --- Fixed in r112801, r112802 and r112947, thank you. I have confirmed on Cygwin-1.5 and Cygwin-1.7. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 20:59:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 22:59:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 8066] New: llvm+checking assert (S == TransformForPostIncUse(Denormalize, Result, User, OperandValToReplace, Loops, SE, DT) && "SCEV normalization is not invertible!") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8066 Summary: llvm+checking assert (S == TransformForPostIncUse(Denormalize, Result, User, OperandValToReplace, Loops, SE, DT) && "SCEV normalization is not invertible!") Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: astrange at ithinksw.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5447) --> (http://llvm.org/bugs/attachment.cgi?id=5447) preprocessed/unreduced source Using recent clang trunk with checking/assertions (whatever XDEBUG is) on x86-64-apple-darwin10. > /usr/local/llvm/bin/clang -O -S h264.i In file included from libavcodec/h264.c:1: libavcodec/h264.c:2333:23: warning: incompatible pointer types initializing 'int (*)[64]' with an expression of type 'int *' ...ref2frm)[64] = h->ref2frm[ h->slice_num&(16 -1) ][0] + (h->mb_mbaff ? 20 : 2)... ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libavcodec/h264.c:2410:23: warning: incompatible pointer types initializing 'int (*)[64]' with an expression of type 'int *' ...ref2frm)[64] = h->ref2frm[ h->slice_table[top_xy]&(16 -1) ][0] + (h->mb_mbaff ? 20 : 2)... ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libavcodec/h264.c:2425:27: warning: incompatible pointer types initializing 'int (*)[64]' with an expression of type 'int *' ...ref2frm)[64] = h->ref2frm[ h->slice_table[left_xy[0]]&(16 -1) ][0] + (h->mb_mbaff ? 20 : 2)... ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Assertion failed: (S == TransformForPostIncUse(Denormalize, Result, User, OperandValToReplace, Loops, SE, DT) && "SCEV normalization is not invertible!"), function TransformForPostIncUse, file /Users/astrange/Projects/src/llvm/lib/Analysis/ScalarEvolutionNormalization.cpp, line 115. 0 clang 0x00000001023e9092 PrintStackTrace(void*) + 34 1 clang 0x00000001023ec43a SignalHandler(int) + 3818 2 libSystem.B.dylib 0x00007fff803fc35a _sigtramp + 26 3 libSystem.B.dylib 0x0000000103e4a560 _sigtramp + 2208621088 4 clang 0x000000010002d802 __assert_rtn + 66 5 clang 0x000000010204b0f9 llvm::TransformForPostIncUse(llvm::TransformKind, llvm::SCEV const*, llvm::Instruction*, llvm::Value*, llvm::SmallPtrSet&, llvm::ScalarEvolution&, llvm::DominatorTree&) + 4521 6 clang 0x0000000101f0ae1e llvm::IVUsers::AddUser(llvm::Instruction*, llvm::Value*) + 350 7 clang 0x0000000101f0e4c2 llvm::IVUsers::AddUsersIfInteresting(llvm::Instruction*) + 562 8 clang 0x0000000101f0fe8b llvm::IVUsers::runOnLoop(llvm::Loop*, llvm::LPPassManager&) + 1179 9 clang 0x0000000101f708c7 llvm::LPPassManager::runOnFunction(llvm::Function&) + 6823 10 clang 0x00000001021fdb70 llvm::FPPassManager::runOnFunction(llvm::Function&) + 640 11 clang 0x00000001021fdd62 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 146 12 clang 0x00000001021fe0fc llvm::FunctionPassManager::run(llvm::Function&) + 236 13 clang 0x00000001002ca145 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1381 14 clang 0x000000010043e8be (anonymous namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 286 15 clang 0x000000010049b1fe clang::ParseAST(clang::Sema&, bool) + 286 16 clang 0x000000010043f4cc clang::CodeGenAction::ExecuteAction() + 60 17 clang 0x00000001000bbcf1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 3473 18 clang 0x000000010004744a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2762 19 clang 0x000000010002fb63 cc1_main(char const**, char const**, char const*, void*) + 627 20 clang 0x000000010003befe main + 6686 21 clang 0x000000010002dbd8 start + 52 22 clang 0x0000000000000022 start + 4294780030 Stack dump: 0. Program arguments: /usr/local/llvm/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name h264.i -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.14 -resource-dir /usr/local/llvm/lib/clang/2.8 -O2 -ferror-limit 19 -fmessage-length 79 -stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -o h264.s -x cpp-output h264.i 1. parser at end of file 2. Code generation 3. Running pass 'Loop Pass Manager' on function '@decode_frame' 4. Running pass 'Induction Variable Users' on basic block '%for.cond421' clang: error: clang frontend command failed due to signal 4 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 21:42:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 23:42:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 8067] New: Assertion `!cast(Use)->isVolatile() && Use->getOperand(0) != ASIV && "AST broken"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8067 Summary: Assertion `!cast(Use)->isVolatile() && Use->getOperand(0) != ASIV && "AST broken"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu [regehr at gamow tmp424]$ clang -v clang version 2.8 (trunk 112720) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp424]$ cat small.c typedef int int32_t; typedef unsigned char uint8_t; int32_t g_8; uint161 (void) { int32_t *l_9[5][8]; int i, j; l_9[i][j] = 0; uint8_t l_15; for (0; 1; g_8 += 1) l_9[g_8][l_15] = &g_8; } [regehr at gamow tmp424]$ clang -O1 small.c small.c:4:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] uint161 (void) ^ small.c:10:8: warning: expression result unused [-Wunused-value] for (0; 1; g_8 += 1) ^ clang: LICM.cpp:701: void::LICM::PromoteAliasSet(llvm::AliasSet&): Assertion `!cast(Use)->isVolatile() && Use->getOperand(0) != ASIV && "AST broken"' failed. 0 clang 0x000000000166ebff 1 clang 0x0000000001670e72 2 libpthread.so.0 0x00007f59adbdb190 3 libc.so.6 0x00007f59acee04b5 gsignal + 53 4 libc.so.6 0x00007f59acee3f50 abort + 384 5 libc.so.6 0x00007f59aced9481 __assert_fail + 241 6 clang 0x00000000013a6bad 7 clang 0x00000000013a7bab 8 clang 0x00000000014ca2c4 llvm::LPPassManager::runOnFunction(llvm::Function&) + 1060 9 clang 0x00000000015b4aed llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 10 clang 0x000000000149810b 11 clang 0x0000000001498865 12 clang 0x00000000015b4684 llvm::MPPassManager::runOnModule(llvm::Module&) + 500 13 clang 0x00000000015b47f7 llvm::PassManagerImpl::run(llvm::Module&) + 167 14 clang 0x00000000007c7917 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1623 15 clang 0x00000000007c3a2b 16 clang 0x00000000008e0593 clang::ParseAST(clang::Sema&, bool) + 291 17 clang 0x00000000007c4a14 clang::CodeGenAction::ExecuteAction() + 68 18 clang 0x00000000006d2ebd clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 349 19 clang 0x00000000006b152c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1292 20 clang 0x00000000006a9363 cc1_main(char const**, char const**, char const*, void*) + 467 21 clang 0x00000000006b0125 main + 4133 22 libc.so.6 0x00007f59acecbabd __libc_start_main + 253 23 clang 0x00000000006a7ce9 Stack dump: 0. Program arguments: /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r112720-install/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20 -resource-dir /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r112720-install/lib/clang/2.8 -O1 -ferror-limit 19 -fmessage-length 95 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-38CgRv.s -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Loop Pass Manager' on function '@uint161' 5. Running pass 'Loop Invariant Code Motion' on basic block '%for.body' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 21:46:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 2 Sep 2010 23:46:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 8068] New: Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8068 Summary: Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu [regehr at gamow tmp425]$ clang -v clang version 2.8 (trunk 112720) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp425]$ cat small.c typedef short int int16_t; typedef int int32_t; typedef unsigned char uint8_t; static int16_t safe_add_func_int32_t_s_s (int32_t si1, int16_t si2) { return si1 > 0 && si2 > 0 && si1 > -si2 || si1 < 0 && si2 < 0 && si1 < -si2 ? : si1 + si2; } uint8_t g_12; int16_t *g_74[4][4][5] = { }; int16_t **g_76[6] = { &g_74[0][3][3], &g_74[0][3][3], &g_74[0][3][3], &g_74[0][3][3], &g_74[0][3][3], &g_74[0][3][3] }; int16_t ***volatile g_75 = &g_76[0]; int16_t func_40 (int32_t * const p_41) { } int326 (int32_t *** p_107, int16_t *** p_108, int16_t p_109, int16_t p_110) { for (g_12 = 1; g_12; g_12 = safe_add_func_int32_t_s_s (g_12, 0)) { for (g_12 = 0;; 1) break; if (func_40 (**g_75)) { } } } [regehr at gamow tmp425]$ clang -O2 -c small.c -w While deleting: i8 %tmp6 Use still stuck around after Def is destroyed: store i8 %tmp6, i8* @g_12 clang: Value.cpp:75: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed. 0 clang 0x000000000166ebff 1 clang 0x0000000001670e72 2 libpthread.so.0 0x00007fc545521190 3 libc.so.6 0x00007fc5448264b5 gsignal + 53 4 libc.so.6 0x00007fc544829f50 abort + 384 5 libc.so.6 0x00007fc54481f481 __assert_fail + 241 6 clang 0x00000000015cbb83 llvm::Value::~Value() + 995 7 clang 0x0000000001596387 llvm::LoadInst::~LoadInst() + 23 8 clang 0x00000000013a731c 9 clang 0x00000000013a7bab 10 clang 0x00000000014ca2c4 llvm::LPPassManager::runOnFunction(llvm::Function&) + 1060 11 clang 0x00000000015b4aed llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 12 clang 0x000000000149810b 13 clang 0x0000000001498865 14 clang 0x00000000015b4684 llvm::MPPassManager::runOnModule(llvm::Module&) + 500 15 clang 0x00000000015b47f7 llvm::PassManagerImpl::run(llvm::Module&) + 167 16 clang 0x00000000007c7917 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1623 17 clang 0x00000000007c3a2b 18 clang 0x00000000008e0593 clang::ParseAST(clang::Sema&, bool) + 291 19 clang 0x00000000007c4a14 clang::CodeGenAction::ExecuteAction() + 68 20 clang 0x00000000006d2ebd clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 349 21 clang 0x00000000006b152c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1292 22 clang 0x00000000006a9363 cc1_main(char const**, char const**, char const*, void*) + 467 23 clang 0x00000000006b0125 main + 4133 24 libc.so.6 0x00007fc544811abd __libc_start_main + 253 25 clang 0x00000000006a7ce9 Stack dump: 0. Program arguments: /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r112720-install/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20 -resource-dir /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r112720-install/lib/clang/2.8 -O2 -w -ferror-limit 19 -fmessage-length 95 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-L6xohy.s -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Loop Pass Manager' on function '@int326' 5. Running pass 'Loop Invariant Code Motion' on basic block '%for.body' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) [regehr at gamow tmp425]$ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 2 22:02:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 00:02:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 8069] New: llvm+checking never finishes compiling Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8069 Summary: llvm+checking never finishes compiling Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: astrange at ithinksw.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5448) --> (http://llvm.org/bugs/attachment.cgi?id=5448) preprocessed source Attached file didn't stop compiling after 20 minutes with x86-64-apple-darwin10 + llvm/clang trunk with checking enabled and: > /usr/local/llvm/bin/clang -O3 -Xclang -ftime-report -c fft.i Seems to be caused by the inliner causing the size of fft65536() to explode. llvm::SmallPtrSetImpl::FindBucketFor () at /Users/astrange/Projects/src/llvm/lib/Support/SmallPtrSet.cpp:122 122 Bucket = (Bucket + ProbeAmt++) & (ArraySize-1); (gdb) bt #0 llvm::SmallPtrSetImpl::FindBucketFor () at /Users/astrange/Projects/src/llvm/lib/Support/SmallPtrSet.cpp:122 #1 0x000000010235e220 in llvm::SmallPtrSetImpl::insert_imp (this=0x7fff5fbf8a00, Ptr=0x104376010) at /Users/astrange/Projects/src/llvm/lib/Support/SmallPtrSet.cpp:61 #2 0x00000001015653cb in llvm::SmallPtrSet::erase () at /Users/astrange/Projects/src/llvm/include/llvm/ADT/SmallPtrSet.h:6457 #3 0x00000001015653cb in checkForCyclesHelper (N=0x1044f6010, Visited=@0x7fff5fbf8b30, Checked=@0x7fff5fbf8a00) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:61 … #3570 0x00000001015653b8 in checkForCyclesHelper (N=0x104664a10, Visited=@0x7fff5fbf8b30, Checked=@0x7fff5fbf8a00) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:61 #3571 0x00000001015653b8 in checkForCyclesHelper (N=0x104664b10, Visited=@0x7fff5fbf8b30, Checked=@0x7fff5fbf8a00) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:61 #3572 0x00000001015653b8 in checkForCyclesHelper (N=0x104664c10, Visited=@0x7fff5fbf8b30, Checked=@0x7fff5fbf8a00) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:61 #3573 0x00000001015653b8 in checkForCyclesHelper (N=0x104664d10, Visited=@0x7fff5fbf8b30, Checked=@0x7fff5fbf8a00) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:61 #3574 0x0000000101565501 in ~SmallPtrSet [inlined] () at /Users/astrange/Projects/src/llvm/include/llvm/ADT/SmallPtrSet.h:6467 #3575 0x0000000101565501 in llvm::checkForCycles (N=0x104664d10) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:61 #3576 0x0000000100ef4d88 in llvm::SelectionDAG::setRoot (this=0x103ec7f20, N={Node = 0x104664d10, ResNo = 0}) at SelectionDAG.h:61 #3577 0x00000001015df94f in llvm::SelectionDAGBuilder::LowerCallTo (this=0x103ec8930, CS=, Callee={Node = 0x1041ba710, ResNo = 0}, isTailCall=false, LandingPad=0x0) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:61 #3578 0x00000001015eee4a in llvm::SelectionDAGBuilder::visitCall (this=0x103ec8930, I=@0x103e43232) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:61 #3579 0x00000001015d241d in llvm::SelectionDAGBuilder::visit (this=0x103ec8930, Opcode=, I=@0x103e43230) at Instruction.def:61 #3580 0x0000000101606f83 in llvm::SelectionDAGBuilder::visit (this=0x103ec8930, I=@0x103e43230) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:61 #3581 0x0000000101658788 in llvm::ilist_nextprev_traits::getNext () at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:356 #3582 llvm::ilist_node::getNext () at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:217 #3583 llvm::ilist_iterator::operator++ () at /Users/astrange/Projects/src/llvm/include/llvm/ADT/ilist_node.h:58 #3584 0x0000000101658788 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x103ec7a20, Begin=, End={> = {}, NodePtr = 0x103e31ad0}, HadTailCall=@0x7fff5fbf959e) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:61 #3585 0x0000000101661690 in llvm::SelectionDAGISel::SelectAllBasicBlocks (this=0x103ec7a20, Fn=) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:61 #3586 0x0000000101661da4 in llvm::SelectionDAGISel::runOnMachineFunction (this=0x103ec7a20, mf=@0x104a49d70) at /Users/astrange/Projects/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:61 #3587 0x0000000101926ec3 in llvm::MachineFunctionPass::runOnFunction (this=0x103ec7a20, F=) at /Users/astrange/Projects/src/llvm/lib/CodeGen/MachineFunctionPass.cpp:61 #3588 0x00000001021fdae4 in llvm::FPPassManager::runOnFunction (this=0x103ebf440, F=@0x103e31ee0) at /Users/astrange/Projects/src/llvm/lib/VMCore/PassManager.cpp:61 #3589 0x00000001021fdd62 in llvm::FunctionPassManagerImpl::run (this=0x103ebf100, F=@0x103e31ee0) at /Users/astrange/Projects/src/llvm/lib/VMCore/PassManager.cpp:61 #3590 0x00000001021fe0fc in llvm::FunctionPassManager::run (this=0x103ec02e0, F=@0x103e31ee0) at /Users/astrange/Projects/src/llvm/lib/VMCore/PassManager.cpp:61 #3591 0x00000001002ca145 in clang::EmitBackendOutput (Diags=, CGOpts=, TOpts=, M=, Action=, OS=) at /Users/astrange/Projects/src/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:61 #3592 0x000000010043e8be in (anonymous namespace)::BackendConsumer::HandleTranslationUnit (this=0x103e17840, C=) at /Users/astrange/Projects/src/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:61 #3593 0x000000010049b1fe in clang::ParseAST (S=@0x10402d200, PrintStats=false) at /Users/astrange/Projects/src/llvm/tools/clang/lib/Parse/ParseAST.cpp:61 #3594 0x000000010043f4cc in clang::CodeGenAction::ExecuteAction (this=0x103e12680) at /Users/astrange/Projects/src/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:61 #3595 0x00000001000fb5cf in ~TimeRegion [inlined] () at /Users/astrange/Projects/src/llvm/include/llvm/Support/Timer.h:182 #3596 0x00000001000fb5cf in clang::FrontendAction::Execute (this=0x103e12680) at /Users/astrange/Projects/src/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:61 #3597 0x00000001000bbcf1 in clang::CompilerInstance::ExecuteAction (this=0x103e112b0, Act=@0x103e12680) at /Users/astrange/Projects/src/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:61 #3598 0x000000010004744a in clang::ExecuteCompilerInvocation (Clang=0x103e112b0) at /Users/astrange/Projects/src/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:61 #3599 0x000000010002fb63 in cc1_main (ArgBegin=0x7fff5fbfd608, ArgEnd=0x21, Argv0=0x103e10688 "/usr/local/llvm/bin/clang", MainAddr=0x100036710) at /Users/astrange/Projects/src/llvm/tools/clang/tools/driver/cc1_main.cpp:61 #3600 0x000000010003befe in main (argc_=35, argv_=0x7fff5fbfe8f0) at /Users/astrange/Projects/src/llvm/tools/clang/tools/driver/driver.cpp:61 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 00:03:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 02:03:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8070] New: shellinabox does not compile under scan-build Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8070 Summary: shellinabox does not compile under scan-build Product: clang Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: tcare at apple.com CC: llvmbugs at cs.uiuc.edu, tcare at apple.com The open source project Shell in a Box compiles successfully on Linux, but fails using the same commands under scan-build. The build fails regardless of compiler. With scan-build: In file included from httpconnection.c:50: /usr/include/math.h:261:1: warning: this is the location of the previous definition httpconnection.c:212: error: conflicting types for ‘strcasestr’ /usr/include/string.h:371: note: previous declaration of ‘strcasestr’ was here make[2]: *** [httpconnection.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 03:41:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 05:41:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 8071] New: Lookup of dependent function name declared in instantiation context fails Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8071 Summary: Lookup of dependent function name declared in instantiation context fails Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hans at chromium.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code fails to compile with Clang built from trunk r112953: namespace ns { template void function_template(const T &val) { foo(val); } } void foo(int x) { } void test() { ns::function_template(42); } clang++ -c /tmp/a.cc /tmp/a.cc:4:5: error: use of undeclared identifier 'foo' foo(val); ^ /tmp/a.cc:11:3: note: in instantiation of function template specialization 'ns::function_template' requested here ns::function_template(42); ^ 1 error generated. This compiles with GCC. I'm not a standards expert, but since foo is a type-dependent name, shouldn't it be looked up in the context of the template instantiation, or something to that effect? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 03:55:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 05:55:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 8071] Lookup of dependent function name declared in instantiation context fails In-Reply-To: References: Message-ID: <20100903105520.9D48D2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8071 hans at chromium.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from hans at chromium.org 2010-09-03 05:55:20 CDT --- Sorry, just found http://clang.llvm.org/compatibility.html#dep_lookup Marking invalid. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 08:15:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 10:15:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 7234] linking fails when compiling with -O4 In-Reply-To: References: Message-ID: <20100903151519.E49352A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7234 Toralf Niebuhr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #7 from Toralf Niebuhr 2010-09-03 10:15:19 CDT --- This is an ld64 bug filed under apple bug ID: # 8212744 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 08:17:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 10:17:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 8072] New: clang passes aliasing storage to sret argument on x86-64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8072 Summary: clang passes aliasing storage to sret argument on x86-64 Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: gohman at apple.com CC: llvmbugs at cs.uiuc.edu As discussed in PR6525, the x86-64 ABI now explicitly requires sret arguments to point to non-aliased memory. GCC and llvm-gcc do this, but clang does not. Here is a small C testcase which demonstrates the problem: struct A { long i0; long i1; long i2; }; extern struct A global; struct A call(struct A *p); void foo(void) { global = call(&global); } Clang emits this LLVM IR: tail call void @call(%struct.A* sret @global, %struct.A* @global) nounwind The sret argument here is clearly aliased. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 09:25:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 11:25:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7268] Convoluted code-generation bug leading to segfault In-Reply-To: References: Message-ID: <20100903162514.6EEF72A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7268 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |gohman at apple.com Resolution| |FIXED --- Comment #1 from Dan Gohman 2010-09-03 11:25:13 CDT --- I see the crash on x86-64 Lucid with r105219 but not ToT. Please re-open if this continues to be a problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 09:47:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 11:47:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 8031] clang include path on Linux is not found In-Reply-To: References: Message-ID: <20100903164728.D57DE2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8031 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2010-09-03 11:47:28 CDT --- Patch applied in r112970, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 09:55:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 11:55:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 2581] jump threading: Useless select not removed In-Reply-To: References: Message-ID: <20100903165542.D51FB2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2581 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #23 from Owen Anderson 2010-09-03 11:55:41 CDT --- Fixed by CorrelatedValuePropagation. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 09:58:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 11:58:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 4420] Missed const propagation from condition of branch to phi node at landing In-Reply-To: References: Message-ID: <20100903165803.2FE592A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4420 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |resistor at mac.com Resolution| |FIXED --- Comment #1 from Owen Anderson 2010-09-03 11:58:02 CDT --- Fixed by CorrelatedValuePropagation. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 09:59:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 11:59:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 8073] New: clang segfault with certain pointer declaration. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8073 Summary: clang segfault with certain pointer declaration. Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nbowler at draconx.ca CC: llvmbugs at cs.uiuc.edu Compiling the following program causes clang to instantly segfault: int main(void) { static void *x = &x; return 0; } Spewing the following to the console: 0 clang 0x0000000001071b3f 1 clang 0x000000000107218c 2 libpthread.so.0 0x00007f6c70508010 3 clang 0x0000000000f7cfeb 4 clang 0x0000000000f7d31f 5 clang 0x0000000000cf8144 6 clang 0x0000000000cf1f2f 7 clang 0x00000000010011e8 8 clang 0x000000000100125a 9 clang 0x000000000041b252 10 clang 0x00000000005e8424 11 clang 0x000000000041e257 12 clang 0x000000000041174a 13 clang 0x0000000000414a33 main + 1731 14 libc.so.6 0x00007f6c6f813bbd __libc_start_main + 253 15 clang 0x000000000040fc79 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/lib/clang/1.1 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Mmqfg7.s -x c test.c 1. parser at end of file 2. Code generation clang: error: compiler command failed due to signal 11 (use -v to see invocation) Moving the declaration of x to file scope or removing the 'static' storage-class specifier allows the program to compile successfully. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 10:00:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 12:00:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 4413] Missed optimization in select on correlated phi nodes In-Reply-To: References: Message-ID: <20100903170010.96DD12A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4413 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |resistor at mac.com Resolution| |FIXED --- Comment #1 from Owen Anderson 2010-09-03 12:00:10 CDT --- Fixed with CorrelatedValuePropagation. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 10:17:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 12:17:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 2259] LLVM installs tblgen man page In-Reply-To: References: Message-ID: <20100903171754.030FD2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2259 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Dan Gohman 2010-09-03 12:17:53 CDT --- LLVM now installs a tblgen command. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 11:37:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 13:37:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 8044] clang miscompiles inline asm (uses ecx for two different things) In-Reply-To: References: Message-ID: <20100903183745.D50162A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8044 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Jakob Stoklund Olesen 2010-09-03 13:37:45 CDT --- Fixed in r112988. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 11:59:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 13:59:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 8073] clang segfault with certain pointer declaration. In-Reply-To: References: Message-ID: <20100903185921.2A6652A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8073 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from John McCall 2010-09-03 13:59:20 CDT --- Fixed in r112992. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 12:09:18 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 14:09:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 4855] Missed optimization on pointer known equal to a constant global In-Reply-To: References: Message-ID: <20100903190918.04FEB2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4855 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 12:58:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 14:58:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 8074] New: Attr.td derived sources not rebuilt Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8074 Summary: Attr.td derived sources not rebuilt Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: holm at liacs.nl CC: llvmbugs at cs.uiuc.edu When using the CMake generated makefiles (and also VS 2008 projects) to build clang, the derived sources from Attr.td (AttrImpl.inc and Attrs.inc (plus maybe more)) are not rebuild when Attr.td changes. This is obviously not desirable. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 13:20:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 15:20:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 8075] New: False positive with -Wuninitialized when accessing *static* class members Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8075 Summary: False positive with -Wuninitialized when accessing *static* class members Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Keywords: quality-of-implementation Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com % cat t4.cc struct S1 { enum { FOO = 42 }; static const int bar = 42; static int baz(); S1(int); }; const int S1::bar; struct S2 { S1 s1; S2() : s1(s1.FOO) {} }; struct S3 { S1 s1; S3() : s1(s1.bar) {} }; struct S4 { S1 s1; S4() : s1(s1.baz()) {} }; % ./bin/clang -fsyntax-only -Wall t4.cc t4.cc:12:13: warning: field is uninitialized when used here [-Wuninitialized] S2() : s1(s1.FOO) {} ^ t4.cc:17:13: warning: field is uninitialized when used here [-Wuninitialized] S3() : s1(s1.bar) {} ^ 2 warnings generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 13:30:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 15:30:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 8076] New: clang segfault with variably-modified function parameters. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8076 Summary: clang segfault with variably-modified function parameters. Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nbowler at draconx.ca CC: llvmbugs at cs.uiuc.edu The following C source causes clang to segfault: void foo(void) { void bar(int, char (*a)[*]); bar(0, 0); } Spewing the following to the console: 0 clang 0x0000000001071b3f 1 clang 0x000000000107218c 2 libpthread.so.0 0x00007fd9399e4010 3 clang 0x000000000057389b 4 clang 0x0000000000575cb9 5 clang 0x00000000005d526b 6 clang 0x00000000005d4f81 7 clang 0x00000000005759c2 8 clang 0x0000000000575cb9 9 clang 0x000000000054ebe7 10 clang 0x000000000054eecf 11 clang 0x00000000005211fc 12 clang 0x000000000054f4c3 13 clang 0x000000000054f724 14 clang 0x000000000056eca3 15 clang 0x000000000057532f 16 clang 0x0000000000575cb9 17 clang 0x000000000054ebe7 18 clang 0x00000000005b69da 19 clang 0x00000000005b82c0 20 clang 0x00000000005b6936 21 clang 0x00000000005b6969 22 clang 0x00000000005d88ab 23 clang 0x0000000000505231 24 clang 0x0000000000505cb3 25 clang 0x0000000000505e3c 26 clang 0x0000000000505f5b 27 clang 0x00000000004fe141 28 clang 0x00000000004191d4 29 clang 0x00000000005e83b5 30 clang 0x000000000041e257 31 clang 0x000000000041174a 32 clang 0x0000000000414a33 main + 1731 33 libc.so.6 0x00007fd938cefbbd __libc_start_main + 253 34 clang 0x000000000040fc79 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/lib/clang/1.1 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-yM4W3J.s -x c test.c 1. parser at end of file 2. test.c:1:6: LLVM IR generation of declaration 'foo' 3. test.c:1:6: Generating code for declaration 'foo' 4. test.c:2:1: LLVM IR generation of compound statement ('{}') clang: error: compiler command failed due to signal 11 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 13:57:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 15:57:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 8077] New: Support anonymous and local type template arguments Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8077 Summary: Support anonymous and local type template arguments Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5450) --> (http://llvm.org/bugs/attachment.cgi?id=5450) proposed patch This is enabled fully in C++0x mode, and as an extension (with appropriate warnings) in C++98. I've tried to test both the sema side of this as well as the codegen. Please let me know if the codegen is correct, and the way I'm testing is correct. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 14:13:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 16:13:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 8077] Support anonymous and local type template arguments In-Reply-To: References: Message-ID: <20100903211306.F3CE92A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8077 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chandler Carruth 2010-09-03 16:13:06 CDT --- And now actually marked as fixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 14:54:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 16:54:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 7402] Incorrect "initializing multiple members" error, which lacks a SourceLocation In-Reply-To: References: Message-ID: <20100903215440.62A3C2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7402 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #3 from Chandler Carruth 2010-09-03 16:54:39 CDT --- Fixed again in r113019. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 15:47:39 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 17:47:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 1757] Missed optimization: any number greater than two is not equal to two In-Reply-To: References: Message-ID: <20100903224739.621382A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=1757 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |resistor at mac.com Resolution| |FIXED --- Comment #6 from Owen Anderson 2010-09-03 17:47:38 CDT --- Fixed in r113025. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 16:47:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 18:47:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 8066] llvm+checking assert (S == TransformForPostIncUse(Denormalize, Result, User, OperandValToReplace, Loops, SE, DT) && "SCEV normalization is not invertible!") In-Reply-To: References: Message-ID: <20100903234705.D85122A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8066 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Dan Gohman 2010-09-03 18:47:05 CDT --- Fixed in r113021. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 17:12:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 19:12:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 8068] Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed. In-Reply-To: References: Message-ID: <20100904001244.481672A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8068 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2010-09-03 19:12:43 CDT --- Fixed in r113042, thanks!! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 18:47:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 20:47:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 8078] New: Indvars Pass Turns a Counted Loop into an Infinite Loop Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8078 Summary: Indvars Pass Turns a Counted Loop into an Infinite Loop Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tjablin at cs.princeton.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5451) --> (http://llvm.org/bugs/attachment.cgi?id=5451) Test case Transforms an ordinary counted loop into an infinite loop. I have attached C source code and llvm bitcode to demonstrate the bug. To reproduce: $ clang -O2 ./KS-2.c -emit-llvm -c -o ks.all.ll $ clang ks.all.ll -o ks.all $ ./ks.all 0 + 1: 1 $ opt ks.all.ll -indvars -o ks.all.indvars.ll $ clang ks.all.indvars.ll -o ks.all.indvars $ ./ks.all.indvars 0 + 1: 1 0 + 1: 1 0 + 1: 1 ... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 18:56:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 20:56:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 8079] New: Bugpoint segfaults when diagnosing 8408 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8079 Summary: Bugpoint segfaults when diagnosing 8408 Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tjablin at cs.princeton.edu CC: llvmbugs at cs.uiuc.edu -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 19:31:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 21:31:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 8080] New: Assertion `use_empty() && "Uses remain when a value is destroyed!" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8080 Summary: Assertion `use_empty() && "Uses remain when a value is destroyed!" Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: ofv at wanadoo.es CC: llvmbugs at cs.uiuc.edu That aasertion on Value::~Value fails when executing examples/Fibonacci. Those debug messages are also shown, which comes from the same place: Use still stuck around after Def is destroyed: %arg1 = sub i32 %AnArg, 2 Use still stuck around after Def is destroyed: %cond = icmp sle i32 %AnArg, 2 A fix for PR 8068, which reports the same assertion on clang, was just committed on r113042. The problem with Fibonacci was unaffected by that fix. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 3 19:43:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 3 Sep 2010 21:43:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 8078] Indvars Pass Turns a Counted Loop into an Infinite Loop In-Reply-To: References: Message-ID: <20100904024315.1C7032A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8078 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Dan Gohman 2010-09-03 21:43:14 CDT --- Fixed in 113057. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 4 06:18:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 4 Sep 2010 08:18:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8081] New: -analyzer-check-objc-mem -analyzer-experimental-checks: Segmentation fault (core dumped) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8081 Summary: -analyzer-check-objc-mem -analyzer-experimental-checks: Segmentation fault (core dumped) Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: dimhen at gmail.com CC: llvmbugs at cs.uiuc.edu # cat tst.c #include void new_fseek(FILE *stream, long offset, int whence) { fseek(stream, offset, whence); } # clang --version clang version 2.8 (trunk 113069) Target: i386-pc-linux-gnu Thread model: posix # /usr/src/llvm/Release+Asserts/bin/clang -cc1 -analyze -analyzer-check-objc-mem -analyzer-experimental-checks tst.c 0 clang 0x09094be8 Stack dump: 0. Program arguments: /usr/src/llvm/Release+Asserts/bin/clang -cc1 -analyze -analyzer-check-objc-mem -analyzer-experimental-checks tst.c 1. parser at end of file 2. tst.c:5:3: Error evaluating statement 3. tst.c:5:3: Error evaluating statement Segmentation fault (core dumped) # /usr/src/llvm/Release+Asserts/bin/clang -cc1 -analyze -analyzer-experimental-checks tst.c # /usr/src/llvm/Release+Asserts/bin/clang -cc1 -analyze -analyzer-check-objc-mem tst.c -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 4 11:39:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 4 Sep 2010 13:39:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 8082] New: clang doesn't diagnose reference to reference Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8082 Summary: clang doesn't diagnose reference to reference Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com GCC rejects this, clang doesn't: class foo { foo(); typedef int& A; A x; A & getfoo() { return x; } }; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 4 17:41:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 4 Sep 2010 19:41:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 7990] calling non-const method from a const method produces embarrassing diagnostic In-Reply-To: References: Message-ID: <20100905004159.4EF972A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7990 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2010-09-04 19:41:59 CDT --- *** This bug has been marked as a duplicate of bug 6678 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 4 23:04:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 01:04:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 8063] clang asserts in StreamIt fft benchmark In-Reply-To: References: Message-ID: <20100905060419.A051E2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8063 Thomas B. Jablin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |llvmbugs at cs.uiuc.edu Component|Frontend |new bugs AssignedTo|unassignedclangbugs at nondot. |unassignedbugs at nondot.org |org | Product|clang |new-bugs --- Comment #4 from Thomas B. Jablin 2010-09-05 01:04:19 CDT --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Can you provide the output of "clang -v"? I can't reproduce. > > > > I just tested again with revision 113069 and it works now. I am marking FIXED. > > I spoke too soon. My testcase now works, but the full program still dies. I'll > post the full C source. Looking at it again, the bug is actually in llvm proper. The testcase still asserts with -O2. I have attached a bugpoint reduced testcase. The bug is in the -globalopt pass. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 01:08:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 03:08:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 8083] New: wine's kernel32/time test fails with clang, passes with gcc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8083 Summary: wine's kernel32/time test fails with clang, passes with gcc Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: austinenglish at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5455) --> (http://llvm.org/bugs/attachment.cgi?id=5455) source example >From http://bugs.winehq.org/show_bug.cgi?id=24270. I've narrowed the case down a bit, but it's still in the form of a wine test. Hopefully it'll give you a starting point though. If I can provide any more information, please let me know. Clang used: austin at midna:~/wine-clang/dlls/kernel32/tests$ clang --version clang version 1.1 (branches/release_27) Target: x86_64-pc-linux-gnu Thread model: posix Same test passes with: austin at midna:~/wine-clang/dlls/kernel32/tests$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ Thread model: posix gcc version 4.6.0 20100821 (experimental) (GCC) stripped down testcase attached. On clang, make time.ok gives: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so time.c && touch time.ok time.c:96: Test failed: Test SystemTimeToTzSpecificLocalTime #3. Got 2004-03-02 02:00. Expect hour = 03 time.c:96: Test failed: Test SystemTimeToTzSpecificLocalTime #3. Got 2004-03-02 02:00. Expect hour = 03 time.c:96: Test failed: Test SystemTimeToTzSpecificLocalTime #1. Got 2004-03-02 02:00. Expect hour = 01 time.c:96: Test failed: Test SystemTimeToTzSpecificLocalTime #2. Got 2004-03-02 02:00. Expect hour = 01 time.c:96: Test failed: Test SystemTimeToTzSpecificLocalTime #3. Got 2004-03-02 02:00. Expect hour = 03 time.c:96: Test failed: Test SystemTimeToTzSpecificLocalTime #3. Got 2004-03-17 02:00. Expect hour = 03 make: *** [time.ok] Error 6 on gcc, passes without error. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 02:48:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 04:48:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 8084] New: No namespace awareness of static template fields Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8084 Summary: No namespace awareness of static template fields Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: fritzsche at acm.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com > cat foo.cxx namespace F { template struct Foo { static A *field; }; } using namespace F; struct Bar : Foo {}; template <> Bar* Foo::field = 0; > clang++ -fsyntax-only foo.cxx foo.cxx:9:28: error: static data member specialization of 'field' must originally be declared in namespace 'F' template <> Bar* Foo::field = 0; ^ foo.cxx:3:19: note: explicitly specialized declaration is here static A *field; ================================================================ system: Linux 2.6.32-24-generic amd64 Ubuntu 10.04 clang version 2.8 (trunk 113084) Target: x86_64-unknown-linux-gnu Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 03:03:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 05:03:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8085] New: [PATCH] lib/System/Host.cpp: x86 SSE3 Feature check bug (wrong datum used) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8085 Summary: [PATCH] lib/System/Host.cpp: x86 SSE3 Feature check bug (wrong datum used) Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: System Library AssignedTo: unassignedbugs at nondot.org ReportedBy: nms+llvm at otdel-1.org CC: llvmbugs at cs.uiuc.edu sse3 check must be done after cpuid(1, ...), not after cpuid(0x80000001, ...) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 03:19:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 05:19:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 8086] New: lib/Target/X86/X86InstrSSE.td: cvtsi2sd & friends are not in SSE1 (they are in SSE2) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8086 Summary: lib/Target/X86/X86InstrSSE.td: cvtsi2sd & friends are not in SSE1 (they are in SSE2) Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nms+llvm at otdel-1.org CC: llvmbugs at cs.uiuc.edu well, summary says all -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 08:23:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 10:23:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 8082] clang doesn't diagnose reference to reference In-Reply-To: References: Message-ID: <20100905152355.B15082A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8082 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Douglas Gregor 2010-09-05 10:23:55 CDT --- This is C++ DR106: http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#106 My impression is that this defect was intended to apply to the C++98/03 language, but it missed the cutoff for the C++03 document. EDG seems to be treating it that way, and I'm guessing that newer GCC's do, too. I think Clang is doing the right thing. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 09:43:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 11:43:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 8087] New: operator overloading for enums is ambiguous Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8087 Summary: operator overloading for enums is ambiguous Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pip88nl at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang rejects the following code: // BEGIN enum E { one }; bool operator >= (E, E) { return 0; } int main () { E a = one, b = one; a >= b; // ambiguous here } // END with an ambiguity error. This is true for revision 112476 and release 2.7. According to the C++ standard 13.6.1: If there is a user-written candidate withthe same name and parameter types as a built-in candidate operator function, the built-in operator function is hidden and is not included in the set of candidate functions. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 10:21:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 12:21:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8063] clang asserts in StreamIt fft benchmark In-Reply-To: References: Message-ID: <20100905172114.788422A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8063 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #7 from Chris Lattner 2010-09-05 12:21:14 CDT --- Fixed in r113109, thanks for the reduced testcase! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 15:41:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 17:41:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8088] New: segfault on simple template function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8088 Summary: segfault on simple template function Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: release blocker Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pip88nl at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5457) --> (http://llvm.org/bugs/attachment.cgi?id=5457) stderr output of "clang test.cc" In revision 113114, clang causes signal 11 to be raised when trying to parse a simple template function: // BEGIN template T const &id (T const &a) { return a; } int main () { id (0); } // END uname -a: Linux osiris 2.6.32-5-amd64 #1 SMP Thu Aug 12 13:01:50 UTC 2010 x86_64 GNU/Linux clang -v: clang version 2.8 (trunk 113114) Target: x86_64-pc-linux-gnu Thread model: posix Error output attached. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 16:09:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 18:09:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 8080] Assertion `use_empty() && "Uses remain when a value is destroyed!" In-Reply-To: References: Message-ID: <20100905230940.D59932A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8080 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2010-09-05 18:09:40 CDT --- Fixed in r113123, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 16:16:13 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 18:16:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 8023] clang c++ assertion "Invalid opcode for overloaded unary operator" using __real__ on expression of class type In-Reply-To: References: Message-ID: <20100905231613.627AD2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8023 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Eli Friedman 2010-09-05 18:16:12 CDT --- Fixed in r113124. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 16:16:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 18:16:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 7320] #pragma GCC dependency crashes FE without the optional trailing text In-Reply-To: References: Message-ID: <20100905231628.464702A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7320 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|new bugs |Frontend Resolution| |FIXED AssignedTo|unassignedbugs at nondot.org |unassignedclangbugs at nondot. | |org Product|new-bugs |clang --- Comment #2 from Chris Lattner 2010-09-05 18:16:27 CDT --- Fixed in r113125, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 16:30:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 18:30:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7192] clang -Wwrite-strings doesn't allow writing to wchars In-Reply-To: References: Message-ID: <20100905233001.19DF52A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7192 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-09-05 18:30:00 CDT --- Fixed in r113127, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 17:10:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 19:10:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 7242] Assert on valid code: Constant declref with side-effect?! In-Reply-To: References: Message-ID: <20100906001053.D66D42A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7242 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Eli Friedman 2010-09-05 19:10:53 CDT --- Fixed in r113128. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 17:13:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 19:13:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 7151] problem with anonymous union + c99 initializers In-Reply-To: References: Message-ID: <20100906001331.4415C2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7151 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2010-09-05 19:13:30 CDT --- Fixed here: r113130 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 17:15:13 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 19:15:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 6926] llvm build fails due to __func__ conflicts in gcc 4.5.1 on Darwin 10.6.2 In-Reply-To: References: Message-ID: <20100906001513.C9D9D2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6926 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Chris Lattner 2010-09-05 19:15:13 CDT --- No idea. It's a bug in your host GCC. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 17:16:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 19:16:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 7092] [patch] Makes Module::getOrInsertFunction accept va_args in addition to ellipsis In-Reply-To: References: Message-ID: <20100906001648.774972A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7092 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #4 from Chris Lattner 2010-09-05 19:16:48 CDT --- I would rather not do this. The varargs versions of these functions are just a convenience, if you want to pass in a structured list, please usethe std:vector versions of these. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 18:10:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 20:10:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 5319] store not sunk by licm In-Reply-To: References: Message-ID: <20100906011032.2E1322A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5319 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2010-09-05 20:10:31 CDT --- Fixed in r113134. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 19:06:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 21:06:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 8089] New: clang crashes when an enum forward declaration is used in cast Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8089 Summary: clang crashes when an enum forward declaration is used in cast Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pichet2000 at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com test.cpp: enum E; int a = (E)3; clang -cc1 -fsyntax-only test.cpp stack dump. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 19:09:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 21:09:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 8090] New: clang++ crash after typo recovery Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8090 Summary: clang++ crash after typo recovery Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang++ crashes on this, I hit this when I forgot to include : template int max(const _Tp& __a, const _Tp& __b) { } void Emit() { map::iterator LI; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 19:45:02 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 5 Sep 2010 21:45:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 7997] -ccc-cxx option doesn't work on Linux In-Reply-To: References: Message-ID: <20100906024502.EDC352A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7997 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rafael.espindola at gmail.com Resolution| |FIXED --- Comment #2 from Rafael Ávila de Espíndola 2010-09-05 21:45:02 CDT --- Fixed in r113138. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 22:02:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 00:02:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 2345] ICE on invalid inline asm constraint letter In-Reply-To: References: Message-ID: <20100906050215.7AB522A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2345 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-09-06 00:02:14 CDT --- Fixed in clang: t.c:5:25: error: invalid input constraint 'z' in asm __asm__ ("lpm %0, Z"::"z"(foo)); ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 22:05:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 00:05:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 5033] failure to warn about uninitialized induction var In-Reply-To: References: Message-ID: <20100906050536.74EF72A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5033 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #4 from Chris Lattner 2010-09-06 00:05:35 CDT --- Clang doesn't report use of uninitialized variables yet, but it's on the todo list. -Wuninitialized is the starting point. This bug isn't going to make it happen though. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 22:11:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 00:11:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 8067] Assertion `!cast(Use)->isVolatile() && Use->getOperand(0) != ASIV && "AST broken"' failed. In-Reply-To: References: Message-ID: <20100906051134.7D6652A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8067 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2010-09-06 00:11:33 CDT --- Fixed in r113146, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 22:19:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 00:19:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 8085] [PATCH] lib/System/Host.cpp: x86 SSE3 Feature check bug (wrong datum used) In-Reply-To: References: Message-ID: <20100906051958.D654B2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8085 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-09-06 00:19:58 CDT --- Yep, you're right, applied in r113147, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 22:25:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 00:25:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 7844] clang crash due to memory unsafety In-Reply-To: References: Message-ID: <20100906052548.48A2A2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7844 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2010-09-06 00:25:47 CDT --- This doesn't repro for me (running clang under valgrind), and I fixed a ton of bugs in AliasSetTracker+LICM that could cause this sort of failure. Closing as fixed, please reopen if it still repros for you. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 5 22:30:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 00:30:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 5159] sroa and other passes does a rotten job on vector code from the gcc plugin In-Reply-To: References: Message-ID: <20100906053036.03CC92A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5159 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2010-09-06 00:30:35 CDT --- The generated code (after -O3 | llc) looks pretty reasonable to me. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 00:42:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 02:42:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8086] lib/Target/X86/X86InstrSSE.td: cvtsi2sd & friends are not in SSE1 (they are in SSE2) In-Reply-To: References: Message-ID: <20100906074229.EC5982A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8086 Nikolai Saoukh changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 01:07:39 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 03:07:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 8091] New: clang crash with member templates Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8091 Summary: clang crash with member templates Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: release blocker Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pip88nl at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5459) --> (http://llvm.org/bugs/attachment.cgi?id=5459) error output from clang -c -v clang-broken.ii Clang revision 113114 crashes in certain uses of nested templates. It does not crash if a builtin type is used as argument to allocator instead of struct pair. It does still crash if struct pair is forward declared or defined. Unfortunately, bugzilla doesn't allow me to attach multiple files, so here is the code: // BEGIN template struct allocator { template struct rebind { typedef allocator<_Tp1> other; }; }; template struct _Rb_tree { typedef typename _Alloc::template rebind::other _Node_allocator; typedef int const_reverse_iterator; struct _Rb_tree_impl : _Node_allocator { }; _Rb_tree_impl _M_impl; }; typedef _Rb_tree >::const_reverse_iterator const_reverse_iterator; // END -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 06:53:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 08:53:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 8092] New: llvm.init.trampoline doesn't work if the function argument is a function pointer. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8092 Summary: llvm.init.trampoline doesn't work if the function argument is a function pointer. Product: new-bugs Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: fvbommel at wxs.nl CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5460) --> (http://llvm.org/bugs/attachment.cgi?id=5460) A wrapper around llvm.init.trampoline The attached .ll file contains a function calling llvm.init.trampoline, passing its own arguments on to it. LLVM doesn't like this: ===== $ llc make_trampoline.ll llvm.init_trampoline parameter #2 must resolve to a function. %tramp = tail call i8* @llvm.init.trampoline(i8* %mem, i8* %fn, i8* %data) Broken module found, compilation aborted! 0 llc 0x0000000000da92df 1 llc 0x0000000000dab552 2 libpthread.so.0 0x00007fa4ab8b78f0 3 libc.so.6 0x00007fa4aaba6a75 gsignal + 53 4 libc.so.6 0x00007fa4aabaa5c0 abort + 384 5 llc 0x0000000000d2160b 6 llc 0x0000000000cfb6cd llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 7 llc 0x0000000000cfb7cb llvm::FPPassManager::runOnModule(llvm::Module&) + 75 8 llc 0x0000000000cfb257 llvm::MPPassManager::runOnModule(llvm::Module&) + 503 9 llc 0x0000000000cfb3d7 llvm::PassManagerImpl::run(llvm::Module&) + 167 10 llc 0x000000000053744d main + 4109 11 libc.so.6 0x00007fa4aab91c4d __libc_start_main + 253 12 llc 0x0000000000535829 Stack dump: 0. Program arguments: llc make_trampoline.ll 1. Running pass 'Function Pass Manager' on module 'make_trampoline.ll'. 2. Running pass 'Module Verifier' on function '@make_trampoline' Aborted ===== Commenting out this assert in the verifier shows it is currently backed up by one in the SelectionDAGBuilder (by way of cast): ===== $ llc make_trampoline.ll llc: /home/urxae/opt/llvm/trunk/include/llvm/Support/Casting.h:202: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = llvm::Function, Y = llvm::Value*]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. 0 llc 0x0000000000da928f 1 llc 0x0000000000dab502 2 libpthread.so.0 0x00007f771ea9d8f0 3 libc.so.6 0x00007f771dd8ca75 gsignal + 53 4 libc.so.6 0x00007f771dd905c0 abort + 384 5 libc.so.6 0x00007f771dd85941 __assert_fail + 241 6 llc 0x0000000000917abc llvm::SelectionDAGBuilder::visitIntrinsicCall(llvm::CallInst const&, unsigned int) + 17372 7 llc 0x0000000000917fae llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 654 8 llc 0x00000000008ffb2a llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) + 394 9 llc 0x0000000000925d0d llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 45 10 llc 0x0000000000933aa0 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 160 11 llc 0x00000000009340f4 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1460 12 llc 0x0000000000934da6 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 486 13 llc 0x0000000000cfb6cd llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 14 llc 0x0000000000cfb7cb llvm::FPPassManager::runOnModule(llvm::Module&) + 75 15 llc 0x0000000000cfb257 llvm::MPPassManager::runOnModule(llvm::Module&) + 503 16 llc 0x0000000000cfb3d7 llvm::PassManagerImpl::run(llvm::Module&) + 167 17 llc 0x000000000053744d main + 4109 18 libc.so.6 0x00007f771dd77c4d __libc_start_main + 253 19 llc 0x0000000000535829 Stack dump: 0. Program arguments: llc make_trampoline.ll 1. Running pass 'Function Pass Manager' on module 'make_trampoline.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@make_trampoline' Aborted ===== Is there any reason for this? As far as I can tell, there's no reason llvm.init.trampoline shouldn't be able to work for function pointers; the nest arg is given a specially-reserved register in the callling convention (at least on X86 and X86-64, I didn't check the other backends) so it's not like the argument list actually has to be rewritten by it. That means it should be able to just store some static code and the pointers to the memory provided, right? (At the very least, this should be more clearly documented in LangRef.html if this was intentional; it does currently say "The func argument must hold a function bitcast to an i8*.", but that could be interpreted to mean "indirection" by way of function arguments, phi nodes, etc. is allowed) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 10:44:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 12:44:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 8093] New: Assertion failed: (0 && "Unknown immediate size"), function getSizeOfImm, file X86InstrInfo.h, line 486. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8093 Summary: Assertion failed: (0 && "Unknown immediate size"), function getSizeOfImm, file X86InstrInfo.h, line 486. Product: libraries Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu pes delta$ cat x.c void bus_space_read_multi_2(void) { __asm volatile ("1: loop 1b"); } pes delta$ clang -integrated-as x.c > > > Assertion failed: (0 && "Unknown immediate size"), function getSizeOfImm, file X86InstrInfo.h, line 486. Stack dump: 0. Program arguments: clang -integrated-as x.c 1. parser at end of file 2. Code generation 3. Running pass 'X86 AT&T-Style Assembly Printer' on function '@bus_space_read_multi_2' Abort (core dumped) with Inst.dump() in MCStreamer::EmitInstruction(). This reproduces on both ELF/MachO. the problem here is with the encoding of the loop instruction. it tries to get the size of the immediate by: TSFlags & X86II::ImmMask but TSFLags is 0xE2000001 (in debugger, in X86GenInstrInfo.inc it's defined to be 0xe200002bULL) and X86II::ImmMask is E000 so it clearly does not match. I think that the TSFLags are wrong -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 11:46:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 13:46:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8093] Assertion failed: (0 && "Unknown immediate size"), function getSizeOfImm, file X86InstrInfo.h, line 486. In-Reply-To: References: Message-ID: <20100906184629.382BD2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8093 Roman Divacky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Roman Divacky 2010-09-06 13:46:28 CDT --- fixed in 113158. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 11:55:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 13:55:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 8083] wine's kernel32/time test fails with clang, passes with gcc In-Reply-To: References: Message-ID: <20100906185531.69B022A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8083 austinenglish at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from austinenglish at gmail.com 2010-09-06 13:55:31 CDT --- Turns out wine was trying to access a member of an array beyond the defined end. Gcc was allowing it, clang wasn't, but it's undefined behavior. Invalid, sorry for the spam. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 12:09:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 14:09:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 8094] New: clang hangs while compiling PHP Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8094 Summary: clang hangs while compiling PHP Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ambrop7 at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5461) --> (http://llvm.org/bugs/attachment.cgi?id=5461) Preprocessed source that hangs clang Clang hangs while compiling PHP 5.3.3, in file ext/standard/crypt_sha512.c. Preprocessed source is attached. Using llvm/clang 2.8 branch, compiled with gcc 4.5.1, Gentoo Linux ~amd64. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 14:18:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 16:18:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 7401] Unhelpful error message when taking address of static template function through an instance In-Reply-To: References: Message-ID: <20100906211831.F06A92A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7401 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |WORKSFORME --- Comment #1 from Eli Friedman 2010-09-06 16:18:31 CDT --- Appears to be working with current trunk; not sure when it was fixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 15:15:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 17:15:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8095] New: -Wglobal-constructors false positive Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8095 Summary: -Wglobal-constructors false positive Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ori at avtalion.name CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following example gives a warning when -Wglobal-constructors is enabled: struct Foo { int x; Foo(int x1) : x(x1) {} }; void bar() { static Foo a(0); } --- clang++ output: a.cpp:8:13: warning: declaration requires a global constructor [-Wglobal-constructors] static Foo a(0); ^~~ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 16:14:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 18:14:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8095] -Wglobal-constructors false positive In-Reply-To: References: Message-ID: <20100906231416.0D3192A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8095 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |rjmccall at apple.com Resolution|INVALID | --- Comment #2 from Chris Lattner 2010-09-06 18:14:15 CDT --- Ah, no, you're right, it's a static in a function, so it is lazily constructed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 16:13:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 18:13:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 8095] -Wglobal-constructors false positive In-Reply-To: References: Message-ID: <20100906231338.AE2322A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8095 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2010-09-06 18:13:38 CDT --- That does require a static constructor. When the optimizer is turned on, sometimes it can remove them, but it certainly does at -O0. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 6 21:20:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 6 Sep 2010 23:20:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 8096] New: instcombine make a call to sqrt dead but fails to remove it Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8096 Summary: instcombine make a call to sqrt dead but fails to remove it Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Jan Voung found this interesting test case: --------------------------------------------------- define float @my_sqrt_f(float %d) nounwind { entry: %0 = fpext float %d to double %1 = call double @sqrt(double %0) nounwind %2 = fptrunc double %1 to float ret float %2 } declare double @sqrt(double) nounwind ------------------------------------------------ $ opt -instcombine test.ll -o test2.ll -S Produces ---------------------------------------- define float @my_sqrt_f(float %d) nounwind { entry: %0 = fpext float %d to double %1 = call double @sqrt(double %0) nounwind %2 = call float @sqrtf(float %d) nounwind ret float %2 } declare double @sqrt(double) nounwind declare float @sqrtf(float) nounwind ------------------------------------- Since sqrt is not side effect free, we are now stuck with both calls. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 08:31:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 10:31:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 7115] Assertion failed: (isa(Val) && "cast_or_null() argument of incompatible type!"), function cast_or_null, file /Users/az/Programmierung/CppIDE/llvm-src/include/llvm/Support/Casting.h, line 213. In-Reply-To: References: Message-ID: <20100907153115.DB9CE2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7115 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #13 from Chris Lattner 2010-09-07 10:31:14 CDT --- Ok, lets call it fixed. Please file a new bug if not, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 08:32:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 10:32:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 8056] missing fixit to add parens to function call In-Reply-To: References: Message-ID: <20100907153204.ECC682A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8056 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Douglas Gregor 2010-09-07 10:32:04 CDT --- *** This bug has been marked as a duplicate of bug 5478 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 08:44:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 10:44:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8097] New: __has_trivial_constructor doesn't work for void and arrays of unknown bound Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8097 Summary: __has_trivial_constructor doesn't work for void and arrays of unknown bound Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hhinnant at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This trait is supposed to work for void types, and arrays of unknown bounds. I believe it should answer false to both. Here is a test case I believe should compile: template void test__has_trivial_constructor() { static_assert(__has_trivial_constructor(T) == Result, ""); // or use assert if -std=c++0x not specified } int main() { test__has_trivial_constructor(); test__has_trivial_constructor(); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 08:52:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 10:52:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 8098] New: uncaught exception doesn't cause expected behavior Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8098 Summary: uncaught exception doesn't cause expected behavior Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Hello, I am using a snapshot of llvm+clang from yesterday, with the headers of libstdc++-4.2, on debian testing x64. When I compile and run this code: #include int main(){ throw std::logic_error("Hello.\nAgain?\n"); return 0; } with g++ I get this output: terminate called after throwing an instance of 'std::logic_error' what(): Hello. Again? with clang++ -O2 I just get a segmentation fault. Without -O2, I get "terminate called without an active exception" before the segfault. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 09:33:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 11:33:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8099] New: Assertion failed with PCH in getTranslationUnitDecl, file DeclBase.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8099 Summary: Assertion failed with PCH in getTranslationUnitDecl, file DeclBase.cpp Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: luc_j_bourhis at mac.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com ~/Desktop> clang --version clang version 2.9 (trunk 113198) Target: x86_64-apple-darwin10 Thread model: posix ~/Desktop> clang++ -o hybrid_times_ext.o -c -include precompiled.h -fPIC -fno-strict-aliasing -w -O3 hybrid_times_ext.preprocessed.cpp Assertion failed: (DC && "This decl is not contained in a translation unit!"), function getTranslationUnitDecl, file DeclBase.cpp, line 203. 0 clang 0x0000000100ef9dd2 PrintStackTrace(void*) + 34 1 clang 0x0000000100efa2b9 SignalHandler(int) + 841 2 libSystem.B.dylib 0x00007fff821e135a _sigtramp + 26 3 clang 0x00000001000141a3 global constructors keyed to a + 259 4 clang 0x0000000100021966 abort + 22 5 clang 0x0000000100021928 __assert_rtn + 56 6 clang 0x0000000100565da3 clang::Decl::getTranslationUnitDecl() + 115 7 clang 0x0000000100565ca9 clang::Decl::getASTContext() const + 9 8 clang 0x0000000100577702 clang::FunctionTemplateDecl::newCommon() + 18 9 clang 0x00000001005774b5 clang::RedeclarableTemplateDecl::getCommonPtr() + 37 10 clang 0x00000001000da0d0 clang::ASTDeclReader::VisitRedeclarableTemplateDecl(clang::RedeclarableTemplateDecl*) + 288 11 clang 0x00000001000dae98 clang::ASTDeclReader::VisitFunctionTemplateDecl(clang::FunctionTemplateDecl*) + 24 12 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 13 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 14 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 15 clang 0x00000001000d52f1 clang::ASTDeclReader::VisitFunctionDecl(clang::FunctionDecl*) + 497 16 clang 0x00000001000d97de clang::ASTDeclReader::VisitCXXMethodDecl(clang::CXXMethodDecl*) + 30 17 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 18 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 19 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 20 clang 0x00000001000d2596 clang::ASTDeclReader::VisitDecl(clang::Decl*) + 70 21 clang 0x00000001000d5038 clang::ASTDeclReader::VisitDeclaratorDecl(clang::DeclaratorDecl*) + 24 22 clang 0x00000001000d7e08 clang::ASTDeclReader::VisitVarDecl(clang::VarDecl*) + 24 23 clang 0x00000001000d80a8 clang::ASTDeclReader::VisitParmVarDecl(clang::ParmVarDecl*) + 24 24 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 25 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 26 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 27 clang 0x00000001000e4971 clang::ASTStmtReader::VisitCXXDefaultArgExpr(clang::CXXDefaultArgExpr*) + 113 28 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 29 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 30 clang 0x00000001000d7f76 clang::ASTDeclReader::VisitVarDecl(clang::VarDecl*) + 390 31 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 32 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 33 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 34 clang 0x00000001000dff9c clang::ASTStmtReader::VisitDeclRefExpr(clang::DeclRefExpr*) + 300 35 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 36 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 37 clang 0x00000001000c0762 clang::ASTReader::ReadTemplateArgument(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 482 38 clang 0x00000001000c0de6 clang::ASTReader::ReadTemplateArgumentList(llvm::SmallVector&, llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 150 39 clang 0x00000001000bfeaf clang::ASTReader::ReadTypeRecord(unsigned int) + 8047 40 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 41 clang 0x00000001000c0e9f clang::ASTReader::GetTypeSourceInfo(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 63 42 clang 0x00000001000c530a clang::ASTReader::ReadCXXBaseSpecifier(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 138 43 clang 0x00000001000d943b clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 1467 44 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 45 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 46 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 47 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 48 clang 0x00000001000d25ff clang::ASTDeclReader::VisitDecl(clang::Decl*) + 175 49 clang 0x00000001000d4a18 clang::ASTDeclReader::VisitTagDecl(clang::TagDecl*) + 24 50 clang 0x00000001000d4da8 clang::ASTDeclReader::VisitRecordDecl(clang::RecordDecl*) + 24 51 clang 0x00000001000d8f46 clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 198 52 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 53 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 54 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 55 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 56 clang 0x00000001000d2596 clang::ASTDeclReader::VisitDecl(clang::Decl*) + 70 57 clang 0x00000001000d4a18 clang::ASTDeclReader::VisitTagDecl(clang::TagDecl*) + 24 58 clang 0x00000001000d4da8 clang::ASTDeclReader::VisitRecordDecl(clang::RecordDecl*) + 24 59 clang 0x00000001000d8f46 clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 198 60 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 61 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 62 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 63 clang 0x00000001000d2596 clang::ASTDeclReader::VisitDecl(clang::Decl*) + 70 64 clang 0x00000001000d5038 clang::ASTDeclReader::VisitDeclaratorDecl(clang::DeclaratorDecl*) + 24 65 clang 0x00000001000d512c clang::ASTDeclReader::VisitFunctionDecl(clang::FunctionDecl*) + 44 66 clang 0x00000001000d97de clang::ASTDeclReader::VisitCXXMethodDecl(clang::CXXMethodDecl*) + 30 67 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 68 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 69 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 70 clang 0x00000001000d25ff clang::ASTDeclReader::VisitDecl(clang::Decl*) + 175 71 clang 0x00000001000d4a18 clang::ASTDeclReader::VisitTagDecl(clang::TagDecl*) + 24 72 clang 0x00000001000d4da8 clang::ASTDeclReader::VisitRecordDecl(clang::RecordDecl*) + 24 73 clang 0x00000001000d8fd1 clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 337 74 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 75 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 76 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 77 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 78 clang 0x00000001000bf4ec clang::ASTReader::ReadTypeRecord(unsigned int) + 5548 79 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 80 clang 0x00000001000bfeea clang::ASTReader::ReadTypeRecord(unsigned int) + 8106 81 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 82 clang 0x00000001000be49d clang::ASTReader::ReadTypeRecord(unsigned int) + 1373 83 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 84 clang 0x00000001000dfcc0 clang::ASTStmtReader::VisitExpr(clang::Expr*) + 64 85 clang 0x00000001000e0fc2 clang::ASTStmtReader::VisitCastExpr(clang::CastExpr*) + 34 86 clang 0x00000001000e9417 clang::StmtVisitor::Visit(clang::Stmt*) + 2071 87 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 88 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 89 clang 0x00000001000d7f76 clang::ASTDeclReader::VisitVarDecl(clang::VarDecl*) + 390 90 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 91 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 92 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 93 clang 0x00000001000dff9c clang::ASTStmtReader::VisitDeclRefExpr(clang::DeclRefExpr*) + 300 94 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 95 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 96 clang 0x00000001000c0762 clang::ASTReader::ReadTemplateArgument(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 482 97 clang 0x00000001000c0de6 clang::ASTReader::ReadTemplateArgumentList(llvm::SmallVector&, llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 150 98 clang 0x00000001000bfeaf clang::ASTReader::ReadTypeRecord(unsigned int) + 8047 99 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 100 clang 0x00000001000c0e9f clang::ASTReader::GetTypeSourceInfo(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 63 101 clang 0x00000001000c530a clang::ASTReader::ReadCXXBaseSpecifier(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 138 102 clang 0x00000001000d943b clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 1467 103 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 104 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 105 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 106 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 107 clang 0x00000001000d25ff clang::ASTDeclReader::VisitDecl(clang::Decl*) + 175 108 clang 0x00000001000d4a18 clang::ASTDeclReader::VisitTagDecl(clang::TagDecl*) + 24 109 clang 0x00000001000d4da8 clang::ASTDeclReader::VisitRecordDecl(clang::RecordDecl*) + 24 110 clang 0x00000001000d8f46 clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 198 111 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 112 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 113 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 114 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 115 clang 0x00000001000d25ff clang::ASTDeclReader::VisitDecl(clang::Decl*) + 175 116 clang 0x00000001000d4a18 clang::ASTDeclReader::VisitTagDecl(clang::TagDecl*) + 24 117 clang 0x00000001000d4da8 clang::ASTDeclReader::VisitRecordDecl(clang::RecordDecl*) + 24 118 clang 0x00000001000d8f46 clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 198 119 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 120 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 121 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 122 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 123 clang 0x00000001000d25ff clang::ASTDeclReader::VisitDecl(clang::Decl*) + 175 124 clang 0x00000001000d4a18 clang::ASTDeclReader::VisitTagDecl(clang::TagDecl*) + 24 125 clang 0x00000001000d4da8 clang::ASTDeclReader::VisitRecordDecl(clang::RecordDecl*) + 24 126 clang 0x00000001000d8f46 clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 198 127 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 128 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 129 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 130 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 131 clang 0x00000001000d25ff clang::ASTDeclReader::VisitDecl(clang::Decl*) + 175 132 clang 0x00000001000d4a18 clang::ASTDeclReader::VisitTagDecl(clang::TagDecl*) + 24 133 clang 0x00000001000d4da8 clang::ASTDeclReader::VisitRecordDecl(clang::RecordDecl*) + 24 134 clang 0x00000001000d8f46 clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 198 135 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 136 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 137 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 138 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 139 clang 0x00000001000da41e clang::ASTDeclReader::VisitClassTemplateDecl(clang::ClassTemplateDecl*) + 126 140 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 141 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 142 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 143 clang 0x00000001000c0bf1 clang::ASTReader::ReadTemplateName(llvm::SmallVector const&, unsigned int&) + 481 144 clang 0x00000001000bfe69 clang::ASTReader::ReadTypeRecord(unsigned int) + 7977 145 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 146 clang 0x00000001000c04c6 clang::ASTReader::ReadNestedNameSpecifier(llvm::SmallVector const&, unsigned int&) + 278 147 clang 0x00000001000dff0e clang::ASTStmtReader::VisitDeclRefExpr(clang::DeclRefExpr*) + 158 148 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 149 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 150 clang 0x00000001000c0762 clang::ASTReader::ReadTemplateArgument(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 482 151 clang 0x00000001000c0de6 clang::ASTReader::ReadTemplateArgumentList(llvm::SmallVector&, llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 150 152 clang 0x00000001000bfeaf clang::ASTReader::ReadTypeRecord(unsigned int) + 8047 153 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 154 clang 0x00000001000c0e9f clang::ASTReader::GetTypeSourceInfo(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 63 155 clang 0x00000001000c530a clang::ASTReader::ReadCXXBaseSpecifier(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 138 156 clang 0x00000001000d943b clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 1467 157 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 158 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 159 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 160 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 161 clang 0x00000001000d25ff clang::ASTDeclReader::VisitDecl(clang::Decl*) + 175 162 clang 0x00000001000d4a18 clang::ASTDeclReader::VisitTagDecl(clang::TagDecl*) + 24 163 clang 0x00000001000d4da8 clang::ASTDeclReader::VisitRecordDecl(clang::RecordDecl*) + 24 164 clang 0x00000001000d8f46 clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 198 165 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 166 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 167 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 168 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 169 clang 0x00000001000d25ff clang::ASTDeclReader::VisitDecl(clang::Decl*) + 175 170 clang 0x00000001000d4a18 clang::ASTDeclReader::VisitTagDecl(clang::TagDecl*) + 24 171 clang 0x00000001000d4da8 clang::ASTDeclReader::VisitRecordDecl(clang::RecordDecl*) + 24 172 clang 0x00000001000d8f46 clang::ASTDeclReader::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 198 173 clang 0x00000001000da4f5 clang::ASTDeclReader::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) + 37 174 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 175 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 176 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 177 clang 0x00000001000da41e clang::ASTDeclReader::VisitClassTemplateDecl(clang::ClassTemplateDecl*) + 126 178 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 179 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 180 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 181 clang 0x00000001000c0bf1 clang::ASTReader::ReadTemplateName(llvm::SmallVector const&, unsigned int&) + 481 182 clang 0x00000001000bfe69 clang::ASTReader::ReadTypeRecord(unsigned int) + 7977 183 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 184 clang 0x00000001000c04c6 clang::ASTReader::ReadNestedNameSpecifier(llvm::SmallVector const&, unsigned int&) + 278 185 clang 0x00000001000bf65f clang::ASTReader::ReadTypeRecord(unsigned int) + 5919 186 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 187 clang 0x00000001000c0e9f clang::ASTReader::GetTypeSourceInfo(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 63 188 clang 0x00000001000d49d2 clang::ASTDeclReader::VisitTypedefDecl(clang::TypedefDecl*) + 98 189 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 190 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 191 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 192 clang 0x00000001000bf29b clang::ASTReader::ReadTypeRecord(unsigned int) + 4955 193 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 194 clang 0x00000001000bf69a clang::ASTReader::ReadTypeRecord(unsigned int) + 5978 195 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 196 clang 0x00000001000c0e9f clang::ASTReader::GetTypeSourceInfo(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 63 197 clang 0x00000001000d49d2 clang::ASTDeclReader::VisitTypedefDecl(clang::TypedefDecl*) + 98 198 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 199 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 200 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 201 clang 0x00000001000bf29b clang::ASTReader::ReadTypeRecord(unsigned int) + 4955 202 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 203 clang 0x00000001000c061b clang::ASTReader::ReadTemplateArgument(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 155 204 clang 0x00000001000c0de6 clang::ASTReader::ReadTemplateArgumentList(llvm::SmallVector&, llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 150 205 clang 0x00000001000bfeaf clang::ASTReader::ReadTypeRecord(unsigned int) + 8047 206 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 207 clang 0x00000001000c04c6 clang::ASTReader::ReadNestedNameSpecifier(llvm::SmallVector const&, unsigned int&) + 278 208 clang 0x00000001000dff0e clang::ASTStmtReader::VisitDeclRefExpr(clang::DeclRefExpr*) + 158 209 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 210 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 211 clang 0x00000001000d7f76 clang::ASTDeclReader::VisitVarDecl(clang::VarDecl*) + 390 212 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 213 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 214 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 215 clang 0x00000001000dff9c clang::ASTStmtReader::VisitDeclRefExpr(clang::DeclRefExpr*) + 300 216 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 217 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 218 clang 0x00000001000d7f76 clang::ASTDeclReader::VisitVarDecl(clang::VarDecl*) + 390 219 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 220 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 221 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 222 clang 0x00000001000dff9c clang::ASTStmtReader::VisitDeclRefExpr(clang::DeclRefExpr*) + 300 223 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 224 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 225 clang 0x00000001000c0762 clang::ASTReader::ReadTemplateArgument(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 482 226 clang 0x00000001000c0de6 clang::ASTReader::ReadTemplateArgumentList(llvm::SmallVector&, llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 150 227 clang 0x00000001000bfeaf clang::ASTReader::ReadTypeRecord(unsigned int) + 8047 228 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 229 clang 0x00000001000c0e9f clang::ASTReader::GetTypeSourceInfo(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 63 230 clang 0x00000001000d49d2 clang::ASTDeclReader::VisitTypedefDecl(clang::TypedefDecl*) + 98 231 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 232 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 233 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 234 clang 0x00000001000bf29b clang::ASTReader::ReadTypeRecord(unsigned int) + 4955 235 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 236 clang 0x00000001000bf69a clang::ASTReader::ReadTypeRecord(unsigned int) + 5978 237 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 238 clang 0x00000001000c061b clang::ASTReader::ReadTemplateArgument(llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 155 239 clang 0x00000001000c0de6 clang::ASTReader::ReadTemplateArgumentList(llvm::SmallVector&, llvm::BitstreamCursor&, llvm::SmallVector const&, unsigned int&) + 150 240 clang 0x00000001000bfeaf clang::ASTReader::ReadTypeRecord(unsigned int) + 8047 241 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 242 clang 0x00000001000be49d clang::ASTReader::ReadTypeRecord(unsigned int) + 1373 243 clang 0x00000001000bd52b clang::ASTReader::GetType(unsigned int) + 379 244 clang 0x00000001000dfcc0 clang::ASTStmtReader::VisitExpr(clang::Expr*) + 64 245 clang 0x00000001000e0fc2 clang::ASTStmtReader::VisitCastExpr(clang::CastExpr*) + 34 246 clang 0x00000001000e9417 clang::StmtVisitor::Visit(clang::Stmt*) + 2071 247 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 248 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 249 clang 0x00000001000d7f76 clang::ASTDeclReader::VisitVarDecl(clang::VarDecl*) + 390 250 clang 0x00000001000d23d8 clang::ASTDeclReader::Visit(clang::Decl*) + 24 251 clang 0x00000001000dc09c clang::ASTReader::ReadDeclRecord(unsigned int, unsigned int) + 2892 252 clang 0x00000001000c035d clang::ASTReader::GetDecl(unsigned int) + 205 253 clang 0x00000001000dff9c clang::ASTStmtReader::VisitDeclRefExpr(clang::DeclRefExpr*) + 300 254 clang 0x00000001000e87f1 clang::ASTReader::ReadStmtFromStream(llvm::BitstreamCursor&) + 11057 255 clang 0x00000001000e8b49 clang::ASTReader::ReadExpr(llvm::BitstreamCursor&) + 25 Stack dump: 0. Program arguments: /Users/luc/Developer/llvm/Release+Asserts/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name hybrid_times_ext.preprocessed.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.2 -resource-dir /Users/luc/Developer/llvm/Release+Asserts/lib/clang/2.9 -include-pch precompiled.h.gch -O3 -w -ferror-limit 19 -fmessage-length 104 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o hybrid_times_ext.o -x c++ hybrid_times_ext.preprocessed.cpp 1. /usr/include/i386/_types.h:37:1: current parser token 'typedef' clang: error: clang frontend command failed due to signal 4 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 09:39:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 11:39:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 8100] New: No way to prevent excessive constant propagation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8100 Summary: No way to prevent excessive constant propagation Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu Hello, consider this code: #include #include int main(){ double a=1.1; double b=10.1; fesetround(FE_UPWARD); assert(-((-a)*b)!=a*b); } Excessive optimization will remove the double negation. gcc has option -frounding-math to help with this. Intel's -fp-model strict is not quite as good (it fails for this example) but it helps (for instance it lets the code work if I write 1.1 and 10.1 instead of a and b in the assertion). With llvm-gcc or clang, this always fails at -O1. A similar option for llvm would be very welcome, there are applications where rounding in the appropriate direction is crucial (precision and speed come far behind). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 10:12:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 12:12:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8101] New: __has_nothrow_constructor failures Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8101 Summary: __has_nothrow_constructor failures Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hhinnant at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I believe __has_nothrow_constructor is failing for void types, arrays of unknown bounds, and classes with virtual destructors. Specifically I believe the following test should pass: template void test__has_nothrow_constructor() { static_assert(__has_nothrow_constructor(T) == Result, ""); } class VirtualDtor { virtual ~VirtualDtor(); }; int main() { test__has_nothrow_constructor(); test__has_nothrow_constructor(); test__has_nothrow_constructor(); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 10:17:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 12:17:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 8102] New: LICM crashes by dereferencing an invalid pointer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8102 Summary: LICM crashes by dereferencing an invalid pointer Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: release blocker Priority: P Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: benny.kra at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5464) --> (http://llvm.org/bugs/attachment.cgi?id=5464) reduced c++ testcase This one is a bit hard to reproduce and blocks i386 selfhost on FreeBSD (which has some malloc debugging enabled by default) The bugpoint-reduced file can be tested on darwin with MallocScribble or guard malloc: $ MallocScribble=1 opt -inline -licm -disable-output bugpoint-reduced-simplified.ll [1] 11068 segmentation fault MallocScribble=1 opt -inline -licm -disable-output The c++ test (which was reduced from llvm's DAGDeltaAlgorithm.cpp): $ MallocScribble=1 clang++ -m32 -O2 -c x.cpp Stack dump: 0. Program arguments: /Users/d0k/build/llvm/Debug+Asserts/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name x.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -target-cpu yonah -target-linker-version 97.14 -resource-dir /Users/d0k/build/llvm/Debug+Asserts/lib/clang/2.9 -O2 -ferror-limit 19 -fmessage-length 110 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o x.o -x c++ x.cpp 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'x.cpp'. 4. Running pass 'Loop Pass Manager' on function '@_ZNSt8_Rb_treeIjjSt9_IdentityIjESt4lessIjESaIjEE16_M_insert_uniqueISt23_Rb_tree_const_iteratorIjEEEvT_S9_' 5. Running pass 'Loop Invariant Code Motion' on basic block '%for.body' clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 11:49:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 13:49:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 4504] invalid output constraint '=o' in asm In-Reply-To: References: Message-ID: <20100907184958.B22E32A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4504 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Dale Johannesen 2010-09-07 13:49:58 CDT --- I recently fixed some missing X86-specific constraints, but this is generic. Fixed in 113246. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 13:01:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 15:01:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 8096] instcombine makes a call to sqrt dead but fails to remove it In-Reply-To: References: Message-ID: <20100907200154.27B492A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8096 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Chris Lattner 2010-09-07 15:01:53 CDT --- Fixed in r113260, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 13:27:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 15:27:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 8105] New: __has_trivial_copy does not work with void, arrays with incomplete or complete bounds Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8105 Summary: __has_trivial_copy does not work with void, arrays with incomplete or complete bounds Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hhinnant at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I expect all three of the following tests to fail: #include template void test() { T t(std::declval()); } int main() { test(); test(); test(); } I therefore expect all of __has_trivial_copy(void), __has_trivial_copy(int[3]), and __has_trivial_copy(int[]) to return false: template void test__has_trivial_copy() { static_assert(__has_trivial_copy(T) == Result, ""); } int main() { test__has_trivial_copy(); test__has_trivial_copy(); test__has_trivial_copy(); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 13:45:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 15:45:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 8081] -analyzer-check-objc-mem -analyzer-experimental-checks: Segmentation fault (core dumped) In-Reply-To: References: Message-ID: <20100907204552.DE8382A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8081 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |FIXED --- Comment #1 from Ted Kremenek 2010-09-07 15:45:52 CDT --- Fixed: http://llvm.org/viewvc/llvm-project?view=rev&revision=113282 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 13:49:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 15:49:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7972] Memory leaks in LLVM In-Reply-To: References: Message-ID: <20100907204914.ED21C2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7972 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |resistor at mac.com Resolution| |FIXED --- Comment #1 from Owen Anderson 2010-09-07 15:49:14 CDT --- Fixed in r113283. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 14:50:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 16:50:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7501] CXXNewExpr should remember source locations better In-Reply-To: References: Message-ID: <20100907215016.ED7A42A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7501 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-09-07 16:50:16 CDT --- Fixed in Clang r113291. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 15:05:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 17:05:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8106] New: clang fails with "AbstractTypeUser not in user list!" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8106 Summary: clang fails with "AbstractTypeUser not in user list!" Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: gonsolo at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5468) --> (http://llvm.org/bugs/attachment.cgi?id=5468) Reduced bugpoint testcase clang fails to compile only sometimes with the following error message: clang: /home/xxx/src/llvm/lib/VMCore/Type.cpp:1012: void llvm::Type::removeAbstractTypeUser(llvm::AbstractTypeUser *) const: Assertion `i != 0 && "AbstractTypeUser not in user list!"' failed. Stack dump: 0. Program arguments: /home/xxx/bin/clang -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name bugpoint-output.bc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir /home/xxx/lib/clang/2.8 -ferror-limit 19 -fmessage-length 177 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-2s6iXw.s -x ir bugpoint-output.bc clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) Attached is the reduced bugpoint output. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 15:06:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 17:06:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 8107] New: __has_nothrow_copy not working for some types Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8107 Summary: __has_nothrow_copy not working for some types Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hhinnant at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Here is a test that would be nice if it passed: template void test__has_nothrow_copy() { static_assert(__has_nothrow_copy(T) == Result, ""); } class NotEmpty { public: virtual ~NotEmpty(); }; int main() { test__has_nothrow_copy(); test__has_nothrow_copy(); test__has_nothrow_copy(); test__has_nothrow_copy(); } The __has_nothrow_copy trait fails to compile for void types, and arrays of unknown bounds. I believe it should compile and return false for those. I also believe it should return false for arrays of known bounds because one can not copy construct an array (even one of known bounds). I plan to open an LWG issue against N3126 on this last point. Finally, though it is a QOI issue, I believe clang should be able to detect that the NotEmpty example above has a non-trivial but nothrow copy constructor. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 15:35:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 17:35:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 8108] New: Missed optimization opportunity with duplicated conditional (JumpThreading?) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8108 Summary: Missed optimization opportunity with duplicated conditional (JumpThreading?) Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: resistor at mac.com CC: llvmbugs at cs.uiuc.edu See the attached .ll files. In particular, note this snippet: lor.rhs.i: %cmp9.i = icmp eq i32 %tmp2, 16 br label %_Z16sparc_floating_pPK4type.exit _Z16sparc_floating_pPK4type.exit: %call19 = phi i1 [ true, %sw.bb.i ], [ %cmp9.i, %lor.rhs.i ], [ true, %sw.bb.i ] %cmp = icmp eq i32 %tmp2, 16 %or.cond = and i1 %call19, %cmp br i1 %or.cond, label %if.end18, label %sw.bb.i24 Notice that the comparison of %tmp2 with 16 is repeated. If this edge were to be threaded by JumpThreading, GVN would pick up the duplication and get rid of it. However, because we can't actually determine a *value* for the comparison JumpThreading does not currently choose to thread this edge. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 15:36:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 17:36:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 8106] clang fails with "AbstractTypeUser not in user list!" In-Reply-To: References: Message-ID: <20100907223642.A68FB2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8106 gonsolo at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from gonsolo at gmail.com 2010-09-07 17:36:42 CDT --- Nevermind. It was my own (spoiled) branch of clang. :( -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 16:37:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 18:37:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 8109] New: __has_trivial_assign not working for void and arrays Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8109 Summary: __has_trivial_assign not working for void and arrays Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hhinnant at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Because I expect the following three tests to result in invalid code: #include template void test() { std::declval() = std::declval(); } int main() { test(); test(); test(); } I expect the following __has_trivial_assign tests to pass (return false): template void test__has_trivial_assign() { static_assert(__has_trivial_assign(T) == Result, ""); } int main() { test__has_trivial_assign(); test__has_trivial_assign(); test__has_trivial_assign(); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 17:35:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 19:35:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 8110] New: Type traits fail to compile for void and incomplete arrays Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8110 Summary: Type traits fail to compile for void and incomplete arrays Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sebastian.redl at getdesigned.at CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Due to following outdated GCC docs, Clang rejects code like __is_pod(void) and __is_pod(int[]). Such code should be accepted. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 17:49:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 19:49:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 8110] Type traits fail to compile for void and incomplete arrays In-Reply-To: References: Message-ID: <20100908004932.AB9432A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8110 Sebastian Redl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Sebastian Redl 2010-09-07 19:49:32 CDT --- Fixed in r113326 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 17:50:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 19:50:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 8097] __has_trivial_constructor doesn't work for void and arrays of unknown bound In-Reply-To: References: Message-ID: <20100908005006.C114C2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8097 Sebastian Redl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 17:51:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 19:51:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8109] __has_trivial_assign not working for void and arrays In-Reply-To: References: Message-ID: <20100908005101.3686D2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8109 Sebastian Redl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Sebastian Redl 2010-09-07 19:51:00 CDT --- Marking this fixed; leaving the debate about the correct value for arrays for another bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 21:35:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 23:35:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 6224] The x86 Disassembler (edis) is built even if x86 target is not selected -> build fails In-Reply-To: References: Message-ID: <20100908043555.A17D62A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6224 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-09-07 23:35:55 CDT --- This got fixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 21:37:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 23:37:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 6849] diagnostic could be improved slightly perhaps on long template match In-Reply-To: References: Message-ID: <20100908043743.C42642A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6849 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dgregor at apple.com, | |llvmbugs at cs.uiuc.edu Component|Frontend |C++ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 21:47:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 23:47:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 8095] -Wglobal-constructors false positive In-Reply-To: References: Message-ID: <20100908044717.7DB5D2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8095 Sebastian Redl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |sebastian.redl at getdesigned. | |at Resolution| |FIXED --- Comment #3 from Sebastian Redl 2010-09-07 23:47:17 CDT --- Fixed in r113344. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 21:53:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 23:53:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 8061] [MC] xchgl , rejected by MC assembler In-Reply-To: References: Message-ID: <20100908045354.725632A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8061 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Summary|[MC] xchgl instruction |[MC] xchgl , |unknown to MC |rejected by MC assembler --- Comment #3 from Chris Lattner 2010-09-07 23:53:54 CDT --- Fixed in r113346, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 21:53:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 23:53:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 8091] clang crash with member templates In-Reply-To: References: Message-ID: <20100908045355.0385E2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8091 Sebastian Redl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sebastian.redl at getdesigned. | |at Resolution| |WORKSFORME --- Comment #1 from Sebastian Redl 2010-09-07 23:53:54 CDT --- Can't reproduce. There's a good chance that Doug's recent source location patches fixed this. Reopen if you can still reproduce it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 21:58:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 7 Sep 2010 23:58:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 7691] wrong encoding of movq %rax, 0 In-Reply-To: References: Message-ID: <20100908045843.A12652A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7691 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2010-09-07 23:58:43 CDT --- This got fixed along the way: $ gcc t.s -c $ otool -tv t.o t.o: (__TEXT,__text) section 0000000000000000 movq %rax,0x00000000 $ otool -t t.o t.o: (__TEXT,__text) section 0000000000000000 48 89 04 25 00 00 00 00 $ llvm-mc t.s .section __TEXT,__text,regular,pure_instructions movq %rax, 0 [Nehalem:~/llvm] sabre% llvm-mc t.s -show-encoding .section __TEXT,__text,regular,pure_instructions movq %rax, 0 ## encoding: [0x48,0x89,0x04,0x25,0x00,0x00,0x00,0x00] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 22:02:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 00:02:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 7352] x86/llvm-mc missing instructions In-Reply-To: References: Message-ID: <20100908050204.4A1F12A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7352 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Chris Lattner 2010-09-08 00:02:03 CDT --- Here's an update: the first ambiguous instruction now gets a good diagnostic: t.s:1:1: error: ambiguous instructions require an explicit suffix (could be 'addb', 'addw', 'addl', or 'addq') add $1, 1(%esp) ^ The 1+(%eax) example won't be supported. The third one is movsx/movzx, which is tracked by PR 7459, so I'm closing this as done. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 7 22:17:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 00:17:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 7254] [MC] unrecognized instruction lock In-Reply-To: References: Message-ID: <20100908051759.AFD9F2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7254 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-09-08 00:17:59 CDT --- Implemented in r113348 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 05:43:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 07:43:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 8111] New: FoldingSetNodeID::AddString and endianness Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8111 Summary: FoldingSetNodeID::AddString and endianness Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: fvbommel at wxs.nl CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5471) --> (http://llvm.org/bugs/attachment.cgi?id=5471) proposed patch There's a bug in FoldingSetNodeID::AddString. On little-endian systems it hashes unaligned strings in a different way than aligned strings. ===== $ cat addstring-endianness.cpp #include "llvm/ADT/FoldingSet.h" #include using namespace llvm; using namespace std; int main() { FoldingSetNodeID a, b; // An aligned string string str1= "a test string"; a.AddString(str1.c_str()); printf("a: added '%s'\n", str1.c_str()); // An unaligned string string str2 = ">" + str1; b.AddString(str2.c_str() + 1); printf("b: added '%s'\n", str2.c_str() + 1); printf("%08x\n", a.ComputeHash()); printf("%08x\n", b.ComputeHash()); } $ g++ addstring-endianness.cpp `llvm-config --cxxflags --ldflags --libs` -o test && ./test a: added 'a test string' b: added 'a test string' 5393c06e 93b97eaf ===== After applying the attached patch: ===== $ g++ addstring-endianness.cpp `llvm-config --cxxflags --ldflags --libs` -o test && ./test a: added 'a test string' b: added 'a test string' 5393c06e 5393c06e ===== -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 08:21:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 10:21:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 8112] New: Missed optimization during register coalescing Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8112 Summary: Missed optimization during register coalescing Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Keywords: code-quality Severity: normal Priority: P Component: Register Allocator AssignedTo: unassignedbugs at nondot.org ReportedBy: borja.ferav at gmail.com CC: llvmbugs at cs.uiuc.edu Compiling the following C code with: $ clang -cc1 -triple thumbv5-u-u -S -O2 test.c -o - typedef unsigned long long t; t foo(t a, t b) { t a4 = b^a^18; return a4; } emits: eors r1, r3 mov r3, r0 eors r3, r2 movs r0, #18 eors r0, r3 bx lr instead of eors r1, r3 eors r0, r2 movs r4, #18 eors r0, r4 bx lr IR: define arm_aapcscc i64 @foo(i64 %a, i64 %b) nounwind readnone { entry: %xor = xor i64 %a, 18 ; [#uses=1] %xor2 = xor i64 %xor, %b ; [#uses=1] ret i64 %xor2 } The first move could be eliminated if the imm value is moved to a scratch register instead of moving it to r0 which is used as a return value register. I noticed this while developing a new backend, however it can be reproduced in ARM aswell (shown here), so it's not a backend issue. Jakob Stoklund did a great analysis explaining where the problem is that can be found here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-September/034430.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 10:28:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 12:28:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8113] New: MachineMemOperands not propageted in ARMLoadStoreOptimizer.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8113 Summary: MachineMemOperands not propageted in ARMLoadStoreOptimizer.cpp Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: ahatanak at gmail.com CC: llvmbugs at cs.uiuc.edu A potential bug in ARMLoadStoreOptimizer.cpp related to the questions asked in the following link (It doesn't seem to result in generation of incorrect code, but I am not sure whether it is correct not to propagate MachineMemOperands). http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-September/034485.html Here are the sample source file and .ll file I used. - input source file void f(int *a, int* b, int n) { int i = 0; for (i = 0; i < n - 1; ++i) b[i] = a[i] + a[i + 1]; } - bc file, generated by entering # llvm-gcc -emit-llvm -O3 -c f.c -o f.bc -m32 ; ModuleID = '' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-unknown-linux-gnu" define void @f(i32* nocapture %a, i32* nocapture %b, i32 %n) nounwind { entry: %0 = add nsw i32 %n, -1 ; [#uses=2] %1 = icmp sgt i32 %0, 0 ; [#uses=1] br i1 %1, label %bb, label %return bb: ; preds = %bb, %entry %i.03 = phi i32 [ %tmp, %bb ], [ 0, %entry ] ; [#uses=3] %scevgep = getelementptr i32* %a, i32 %i.03 ; [#uses=1] %scevgep4 = getelementptr i32* %b, i32 %i.03 ; [#uses=1] %tmp = add i32 %i.03, 1 ; [#uses=3] %scevgep5 = getelementptr i32* %a, i32 %tmp ; [#uses=1] %2 = load i32* %scevgep, align 4 ; [#uses=1] %3 = load i32* %scevgep5, align 4 ; [#uses=1] %4 = add nsw i32 %3, %2 ; [#uses=1] store i32 %4, i32* %scevgep4, align 4 %exitcond = icmp eq i32 %tmp, %0 ; [#uses=1] br i1 %exitcond, label %return, label %bb return: ; preds = %bb, %entry ret void } # gdb llc (gdb) b ARMLoadStoreOptimizer.cpp:1504 (gdb) r -march=arm -mcpu=cortex-a8 f.bc -o f.arm.s (gdb) p MF->dump() ... BB#2: derived from LLVM BB %bb Predecessors according to CFG: BB#1 BB#2 %reg16389 = PHI %reg16385, , %reg16394, ; GPR:%reg16389,16385,16394 %reg16390 = PHI %reg16388, , %reg16393, ; GPR:%reg16390,16388,16393 %reg16391 = PHI %reg16387, , %reg16392, ; GPR:%reg16391,16387,16392 %reg16399 = LDR %reg16390, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%scevgep9] GPR:%reg16399,16390 %reg16400 = LDR %reg16390, %reg0, 0, pred:14, pred:%reg0; mem:LD4[%lsr.iv3] GPR:%reg16400,16390 ... (gdb) fin (gdb) p MF->dump() ... BB#2: derived from LLVM BB %bb Predecessors according to CFG: BB#1 BB#2 %reg16389 = PHI %reg16385, , %reg16394, ; GPR:%reg16389,16385,16394 %reg16390 = PHI %reg16388, , %reg16393, ; GPR:%reg16390,16388,16393 %reg16391 = PHI %reg16387, , %reg16392, ; GPR:%reg16391,16387,16392 %reg16399, %reg16400 = LDRD %reg16390, %reg0, 260, pred:14, pred:%reg0; GPR:%reg16399,16400,16390 ... When the two LDR instructions are removed from the BB and a new LDRD instruction is added, the MachineMemOperands attached to the LDR instructions (mem:LD4[%scevgep9] and mem:LD4[%lsr.iv3]) do not get propagated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 11:04:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 13:04:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7231] LLVMContext's ownership rules are inconsistent with LLVM convention In-Reply-To: References: Message-ID: <20100908180401.506C02A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7231 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Owen Anderson 2010-09-08 13:04:01 CDT --- Improved/fixed in r113374. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 11:59:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 13:59:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 8114] New: outb %al, (%dx) --> error: invalid operand for instruction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8114 Summary: outb %al, (%dx) --> error: invalid operand for instruction Product: libraries Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu witten delta# cat foo.s outb %al, (%dx) witten delta# as foo.s && echo success success witten delta# llvm-mc foo.s .section __TEXT,__text,regular,pure_instructions foo.s:1:11: error: invalid operand for instruction outb %al, (%dx) ^ also, the diagnostics are pretty wrong too: witten delta# cat foo.s outb %al, (%dx) outw %al, (%dx) outl %al, (%dx) witten delta# llvm-mc foo.s .section __TEXT,__text,regular,pure_instructions foo.s:1:11: error: invalid operand for instruction outb %al, (%dx) ^ foo.s:3:6: error: invalid operand for instruction outl %al, (%dx) ^ ie. two warnings, now I put some spaces there: witten delta# cat foo.s outb %al, (%dx) outw %al, (%dx) outl %al, (%dx) witten delta# llvm-mc foo.s .section __TEXT,__text,regular,pure_instructions foo.s:1:11: error: invalid operand for instruction outb %al, (%dx) ^ foo.s:3:6: error: invalid operand for instruction outw %al, (%dx) ^ foo.s:5:6: error: invalid operand for instruction outl %al, (%dx) suddenly I have three warnings :) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 12:35:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 14:35:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 8099] Assertion failed with PCH in getTranslationUnitDecl, file DeclBase.cpp In-Reply-To: References: Message-ID: <20100908193517.13ED32A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8099 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Argyrios Kyrtzidis 2010-09-08 14:35:16 CDT --- Fixed at r113391. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 13:30:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 15:30:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8116] New: opt segfaults in GVN pass on klee_int.ll Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8116 Summary: opt segfaults in GVN pass on klee_int.ll Product: tools Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: opt AssignedTo: unassignedbugs at nondot.org ReportedBy: nobled at dreamwidth.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5472) --> (http://llvm.org/bugs/attachment.cgi?id=5472) reduced testcase of klee_int.ll Klee SVN checkout: r110352 LLVM: 2.7 (compiled from source) llvm-gcc: 2.7 (packaged in Ubuntu Lucid) Following the instructions on http://klee.llvm.org/GetStarted.html (which say to use LLVM 2.7 in case Klee isn't up to date with LLVM trunk), I can't build Klee because opt segfaults on klee_int.ll. Bugpoint-reduced test case attached. ../llvm-2.7/Release/bin/bugpoint -auto -std-compile-opts ./runtime/Intrinsic/Release/klee_int.ll *** You can reproduce the problem with: opt bugpoint-reduced-simplified.bc -gvn Klee make log: ---- llvm[2]: Compiling klee_init_env.c for Release build llvm[2]: Linking Release executable klee-replay (without symbols) llvm[2]: ======= Finished Linking Release Executable klee-replay (without symbols) make[2]: Leaving directory `/root/klee/tools/klee-replay' make[1]: Leaving directory `/root/klee/tools' make[1]: Entering directory `/root/klee/runtime' make[2]: Entering directory `/root/klee/runtime/Intrinsic' llvm[2]: Compiling klee_div_zero_check.c for Release build (bytecode) llvm[2]: Compiling klee_div_zero_check.ll to klee_div_zero_check.bc for Release build (bytecode) llvm[2]: Compiling klee_int.c for Release build (bytecode) llvm[2]: Compiling klee_int.ll to klee_int.bc for Release build (bytecode) 0 opt 0x084ad628 Stack dump: 0. Program arguments: /root/llvm-2.7/Release/bin/opt /root/klee/runtime/Intrinsic/Release/klee_int.ll -std-compile-opts -o /root/klee/runtime/Intrinsic/Release/klee_int.bc 1. Running pass 'CallGraph Pass Manager' on module '/root/klee/runtime/Intrinsic/Release/klee_int.ll'. 2. Running pass 'Global Value Numbering' on function '@klee_int' make[2]: *** [/root/klee/runtime/Intrinsic/Release/klee_int.bc] Segmentation fault make[2]: Leaving directory `/root/klee/runtime/Intrinsic' make[1]: *** [Intrinsic/.makeall] Error 2 make[1]: Leaving directory `/root/klee/runtime' make: *** [all] Error 1 --- -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 13:41:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 15:41:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 8116] opt segfaults in GVN pass on klee_int.ll In-Reply-To: References: Message-ID: <20100908204107.191B22A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8116 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |baldrick at free.fr Resolution| |WORKSFORME --- Comment #1 from Duncan Sands 2010-09-08 15:41:06 CDT --- I don't see this with opt from the latest LLVM subversion, or with the 2.8 release candidate (rc1). So it looks like the LLVM issue has been fixed already. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 14:43:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 16:43:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 8117] New: Crash with signal 11 when using PCH Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8117 Summary: Crash with signal 11 when using PCH Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: luc_j_bourhis at mac.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5473) --> (http://llvm.org/bugs/attachment.cgi?id=5473) self-contained code reproducing the bug - the top directory of the Boost library shall be found at $BOOSTROOT - replace the -I by what is appropriate if one does not work on MacOS X - expand the attachment, then cd clang-pch-2, then ~/Developer/Tests/clang-pch-2> clang --version clang version 2.9 (trunk 113403) Target: x86_64-apple-darwin10 Thread model: posix ~/Developer/Tests/clang-pch-2> clang++ -o boost_adaptbx/precompiled.h.gch -c -DBOOST_ALL_NO_LIB -DBOOST_DISABLE_THREADS -DBOOST_PYTHON_MAX_BASES=2 -x c++-header -fPIC -fno-strict-aliasing -w -DNDEBUG -O3 -I. -I$BOOSTROOT -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 boost_adaptbx/precompiled.h ~/Developer/Tests/clang-pch-2> clang++ -o meta_ext.o -c -DBOOST_ALL_NO_LIB -DBOOST_DISABLE_THREADS -DBOOST_PYTHON_MAX_BASES=2 -I/Users/luc/Developer/cctbx/boost -I. -fPIC -fno-strict-aliasing -w -DNDEBUG -O3 -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -include boost_adaptbx/precompiled.h boost_adaptbx/meta_ext.cpp 0 clang 0x00000001013794f2 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::sys::Path const&) + 11538 1 clang 0x000000010137a313 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::sys::Path const&) + 15155 2 libSystem.B.dylib 0x00007fff80e9935a _sigtramp + 26 3 libSystem.B.dylib 0x0000000000005b96 _sigtramp + 2132199510 4 clang 0x000000010050cfc2 llvm::SmallVectorImpl::operator=(llvm::SmallVectorImpl const&) + 45906 5 clang 0x00000001004a5d42 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 109714 6 clang 0x00000001004a63b4 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 111364 7 clang 0x00000001004a69ce llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 112926 8 clang 0x00000001004a70c2 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 114706 9 clang 0x000000010042caf1 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 224465 10 clang 0x0000000100533f09 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 151609 11 clang 0x00000001005196f2 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 43042 12 clang 0x000000010051836b clang::QualType::isMoreQualifiedThan(clang::QualType) const + 38043 13 clang 0x000000010051966b clang::QualType::isMoreQualifiedThan(clang::QualType) const + 42907 14 clang 0x0000000100533b95 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 150725 15 clang 0x00000001005196f2 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 43042 16 clang 0x000000010051c8bd clang::QualType::isMoreQualifiedThan(clang::QualType) const + 55789 17 clang 0x00000001005198f6 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 43558 18 clang 0x000000010051a9ba clang::QualType::isMoreQualifiedThan(clang::QualType) const + 47850 19 clang 0x0000000100519801 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 43313 20 clang 0x000000010051ba40 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 52080 21 clang 0x0000000100519a64 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 43924 22 clang 0x0000000100533fdf clang::QualType::isMoreQualifiedThan(clang::QualType) const + 151823 23 clang 0x000000010053aab4 llvm::cast_retty::ret_type llvm::cast(clang::QualType const&) + 4532 24 clang 0x000000010053c93c llvm::cast_retty::ret_type llvm::cast(clang::QualType const&) + 12348 25 clang 0x00000001005409c6 llvm::cast_retty::ret_type llvm::cast(clang::QualType const&) + 28870 26 clang 0x00000001005437b9 llvm::cast_retty::ret_type llvm::cast(clang::QualType const&) + 40633 27 clang 0x00000001005115d5 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 9989 28 clang 0x00000001005314b5 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 140773 29 clang 0x0000000100531b79 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 142505 30 clang 0x0000000100531467 clang::QualType::isMoreQualifiedThan(clang::QualType) const + 140695 31 clang 0x0000000100533b2f clang::QualType::isMoreQualifiedThan(clang::QualType) const + 150623 32 clang 0x0000000100544992 llvm::cast_retty::ret_type llvm::cast(clang::QualType const&) + 45202 33 clang 0x0000000100544294 llvm::cast_retty::ret_type llvm::cast(clang::QualType const&) + 43412 34 clang 0x0000000100544e39 llvm::cast_retty::ret_type llvm::cast(clang::QualType const&) + 46393 35 clang 0x0000000100544294 llvm::cast_retty::ret_type llvm::cast(clang::QualType const&) + 43412 36 clang 0x000000010032576f llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 9199 37 clang 0x0000000100312279 llvm::SmallVectorTemplateBase::grow(unsigned long) + 44057 38 clang 0x00000001002c081f llvm::GetElementPtrInst* llvm::GetElementPtrInst::CreateInBounds(llvm::Value*, llvm::Value**, llvm::Value**, llvm::Twine const&, llvm::Instruction*) + 559 39 clang 0x000000010027d73c llvm::IRBuilder >::CreateIsNull(llvm::Value*, llvm::Twine const&) + 5260 40 clang 0x0000000100053f49 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 6969 41 clang 0x00000001000288a4 std::_Rb_tree, std::less, std::allocator >::_M_erase(std::_Rb_tree_node*) + 3780 42 clang 0x0000000100020453 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 12771 43 clang 0x0000000100026fc4 std::vector >::operator=(std::vector > const&) + 11604 44 clang 0x000000010001eed8 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 7272 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name meta_ext.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.2 -resource-dir /usr/local/lib/clang/2.9 -include-pch boost_adaptbx/precompiled.h.gch -D BOOST_ALL_NO_LIB -D BOOST_DISABLE_THREADS -D BOOST_PYTHON_MAX_BASES=2 -D NDEBUG -I /Users/luc/Developer/cctbx/boost -I . -I /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -O3 -w -ferror-limit 19 -fmessage-length 104 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o meta_ext.o -x c++ boost_adaptbx/meta_ext.cpp 1. parser at end of file 2. /Users/luc/Developer/cctbx/boost/boost/python/object/py_function.hpp:46:46: instantiating function definition 'signature' 3. /Users/luc/Developer/cctbx/boost/boost/python/detail/caller.hpp:230:34: instantiating function definition 'signature' clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 15:34:18 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 17:34:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 8118] New: self-hosting broken Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8118 Summary: self-hosting broken Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: luc_j_bourhis at mac.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5474) --> (http://llvm.org/bugs/attachment.cgi?id=5474) The log produced by ./configure --enable-optimized CXX=clang On MacOS 10.6.4 with XCode 3.2.2, LLVM + Clang trunk r113403 ./configure --enable-optimized CXX=clang make fails at llvm[2]: Linking Release+Asserts executable FileCheck (without symbols) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 15:40:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 17:40:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 8118] self-hosting broken In-Reply-To: References: Message-ID: <20100908224020.5E7D12A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8118 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Douglas Gregor 2010-09-08 17:40:20 CDT --- You need to configure with CC=clang CXX=clang++ for self-host. All of the link failures are due to the standard library not being linked in. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 17:43:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 8 Sep 2010 19:43:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 8119] New: missing typename in function prototype is parsed as variable declaration Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8119 Summary: missing typename in function prototype is parsed as variable declaration Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This code snippet is invalid and is rejected by both gcc and clang: template class Map { public: class Iterator { }; }; template void f1(Map::Iterator v) { } but what's wrong? Let's ask clang: test.cc:9:6: error: variable 'f1' declared as a template void f1(Map::Iterator v) { ^ test.cc:9:27: error: expected ')' void f1(Map::Iterator v) { ^ test.cc:9:8: note: to match this '(' void f1(Map::Iterator v) { ^ test.cc:9:29: error: expected ';' at end of declaration void f1(Map::Iterator v) { ^ ; test.cc:9:30: error: expected unqualified-id void f1(Map::Iterator v) { ^ 4 errors generated. This is a terrible diagnostic. It sounds like things go wrong when clang decides that f1 is a variable instead of a function. The desired diagnostic is the fixit that says where to insert 'typename' before Map. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 8 23:02:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 01:02:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 6059] Insuficent allignment on call on ARM In-Reply-To: References: Message-ID: <20100909060249.05EAF2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6059 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #14 from Rafael Ávila de Espíndola 2010-09-09 01:02:47 CDT --- The correctness issue is long fixed (thanks Bob!). I also posted my patch that splits the arguments in the IL. In any case, we can close this bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 9 01:43:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 03:43:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8120] New: 2.8 branch fails to compile Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8120 Summary: 2.8 branch fails to compile Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bero at arklinux.org CC: llvmbugs at cs.uiuc.edu Building llvm and clang from today's 2.8 branches fails: ASTWriter.cpp:781:20: error: invalid suffix "rc" on integer constant The problem is that ASTWriter.cpp assumes CLANG_VERSION_MINOR is an integer while the build tools in 2.8 branch produce #define CLANG_VERSION_MINOR 8rc in include/clang/Basic/Version.inc -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 9 04:32:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 06:32:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 8117] Crash with signal 11 when using PCH In-Reply-To: References: Message-ID: <20100909113251.481602A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8117 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Argyrios Kyrtzidis 2010-09-09 06:32:50 CDT --- Fixed at r113481. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 9 07:28:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 09:28:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 8121] New: clang doesn't find STL headers and library Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8121 Summary: clang doesn't find STL headers and library Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bero at arklinux.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This is with a current checkout of the 2.8 branch (that version isn't listed in bugzilla) Not sure if this is a bug or a feature [e.g. to make it easier to use libc++ or some other alternative STL], but it's unexpected: [bero at matterhorn ~]$ cat >test.cpp #include int main(int argc, char **argv) { std::cout << "Test" << std::endl; } [bero at matterhorn ~]$ clang test.cpp test.cpp:1:10: fatal error: 'iostream' file not found #include ^ 1 error generated. [bero at matterhorn ~]$ clang -I/usr/include/c++/4.5.1 -I/usr/include/c++/4.5.1/x86_64-unknown-linux-gnu test.cpp /tmp/cc-6CmGWX.o: In function `__cxx_global_var_init': test.cpp:(.text+0xc): undefined reference to `std::ios_base::Init::~Init()' test.cpp:(.text+0x30): undefined reference to `std::ios_base::Init::Init()' /tmp/cc-6CmGWX.o: In function `main': test.cpp:(.text+0x60): undefined reference to `std::basic_ostream >& std::endl >(std::basic_ostream >&)' test.cpp:(.text+0x6b): undefined reference to `std::cout' test.cpp:(.text+0x91): undefined reference to `std::basic_ostream >& std::operator<< >(std::basic_ostream >&, char const*)' test.cpp:(.text+0x9d): undefined reference to `std::basic_ostream >::operator<<(std::basic_ostream >& (*)(std::basic_ostream >&))' collect2: ld returned 1 exit status clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation) [bero at matterhorn ~]$ clang -I/usr/include/c++/4.5.1 -I/usr/include/c++/4.5.1/x86_64-unknown-linux-gnu test.cpp -lstdc++ [works as expected] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 9 07:29:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 09:29:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 8122] New: 2.8 isn't listed in versions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8122 Summary: 2.8 isn't listed in versions Product: Bugzilla Admin Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Products AssignedTo: unassignedbugs at nondot.org ReportedBy: bero at arklinux.org CC: llvmbugs at cs.uiuc.edu llvm and clang 2.8 have been branched -- it would probably be good to add 2.8 in the list of available versions in bugzilla for people who want to report bugs in the 2.8 branch -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 9 07:59:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 09:59:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 8121] clang doesn't find STL headers and library In-Reply-To: References: Message-ID: <20100909145944.61DF72A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8121 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Douglas Gregor 2010-09-09 09:59:43 CDT --- Please see http://clang.llvm.org/get_started.html for the fix. Also, use "clang++" to get the compiler to automatically link against the C++ standard library. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 9 13:15:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 15:15:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 8120] 2.8 branch fails to compile In-Reply-To: References: Message-ID: <20100909201559.765C32A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8120 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bill Wendling 2010-09-09 15:15:59 CDT --- Fixed in the branch as r113532. Here's the patch to apply to tools/clang: Index: include/clang/Basic/Makefile =================================================================== --- include/clang/Basic/Makefile (revision 113530) +++ include/clang/Basic/Makefile (working copy) @@ -16,6 +16,7 @@ # Compute the Clang version from the LLVM version, unless specified explicitly. ifndef CLANG_VERSION CLANG_VERSION := $(subst svn,,$(LLVMVersion)) +CLANG_VERSION := $(subst rc,,$(CLANG_VERSION)) endif CLANG_VERSION_COMPONENTS := $(subst ., ,$(CLANG_VERSION)) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 9 15:45:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 17:45:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8123] New: -init always treated as release, even when you can prove it isn't. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8123 Summary: -init always treated as release, even when you can prove it isn't. Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu The analyser generates this: obj = [c allocWithZone: zone]; - 6 Method returns an Objective-C object with a +1 retain count (owning reference) 655 GSIArrayAddItem(objMap, (GSIArrayItem)obj); 656 657 rep = [obj initWithCoder: self]; - 7 Object released 658 if (rep != obj) -8 Taking false branch 659 { 660 obj = rep; 661 GSIArraySetItemAtIndex(objMap, (GSIArrayItem)obj, xref); 662 } 663 664 rep = [obj awakeAfterUsingCoder: self]; -9 Reference-counted object is used after it is released The false branch is taken if rep == obj. In this case, obj is not used after being released, because obj is rep, therefore obj was not released. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 9 15:56:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 17:56:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 8124] New: copy is only important at the start of a method name Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8124 Summary: copy is only important at the start of a method name Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu The analyser produces this: d = [NSDataClass dataWithBytesNoCopy: b length: l]; - 6 Method returns an Objective-C object with a +1 retain count (owning reference) It appears to be treating this method as returning an owning reference because it contains the word copy. It should be checking if the method starts with copy (e.g. -copy, -copyWithZone:). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 9 18:08:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 9 Sep 2010 20:08:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 8124] copy is only important at the start of a method name In-Reply-To: References: Message-ID: <20100910010819.D596C2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8124 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Ted Kremenek 2010-09-09 20:08:19 CDT --- Confirmed. From the Cocoa naming conventions: "You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example,alloc, newObject, or mutableCopy), or if you send it a retain message." Official guidelines here: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html%23//apple_ref/doc/uid/20000994-BAJHFBGH -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 10 01:56:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Sep 2010 03:56:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 8124] copy is only important at the start of a method name In-Reply-To: References: Message-ID: <20100910085645.BFDB12A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8124 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #3 from David Chisnall 2010-09-10 03:56:45 CDT --- In that case, the guidelines are either incorrect or are case sensitive. The Cocoa APIs contain several examples of methods that have Copy in their names. Lots of things that take pointers as arguments have either Copy or NoCopy in the argument name. The one shown in this bug report is a good example - dataWithBytesNoCopy: is a Cocoa method which returns an autoreleased instance. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 10 06:37:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Sep 2010 08:37:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8125] New: switches over a 2-bit domain lowered inefficiently Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8125 Summary: switches over a 2-bit domain lowered inefficiently Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: ggreif at gmail.com CC: llvmbugs at cs.uiuc.edu Consider this C++ program: ########################################## struct Foo { void* tagged; Foo* follow(void); Foo* collect(unsigned = 1); }; Foo* Foo::follow(void) { int t = (unsigned long)tagged & 0x3; switch (t) { case 0: case 1: return (this + 1)->follow(); case 3: return this + 1; case 2: return (this + 1)->collect(); } } Foo* Foo::collect(unsigned acc) { int t = (unsigned long)tagged & 0x3; switch (t) { case 0: case 1: return (this + 1)->collect((acc << 1) | t); case 3: return this + 1; case 2: return this + 1 + acc; } } ########################################## Clang compiles the second function to: ########################################## define %struct.Foo* @_ZN3Foo7collectEj(%struct.Foo* %this, i32 %acc) nounwind readonly align 2 { entry: br label %tailrecurse tailrecurse: ; preds = %sw.bb, %entry %indvar = phi i64 [ %indvar.next, %sw.bb ], [ 0, %entry ] %acc.tr = phi i32 [ %or, %sw.bb ], [ %acc, %entry ] %tmp = getelementptr inbounds %struct.Foo* %this, i64 %indvar, i32 0 %tmp2 = load i8** %tmp, align 8 %0 = ptrtoint i8* %tmp2 to i64 %and = and i64 %0, 3 %conv = trunc i64 %and to i32 switch i32 %conv, label %sw.epilog [ i32 0, label %sw.bb i32 1, label %sw.bb i32 3, label %sw.bb6 i32 2, label %sw.bb8 ] sw.bb: ; preds = %tailrecurse, %tailrecurse %shl = shl i32 %acc.tr, 1 %or = or i32 %conv, %shl %indvar.next = add i64 %indvar, 1 br label %tailrecurse sw.bb6: ; preds = %tailrecurse %this.tr.sum21 = add i64 %indvar, 1 %add.ptr7 = getelementptr inbounds %struct.Foo* %this, i64 %this.tr.sum21 ret %struct.Foo* %add.ptr7 sw.bb8: ; preds = %tailrecurse %idx.ext = zext i32 %acc.tr to i64 %add.ptr9.sum = add i64 %idx.ext, 1 %this.tr.sum = add i64 %indvar, %add.ptr9.sum %add.ptr11 = getelementptr inbounds %struct.Foo* %this, i64 %this.tr.sum ret %struct.Foo* %add.ptr11 sw.epilog: ; preds = %tailrecurse ret %struct.Foo* undef } ########################################## With a pretty switch statement inside. As an aside, I get clang warnings: Release+Asserts/bin/clang++ -O2 switch.cpp -o switch.O2.ll -emit-llvm -S -fno-exceptions switch.cpp:21:1: warning: control may reach end of non-void function [-Wreturn-type] } ^ switch.cpp:35:1: warning: control may reach end of non-void function [-Wreturn-type] } ^ 2 warnings generated. These are an inability in clang to see that the AND mask has 2 bits, which admits 4 combinations and that all are covered in the switch instruction. Also the default switch arm (returning undefined arises from this). Meta-question can the switch be written as: "switch i32 %conv, undefined [...]"? Okay, now let's look at the generated assembly (x86-64) of the first function: ########################################## _ZN3Foo6followEv: .Leh_func_begin0: pushq %rbp .Ltmp0: movq %rsp, %rbp .Ltmp1: movl $2, %ecx movq %rdi, %rdx leaq 8(%rdi), %rax leaq 16(%rdi), %rsi jmp .LBB0_1 .align 16, 0x90 .LBB0_9: addq $8, %rax incq %rcx addq $8, %rsi .LBB0_1: movl -16(%rsi), %edi andl $3, %edi ;; we should jz here cmpl $2, %edi jb .LBB0_9 cmpl $3, %edi ;; no need for this compare je .LBB0_10 cmpl $2, %edi ;; no need for this compare jne .LBB0_13 movl $1, %eax .align 16, 0x90 .LBB0_5: movl -8(%rsi), %edi andl $3, %edi ;; we should jz here cmpl $3, %edi ;; comparing with 2 would allow "trisection" je .LBB0_11 cmpl $2, %edi ;; no need for this compare je .LBB0_12 cmpl $1, %edi ;; no need for this compare ja .LBB0_13 addl %eax, %eax orl %edi, %eax incq %rcx addq $8, %rsi jmp .LBB0_5 .LBB0_10: popq %rbp ret .LBB0_11: movq %rsi, %rax popq %rbp ret .LBB0_12: movl %eax, %eax addq %rcx, %rax leaq (%rdx,%rax,8), %rax .LBB0_13: popq %rbp ret .Ltmp2: .size _ZN3Foo6followEv, .Ltmp2-_ZN3Foo6followEv .Leh_func_end0: ########################################## I have commented stuff that looks very inefficient. I can imagine a target independent lowering of a 2-bit value domain (the AND-mask having popcnt=2 with the zero-value peeled off immediately after the AND) like this: Enumerate the 3 possible values in order: x < y < z compare against y, if eq ---> leg for y if smaller ---> leg for x if bigger ---> leg for z Look 'ma, only one compare! When the 2 bits of the mask are adjacent, then on targets which have a rcr (rotate with carry) one could rotate the upper bit into the carry flag and the next bit would end up in the minus flag. This would allow a 4-way branch. On other targets (PPC) we could move to condition code register and have a multi-way branch too. Links: http://docs.sun.com/app/docs/doc/802-1948/6i5uqa9p5?l=en&a=view -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 10 10:06:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Sep 2010 12:06:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 8126] New: Strange behaviour with integer promotion on x86-64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8126 Summary: Strange behaviour with integer promotion on x86-64 Product: clang Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu I have some code in a simple inline function: static INLINE void GSIMapRightSizeMap(GSIMapTable map, uintptr_t capacity) { if (3 * capacity >= 4 * map->bucketCount) { GSIMapResize(map, (3 * capacity)/4 + 1); } } This code crashes while evaluating the 4 * map->bucketCount expression with a segfault. I've eliminated the possibility that map is an invalid pointer and added some debugging statements: printf("Map: %p\n", map); printf("Map: %lx\n", map->bucketCount); printf("Map: %lx\n", (uintptr_t)(4 * (int)map->bucketCount)); printf("Map: %lx\n", (4 * map->bucketCount)); Here, map is a pointer to a structure and the bucketCount field is an uintptr_t, which is a 64-bit quantity on the target architecture (x86-64). The output from this is: Map: 0x802008b10 Map: 0 Map: 0 Program received signal SIGBUS, Bus error. The first line was just sanity checking, to see if the debugger was getting the same address for map as the code - it was. Inspecting this pointer in the debugger shows that map is a valid value. The value of the field is 0 - both the debugger and the second print statement agree on this. The value of the field cast to an int and multiplied by 4 is 0. Attempting to multiply the field by a 4, either as the literal 4 or as ((uintptr_t) 4), crashes. Similarly, this line generates a crash: uintptr_t p = 4 * map->bucketCount; However, this works correctly: uintptr_t p = map->bucketCount * 4; I therefore assume that something is going a bit wrong with the integer promotion code. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 10 16:51:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Sep 2010 18:51:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 8127] New: Templated Default Arguments in C++ Member Functions Not Left Unevaluated Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8127 Summary: Templated Default Arguments in C++ Member Functions Not Left Unevaluated Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: colin at colinsmith.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I just started trying to get Clang to compile a rather large piece of scientific code and ran into a problem that I'm not sure is a bug or a violation of the C++ spec. The codebase uses smart-pointers which are templated on classes that are subclasses of a reference counted class (like Boost intrusive_ptr). To cut down on compile time, many of those subclasses are forward declared, which Clang handles great. The problem comes when one of those forward declared subclasses is used as an argument in a member function and given a default value. A very stripped down snippet of code which reproduces the error is the following: template< typename T > class PointerClass { public: PointerClass( T * object_p ) : p_( object_p ) { p_->acquire(); } private: T * p_; }; class ExternallyImplementedClass; class MyClass { void foo( PointerClass = 0 ); }; int main(void) { return 0; } This compiles fine with gcc (and probably Visual C++), but produces an error with Clang. The error goes away if the "= 0" is removed. The error produced is the following: clang_test.cc:4:5: error: member access into incomplete type 'ExternallyImplementedClass' p_->acquire(); ^ clang_test.cc:13:55: note: in instantiation of member function 'PointerClass::PointerClass' requested here void foo( PointerClass = 0 ); ^ clang_test.cc:10:7: note: forward declaration of 'ExternallyImplementedClass' class ExternallyImplementedClass; ^ 1 error generated. Because the foo function is never used and its implementation would be in another file, I'm not sure why PointerClass would be getting instantiated. When a piece of code would be using foo, it would have access to the full header for ExternallyImplementedClass and make instantiation possible. Comment from Douglas Gregor off the e-mail list: This is definitely a bug in Clang. We're not treating default arguments as unevaluated contexts, so we perform template instantiation when we shouldn't. Could you file this as a bug against Clang? - Doug -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 10 20:13:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Sep 2010 22:13:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 8128] New: Index/complete-at-exprstmt.m Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8128 Summary: Index/complete-at-exprstmt.m Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu This is a 2.8 blocker. On make check, test/Index/complete-at-exprstmt.m fails in release mode: Unhandled CXCursorKind UNREACHABLE executed at /home/nicholas/2.8-rc1/llvmCore-2.8-rc1.src/tools/clang/tools/libclang/CIndex.cpp:2581! 0 libclang.so 0x00002b8eb19a64bf 1 libclang.so 0x00002b8eb19a6b49 2 libpthread.so.0 0x00002b8eb1c1df60 3 libc.so.6 0x00002b8eb280e420 sigprocmask + 16 4 libclang.so 0x00002b8eb1984098 5 libpthread.so.0 0x00002b8eb1c1df60 6 libc.so.6 0x00002b8eb280e165 gsignal + 53 7 libc.so.6 0x00002b8eb2810f70 abort + 384 8 libclang.so 0x00002b8eb198663d 9 libclang.so 0x00002b8eb14bdb29 clang_getCursorKindSpelling + 873 10 c-index-test 0x0000000000404169 11 c-index-test 0x000000000040626f 12 c-index-test 0x00000000004067cf main + 79 13 libc.so.6 0x00002b8eb27fac4d __libc_start_main + 253 14 c-index-test 0x0000000000402b79 Aborted /home/nicholas/2.8-rc1/llvmCore-2.8-rc1.src/tools/clang/test/Index/complete-at-exprstmt.m:30:15: error: expected string not found in input // CHECK-CC2: {TypedText encode}{LeftParen (}{Placeholder type-name}{RightParen )} ^ :1:1: note: scanning from here NotImplemented:{TypedText dynamic}{HorizontalSpace }{Placeholder property} (30) ^ :1:16: note: possible intended match here NotImplemented:{TypedText dynamic}{HorizontalSpace }{Placeholder property} (30) ^ -- The log shows that it ran: c-index-test -code-completion-at=/home/nicholas/2.8-rc1/llvmCore-2.8-rc1.src/too ls/clang/test/Index/complete-at-exprstmt.m:9:19 -Xclang -code-completion-pattern s /home/nicholas/2.8-rc1/llvmCore-2.8-rc1.src/tools/clang/test/Index/complete-at -exprstmt.m but of course, running that myself with the c-index-test built by test-release.sh doesn't reproduce the problem. It's even valgrind-clean. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 10 22:54:07 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Sep 2010 00:54:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 8129] New: clang++ not suppressing warnings in standard headers. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8129 Summary: clang++ not suppressing warnings in standard headers. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: lhames at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5478) --> (http://llvm.org/bugs/attachment.cgi?id=5478) Test case. Running clang++ -Wall -Werror -c test.cpp on the attached test case (an empty c++ file which #includes valarray) terminates with warnings treated as errors (attached below). I think this should be suppressed for standard headers, right? System is Ubuntu Linux 10.04 (AMD64). - Lang. clang++ output: error: class '_Array' was previously declared as a struct [-Wmismatched-tags] In file included from foo.cpp:1: In file included from /usr/include/c++/4.4/valarray:561: /usr/include/c++/4.4/bits/valarray_after.h:57:24: note: in instantiation of template class 'std::valarray' requested here { return _M_index.size(); } ^ In file included from foo.cpp:1: In file included from /usr/include/c++/4.4/valarray:86: /usr/include/c++/4.4/bits/valarray_array.h:409:12: note: previous use is here struct _Array ^ error: class '_Array' was previously declared as a struct [-Wmismatched-tags] In file included from foo.cpp:1: In file included from /usr/include/c++/4.4/valarray:565: /usr/include/c++/4.4/bits/mask_array.h:143:27: note: in instantiation of template class 'std::valarray' requested here : _M_sz(__s), _M_mask(__m), _M_array(__a) {} ^ In file included from foo.cpp:1: In file included from /usr/include/c++/4.4/valarray:86: /usr/include/c++/4.4/bits/valarray_array.h:409:12: note: previous use is here struct _Array ^ 2 errors generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 13:26:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Sep 2010 15:26:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 8127] Templated Default Arguments in C++ Member Functions Not Left Unevaluated In-Reply-To: References: Message-ID: <20100911202606.58D1D2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8127 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-09-11 15:26:05 CDT --- Fixed in Clang r113700. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 13:26:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Sep 2010 15:26:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 5810] default argument in class template constructor not instantiated In-Reply-To: References: Message-ID: <20100911202634.176482A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5810 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #5 from Douglas Gregor 2010-09-11 15:26:33 CDT --- Fixed in Clang r113700. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 13:30:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Sep 2010 15:30:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 6384] GNU extension: in-class initialization of static const float data members In-Reply-To: References: Message-ID: <20100911203050.29DE62A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6384 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-09-11 15:30:49 CDT --- John implemented support for this extension in Clang r113663. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 15:45:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Sep 2010 17:45:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 8130] New: Clang fails to partially order overloaded operators correctly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8130 Summary: Clang fails to partially order overloaded operators correctly Product: clang Version: 2.7 Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: faisalv at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang fails to partially order overloaded operators correctly. Here is an example that clang fails to compile, from the standard (n3126-C++0x FCD): 14.5.6.2 [temp.func.order] p3 struct A { }; template struct B { template int operator*(R&); // #1 }; template int operator*(T&, R&); // #2 // The declaration of B::operator* is transformed into the equivalent of // template int operator*(B&, R&); // #1a int main() { A a; B b; b * a; // calls #1a } clang -cc1 test.cpp test.cpp:13:3: error: use of overloaded operator '*' is ambiguous b * a; // calls #1a ~ ^ ~ test.cpp:4:23: note: candidate function [with $0 = A] template int operator*(R&); // #1 ^ test.cpp:7:32: note: candidate function [with T = B, R = A] template int operator*(T&, R&); // #2 ^ 1 error generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 15:48:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Sep 2010 17:48:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 7276] [cygwin] C++ programs compiled with clang++ fail to link In-Reply-To: References: Message-ID: <20100911224836.894492A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7276 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dimitry at andric.com Resolution| |FIXED --- Comment #10 from Dimitry Andric 2010-09-11 17:48:35 CDT --- Patch from comment #3 was applied: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100906/034471.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 20:41:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Sep 2010 22:41:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 8089] clang crashes when an enum forward declaration is used in cast In-Reply-To: References: Message-ID: <20100912034134.402472A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8089 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-09-11 22:41:33 CDT --- Fixed in Clang r113711. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 21:28:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Sep 2010 23:28:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 8087] operator overloading for enums is ambiguous In-Reply-To: References: Message-ID: <20100912042833.C262E2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8087 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-09-11 23:28:33 CDT --- Fixed in Clang r113713. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 22:25:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 00:25:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 8084] No namespace awareness of static template fields In-Reply-To: References: Message-ID: <20100912052551.D3B392A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8084 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Douglas Gregor 2010-09-12 00:25:51 CDT --- When the code obeys the C++0x semantics but not the C++98/03 semantics (as the examples described here do), I've downgraded the error to a warning in Clang r113718. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 22:27:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 00:27:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 5970] Implement precompiled headers for C++ In-Reply-To: References: Message-ID: <20100912052736.634A92A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5970 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-09-12 00:27:35 CDT --- Precompiled headers are now implemented for C++. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 11 23:06:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 01:06:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 8131] New: alpha: ICE at gcc/libgcc2.c:567 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8131 Summary: alpha: ICE at gcc/libgcc2.c:567 Product: libraries Version: trunk Platform: DEC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: Alpha AssignedTo: unassignedbugs at nondot.org ReportedBy: mattst88 at gmail.com CC: llvmbugs at cs.uiuc.edu _muldi3.o Both operands to a binary operator are not of the same type! %24 = lshr i128 %23, i64 64, !dbg !37 Instruction does not dominate all uses! %24 = lshr i128 %23, i64 64, !dbg !37 %25 = trunc i128 %24 to i64, !dbg !37 Instruction does not dominate all uses! %25 = trunc i128 %24 to i64, !dbg !37 store i64 %25, i64* %27, align 8, !dbg !37 Broken module found, compilation aborted! /var/tmp/portage/sys-devel/llvm-gcc-9999/work/llvm-gcc-9999/gcc/libgcc2.c: In function '__multi3': /var/tmp/portage/sys-devel/llvm-gcc-9999/work/llvm-gcc-9999/gcc/libgcc2.c:567: internal compiler error: Aborted -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 12 00:22:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 02:22:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 8065] false positive warning due to template meta-programming In-Reply-To: References: Message-ID: <20100912072241.6BDC52A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8065 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-09-12 02:22:41 CDT --- Fixed in Clang r113722. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 12 00:29:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 02:29:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 8055] using declaration not adding template candidates? In-Reply-To: References: Message-ID: <20100912072910.66E502A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8055 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Douglas Gregor 2010-09-12 02:29:09 CDT --- Clang is behaving correctly per C++ [namespace.udecl]p15: When a using-declaration brings names from a base class into a derived class scope, member functions and member function templates in the derived class override and/or hide member functions and member function templates with the same name, parameter-type-list (8.3.5), cv-qualification, and ref-qualifier (if any) in a base class (rather than conflicting). Note that Foo in the derived class has the same name and parameter-type-list as Foo in the base class, so the derived Foo hides the base Foo. The template parameters are not considered. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 12 00:37:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 02:37:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 8047] clang++ incorrectly accepts instantiating dependent declaration with function type In-Reply-To: References: Message-ID: <20100912073737.83CEF2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8047 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-09-12 02:37:37 CDT --- Fixed in Clang r113723. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 12 01:07:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 03:07:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 8034] clang c++ crash explicitly calling overloaded templated conversion operator In-Reply-To: References: Message-ID: <20100912080738.8B5652A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8034 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-09-12 03:07:37 CDT --- Fixed in Clang r113724. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 12 01:16:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 03:16:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 8033] clang c++ assertion "no most-specialized template" with ambiguous template overloads In-Reply-To: References: Message-ID: <20100912081621.DF0D12A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8033 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-09-12 03:16:21 CDT --- Fixed in Clang r113725. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 12 14:47:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 16:47:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 8132] New: signal 11 while analyzing a file with clang from 2.8 branch Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8132 Summary: signal 11 while analyzing a file with clang from 2.8 branch Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bero at arklinux.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5481) --> (http://llvm.org/bugs/attachment.cgi?id=5481) Original file showing the problem Using current 2.8 branch, I get this: [bero at matterhorn QtExt]$ clang -I. -I/usr/include/QtCore -v --analyze MD5.cpp clang version 2.8 (branches/release_28) Target: x86_64-unknown-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -analyze -disable-free -disable-llvm-verifier -main-file-name MD5.cpp -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-check-dead-stores -analyzer-check-objc-mem -analyzer-eagerly-assume -analyzer-check-objc-methodsigs -analyzer-check-objc-unused-ivars -analyzer-check-idempotent-operations -analyzer-output plist -w -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51.0.11.20100810 -v -resource-dir /usr/lib/clang/2.8 -I . -I /usr/include/QtCore -ferror-limit 19 -fmessage-length 82 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o MD5.plist -x c++ MD5.cpp clang -cc1 version 2.8 based upon llvm 2.8rc hosted on x86_64-unknown-linux-gnu #include "..." search starts here: #include <...> search starts here: . /usr/include/QtCore /usr/include/c++/4.5.1 /usr/include/c++/4.5.1/x86_64-unknown-linux-gnu /usr/include/c++/4.5.1/backward /usr/local/include /usr/lib/clang/2.8/include /usr/include End of search list. Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -analyze -disable-free -disable-llvm-verifier -main-file-name MD5.cpp -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-check-dead-stores -analyzer-check-objc-mem -analyzer-eagerly-assume -analyzer-check-objc-methodsigs -analyzer-check-objc-unused-ivars -analyzer-check-idempotent-operations -analyzer-output plist -w -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51.0.11.20100810 -v -resource-dir /usr/lib/clang/2.8 -I . -I /usr/include/QtCore -ferror-limit 19 -fmessage-length 82 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o MD5.plist -x c++ MD5.cpp 1. parser at end of file 2. MD5.cpp:135:2: Error evaluating statement 3. MD5.cpp:135:2: Error evaluating statement clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) Attaching the file triggering the problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 12 16:08:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 18:08:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 8133] New: JIT failure on MultiSource/Applications/spiff/spiff Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8133 Summary: JIT failure on MultiSource/Applications/spiff/spiff Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu This is what's left behind in Output/spiff.out-jit after a nightly test run using the Phase2 Release build of the 2.8 rc1 release candidate. Note that the machine has 4GB RAM so this is probably not a legitimate OOM failure: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc 0 lli 0x0000000000a542ff 1 lli 0x0000000000a54989 2 libpthread.so.0 0x00002b2630164f60 3 libc.so.6 0x00002b2630d56165 gsignal + 53 4 libc.so.6 0x00002b2630d58f70 abort + 384 5 libstdc++.so.6 0x00002b2630643dc5 __gnu_cxx::__verbose_terminate_handler() + 277 6 libstdc++.so.6 0x00002b2630642166 7 libstdc++.so.6 0x00002b2630642193 8 libstdc++.so.6 0x00002b263064228e 9 libstdc++.so.6 0x00002b263064271d operator new(unsigned long) + 125 10 lli 0x000000000077d9e5 _ZNSt6vectorISt4pairIPKN4llvm19TargetRegisterClassEPNS1_14MachineOperandEESaIS7_EE7reserveEm + 69 11 lli 0x000000000077c885 _ZN4llvm19MachineRegisterInfoC2ERKNS_18TargetRegisterInfoE + 149 12 lli 0x0000000000766052 _ZN4llvm15MachineFunctionC2EPKNS_8FunctionERKNS_13TargetMachineEjRNS_17MachineModuleInfoE + 210 13 lli 0x000000000076838c llvm::MachineFunctionAnalysis::runOnFunction(llvm::Function&) + 92 14 lli 0x00000000009e2731 llvm::FPPassManager::runOnFunction(llvm::Function&) + 337 15 lli 0x00000000009e3809 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 201 16 lli 0x00000000009e392b llvm::FunctionPassManager::run(llvm::Function&) + 75 17 lli 0x000000000071f32e _ZN4llvm3JIT24runJITOnFunctionUnlockedEPNS_8FunctionERKNS_10MutexGuardE + 46 18 lli 0x000000000071f6eb llvm::JIT::getPointerToFunction(llvm::Function*) + 731 19 lli 0x0000000000725868 20 lli 0x000000000056bd71 21 lli 0x000000000056b97a X86CompilationCallback + 74 Stack dump: 0. Program arguments: /home/nicholas/2.8-rc1/Phase2/Release/llvmCore-2.8-rc1.obj/Release+Asserts/bin/lli -info-output-file=/home/nicholas/2.8-rc1/llvm-test/MultiSource/Applications/spiff/Output/spiff.out-jit.info -stats -time-passes -force-interpreter=false --disable-core-files Output/spiff.llvm.bc /home/nicholas/2.8-rc1/llvm-test/MultiSource/Applications/spiff/Sample.3 /home/nicholas/2.8-rc1/llvm-test/MultiSource/Applications/spiff/Sample.4 1. Running pass 'Machine Function Analysis' on function '@Z_fatal' Aborted exit 134 RunSafely.sh detected a failure with these command-line arguments: 500 0 /dev/null Output/spiff.out-jit /home/nicholas/2.8-rc1/Phase2/Release/llvmCore-2.8-rc1.obj/Release+Asserts/bin/lli -info-output-file=/home/nicholas/2.8-rc1/llvm-test/MultiSource/Applications/spiff/Output/spiff.out-jit.info -stats -time-passes -force-interpreter=false --disable-core-files Output/spiff.llvm.bc /home/nicholas/2.8-rc1/llvm-test/MultiSource/Applications/spiff/Sample.3 /home/nicholas/2.8-rc1/llvm-test/MultiSource/Applications/spiff/Sample.4 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 12 17:54:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 19:54:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 8133] JIT failure on MultiSource/Applications/spiff/spiff In-Reply-To: References: Message-ID: <20100913005441.EE0C12A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8133 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Nick Lewycky 2010-09-12 19:54:41 CDT --- Never mind, this test passes; it only failed due to ulimits in the nightly test harness. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 12 19:20:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Sep 2010 21:20:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 8134] New: "This decl is not contained in a translation unit!" assertion failure using PCH Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8134 Summary: "This decl is not contained in a translation unit!" assertion failure using PCH Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: llvmbugs at contacts.eelis.net CC: llvmbugs at cs.uiuc.edu If I have pre.hpp containing: template void f(T); template void f(T); void g() { f(0); f('x'); } Then if I do: clang -cc1 pre.hpp -emit-pch -o pre.hpp.pch echo | clang -cc1 -include-pch pre.hpp.pch -x c++ - The second invocation results in: clang: DeclBase.cpp:199: clang::TranslationUnitDecl* clang::Decl::getTranslationUnitDecl(): Assertion `DC && "This decl is not contained in a translation unit!"' failed. I'm using Clang r113729. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 04:49:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 06:49:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8134] "This decl is not contained in a translation unit!" assertion failure using PCH In-Reply-To: References: Message-ID: <20100913114914.2A1C12A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8134 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Argyrios Kyrtzidis 2010-09-13 06:49:13 CDT --- Fixed at r113744, thanks for the report! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 05:48:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 07:48:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8135] New: Clang++ crashes on case ranges (GNU extension) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8135 Summary: Clang++ crashes on case ranges (GNU extension) Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ggreif at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Compile below snippet: ####################################### enum E { one, two, three, four }; int test(enum E e) { switch (e) { case one: return 7; case two ... two + 1: return 42; case four: return 25; default: return 0; } } ####################################### /// invoke as: /// Debug+Asserts/bin/clang++ -c case-range.c /// does not crash with /// Debug+Asserts/bin/clang -c case-range.c It asserts: $ Debug+Asserts/bin/clang++ -c ~/case-range.c clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated] clang++: /home/ggreif/llvm/include/llvm/ADT/APSInt.h:129: bool llvm::APSInt::operator<=(const llvm::APSInt&) const: Assertion `IsUnsigned == RHS.IsUnsigned && "Signedness mismatch!"' failed. 0 clang++ 0x0000000001fb86a4 1 clang++ 0x0000000001fb84cc 2 libpthread.so.0 0x0000003ed7e0eb10 3 libc.so.6 0x0000003ed7230265 gsignal + 53 4 libc.so.6 0x0000003ed7231d10 abort + 272 5 libc.so.6 0x0000003ed72296e6 __assert_fail + 246 6 clang++ 0x0000000001539b83 llvm::APSInt::operator<=(llvm::APSInt const&) const + 67 7 clang++ 0x000000000156f7c1 clang::Sema::ActOnFinishSwitchStmt(clang::SourceLocation, clang::Stmt*, clang::Stmt*) + 5901 8 clang++ 0x0000000001401aa4 clang::Parser::ParseSwitchStatement(clang::AttributeList*) + 872 9 clang++ 0x00000000013fff1e clang::Parser::ParseStatementOrDeclaration(bool) + 1482 10 clang++ 0x0000000001400ce0 clang::Parser::ParseCompoundStatementBody(bool) + 208 11 clang++ 0x0000000001404052 clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 136 12 clang++ 0x00000000014099f9 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 795 13 clang++ 0x000000000140edb5 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 371 14 clang++ 0x000000000140965a clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 764 15 clang++ 0x00000000014096b6 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 62 16 clang++ 0x000000000140914c clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList, clang::Parser::ParsingDeclSpec*) + 1634 17 clang++ 0x0000000001408a5e clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 226 18 clang++ 0x00000000013f4eef clang::ParseAST(clang::Sema&, bool) + 219 19 clang++ 0x00000000011d46bd clang::ASTFrontendAction::ExecuteAction() + 201 20 clang++ 0x00000000012cc0a7 clang::CodeGenAction::ExecuteAction() + 813 21 clang++ 0x00000000011d43c2 clang::FrontendAction::Execute() + 258 22 clang++ 0x00000000011c277b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 641 23 clang++ 0x00000000011802ae clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 696 24 clang++ 0x00000000011750de cc1_main(char const**, char const**, char const*, void*) + 732 25 clang++ 0x000000000117ca8a main + 408 26 libc.so.6 0x0000003ed721d994 __libc_start_main + 244 27 clang++ 0x0000000001174919 Stack dump: 0. Program arguments: Debug+Asserts/bin/clang++ -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name case-range.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.17.50.0.6 -resource-dir Debug+Asserts/lib/clang/2.9 -ferror-limit 19 -fmessage-length 126 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-PeCbYu.s -x c++ /home/ggreif/case-range.c 1. /home/ggreif/case-range.c:22:1: current parser token '}' 2. /home/ggreif/case-range.c:10:1: parsing function body 'test' 3. /home/ggreif/case-range.c:10:1: in compound statement ('{}') clang++: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 08:56:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 10:56:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 8126] Strange behaviour with integer promotion on x86-64 In-Reply-To: References: Message-ID: <20100913155600.1CC782A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8126 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |daniel at zuster.org Resolution| |INVALID --- Comment #3 from Daniel Dunbar 2010-09-13 10:55:59 CDT --- We need a test case, this bug is actionable at the moment. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 09:01:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 11:01:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 8122] 2.8 isn't listed in versions In-Reply-To: References: Message-ID: <20100913160135.6ED9B2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8122 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |daniel at zuster.org Resolution| |FIXED --- Comment #1 from Daniel Dunbar 2010-09-13 11:01:35 CDT --- Done. God I hate bugzilla. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 13:38:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 15:38:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 8136] New: clang doesn't detect invalid redeclarations after a using directive brings in something with the same name Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8136 Summary: clang doesn't detect invalid redeclarations after a using directive brings in something with the same name Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This should obviously not compile (because of the conflict between the namespace and the class): namespace A { template class A; } using namespace A; class A {}; I assume that the redecl lookup is finding the template, which is then dropped because it's in the wrong scope. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 13:42:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 15:42:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 8137] New: clang gets confused by ambiguities in template-name checks introduced by using directives Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8137 Summary: clang gets confused by ambiguities in template-name checks introduced by using directives Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com namespace A { template class foo; } using namespace A; template void foo(); template <> void foo(); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 13:53:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 15:53:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 8138] New: Bugpoint: Loop extraction broke the program Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8138 Summary: Bugpoint: Loop extraction broke the program Product: tools Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: bugpoint AssignedTo: unassignedbugs at nondot.org ReportedBy: stoklund at 2pi.dk CC: llvmbugs at cs.uiuc.edu While debugging a Bullet miscompile with -regalloc=fast on darwin x86_64: bugpoint -llc-safe t.bc -Xlinker all.a -Xlinker -lstdc++ -tool-args -regalloc=fast Read input file : 't.bc' *** All input ok Initializing execution environment: Found gcc: /opt/local/libexec/ccache/gcc Running the code generator to test for a crash: Generating reference output from raw program: Reference output is: bugpoint.reference.out-di09Is *** Checking the code generator... *** Input program does not match reference diff! Debugging code generator problem! Checking to see if the program is misoptimized when these functions are run through the passes: _ZN15btGjkEpaSolver220StackSizeRequirementEv _ZN15btGjkEpaSolver28DistanceEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsE _ZN12gjkepa2_impl10InitializeEPK13btConvexShapeRK11btTransformS2_S5_RN15btGjkEpaSolver28sResultsERNS_13MinkowskiDiffEb _ZN12gjkepa2_impl3GJK8EvaluateERKNS_13MinkowskiDiffERK9btVector3 _ZNK12gjkepa2_impl13MinkowskiDiff7SupportERK9btVector3j _ZN15btGjkEpaSolver211PenetrationEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsEb _ZN12gjkepa2_impl3EPA8EvaluateERNS_3GJKERK9btVector3 _ZN15btGjkEpaSolver214SignedDistanceERK9btVector3fPK13btConvexShapeRK11btTransformRNS_8sResultsE _ZN15btGjkEpaSolver214SignedDistanceEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsE _ZN11btMatrix3x311setRotationERK12btQuaternion... <21 total> : still failing! Checking to see if the program is misoptimized when these functions are run through the passes: _ZN12gjkepa2_impl3GJK13EncloseOriginEv _ZN12gjkepa2_impl3GJK3detERK9btVector3S3_S3_ _ZN12gjkepa2_impl3EPA7newfaceEPNS_3GJK3sSVES3_S3_b _ZN12gjkepa2_impl3EPA8findbestEv _ZNK12gjkepa2_impl3GJK10getsupportERK9btVector3RNS0_3sSVE _ZN12gjkepa2_impl3EPA6expandEjPNS_3GJK3sSVEPNS0_5sFaceEjRNS0_8sHorizonE _ZN12gjkepa2_impl3GJK13appendverticeERNS0_8sSimplexERK9btVector3 _ZN12gjkepa2_impl3EPA10InitializeEv _ZN12gjkepa2_impl3GJK13projectoriginERK9btVector3S3_PfRj _ZN12gjkepa2_impl3GJK13projectoriginERK9btVector3S3_S3_PfRj... <11 total> : didn't fail. Checking to see if the program is misoptimized when these functions are run through the passes: _ZN15btGjkEpaSolver220StackSizeRequirementEv _ZN15btGjkEpaSolver28DistanceEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsE _ZN12gjkepa2_impl10InitializeEPK13btConvexShapeRK11btTransformS2_S5_RN15btGjkEpaSolver28sResultsERNS_13MinkowskiDiffEb _ZN12gjkepa2_impl3GJK8EvaluateERKNS_13MinkowskiDiffERK9btVector3 _ZNK12gjkepa2_impl13MinkowskiDiff7SupportERK9btVector3j _ZN15btGjkEpaSolver211PenetrationEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsEb _ZN12gjkepa2_impl3EPA8EvaluateERNS_3GJKERK9btVector3 _ZN15btGjkEpaSolver214SignedDistanceERK9btVector3fPK13btConvexShapeRK11btTransformRNS_8sResultsE _ZN15btGjkEpaSolver214SignedDistanceEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsE _ZN11btMatrix3x311setRotationERK12btQuaternion : still failing! Checking to see if the program is misoptimized when these functions are run through the passes: _ZN15btGjkEpaSolver211PenetrationEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsEb _ZN12gjkepa2_impl3EPA8EvaluateERNS_3GJKERK9btVector3 _ZN15btGjkEpaSolver214SignedDistanceERK9btVector3fPK13btConvexShapeRK11btTransformRNS_8sResultsE _ZN15btGjkEpaSolver214SignedDistanceEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsE _ZN11btMatrix3x311setRotationERK12btQuaternion : still failing! Checking to see if the program is misoptimized when these functions are run through the passes: _ZN15btGjkEpaSolver214SignedDistanceERK9btVector3fPK13btConvexShapeRK11btTransformRNS_8sResultsE _ZN15btGjkEpaSolver214SignedDistanceEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsE _ZN11btMatrix3x311setRotationERK12btQuaternion : didn't fail. Checking to see if the program is misoptimized when these functions are run through the passes: _ZN15btGjkEpaSolver211PenetrationEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsEb _ZN12gjkepa2_impl3EPA8EvaluateERNS_3GJKERK9btVector3 : still failing! Checking to see if the program is misoptimized when this function is run through the passes: _ZN12gjkepa2_impl3EPA8EvaluateERNS_3GJKERK9btVector3 : didn't fail. Checking to see if the program is misoptimized when this function is run through the passes: _ZN15btGjkEpaSolver211PenetrationEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsEb : still failing! *** The following function is being miscompiled: _ZN15btGjkEpaSolver211PenetrationEPK13btConvexShapeRK11btTransformS2_S5_RK9btVector3RNS_8sResultsEb Extracted a loop from the breaking portion of the program. *** ERROR: Loop extraction broke the program. :( Please report a bug! Continuing on with un-loop-extracted version. Please submit the bugpoint-loop-extract-fail-*.bc files. Checking to see if the program is misoptimized when all blocks are extracted. $ echo $? 11 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 14:17:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 16:17:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 8139] New: RFE: opt should strip optsize bit with some options Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8139 Summary: RFE: opt should strip optsize bit with some options Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Archive library AssignedTo: unassignedbugs at nondot.org ReportedBy: daniel at zuster.org CC: llvmbugs at cs.uiuc.edu I think it makes sense for: -- $ clang -c -Os -flto -o t.bc t.c $ opt -O3 -o t2.bc t.bc -- to produce something as close as possible to: -- $ clang -c -O3 -flto -o t.bc t.c -- For this to work properly, opt should be stripping the optsize bit off of functions except when it is run with the optimize size options. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 14:31:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 16:31:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 8140] New: Duplicate (?) error on function pointer assignment with incompatible exception specification Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8140 Summary: Duplicate (?) error on function pointer assignment with incompatible exception specification Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Keywords: quality-of-implementation Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Testcase: void (*pf)() throw(int); void f() { pf = f; }; Error output: :3:8: error: target exception specification is not superset of source pf = f; ^ :3:6: error: assigning to 'void (*)() throw(int)' from incompatible type 'void ()' pf = f; ^ ~ This should be one error (possibly with a note), not two pointing out the same issue. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 16:53:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 18:53:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 8141] New: GNU statement-expression ({}) segfaults Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8141 Summary: GNU statement-expression ({}) segfaults Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pip88nl at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5487) --> (http://llvm.org/bugs/attachment.cgi?id=5487) stack trace The following code: // BEGIN struct list { struct list *tail; }; struct list * foo (void) { struct list *items; for (;; items = ({ do { } while (0); items->tail; })) { } } // END segfaults: clang version 2.8 (trunk 113114) Target: x86_64-pc-linux-gnu Thread model: posix stack trace attached. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 17:07:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 19:07:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 8142] New: implement -Wenum-compare Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8142 Summary: implement -Wenum-compare Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang does not emit a warning on this code: enum X { Ax, Bx }; enum Y { Ay, By }; int foo(enum X x, enum Y y) { return x == y; } while GCC does: enum.cc: In function ‘int foo(X, Y)’: enum.cc:5: warning: comparison between ‘enum X’ and ‘enum Y’ This is under -Wenum-compare in GCC. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 17:19:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 19:19:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 8102] use after free in LICM In-Reply-To: References: Message-ID: <20100914001915.458952A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8102 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Chris Lattner 2010-09-13 19:19:13 CDT --- Fixed in r113820, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 17:51:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 19:51:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 8143] New: #pragma diagnostic ignored is not honoured by template code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8143 Summary: #pragma diagnostic ignored is not honoured by template code Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: luc_j_bourhis at mac.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5488) --> (http://llvm.org/bugs/attachment.cgi?id=5488) self-contained snippet reproducing the bug ~> clang --version clang version 2.9 (trunk 113485) Target: x86_64-apple-darwin10 Thread model: posix ~> make clang++ -c -o main.o main.cpp In file included from main.cpp:1: ./warning.hpp:6:9: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (x < T(0)) return -x; ~ ^ ~~~~ main.cpp:5:16: note: in instantiation of function template specialization 'absolute' requested here std::cout << absolute(1u) << absolute_unsigned(1u) << std::endl; ^ 1 warning generated. Thus "#pragma diagnostic ignored" is actually ignored by templated code. C.f. thread http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-September/010884.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 13 18:14:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Sep 2010 20:14:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 8141] [CFG] GNU statement-expression ({}) segfaults In-Reply-To: References: Message-ID: <20100914011454.BA8EB2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8141 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Ted Kremenek 2010-09-13 20:14:54 CDT --- Fixed: http://llvm.org/viewvc/llvm-project?view=rev&revision=113826 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 01:55:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 03:55:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 8144] New: Variables inside inline asm is optimized away even though they are marked as used Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8144 Summary: Variables inside inline asm is optimized away even though they are marked as used Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ismail at namtrac.org CC: llvmbugs at cs.uiuc.edu This is a case from MPlayer, I will attach the preprocessed vf_fspp.i file. Variables MM_FIX_1_082392200 and MM_FIX_1_414213562 are optimized away. Rest of the MM_* variables are fine. Tested on MacOSX 10.6, clang trunk r113836. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 09:42:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 11:42:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8145] New: lnt should record the linker version in --simple runs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8145 Summary: lnt should record the linker version in --simple runs Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: stoklund at 2pi.dk CC: llvmbugs at cs.uiuc.edu When running the lnt tester tool with --simple -cflag -flto, the linker plays a significant role in the LTO process. The lnt tool should record the linker version that was used. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 09:55:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 11:55:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 8146] New: Clang incorrectly emitting 'is a private member of' error for templated friend class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8146 Summary: Clang incorrectly emitting 'is a private member of' error for templated friend class Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: mike.gist at imgtec.com CC: llvmbugs at cs.uiuc.edu I failed to find a less complex example of this issue, so apologies for the amount of code. See hash.h for the problematic code, test.cpp is a preprocessed file including this header which clang++ will emit errors on. In the class 'HashElement' the class 'csHash' is declared as a friend. However, accesses to the private 'key' and 'value' members of the HashElement objects in csHash member functions trigger the 'is a private member of' error. Both GCC and MSVC can compile the example code with no errors. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 12:51:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 14:51:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 8147] New: clang accepts an invalid program Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8147 Summary: clang accepts an invalid program Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pip88nl at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In C++03 mode, clang should reject the following program: // BEGIN template void func (T) { } enum { foo = 255 }; int main () { func (foo); } // END It is accepted by: clang version 2.9 (trunk 113840) Target: x86_64-pc-linux-gnu Thread model: posix In C++0x, using anonymous types as template parameters is valid, in C++03, it is not. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 13:22:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 15:22:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 8147] clang accepts an invalid program In-Reply-To: References: Message-ID: <20100914202248.D7D8D2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8147 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Douglas Gregor 2010-09-14 15:22:47 CDT --- *** This bug has been marked as a duplicate of bug 6784 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 16:01:22 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 18:01:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 8148] New: Inefficient code generated for rotate idiom Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8148 Summary: Inefficient code generated for rotate idiom Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: benny.kra at gmail.com CC: llvmbugs at cs.uiuc.edu Reported by helmut on IRC. clang compiles this code: #define ROTL(v, s) (((v) << (s))|((v) >> (32-(s)))) uint32_t foo(uint32_t a) { return ROTL(a + 0xd76aa478, 7); } into a shift/or sequence instead of the more efficient "rol" instruction on x86. Removing the addition or turning ROTL into an inline function produces the expected result. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 16:10:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 18:10:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 8149] New: [CFG] GNU statement-expression ({}) segfaults Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8149 Summary: [CFG] GNU statement-expression ({}) segfaults Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pip88nl at gmail.com CC: kremenek at apple.com, llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code: // BEGIN void foo (void) { for (; ({ do { } while (0); 0; });) { } } // END segfaults on: clang version 2.9 (trunk 113840) Target: x86_64-pc-linux-gnu Thread model: posix Note that it does not segfault if "void foo" is "int main". -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 16:34:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 18:34:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 8114] outb %al, (%dx) --> error: invalid operand for instruction In-Reply-To: References: Message-ID: <20100914233454.1939C2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8114 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2010-09-14 18:34:53 CDT --- What a terrible, distasteful abomination. Implemented in r113894. I will ask to get it pulled into 2.8 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 16:41:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 18:41:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 8150] New: clang -fcolor-diagnostics and !isatty(stderr) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8150 Summary: clang -fcolor-diagnostics and !isatty(stderr) Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: fvbommel at wxs.nl CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5492) --> (http://llvm.org/bugs/attachment.cgi?id=5492) Proposed patch Clang's -fcolor-diagnostics command-line option doesn't enable colored diagnostics if it's of the opinion that stderr can't handle them (i.e. StandardErrHasColors() returns false). IMHO, if this option is explicitly passed to the driver then it should respect that. (For instance, ccache users can't get colored diagnostics otherwise because ccache also caches warnings, so it has to redirect stderr) I'm attaching a small patch that fixes this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 17:30:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 19:30:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 8144] Variables inside inline asm is optimized away even though they are marked as used In-Reply-To: References: Message-ID: <20100915003023.6F0812A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8144 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2010-09-14 19:30:23 CDT --- Fixed in r113911, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 14 18:53:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Sep 2010 20:53:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 8036] ARM NEON intrinsics vget_low_u8, etc produce inefficient code In-Reply-To: References: Message-ID: <20100915015300.408842A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8036 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Bob Wilson 2010-09-14 20:52:59 CDT --- Fixed in llvm svn 113919. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 00:01:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 02:01:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 8149] [CFG] GNU statement-expression ({}) segfaults In-Reply-To: References: Message-ID: <20100915070136.0190F2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8149 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Ted Kremenek 2010-09-15 02:01:35 CDT --- Fixed in r113953. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 00:41:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 02:41:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 8151] New: Ambiguous name lookup compiling error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8151 Summary: Ambiguous name lookup compiling error Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: scoopr at iki.fi CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5493) --> (http://llvm.org/bugs/attachment.cgi?id=5493) Test case extracted from assimp I'm trying to compile http://assimp.sf.net Attached is a reduced testcase for this issue. The error from it is: test2.cpp:8:3: error: reference to 'Face' is ambiguous Face *mFaces; ^ test2.cpp:1:22: note: candidate found by name lookup is 'A::Face' namespace A { struct Face {}; } ^ test2.cpp:2:22: note: candidate found by name lookup is 'B::Face' namespace B { struct Face {}; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 02:41:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 04:41:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 8152] New: LLVM stack alignment doesn't match gcc's requirements on Linux32 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8152 Summary: LLVM stack alignment doesn't match gcc's requirements on Linux32 Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu ... which causes the gcc compiled function to crash because it expects 16-byte aligned stack (in gcc 4.4 at least with -fpmath=sse). I'm told that older gcc's don't require (or set) 16, so just setting 16-byte would break older ones. This seems to be a good solution: richi: well, just make sure outgoing stack boundary is always 16-byte and do not assume anything about incoming stack alignemnt Idea from aKor: (12:37:18 PM) aKor: [13:32] aKor: edwin: but maintaining outgoing stack boundary is certainly possible in "common cases" (12:37:18 PM) aKor: [13:32] aKor: (without dynamic allocas) (12:37:34 PM) aKor: this seems to be the best way wrt backward compatibility stuff -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 03:15:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 05:15:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 8153] New: llvm-gcc fails to build with gcc-4.2 on x86-32 linux Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8153 Summary: llvm-gcc fails to build with gcc-4.2 on x86-32 linux Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu If LLVM is configured with --enable-optimization --enable-assertions and built with gcc-4.2/g++-4.2 on x86-32 linux, then the llvm-gcc build fails (see below). This does not occur if gcc-4.3 or gcc-4.4 is used. .../gcc/xgcc -B/home/duncan/LLVM/gcc-4.2.llvm-objects-32/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-4.2.llvm/gcc -I../../gcc-4.2.llvm/gcc/. -I../../gcc-4.2.llvm/gcc/../include -I../../gcc-4.2.llvm/gcc/../libcpp/include -I../../gcc-4.2.llvm/gcc/../libdecnumber -I../libdecnumber -I/home/duncan/llvm-2.8/Phase1/Release/llvmCore-2.8-rc1.obj/include -I/home/duncan/llvm-2.8/llvmCore-2.8-rc1.src/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ -c ../../gcc-4.2.llvm/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ../../gcc-4.2.llvm/gcc/crtstuff.c:378: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 03:25:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 05:25:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 8154] New: Crash in Optimize for code generation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8154 Summary: Crash in Optimize for code generation Product: new-bugs Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: pawel.worach at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5494) --> (http://llvm.org/bugs/attachment.cgi?id=5494) bugpoint-reduced-simplified.bc llvm r113919. Stack dump: 0. Program arguments: llc bugpoint-reduced-simplified.bc 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.bc'. 2. Running pass 'Optimize for code generation' on function '@_sem_timedwait' Segmentation fault -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 09:25:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 11:25:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8155] New: couldn't get a simple c++ code to compile Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8155 Summary: couldn't get a simple c++ code to compile Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: gryzman at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com following code causes it to die: #include #include #include #include #include int main() { const char* f = "dupa"; std::string dupa = std::string(f); std::cout << dupa; return 0; } I got following output: clang++ dupa.cpp 0 clang 0x0955f658 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name dupa.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.15.92.0.2 -resource-dir /usr/local/lib/clang/2.9 -ferror-limit 19 -fmessage-length 237 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-F7fhl6.s -x c++ dupa.cpp 1. parser at end of file 2. Code generation 3. Running pass 'X86 DAG->DAG Instruction Selection' on function '@main' clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) clang version 2.9 (trunk 113973) Target: i386-pc-linux-gnu Thread model: posix "/usr/local/bin/clang" -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name dupa.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.15.92.0.2 -v -resource-dir /usr/local/lib/clang/2.9 -ferror-limit 19 -fmessage-length 237 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-dDpr2o.s -x c++ dupa.cpp clang -cc1 version 2.9 based upon llvm 2.9svn hosted on i386-pc-linux-gnu #include "..." search starts here: #include <...> search starts here: /usr/include/c++/3.4.6 /usr/include/c++/3.4.6/i386-redhat-linux /usr/include/c++/3.4.6/backward /usr/local/include /usr/local/lib/clang/2.9/include /usr/include End of search list. 0 clang 0x0955f658 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name dupa.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.15.92.0.2 -v -resource-dir /usr/local/lib/clang/2.9 -ferror-limit 19 -fmessage-length 237 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-dDpr2o.s -x c++ dupa.cpp 1. parser at end of file 2. Code generation 3. Running pass 'X86 DAG->DAG Instruction Selection' on function '@main' clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 11:54:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 13:54:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 8156] New: LegalizeOp incorrect node updates! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8156 Summary: LegalizeOp incorrect node updates! Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: bruno.cardoso at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5496) --> (http://llvm.org/bugs/attachment.cgi?id=5496) "call DAG.viewGraph()" output The current implementation of LegalizeOp has the following behavior: Consider the custom lowering or expansion of any node in the DAG. After a new node is returned in those operations, LegalizeOp is called for this node again, but it doesn't update the DAG to reflect the new uses and to remove the old ones. This leads to the condition where it's impossible to detect some potential folds during lowering time, because some node we're trying to fold can have more than one use, as its previous users are still alive in the DAG when they shouldn't. This currently blocks the rewritting of VECTOR_SHUFFLE lowering for x86, which has several shuffles with different costs, making it important to know during lowering time which nodes are potential folds. Proposed solution: Rewrite the LegalizeOp to work in a work list based fashion and to always update the DAG in the same way DAGCombiner does. To reproduce the problem, try this example with the attached bitcode: llc < v02.ll -march=x86 -mattr=+sse2,-sse41 A quick explanation of what happens here: 1) insertelement is expanded to a vector_shuffle<0,2> 2) x86 LowerVECTOR_SHUFFLE is called for vector_shuffle<0,2> 3) Breakpoint at the beginning of this function, and asks for "call DAG.viewGraph()" using gdb, the resulting graph is attached. The DAG at this point will display to uses for the "load" node, one coming from the old (already expanded) insertelement and one coming from vector_shuffle<0,2>. This leads the lowering to select X86ISD::UNPCKLPD instead of X86ISD::MOVHPS. We circuvent that using a small hack now in x86 sse td files: def : Pat<(v2f64 (X86Unpcklpd VR128:$src1, (scalar_to_vector (loadf64 addr:$src2)))), (MOVHPDrm VR128:$src1, addr:$src2)>; But this is something we obviously don't want. The same problem also occurs for lots of other examples, and every attempt to clean up the vector_shuffle handling right now keeps triggering more of this problem, so a hack here and there is not sufficient anymore to solve the issue. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 13:12:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 15:12:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 7959] Miscompile with gvn In-Reply-To: References: Message-ID: <20100915201232.006002A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7959 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #14 from Eli Friedman 2010-09-15 15:12:25 CDT --- Fixed in r114015; the analysis in comment 11 was helpful. I'm pretty sure comment 12 is wrong, though. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 14:31:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 16:31:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 8157] New: ARM: rdhi, rdlo and rm registers should be different in SMULL on ARMv5 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8157 Summary: ARM: rdhi, rdlo and rm registers should be different in SMULL on ARMv5 Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: castet.matthieu at free.fr CC: llvmbugs at cs.uiuc.edu smull r7, r9, r7, r8 produce as error /tmp/cc-GdDNM1.s:267: rdhi, rdlo and rm must all be differen seems similar to #2313 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 15:03:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 17:03:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 8158] New: Refactor .td file to not have multiple SSE instructions that do the same thing Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8158 Summary: Refactor .td file to not have multiple SSE instructions that do the same thing Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: bruno.cardoso at gmail.com CC: llvmbugs at cs.uiuc.edu The X86 backend has a bunch of instruction that are duplicated because the instruction constraints are different. A full list of the ambiguous matcher instructions can be printed with: tblgen -I ../../../include X86.td -gen-asm-matcher -debug-only ambiguous_instrs -o /dev/null A famous subset of them are the SSE logical instructions, which have FsXXX versions: ANDNPDrm, FsANDNPDrm, XORPDrm, FsXORPDrm, ... Their constraints are: def ANDPSrm { dag OutOperandList = (outs VR128:$dst); dag InOperandList = (ins VR128:$src1, f128mem:$src2); list Pattern = [(set VR128:$dst, (and (bc_v2i64 (v4f32 VR128:$src1)), (memopv2i64 addr:$src2)))]; def FsANDPSrm { dag OutOperandList = (outs FR32:$dst); dag InOperandList = (ins FR32:$src1, f128mem:$src2); list Pattern = [(set FR32:$dst, (X86fand FR32:$src1, (memopfsf32 addr:$src2)))]; Some solutions proposed in previous discussions: 1) Some operations, like bit and, is not a legal op on f32, make the legalizer extend it to v4f32 or some other canonical type for other operations and make sure they get CSE'd right. 2) Use some pattern matching as: def : Pat<(f32 (and foo, bar)), (EXTRACT_SUBREG (PANDrr (INSERT_SUBREG (implicit-def), foo, sub_ss), (INSERT_SUBREG (implicit-def), bar, sub_ss)), sub_ss) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 19:38:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 21:38:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 8159] New: clang accepts redundant scope specifier for variables in class definition Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8159 Summary: clang accepts redundant scope specifier for variables in class definition Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pichet2000 at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang compiles the following without error or warning: class A { int A::a; }; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 20:05:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 22:05:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 8160] New: driver.cpp: captures the object DiagnosticOptions on stack Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8160 Summary: driver.cpp: captures the object DiagnosticOptions on stack Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu tool/driver/driver.cpp:288 in main(), TextDiagnosticPrinter *DiagClient = new TextDiagnosticPrinter(llvm::errs(), DiagnosticOptions()); DiagnosticOptions() is on stack. It causes unexpected behavior. On one of my environments, cygwin-1.5, diagnostic outputs are wrapped by a few columns, to let test/Driver/Xarch.c fail. (due to bogus MessageLength) [My workaround] TextDiagnosticPrinter *DiagClient = new TextDiagnosticPrinter(llvm::errs(), *new DiagnosticOptions()); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 20:50:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 22:50:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 8161] New: Assertion `From != To && "ReplaceAndSimplifyAllUses(X, X) is not valid!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8161 Summary: Assertion `From != To && "ReplaceAndSimplifyAllUses(X,X) is not valid!"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu [regehr at gamow tmp427]$ clang -v clang version 2.9 (trunk 114038) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp427]$ clang -c -O3 small.c small.c:24:8: warning: expression result unused [-Wunused-value] for (0; l_132; l_132 = safe_sub_func_int32_t_s_s (l_132, 1)) ^ small.c:32:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ clang: InstructionSimplify.cpp:461: void llvm::ReplaceAndSimplifyAllUses(llvm::Instruction*, llvm::Value*, const llvm::TargetData*): Assertion `From != To && "ReplaceAndSimplifyAllUses(X,X) is not valid!"' failed. 0 clang 0x000000000169953f 1 clang 0x000000000169b7b2 2 libpthread.so.0 0x00007f11269e3190 3 libc.so.6 0x00007f1125ce84b5 gsignal + 53 4 libc.so.6 0x00007f1125cebf50 abort + 384 5 libc.so.6 0x00007f1125ce1481 __assert_fail + 241 6 clang 0x00000000014c8aeb 7 clang 0x0000000001475128 llvm::SimplifyInstructionsInBlock(llvm::BasicBlock*, llvm::TargetData const*) + 120 8 clang 0x000000000138feb3 9 clang 0x00000000015de4ad llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 10 clang 0x00000000014a4e2b 11 clang 0x00000000014a5585 12 clang 0x00000000015de044 llvm::MPPassManager::runOnModule(llvm::Module&) + 500 13 clang 0x00000000015de1b7 llvm::PassManagerImpl::run(llvm::Module&) + 167 14 clang 0x00000000007cbbb7 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1623 15 clang 0x00000000007c7cab 16 clang 0x00000000008e91a3 clang::ParseAST(clang::Sema&, bool) + 291 17 clang 0x00000000007c8c94 clang::CodeGenAction::ExecuteAction() + 68 18 clang 0x00000000006d5e9d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 349 19 clang 0x00000000006b3bfc clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1292 20 clang 0x00000000006ab968 cc1_main(char const**, char const**, char const*, void*) + 472 21 clang 0x00000000006b27f5 main + 4117 22 libc.so.6 0x00007f1125cd3abd __libc_start_main + 253 23 clang 0x00000000006aa2e9 Stack dump: 0. Program arguments: /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r114038-install/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20 -resource-dir /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r114038-install/lib/clang/2.9 -O3 -ferror-limit 19 -fmessage-length 89 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-D2Fchs.s -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Value Propagation' on function '@func_114' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) [regehr at gamow tmp427]$ cat small.c typedef signed char int8_t; typedef int int32_t; typedef unsigned short int uint16_t; static int8_t safe_add_func_int32_t_s_s (int32_t si1, int32_t si2) { return si1 > 0 && si2 > 0 && si1 > -si2 || si1 < 0 && si2 < 0 && si1 < -si2 ? : si1 + si2; } static int8_t safe_sub_func_int32_t_s_s (int32_t si1, int8_t si2) { return si1 ^ si2 & si1 ^ si1 ^ si2 & ~0 - si2 ^ si2 ? : si1 - si2; } int32_t g_122; uint16_t g_126; uint16_t g_180; int8_t * func_114 (int8_t p_115, int8_t * const *p_116, uint16_t p_117, uint16_t p_118) { int8_t l_132; for (0; l_132; l_132 = safe_sub_func_int32_t_s_s (l_132, 1)) { int32_t *l_173 = &g_122; g_180 &= safe_add_func_int32_t_s_s (*l_173 < 1, g_126); *l_173 = 0; if (g_126) break; } } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 15 20:56:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Sep 2010 22:56:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 8162] New: Assertion `!isConstantRange() && "Constant and ConstantRange cannot be merged."' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8162 Summary: Assertion `!isConstantRange() && "Constant and ConstantRange cannot be merged."' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu [regehr at gamow tmp428]$ clang -v clang version 2.9 (trunk 114038) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp428]$ clang -O3 small.c -w clang: LazyValueInfo.cpp:228: bool::LVILatticeVal::mergeIn(const::LVILatticeVal&): Assertion `!isConstantRange() && "Constant and ConstantRange cannot be merged."' failed. 0 clang 0x000000000169953f 1 clang 0x000000000169b7b2 2 libpthread.so.0 0x00007f8c0ca19190 3 libc.so.6 0x00007f8c0bd1e4b5 gsignal + 53 4 libc.so.6 0x00007f8c0bd21f50 abort + 384 5 libc.so.6 0x00007f8c0bd17481 __assert_fail + 241 6 clang 0x00000000014ca3f5 7 clang 0x00000000014cca39 8 clang 0x00000000014cd5a7 9 clang 0x00000000014cdcb1 10 clang 0x00000000014ce374 llvm::LazyValueInfo::getConstantOnEdge(llvm::Value*, llvm::BasicBlock*, llvm::BasicBlock*) + 68 11 clang 0x000000000138fd02 12 clang 0x00000000015de4ad llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 13 clang 0x00000000014a4e2b 14 clang 0x00000000014a5585 15 clang 0x00000000015de044 llvm::MPPassManager::runOnModule(llvm::Module&) + 500 16 clang 0x00000000015de1b7 llvm::PassManagerImpl::run(llvm::Module&) + 167 17 clang 0x00000000007cbbb7 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1623 18 clang 0x00000000007c7cab 19 clang 0x00000000008e91a3 clang::ParseAST(clang::Sema&, bool) + 291 20 clang 0x00000000007c8c94 clang::CodeGenAction::ExecuteAction() + 68 21 clang 0x00000000006d5e9d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 349 22 clang 0x00000000006b3bfc clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1292 23 clang 0x00000000006ab968 cc1_main(char const**, char const**, char const*, void*) + 472 24 clang 0x00000000006b27f5 main + 4117 25 libc.so.6 0x00007f8c0bd09abd __libc_start_main + 253 26 clang 0x00000000006aa2e9 Stack dump: 0. Program arguments: /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r114038-install/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20 -resource-dir /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r114038-install/lib/clang/2.9 -O3 -w -ferror-limit 19 -fmessage-length 89 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-C2ochI.s -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Value Propagation' on function '@int328' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) [regehr at gamow tmp428]$ cat small.c typedef short int int16_t; typedef unsigned char uint8_t; typedef unsigned int uint32_t; struct S2 { }; int16_t g_106; struct S2 g_128 = { 1L, 0x5E58L }; int328 (uint8_t p_79, uint32_t p_80, struct S3 *p_81, int16_t p_82) { int i, j, k; for (i = 0;; 1) { int16_t l_109 = 0; int16_t *l_130 = &g_106; lbl_133:if (0) break; if (safe (0)) { struct S2 *l_127 = &g_128; int16_t *l_129 = &l_109; *l_129 = l_127; if (p_82) lbl_134:if (l_109) goto lbl_133; else for (i; i < 1; i++) { } } else *l_130 &= (p_79, l_109); } } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 01:04:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 03:04:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 8163] New: clang crashes while compiling h264.c [mplayer/ffmpeg] Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8163 Summary: clang crashes while compiling h264.c [mplayer/ffmpeg] Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ismail at namtrac.org CC: llvmbugs at cs.uiuc.edu [~/Sources/fate-test/work/src]> gcc -v Using built-in specs. Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) [~/Sources/fate-test/work/src]> make CC libavcodec/h264.o libavcodec/h264.c:2328:23: warning: incompatible pointer types initializing 'int (*)[64]' with an expression of type 'int *' int (*ref2frm)[64] = h->ref2frm[ h->slice_num&(MAX_SLICES-1) ][0] + (MB_MBAFF ? 20 : 2); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libavcodec/h264.c:2405:23: warning: incompatible pointer types initializing 'int (*)[64]' with an expression of type 'int *' int (*ref2frm)[64] = h->ref2frm[ h->slice_table[top_xy]&(MAX_SLICES-1) ][0] + (MB_MBAFF ? 20 : 2); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libavcodec/h264.c:2420:27: warning: incompatible pointer types initializing 'int (*)[64]' with an expression of type 'int *' int (*ref2frm)[64] = h->ref2frm[ h->slice_table[left_xy[0]]&(MAX_SLICES-1) ][0] + (MB_MBAFF ? 20 : 2); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0 clang 0x0935b4a8 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name h264.c -mrelocation-model static -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.20.51 -g -resource-dir /usr/local/lib/clang/2.9 -dependency-file libavcodec/h264.d -MT libavcodec/h264.o -D _ISOC99_SOURCE -D _POSIX_C_SOURCE=200112 -D _FILE_OFFSET_BITS=64 -D _LARGEFILE_SOURCE -D HAVE_AV_CONFIG_H -I . -I /home/ismail/Sources/fate-test/work/src -O3 -Wdeclaration-after-statement -Wall -Wno-parentheses -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -std=c99 -ferror-limit 19 -fmessage-length 207 -pthread -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -mllvm -stack-alignment=16 -o /tmp/cc-JW52X1.s -x c libavcodec/h264.c 1. parser at end of file 2. Code generation 3. Running pass 'Optimize for code generation' on function '@xchg_mb_border' clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) make: *** [libavcodec/h264.o] Error 245 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 03:19:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 05:19:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 8164] New: clang++ has the option '-Wswitch-enum' turned on by default Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8164 Summary: clang++ has the option '-Wswitch-enum' turned on by default Product: clang Version: 2.7 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alexandre at elgato.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5500) --> (http://llvm.org/bugs/attachment.cgi?id=5500) Sample c++ file that exhibits the issue Description: Clang always use the '-Wswitch-enum' option when you compile a c++ file. There are apparently no way to turn off this compiler option. When you have a huge c++ project with third party code, you don't want to fix all these warnings. Regression: This issue was reproduced with clang++ from the LLVM 2.7 branch. It can also be reproduced when using Xcode 4.0b3 (Build 4A153). Expected behavior: Clang should not use the '-Wswitch-enum' option by default. Steps to reproduce: 1- Download the attached main.cpp file. 2- In a Terminal window, compile the file using clang++ (clang++ /PATH_TO/main.cpp) Result: clang++ reports 4 warnings although the option -Wswitch-enum was not specified: main.cpp:16:12: warning: enumeration value 'kMyEnumType_Three' not handled in switch [-Wswitch-enum] switch(deviceType) ^ main.cpp:16:12: warning: enumeration value 'kMyEnumType_Four' not handled in switch [-Wswitch-enum] main.cpp:16:12: warning: enumeration value 'kMyEnumType_Five' not handled in switch [-Wswitch-enum] main.cpp:16:12: warning: enumeration value 'kMyEnumType_Six' not handled in switch [-Wswitch-enum] 4 diagnostics generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 06:43:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 08:43:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8164] clang++ has the option '-Wswitch-enum' turned on by default In-Reply-To: References: Message-ID: <20100916134314.859B62A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8164 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Douglas Gregor 2010-09-16 08:43:14 CDT --- This is the correct behavior. Use -Wno-switch-enum to turn off this warning. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 08:47:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 10:47:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 8167] New: Invalid template code accepted Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8167 Summary: Invalid template code accepted Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The line: template < int 0 ; is accepted by clang++, with a warning. It should be rejected. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 10:43:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 12:43:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 8161] [ValueProp] Assertion `From != To && "ReplaceAndSimplifyAllUses(X, X) is not valid!"' failed. In-Reply-To: References: Message-ID: <20100916174304.39F692A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8161 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Owen Anderson 2010-09-16 12:43:03 CDT --- Fixed in r114097. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 11:22:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 13:22:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 8168] New: Clang accepts static functions that would override virtual ones Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8168 Summary: Clang accepts static functions that would override virtual ones Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sebastian.redl at getdesigned.at CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com class A { public: virtual void foo() {} }; class B : public A { public: static void foo() {} }; The standard says ([class.virtual]p2) that any function with the same name, parameter-type-list, cv- and ref-qualifier as a virtual one in a base class overrides the base version and is virtual itself. It does not exclude static members from this, and so B::foo above would end up both static and virtual, which is not allowed. Both G++ and EDG reject the sample, but Clang accepts it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 11:30:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 13:30:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 8162] [LVI] Assertion `!isConstantRange() && "Constant and ConstantRange cannot be merged."' failed. In-Reply-To: References: Message-ID: <20100916183023.46F2B2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8162 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 11:32:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 13:32:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8154] Crash in Optimize for code generation In-Reply-To: References: Message-ID: <20100916183216.7AE6A2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8154 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dalej at apple.com Resolution| |FIXED --- Comment #3 from Dale Johannesen 2010-09-16 13:32:15 CDT --- Fixed in 114104. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 12:09:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 14:09:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 8163] clang crashes while compiling h264.c [mplayer/ffmpeg] In-Reply-To: References: Message-ID: <20100916190903.D9F542A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8163 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #5 from Duncan Sands 2010-09-16 14:09:03 CDT --- I now recall that I saw this same backtrace with PR8154. *** This bug has been marked as a duplicate of bug 8154 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 16 19:08:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Sep 2010 21:08:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8145] lnt should record the linker version in --simple runs In-Reply-To: References: Message-ID: <20100917020801.F36342A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8145 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |daniel at zuster.org Resolution| |FIXED --- Comment #1 from Daniel Dunbar 2010-09-16 21:08:01 CDT --- Fixed here: http://llvm.org/viewvc/llvm-project?view=rev&revision=114150 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 17 02:10:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Sep 2010 04:10:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 8169] New: clang does not allow a getter to be named "namespace" in ObjC++ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8169 Summary: clang does not allow a getter to be named "namespace" in ObjC++ Product: clang Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: js-llvm-bugzilla at webkeks.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I think the paste shows it all: avalon:/tmp$ g++ `objfw-config --all` test.mm avalon:/tmp$ clang `objfw-config --all` test.mm In file included from test.mm:1: In file included from /usr/local/include/ObjFW/ObjFW.h:16: /usr/local/include/ObjFW/OFExceptions.h:1166:40: error: expected identifier @property (readonly, nonatomic, getter=namespace) OFString *ns; ^ In file included from test.mm:1: In file included from /usr/local/include/ObjFW/ObjFW.h:43: /usr/local/include/ObjFW/OFXMLAttribute.h:29:37: error: expected identifier @property (readonly, retain, getter=namespace) OFString *ns; ^ In file included from test.mm:1: In file included from /usr/local/include/ObjFW/ObjFW.h:44: /usr/local/include/ObjFW/OFXMLElement.h:39:35: error: expected identifier @property (readonly, copy, getter=namespace) OFString *ns; ^ 3 errors generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 17 05:51:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Sep 2010 07:51:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 8170] New: Clang does not check constructor declaration that uses a template-id Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8170 Summary: Clang does not check constructor declaration that uses a template-id Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub-johannes at web.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang should reject the following template struct A { A() { } }; When parsing this, A differs from the dependent type A and should be rejected because it does not refer to that class type. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 17 08:22:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Sep 2010 10:22:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8171] New: Illegal bit field manipulation code generated for big endian architectures Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8171 Summary: Illegal bit field manipulation code generated for big endian architectures Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pekka.jaaskelainen at tut.fi CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5502) --> (http://llvm.org/bugs/attachment.cgi?id=5502) x86 clang result This simple C code using bitfields gets wrong bit level manipulation code generated by Clang for our big endian architecture (TCE) while llvm-gcc generates working code: #include struct { unsigned short final : 4; // 1 unsigned short hlen : 4; // 3 unsigned short x : 4; unsigned short y : 4; } val = {1, 2, 3, 4}; int main() { printf("INITIALIZED: val.final = %u, val.hlen = %u, val.x = %u, val.y=%u\n", val.final, val.hlen, val.x, val.y); val.final = 1; val.hlen = 2; val.x = 3; val.y = 4; printf("ASSIGNED: val.final = %u, val.hlen = %u, val.x = %u, val.y=%u\n", val.final, val.hlen, val.x, val.y); return (0); } With llvm-gcc to our architecture (expected result): INITIALIZED: val.final = 1, val.hlen = 2, val.x = 3, val.y=4 ASSIGNED: val.final = 1, val.hlen = 2, val.x = 3, val.y=4 Native x86 Clang generated code works OK too: INITIALIZED: val.final = 1, val.hlen = 2, val.x = 3, val.y=4 ASSIGNED: val.final = 1, val.hlen = 2, val.x = 3, val.y=4 The result when compiling with Clang to our architecture: INITIALIZED: val.final = 4, val.hlen = 3, val.x = 2, val.y=1 ASSIGNED: val.final = 1, val.hlen = 2, val.x = 3, val.y=4 What seems suspicious is that diffing the manipulation code generated for the little endian x86 and our big endian TTA is identical, only the initialization value differs: - at val = global %struct.anon { i8 33, i8 67 }, align 2 ; <%struct.anon*> [#uses=1] + at val = global %struct.anon { i8 18, i8 52 }, align 2 ; <%struct.anon*> [#uses=1] The code then loads the value as i16 and expects the bit field variables (final, hlen, x, y) to be stored at 0..3, 4...7, 8...11, 12..15 for both targets. gcc extracts the bitmask values correctly also for our big endian target (as far as I understood): 4...7, 0...3, LLVM 2.7 disassemblies attached. The problem repeats with the latest revision of the LLVM 2.8 branch also. Testing with another big endian target, PowerPC64: clang -O0 -ccc-host-triple powerpc64-foo-bar bug.c -emit-llvm -c -o bug.bc This also produces the (seemingly) erroneous code, the result is identical except for the datalayout string. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 17 08:31:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Sep 2010 10:31:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8172] New: configure --help in release_28 branch erroneously says assertions are enabled by default Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8172 Summary: configure --help in release_28 branch erroneously says assertions are enabled by default Product: new-bugs Version: 2.8 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu Using r114020 in the release_28 branch, configure --help says that assertions are enabled by default: $ ./configure --help `configure' configures llvm 2.8rc to adapt to many kinds of systems. ... --enable-assertions Compile with assertion checks enabled (default is YES) However, the script contains: # Check whether --enable-assertions was given. if test "${enable_assertions+set}" = set; then enableval=$enable_assertions; else enableval="no" fi so actually, assertions are disabled by default. Even autoconf/configure.ac says so: dnl --enable-assertions : check whether they want to turn on assertions or not: AC_ARG_ENABLE(assertions,AS_HELP_STRING( --enable-assertions,[Compile with assertion checks enabled (default is NO)]),, enableval="no") if test ${enableval} = "yes" ; then AC_SUBST(DISABLE_ASSERTIONS,[[]]) else AC_SUBST(DISABLE_ASSERTIONS,[[DISABLE_ASSERTIONS=1]]) fi Maybe configure needs to be regenerated? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 17 09:06:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Sep 2010 11:06:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 8173] New: clang++ (rev. 114175) fails inference of struct type template param from pointer to overloaded member function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8173 Summary: clang++ (rev. 114175) fails inference of struct type template param from pointer to overloaded member function Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: whatwasthataddress at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5506) --> (http://llvm.org/bugs/attachment.cgi?id=5506) Reduced program that exercises the problem. clang++ fails to compile this simple program. g++ and MSVC do. Also attached. #include #include struct A { boost::signal signal; }; class B { public: void slot (char) {} void slot (double) {} }; template inline boost::signals::connection connect (boost::signal &signalObj, TargetObj* target, ReturnType (MemberObj:: *fn) (Arg1), int group = 0) { return signalObj.connect(group, boost::bind(fn, target, _1)); } int main() { A a; B* mB = new B; ::connect(a.signal, mB, &B::slot); return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 17 12:18:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Sep 2010 14:18:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8174] New: Unreachable Block Elim sometimes changes code, but returns "false" in runOnMachineFunction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8174 Summary: Unreachable Block Elim sometimes changes code, but returns "false" in runOnMachineFunction Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: braxton.mckee at gmail.com CC: llvmbugs at cs.uiuc.edu Even if there are no dead blocks, it is possible for UnreachableBlockElim to remove some Phi nodes. It ought to set a flag and return "true" if it removes any phi nodes. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 17 16:44:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Sep 2010 18:44:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 8175] New: Destructors for stack variables not firing on goto from scope Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8175 Summary: Destructors for stack variables not firing on goto from scope Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jplevyak at acm.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com #include "stdio.h" class L { public: int i; L(int j) : i(j) { printf("L(%d)\n", i); } ~L() { if (i != 11) printf("~L(%d)\n", i); } }; int main(int argc, char *argv[]) { { L b(argc) ; printf("goto\n"); if (argc) goto l; } l: printf("here\n"); return 5; } jplevyak:svn [982] % g++ x.cc ; a.out L(1) goto ~L(1) here jplevyak:svn [983] % clang++ x.cc ; a.out L(1) goto here -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 17 19:58:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Sep 2010 21:58:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8175] Destructors for stack variables not firing on goto from scope In-Reply-To: References: Message-ID: <20100918025816.4BDF32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8175 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from John McCall 2010-09-17 21:58:16 CDT --- Fixed in r114259. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 17 22:20:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 00:20:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 8176] New: Warn about global destructors for static locals on platforms that don't use __cxa_atexit Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8176 Summary: Warn about global destructors for static locals on platforms that don't use __cxa_atexit Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com On platforms that don't use __cxa_atexit, or when use of that function has been specifically disabled, static locals are implemented using global destructors that test the initialization guard to determine if the global was initialized. On these platforms, -Wglobal-constructors should warn about static local variables that require a destructor. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 04:28:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 06:28:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 8177] New: Clang differs from GCC in how it deals with vtables in combination with limited symbol visibility, causing link errors Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8177 Summary: Clang differs from GCC in how it deals with vtables in combination with limited symbol visibility, causing link errors Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tor.arne.vestbo at nokia.com CC: llvmbugs at cs.uiuc.edu It seems as Clang differs from GCC in how it deals with vtables in combination with limited symbol visibility, causing link errors. The following test case exhibits the issue: http://gist.github.com/584533 The template class has one exported member function, which is implicitly instantiated for in foo.cpp. The class itself is not exported. GCC will in this case not include a vtable for TemplateClass in the shared library, and the vtable is generated when building the client application. For Clang the vtable is included in the shared library, but it's not exported, so when building the client application a vtable is not generated, and you'll get an error when linking that the vtable for TemplateClass is missing. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 05:28:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 07:28:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 8178] New: Clang doesn't accept public member reference that is private in derived class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8178 Summary: Clang doesn't accept public member reference that is private in derived class Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub-johannes at web.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code is valid according to [class.access.base] paragraph 4 last bullet. struct A { int a; }; struct B : A { private: using A::a; }; int main() { B b; b.a = 0; } Clang gives main1.cpp:12:5: error: 'a' is a private member of 'B' b.a = 0; ^ main1.cpp:7:12: note: declared private here using A::a; ^ 1 error generated. I'm not sure whether this is one of the weird access checking scenarious that clang intentionally doesn't implement. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 06:00:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 08:00:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 8179] New: exception Failure("There are two interfaces of module Llvm_bitwriter.") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8179 Summary: exception Failure("There are two interfaces of module Llvm_bitwriter.") Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: ojab at ojab.ru CC: llvmbugs at cs.uiuc.edu During `make install` make[2]: Leaving directory `/sources/llvm/bindings/ocaml' Fatal error: exception Failure("There are two interfaces of module Llvm_bitwriter.") make[1]: *** [regen-ocamldoc] Error 2 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 07:14:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 09:14:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 8178] Clang doesn't accept public member reference that is private in derived class In-Reply-To: References: Message-ID: <20100918141417.215AC2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8178 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |INVALID --- Comment #1 from John McCall 2010-09-18 09:14:16 CDT --- I don't think this is valid. The member found is the alias created by the using declaration, not the member itself, and "the alias created by the using-declaration has the usual accessibility for a member-declaration" [namespace.udecl]p15. So that bullet doesn't apply because the alias isn't accessible in any base class, because it's not even declared there. There might be a DR about this, so feel free to re-open if you dispute this interpretation or have other authority. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 08:36:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 10:36:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 8180] New: TD alignment's treatment in struct differs among InstCombine and CodeGen Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8180 Summary: TD alignment's treatment in struct differs among InstCombine and CodeGen Product: new-bugs Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu Consider the IR below; target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" %st = type {i8, double} define double* @foo() { entry: %p = getelementptr %st* null,i32 0,i32 1 ret double* %p } $ opt -instcombine | llc (f64:32:64) _foo: movl $4, %eax $ opt -instcombine | llc (f64:64:64) _foo: movl $8, %eax $ opt | llc (f64:64:64) _foo: movl $4, %eax On i686-linux, TD contains "f64:32:64". On powerpc-linux and cygming, f64 ABI alignment is 64(f64:64:64), thus I saw different results. FYI, it seems clang relies on ABI alignments. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 09:17:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 11:17:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 8181] New: negation operator bypasses resolving the address of an overload Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8181 Summary: negation operator bypasses resolving the address of an overload Product: clang Version: 2.8 Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: faisalv at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang compiles the following code without error: void f() void f(int); bool b = !&f; &f => is unresolvable in a boolean context and should be an error. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 09:40:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 11:40:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 8180] TD alignment's treatment in struct differs among InstCombine and CodeGen In-Reply-To: References: Message-ID: <20100918164031.131A72A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8180 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2010-09-18 11:40:30 CDT --- This is correct behavior. LLC doesn't listen to the behavior of the datalayout specified in the module, the target you compile for overrides it. In practice, this means that the frontend should generate the right td string, or none at all. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 10:42:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 12:42:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 8175] Destructors for stack variables not firing on goto from scope In-Reply-To: References: Message-ID: <20100918174230.584EC2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8175 John Plevyak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #2 from John Plevyak 2010-09-18 12:42:30 CDT --- This case still fails: #include "stdio.h" class L { public: int i; L(int j) : i(j) { printf("L(%d)\n", i); } ~L() { if (i != 11) printf("~L(%d)\n", i); } }; int main(int argc, char *argv[]) { { L b(argc) ; printf("goto\n"); if (!argc) goto l; if (argc < 10) { if (argc) goto l; } else { if (argc == 9) return 2; } return 1; } l: printf("here\n"); return 5; } jplevyak:svn [97] % g++ x.cc ; a.out L(1) goto ~L(1) here jplevyak:svn [98] % clang++ x.cc ; a.out L(1) goto here -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 15:28:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Sep 2010 17:28:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 8182] New: wrong constructor choice (templates) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8182 Summary: wrong constructor choice (templates) Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: muravev at yandex.ru CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang 2.8 (r114073) refuses to compile the code: struct foo { foo() {} template foo(T&) {} private: foo(const foo&); }; int main() { foo f1; foo f2(f1); // error: calling a private constructor of class 'foo' return 0; } But gcc (4.2, 4.5), comeau compilers and I think this is good code; and the reason is described in C++98 standard, 13.3.1 clause 7. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 23:11:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Sep 2010 01:11:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 8183] New: 100 warnings containing "indirection of non-volatile null pointer" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8183 Summary: 100 warnings containing "indirection of non-volatile null pointer" Product: clang Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: llvm at gentlyusedunderwear.com CC: llvmbugs at cs.uiuc.edu -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 18 23:44:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Sep 2010 01:44:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 8183] 100 warnings containing "indirection of non-volatile null pointer" In-Reply-To: References: Message-ID: <20100919064444.3AD042A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8183 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #4 from Chandler Carruth 2010-09-19 01:44:43 CDT --- Sorry about the spam. Bugzilla keeps eating my post. Last try, this time w/o quoting: I'm not sure what you're surprised here. The warning from clang is *because* the argument will always be NULL. From what little I can see, this warning is working as intended, but of course, since you haven't posted the actual code, much less a nice reduced test case that shows the problem, I can't really help much. > Any suggestions to squelch the warning?? The warning itself told you: "note: consider using __builtin_trap() or qualifying pointer with 'volatile'". If you feel there is actually a bug here, please re-open with a test case and a specific problem with Clang's behavior when compiling the test case. Currently, I have no idea what real code led to this warning, or why you feel it was inappropriate for Clang to warn here. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 19 00:07:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Sep 2010 02:07:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 8183] 100 warnings containing "indirection of non-volatile null pointer" In-Reply-To: References: Message-ID: <20100919070704.0DB5F2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8183 Rosyna Keller changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Version|unspecified |trunk Resolution|INVALID | --- Comment #6 from Rosyna Keller 2010-09-19 02:07:03 CDT --- Reopened and attached a super small text case. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 19 04:06:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Sep 2010 06:06:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 8184] New: Analyser does not understand __attribute__((cleanup)) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8184 Summary: Analyser does not understand __attribute__((cleanup)) Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu For exception-safe destruction of Objective-C objects, we use a macro that declares them using __attribute__((cleanup)) with a cleanup function that sends a -release message. This ensures that the object is freed when the function exits, either normally or via unwinding. The analyser, however, does not take the cleanup function into account and so reports a leak for every variable declared in this way. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 19 04:30:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Sep 2010 06:30:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 8185] New: Leaks in main() Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8185 Summary: Leaks in main() Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu It is fairly common not to bother explicitly freeing objects just before a return statement in main(), as the kernel will reclaim the memory immediately afterwards. It's somewhat misleading to categorise things as leaks when they occur in the program's main() function. The analyser encourages you to explicitly -release Objective-C objects just before exiting the program, which can cause thousands of -dealloc methods to be called, doing nothing other than delaying the program's exit. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 19 05:55:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Sep 2010 07:55:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 8186] New: -O3 does not imply -fomit-frame-pointer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8186 Summary: -O3 does not imply -fomit-frame-pointer Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: helmut at subdivi.de CC: llvmbugs at cs.uiuc.edu I compiled the following source using clang-2.7 -O3 on Debian sid amd64: ===== struct buffer { const char *data; unsigned int length; }; void buffer_inplace_advance(struct buffer *b, unsigned int length) { b->data += length; b->length -= length; } ===== This is a disassembly: ===== Dump of assembler code for function buffer_inplace_advance: 0x0000000000400760 <+0>: push %rbp 0x0000000000400761 <+1>: mov %rsp,%rbp 0x0000000000400764 <+4>: mov %esi,%eax 0x0000000000400766 <+6>: add %rax,(%rdi) 0x0000000000400769 <+9>: sub %eax,0x8(%rdi) 0x000000000040076c <+12>: pop %rbp 0x000000000040076d <+13>: retq ===== As you can see it contains a frame pointer. Turning on -fomit-frame-pointer in addition to -O3 makes the code much shorter. For gcc -fomit-frame-pointer is implied in -O3 on this architecture, so clang should probably do this, too. According to baldrick (irc). This bug is reproducible on 2.8, too. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Sep 19 10:06:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Sep 2010 12:06:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 8187] New: PCH with C++ headers stop compilation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8187 Summary: PCH with C++ headers stop compilation Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: muravev at yandex.ru CC: llvmbugs at cs.uiuc.edu, muravev at yandex.ru Created an attachment (id=5508) --> (http://llvm.org/bugs/attachment.cgi?id=5508) Preprocessed test.cpp How to reproduce: $ cat src/test.h #include $ cat src/test.cpp #include int main() { std::stringstream strm; return 0; } $ clang++ -x c++-header -Isrc -o build/test.h.pch src/test.h $ clang++ -c -Isrc -o build/test.o src/test.cpp <---- no errors $ clang++ -c -Isrc -include build/test.h -o build/test.o src/test.cpp In file included from /home/ilya/opt/programming/atom-project/Temp/pch/src/test.h:1: In file included from /usr/include/c++/4.4/sstream:38: In file included from /usr/include/c++/4.4/istream:39: In file included from /usr/include/c++/4.4/ios:42: In file included from /usr/include/c++/4.4/bits/ios_base.h:42: In file included from /usr/include/c++/4.4/bits/locale_classes.h:41: In file included from /usr/include/c++/4.4/string:52: /usr/include/c++/4.4/bits/basic_string.h:417:7: error: constructor for 'std::basic_string' must explicitly initialize the member '_M_dataplus' which does not have a default constructor basic_string(); ^ In file included from /home/ilya/opt/programming/atom-project/Temp/pch/src/test.h:1: /usr/include/c++/4.4/sstream:91:7: note: in instantiation of member function 'std::basic_string, std::allocator >::basic_string' requested here basic_stringbuf(ios_base::openmode __mode = ios_base::in | ios_base::out) ^ /usr/include/c++/4.4/sstream:509:7: note: in instantiation of member function 'std::basic_stringbuf, std::allocator >::basic_stringbuf' requested here basic_stringstream(ios_base::openmode __m = ios_base::out | ios_base::in) ^ src/test.cpp:5:23: note: in instantiation of member function 'std::basic_stringstream, std::allocator >::basic_stringstream' requested here std::stringstream strm; ^ In file included from /home/ilya/opt/programming/atom-project/Temp/pch/src/test.h:1: In file included from /usr/include/c++/4.4/sstream:38: In file included from /usr/include/c++/4.4/istream:39: In file included from /usr/include/c++/4.4/ios:42: In file included from /usr/include/c++/4.4/bits/ios_base.h:42: In file included from /usr/include/c++/4.4/bits/locale_classes.h:41: In file included from /usr/include/c++/4.4/string:52: /usr/include/c++/4.4/bits/basic_string.h:268:28: note: member is declared here mutable _Alloc_hider _M_dataplus; ^ /usr/include/c++/4.4/bits/basic_string.h:251:14: note: 'std::basic_string, std::allocator > >::_Alloc_hider' declared here struct _Alloc_hider : _Alloc ^ 1 error generated. ############### end of console output -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 20 06:14:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Sep 2010 08:14:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 8189] New: Parsing non-type parameter packs (non type variadic templates) is not implemented Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8189 Summary: Parsing non-type parameter packs (non type variadic templates) is not implemented Product: clang Version: 2.8 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: faisalv at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following is syntactically and semantically valid code, but it is not, parsed by clang 2.8: template struct S; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 20 06:28:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Sep 2010 08:28:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 8190] New: template template parameters containing parameter packs (variadic) not implemented entirely Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8190 Summary: template template parameters containing parameter packs (variadic) not implemented entirely Product: clang Version: 2.8 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: faisalv at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following is not implemented in Clang. >From 14.3.3 (temp.arg.template) p3 (n3126) 3 A template-argument matches a template template-parameter (call it P) when each of the template parameters in the template-parameter-list of the template-argument’s corresponding class template or template alias (call it A) matches the corresponding template parameter in the template-parameter-list of P. When P’s templateparameter-list contains a template parameter pack (14.5.3), the template parameter pack will match zero or more template parameters or template parameter packs in the template-parameter-list of A with the same type and form as the template parameter pack in P (ignoring whether those template parameters are template parameter packs) [ Example: template struct eval; template