From bugzilla-daemon at llvm.org Sun Jan 1 02:51:30 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 01 Jan 2012 08:51:30 +0000 Subject: [LLVMbugs] [Bug 11682] New: redundant overflow test not eliminated Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11682 Bug #: 11682 Summary: redundant overflow test not eliminated Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This testcase is simplified from std::vector::_M_insert_aux, the function called by push_back that doesn't get inlined. declare {i8, i1} @llvm.uadd.with.overflow.i8(i8, i8) declare void @use(i8, i1) define void @test(i8 %a) { %A = ashr i8 %a, 3 ; [-32..31] %B = lshr i8 -1, 3 ; 31 %uadd = tail call { i8, i1 } @llvm.uadd.with.overflow.i8(i8 %A, i8 %A) %sum = extractvalue { i8, i1 } %uadd, 0 ; [-64..62] %overflow = extractvalue { i8, i1 } %uadd, 1 ; %overflow is true iff %a is negative %C = icmp ugt i8 %sum, %B ; %C is true iff %sum is [32..255] ; %C is true iff %A is [16..255] ; %C is true iff %a is [128..255] ; %C is true iff %a is negative %D = or i1 %overflow, %C call void @use(i8 %sum, i1 %D) ret void } In this case, %C is equal to %overflow. opt -O2 does not remove the redundant computation, which would be helpful. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 06:34:08 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 01 Jan 2012 12:34:08 +0000 Subject: [LLVMbugs] [Bug 11683] New: Detecting infinite loops Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11683 Bug #: 11683 Summary: Detecting infinite loops Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: angusgh at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified It seems like it would be possible to cat a small subset of simple but common infinite loops by checking whether the variables in the loop condition are changed by either the condition check or the loop body. Sample code that this would trigger on might look like this (yes, I've actually written this kind of code, frequently, and it's not an error to gcc for obvious reasons). int main() { int i=10; while (i>0); //notice the semicolon { i--; } return 0; } This would also possibly be useful in a large set of cases where critical parts of loops have been malformed. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 08:32:22 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 01 Jan 2012 14:32:22 +0000 Subject: [LLVMbugs] [Bug 11684] New: Syntactically illegal pointer-to-function type accepted Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11684 Bug #: 11684 Summary: Syntactically illegal pointer-to-function type accepted Product: clang Version: 3.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ggreif at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Compile this code with clang: ------------------------------------------------------ template struct gauge_member_cfun { typedef RETURN (*ref)(const RECEIVER&, ARG1) const; template struct regauge2 { static RETURN ref(const RECEIVER& r, ARG1 a1) { return (r.*MEMBER_FUN)(a1); } }; template ref regauge(void) const; }; template gauge_member_cfun gauge(RETURN (RECEIVER::*)(ARG1) const); struct Foo { char* foo1c(int) const; }; void gaugers__HS(void) { gauge(&Foo::foo1c).regauge<&Foo::foo1c>(); } ------------------------------------------------------ It compiles without errors. But line 4 > typedef RETURN (*ref)(const RECEIVER&, ARG1) const; is syntactically illegal. There can be no 'const' or 'volatile' specifier on function pointers. So clang should reject this code, just like G++: > gauge.cpp:4: error: ?const? and ?volatile? function specifiers on ?ref? invalid in type declaration -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 11:28:08 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 01 Jan 2012 17:28:08 +0000 Subject: [LLVMbugs] [Bug 11685] New: clang ignores -funsafe-math-optimizations, -ffast-math, etc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11685 Bug #: 11685 Summary: clang ignores -funsafe-math-optimizations, -ffast-math, etc Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: benny.kra at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The clang driver currently doesn't pass information about unsafe fp optimizations down into codegen (llvm-gcc got this right). Many benchmarks are compiled with -ffast-math so this could be an easy perf win for 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 Sun Jan 1 11:43:37 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 01 Jan 2012 17:43:37 +0000 Subject: [LLVMbugs] [Bug 11686] New: Overload candidate computation is a space hog Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11686 Bug #: 11686 Summary: Overload candidate computation is a space hog Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: benny.kra at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The data structures to store conversion sequences are way too big: StandardConversionSequence: 48 bytes UserDefinedConversionSequence: 120 bytes AmbiguousConversionSequence: 80 bytes BadConversionSequence: 32 bytes ImplicitConversionSequence: 128 bytes (union of the last 4 structs + 8 extra bytes) OverloadCandidate.Conversions: 544 bytes (SmallVector) OverloadCandidate: 752 bytes To make matters worse we store the OverloadCandidates in a SmallVector. On a large source file vector reallocation can easily churn through gigabytes of memory. malloc on OSX seems not to aggressively reuse memory so we end up wasting a ton of memory in some cases (I haven't really tracked down what's causing this though). Some possible solutions: - Bit pack structs better (not many opportunities there), reduce SmallVector size - Pool allocate OverloadCandidates. llvm's SpecificBumpPtrAllocator doesn't support iteration, but that can be added. - Enhance the candidate computation to be lazier (not sure if this is feasible) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 12:07:49 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 01 Jan 2012 18:07:49 +0000 Subject: [LLVMbugs] [Bug 10113] Explicit template instantiation with default visibility fails to generate global symbols for certain types In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10113 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #23 from Rafael ?vila de Esp?ndola 2012-01-01 12:07:49 CST --- Fixed in r147405. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 13:11:08 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 01 Jan 2012 19:11:08 +0000 Subject: [LLVMbugs] [Bug 10113] Explicit template instantiation with default visibility fails to generate global symbols for certain types In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10113 Ami Fischman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #24 from Ami Fischman 2012-01-01 13:11:08 CST --- (In reply to comment #23) > Fixed in r147405. Not fixed for me. The repro from #8 still shows a difference from g++ (at 147405) and the chrome shared_library build still fails b/c of "missing" (hidden) 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 Sun Jan 1 13:47:44 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 01 Jan 2012 19:47:44 +0000 Subject: [LLVMbugs] [Bug 11687] New: jump-threading misses constant GEP Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11687 Bug #: 11687 Summary: jump-threading misses constant GEP Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This is a missed optimization in std::vector _M_insert_aux, the function in push_back() that doesn't get optimized enough to get inlined. Testcase: declare i8** @something() declare void @use(i8) define void @test(i64 %a) { entry: %cmp = icmp eq i64 %a, 0 br i1 %cmp, label %brtrue, label %brfalse brfalse: %ptr = call i8** @something() br label %brtrue brtrue: %phi = phi i8** [ %ptr, %brfalse ], [ null, %entry ] %gep = getelementptr inbounds i8** %phi, i64 %a %isnull = icmp eq i8** %gep, null br i1 %isnull, label %brtrue2, label %brfalse2 brtrue2: call void @use(i8 1) ret void brfalse2: call void @use(i8 2) ret void } The important missed optimization is the case where %a is zero. Then, %phi is null, and %gep is "gep inbounds (null, 0)" which is then compared against null (true) and we should thread the edge directly from %entry to %brtrue2. This probably belongs in -jump-threading. There may be a second missed optimization, but I'm not entirely sure. We may be able to remove the edge from %brtrue to %brtrue2, making it branch directly to %brfalse2. The matter at hand is whether %gep could be null, given that the GEP is inbounds and %a is non-zero. Can we have %ptr = inttoptr(10*sizeof(i8**)) and %a = -10 without violating inbounds? I don't think so, in address space zero. Is the only inbounds gep allowed to return null "gep inbounds (null, all-zeros)"? Or is even that not legal? If not, then std::vector push_back() is already being miscompiled... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 13:53:12 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 01 Jan 2012 19:53:12 +0000 Subject: [LLVMbugs] [Bug 11688] New: i386-pc-win32 struct by value return does not match MSVC calling convention Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11688 Bug #: 11688 Summary: i386-pc-win32 struct by value return does not match MSVC calling convention Product: clang Version: 3.0 Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: arcata at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When targeting i?86-pc-win32, Clang returns all structs by hidden pointer, although MSVC returns structs sized {8,4,3,2,1} bytes in registers, as documented at http://msdn.microsoft.com/en-us/library/984x0h58.aspx . A simple test case: --- #include struct Struct1 { uint64_t a; }; struct Struct2 { uint32_t a; }; struct Struct3 { char a, b, c; }; struct Struct1 c_return_1(void) { struct Struct1 r = { 0xC1A4C1A4C1A4C1A4ULL }; return r; } struct Struct2 c_return_2(void) { struct Struct2 r = { 0xC1A4C1A4U }; return r; } struct Struct3 c_return_3(void) { struct Struct3 r = { 0xAA, 0xBB, 0xCC }; return r; } --- cl.exe generates the following asm for c_return_1: --- _c_return_1 PROC ; File c:\users\joe\documents\code\clay\test\externals\abi\common\external_test1.c ; Line 15 push ebp mov ebp, esp sub esp, 8 ; Line 16 mov DWORD PTR _r$[ebp], -1046167132 ; c1a4c1a4H mov DWORD PTR _r$[ebp+4], -1046167132 ; c1a4c1a4H ; Line 17 mov eax, DWORD PTR _r$[ebp] mov edx, DWORD PTR _r$[ebp+4] ; Line 18 mov esp, ebp pop ebp ret 0 _c_return_1 ENDP --- You can see under "Line 17" that it moves the return value into edx:eax. By contrast, clang expects a hidden pointer argument: --- _c_return_1: # @c_return_1 # BB#0: subl $12, %esp movl 16(%esp), %eax movsd L_c_return_1.r, %xmm0 movsd %xmm0, (%esp) movsd %xmm0, (%eax) addl $12, %esp ret $4 --- Similar discrepancies occur for c_return_2 and c_return_3. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 19:21:50 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 02 Jan 2012 01:21:50 +0000 Subject: [LLVMbugs] [Bug 11689] New: cmake build set my apartment on fire Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11689 Bug #: 11689 Summary: cmake build set my apartment on fire Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Documentation AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified 1. use cmake build actual: apartment burned down expected: apartment stays usable. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 19:23:17 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 02 Jan 2012 01:23:17 +0000 Subject: [LLVMbugs] [Bug 11689] cmake build set my apartment on fire In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11689 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |chandlerc at gmail.com Resolution| |INVALID --- Comment #1 from Chandler Carruth 2012-01-01 19:23:17 CST --- Working as intended! PS, MY MASTER PLAN IS NOW COMPLETE!!!!! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 22:26:41 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 02 Jan 2012 04:26:41 +0000 Subject: [LLVMbugs] [Bug 11690] New: Support building chromium in shared_library mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11690 Bug #: 11690 Summary: Support building chromium in shared_library mode Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: fischman at chromium.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified With these env variables: GYP_DEFINES='disable_nacl=1 enable_svg=0 proprietary_codecs=1 ffmpeg_branding=Chrome clang=1 clang_use_chrome_plugins=1 component=shared_library' GYP_GENERATORS=ninja GYP_GENERATOR_FLAGS='output_dir=ninja config=Debug' build chromium with ninja on linux. The component=shared_library directive tries to build parts of chromium as .so's and the final browser links them in dynamically. Today this is broken because of symbol visibility problems (see bug 10113 and bug 10038 for some history), whereas g++ does not have these problems. Chromium pointers: http://code.google.com/p/chromium/wiki/LinuxBuildInstructions http://code.google.com/p/chromium/wiki/NinjaBuild -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 2 01:50:52 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 02 Jan 2012 07:50:52 +0000 Subject: [LLVMbugs] [Bug 11677] lto lazy-loading produces invalid ir In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11677 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Rafael ?vila de Esp?ndola 2012-01-02 01:50:52 CST --- Fixed in r147425. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 2 13:51:22 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 02 Jan 2012 19:51:22 +0000 Subject: [LLVMbugs] [Bug 11691] New: llc assertion failure generating arm neon vst2 with pointer update Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11691 Bug #: 11691 Summary: llc assertion failure generating arm neon vst2 with pointer update 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: andrew.b.adams at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7828 --> http://llvm.org/bugs/attachment.cgi?id=7828 bugpoint-reduced failure case llc fails an assertion when generating the arm neon VST2 instruction when it detects it can use the address-updating form: llc: /data/scratch/omap4/llvm/include/llvm/CodeGen/MachineOperand.h:385: int64_t llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong MachineOperand accessor"' failed. 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 'If Converter' on function '@curved_inner' Aborted I believe this is the case because the assertion is no longer triggered if you include this check in ARMISelLowering.cpp at line 7340 --- a/lib/Target/ARM/ARMISelLowering.cpp +++ b/lib/Target/ARM/ARMISelLowering.cpp @@ -7335,6 +7335,10 @@ static SDValue CombineBaseUpdate(SDNode *N, unsigned NumVecs = 0; if (isIntrinsic) { unsigned IntNo = cast(N->getOperand(1))->getZExtValue(); + + // AA: bail out for VST2 to avoid bug + if (IntNo == Intrinsic::arm_neon_vst2) continue; + switch (IntNo) { default: assert(0 && "unexpected intrinsic for Neon base update"); case Intrinsic::arm_neon_vld1: NewOpc = ARMISD::VLD1_UPD; A bugpoint-simplified bc file is attached. Compile it with -march=arm -mcpu=cortex-a9 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 2 16:02:54 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 02 Jan 2012 22:02:54 +0000 Subject: [LLVMbugs] [Bug 11692] New: An alloca that is never used for anything but updating itself is not optimized away Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11692 Bug #: 11692 Summary: An alloca that is never used for anything but updating itself is not optimized away Product: new-bugs Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Keywords: code-quality Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nodam at otinn.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7829 --> http://llvm.org/bugs/attachment.cgi?id=7829 example showing the behaviour An alloca that is never used for anything but updating itself is not optimized away in the attached example. This depends on the size of the array. When I tested it then it was optimized away if the size of the array was <= 21 and not optimized away otherwise. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 2 20:47:31 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 02:47:31 +0000 Subject: [LLVMbugs] [Bug 11685] clang ignores -funsafe-math-optimizations, -ffast-math, etc In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11685 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |chandlerc at gmail.com Resolution| |FIXED --- Comment #1 from Chandler Carruth 2012-01-02 20:47:31 CST --- Fixed in r147434 and r147440. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 00:10:08 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 06:10:08 +0000 Subject: [LLVMbugs] [Bug 11690] Support building chromium in shared_library mode In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11690 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Rafael ?vila de Esp?ndola 2012-01-03 00:10:08 CST --- Fixed in r 147441. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 05:40:00 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 11:40:00 +0000 Subject: [LLVMbugs] [Bug 11693] New: cannot install without permissions to write to source tree Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11693 Bug #: 11693 Summary: cannot install without permissions to write to source tree Product: new-bugs Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: release blocker Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: devel at fresse.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When issuing make install as a privileged user, the installation script tries to write to the source directory. freundt at segen:pts/19:/home/src/devel/llvm-3.0.src> sudo make V=1 install ... llvm[1]: Regenerating LibDeps.txt.tmp /bin/sh: /home/src/devel/llvm-3.0.src/tools/llvm-config/LibDeps.txt.tmp: Permission denied make[1]: *** [/home/src/devel/llvm-3.0.src/tools/llvm-config/LibDeps.txt.tmp] Error 1 make[1]: Leaving directory `/home/src/devel/llvm-3.0.src/tools/llvm-config' make: *** [install] Error 1 Reproducible: always How to reproduce: 1. run ./configure and make as a user that is allowed to write to the source tree 2. run make install as a user that isn't allowed to write to the source tree In my case the user root is allowed to write to /usr but NOT to the source tree itself. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 06:28:37 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 12:28:37 +0000 Subject: [LLVMbugs] [Bug 11694] New: FHS-ize info pages installation path Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11694 Bug #: 11694 Summary: FHS-ize info pages installation path Product: Build scripts Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: marius.maraloi at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified To better adhere to the FHS-2.3 recommendations, we can update the path for the installed info files. I'm proposing the following modification of "configure" and "autoconf/configure.ac" scripts: eval LLVM_ETCDIR="${prefix}/etc/llvm"; eval LLVM_INCLUDEDIR="${prefix}/include"; -eval LLVM_INFODIR="${prefix}/info"; +eval LLVM_INFODIR="${prefix}/share/info"; eval LLVM_MANDIR="${prefix}/man"; LLVM_CONFIGTIME=`date` As most distrbutions come with at least a symlink between "/usr/info" and "/usr/share/info", I'm submitting this as "enhancement" severity. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 11:08:41 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 17:08:41 +0000 Subject: [LLVMbugs] [Bug 11695] New: clang++ DWARF DW_TAG_friend generated wrong Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11695 Bug #: 11695 Summary: clang++ DWARF DW_TAG_friend generated wrong Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: davea42 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7832 --> http://llvm.org/bugs/attachment.cgi?id=7832 source code used to generate bad DWARF DW_TAG_friend is first documented in DWARF4 and should have a DW_AT_friend attribute, not the attributes listed here (attributes as shown by dwarfdump -i -M). < 4><0x00000dd4> DW_TAG_friend DW_AT_type <0x00000272>
DW_AT_data_member_location DW_OP_plus_uconst 0 DW_AT_accessibility DW_AT_accessibility has a bad form. This is 2.9. The compile command was clang++ -O0 -g const.cpp on Ubuntu 11.10 x86_64. And on Ubuntu 11.10 x86. David Anderson, maintainer of dwarfdump/libdwarf. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 12:16:28 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 18:16:28 +0000 Subject: [LLVMbugs] [Bug 11690] Support building chromium in shared_library mode In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11690 Ami Fischman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Ami Fischman 2012-01-03 12:16:28 CST --- The reduced test cases are fixed at r147441, but net_unittests still doesn't link out of the box. Some more reduced differences: v2.cc: template void Method() {} extern template __attribute__((visibility("default"))) void Method(); template void Method(); $ echo; clang++ -c -fvisibility-inlines-hidden -fvisibility=hidden v2.cc && readelf -Ws v2.o |c++filt |fgrep 'Method<' && g++ -c -fvisibility-inlines-hidden -fvisibility=hidden v2.cc && readelf -Ws v2.o |c++filt |fgrep 'Method<' 9: 0000000000000000 1 FUNC WEAK HIDDEN 5 void Method() 10: 0000000000000000 6 FUNC WEAK DEFAULT 5 void Method() Another difference: #include struct string16_char_traits { typedef int value_type; typedef short char_type; typedef std::streamoff off_type; typedef mbstate_t state_type; typedef std::fpos pos_type; static void assign(short& c1, const short& c2) {} static bool eq(const short& c1, const short& c2) { return c1 == c2; } static bool lt(const short& c1, const short& c2) { return c1 < c2; } static int compare(const short* s1, const short* s2, size_t n) { return 42; } static size_t length(const short* s) { return 42; } static const short* find(const short* s, size_t n, const short& a) { return 0; } static short* move(short* s1, const short* s2, int n) { return s1; } static short* copy(short* s1, const short* s2, size_t n) { return s1; } static short* assign(short* s, size_t n, short a) { return s; } static int not_eof(const int& c) { return 42; } static short to_short(const int& c) { return 42; } static int to_int(const short& c) { return 42; } static bool eq_int(const int& c1, const int& c2) { return true; } static int eof() { return 42; } }; extern template class std::basic_string; typedef std::basic_string string16; template class std::basic_string; $ echo; clang++ -c -fvisibility-inlines-hidden -fvisibility=hidden v2.cc && readelf -Ws v2.o |c++filt |fgrep '::size()' && g++ -c -fvisibility-inlines-hidden -fvisibility=hidden v2.cc && readelf -Ws v2.o |c++filt |fgrep '::size()' 536: 0000000000000000 30 FUNC WEAK HIDDEN 275 std::basic_string >::size() const 474: 0000000000000000 29 FUNC WEAK DEFAULT 338 std::basic_string >::size() const Accomodating these differences with changes in chromium (http://codereview.chromium.org/9071010) lets net_unittests link (yay!). I haven't gotten as far as trying to get chrome itself to link yet because of unrelated issues. I suspect a few more similar cases will pop up. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 13:29:53 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 19:29:53 +0000 Subject: [LLVMbugs] [Bug 11696] New: vector select with i16s returns incorrect result Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11696 Bug #: 11696 Summary: vector select with i16s returns incorrect result Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7833 --> http://llvm.org/bugs/attachment.cgi?id=7833 test case The attached test-case does a vector select with vectors of i16 values; the results it returns are incorrect; half the elements have the wrong value. % llc bug.ll -o bug.s && clang bug.cpp bug.s && ./a.out 0: 100 (expected 100) 1: 100 (expected 2) 2: 100 (expected 100) 3: 100 (expected 4) 4: 100 (expected 100) 5: 100 (expected 6) 6: 100 (expected 100) 7: 100 (expected 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 Jan 3 13:51:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 19:51:24 +0000 Subject: [LLVMbugs] [Bug 11697] New: Failure to link with LTO and -fvisibility-inlines-hidden Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11697 Bug #: 11697 Summary: Failure to link with LTO and -fvisibility-inlines-hidden Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu, rafael.espindola at gmail.com Classification: Unclassified Given the following files: a.h: #include class A; template struct LoopBase { __attribute((noinline)) int a() { printf("foo\n"); return 0; } }; a.cpp: #include template class LoopBase; b.cpp: #include int main() { LoopBase x; return x.a(); } clang with "-O4 -fvisibility-inlines-hidden" fails to link with the following error: ld: lto: could not merge in /var/folders/mb/c671t2cn7k385sks9twml1380000gn/T/b-GaJEgX.o because Linking globals named '_ZN8LoopBaseI1AE1aEv': symbols have different visibilities! for architecture x86_64 I'm pretty sure the C++ in question is valid; I'm not sure whether clang is generating bad IR, or the IR linking is incorrectly rejecting the IR generated by clang. Rafael said he would take a look. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 15:02:20 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 21:02:20 +0000 Subject: [LLVMbugs] [Bug 9774] False -Wunreachable-code warning in conditional expression In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9774 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Ted Kremenek 2012-01-03 15:02:20 CST --- Test case added in r147479. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 15:52:37 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 21:52:37 +0000 Subject: [LLVMbugs] [Bug 11695] clang++ DWARF DW_TAG_friend generated wrong In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11695 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Nick Lewycky 2012-01-03 15:52:37 CST --- Fixed in r146475 (post-3.0): http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111212/133336.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 Tue Jan 3 16:07:02 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 22:07:02 +0000 Subject: [LLVMbugs] [Bug 11661] set-xcode-analyzer fails if Python 2.7 is installed In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11661 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Ted Kremenek 2012-01-03 16:07:02 CST --- Thanks. I hardwired the script to use /usr/bin/python (r147483). I think this should be sufficient. If users report other issues, we can investigate those as they appear. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 16:20:32 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 22:20:32 +0000 Subject: [LLVMbugs] [Bug 11696] vector select with i16s returns incorrect result In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11696 Nadav Rotem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Nadav Rotem 2012-01-03 16:20:32 CST --- Reverted 147426. This should pass 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 Tue Jan 3 16:46:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 22:46:24 +0000 Subject: [LLVMbugs] [Bug 11695] clang++ DWARF DW_TAG_friend generated wrong In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11695 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #5 from Nick Lewycky 2012-01-03 16:46:24 CST --- The bug about bad forms has been fixed, but not the bug about applying attributes on DW_AT_friend. Reopening. The output I attached is indeed using clang from HEAD (which is why the form is fixed, at least). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 16:54:01 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 22:54:01 +0000 Subject: [LLVMbugs] [Bug 11698] New: Add warning on capturing guaranteed nil scope in ARC mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11698 Bug #: 11698 Summary: Add warning on capturing guaranteed nil scope in ARC mode Product: clang Version: trunk Platform: Macintosh OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tjw at me.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7836 --> http://llvm.org/bugs/attachment.cgi?id=7836 Example For initializers where the caller is allowed to do one-time setup configuration, you might write one of the following faulty blocks of code before getting to the correct version. The first case is caught since the nil initialization as part of -fobjc-arc isn't confirmed until the end of the variable declaration (or some such), and we get a warning about capturing uninitialized scope. Neither of these catches the problem in the second snippet of code: clang -c -Wall -fobjc-arc foo.m clang --analyze -Wall -fobjc-arc foo.m But, it would be reasonable to issue a warning that you are capturing guaranteed nil scope and then reading from it (w/o having previously written if it is declared with __block). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 17:16:01 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 23:16:01 +0000 Subject: [LLVMbugs] [Bug 11657] error in backend: Invalid operand for inline asm constraint 'i'! In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11657 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |WONTFIX --- Comment #3 from Eli Friedman 2012-01-03 17:16:01 CST --- You're only getting lucky with gcc for the given testcase... gcc apparently realizes that the two loads of sb_sample_f load the same value, and folds them away even at -O0. I don't think it's worth trying to support this sort of edge case in 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 Jan 3 17:30:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 23:30:46 +0000 Subject: [LLVMbugs] [Bug 11699] New: non-linear algorithm in x86_32 register allocator Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11699 Bug #: 11699 Summary: non-linear algorithm in x86_32 register allocator Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: kcc at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Reproducer (tried on r147487) extracted from a real life program. Looks like x86_32 register allocator has some non-linear algorithm which explodes on large inputs, especially when AddressSanitizer instrumentation is applied. Also, clang dies with SEGV on a huge input (might be a different bug). ---------------- run this bash script: ----------- #!/bin/bash gen() { N=$1 echo "#include " echo "static __gnu_cxx::hash_map x;" echo "void foo() {" for((i=0;i<$N; i++)); do echo "x[$i] = $RANDOM;" done echo "}" } run() { export TIMEFORMAT="--- %R --- $@" time "$@" } for((n=512;n<=8192; n*=2)); do echo $n gen $n > a.cc run g++ -m32 -w -c -O2 a.cc run clang++ -m32 -w -c -O2 a.cc run clang++ -m32 -w -c -O2 a.cc -faddress-sanitizer rm -f a.cc done ---------------- end bash script ----------- 512 --- 0.644 --- g++ -m32 -w -c -O2 a.cc --- 1.297 --- clang++ -m32 -w -c -O2 a.cc --- 9.358 --- clang++ -m32 -w -c -O2 a.cc -faddress-sanitizer 1024 --- 1.075 --- g++ -m32 -w -c -O2 a.cc --- 2.871 --- clang++ -m32 -w -c -O2 a.cc --- 30.950 --- clang++ -m32 -w -c -O2 a.cc -faddress-sanitizer 2048 --- 2.506 --- g++ -m32 -w -c -O2 a.cc --- 7.724 --- clang++ -m32 -w -c -O2 a.cc --- 130.324 --- clang++ -m32 -w -c -O2 a.cc -faddress-sanitizer 4096 --- 6.909 --- g++ -m32 -w -c -O2 a.cc --- 24.520 --- clang++ -m32 -w -c -O2 a.cc --- 739.267 --- clang++ -m32 -w -c -O2 a.cc -faddress-sanitizer 8192 --- 21.421 --- g++ -m32 -w -c -O2 a.cc clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal (use -v to see invocation) The profile looks like this (N=2048): w/o -faddress-sanitizer: 8.84% ::RegisterCoalescer::JoinIntervals 8.24% llvm::LiveInterval::join 4.80% ::LCSSA::runOnLoop 4.30% void std::__adjust_heap 2.79% ComputeUltimateVN With -faddress-sanitizer: 35.92% ::RegisterCoalescer::JoinIntervals 25.48% llvm::LiveInterval::join 10.03% llvm::LiveInterval::find 7.74% ComputeUltimateVN 2.22% llvm::SmallVectorImpl::push_back -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 17:44:53 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 03 Jan 2012 23:44:53 +0000 Subject: [LLVMbugs] [Bug 11700] New: clang++ puts DW_AT_containing type in the wrong place in DWARF output Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11700 Bug #: 11700 Summary: clang++ puts DW_AT_containing type in the wrong place in DWARF output 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: davea42 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7837 --> http://llvm.org/bugs/attachment.cgi?id=7837 Same example source as 11695, demonstrating different DWARF bug The output of clang++ -g -O0 const.cpp (source attached) followed by dwarfdump -i a.out shows in part: < 2><0x000000e9> DW_TAG_class_type DW_AT_sibling <0x000007b7> DW_AT_containing_type <0x000000e9> DW_AT_name "ios_base" but the DWARF4 spec says DW_AT_containing type should only appear on DW_TAG_ptr_to_member_type. Using clang HEAD on Ubuntu 11.10 x86. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 19:02:32 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 01:02:32 +0000 Subject: [LLVMbugs] [Bug 11701] New: 'Assertion failed: (isArray() && "Invalid accessor")' with constexpr and string literal Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11701 Bug #: 11701 Summary: 'Assertion failed: (isArray() && "Invalid accessor")' with constexpr and string literal Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu, richard-llvm at metafoo.co.uk Classification: Unclassified Testcase: class C { char a[4] = "foo"; }; constexpr C a = C(); constexpr int b = a.a[0]; Assertion failed: (isArray() && "Invalid accessor"), function getArrayInitializedElts, file /Volumes/storage/llvm/tools/clang/lib/AST/../../include/clang/AST/APValue.h, line 272. (This is from a thread from cfe-commits; putting it here so we don't lose track of 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 Jan 3 22:36:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 04:36:11 +0000 Subject: [LLVMbugs] [Bug 11702] New: Low-quality diagnostic with block literal + trailing return type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11702 Bug #: 11702 Summary: Low-quality diagnostic with block literal + trailing return type Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: void (^a)() = ^() -> void {}; Gives the following diagnostic: error: function with trailing return type must specify return type 'auto', not '' 1 error generated. This diagnostic is rather confusing, and doesn't actually point at anything. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 01:45:41 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 07:45:41 +0000 Subject: [LLVMbugs] [Bug 11652] assertion failures when Type.cpp is compiled with -Os In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11652 Stepan Dyatkovskiy changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |stpworld at narod.ru Resolution| |FIXED --- Comment #9 from Stepan Dyatkovskiy 2012-01-04 01:45:41 CST --- Fixed in r147470 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 04:16:30 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 10:16:30 +0000 Subject: [LLVMbugs] [Bug 10974] Clang fails on nested vector literals In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10974 Anton Lokhmotov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Anton Lokhmotov 2012-01-04 04:16:30 CST --- http://llvm.org/viewvc/llvm-project?view=rev&revision=147496 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 06:19:59 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 12:19:59 +0000 Subject: [LLVMbugs] [Bug 11703] New: poor x86-64 register allocation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11703 Bug #: 11703 Summary: poor x86-64 register allocation Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Register Allocator AssignedTo: unassignedbugs at nondot.org ReportedBy: jay.foad at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I get: $ echo "unsigned f(unsigned x) { return (x >> 1) + (x & 1); }" | clang -O3 -S -o - -x c - ... # BB#0: # %entry movl %edi, %eax andl $1, %eax shrl %edi addl %eax, %edi movl %edi, %eax ret ... This seems like poor register allocation, because the last two instructions before the ret could be replaced with: addl %edi, %eax I'm using trunk rev 147529 on Ubuntu 11.10 x86-64. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 12:57:19 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 18:57:19 +0000 Subject: [LLVMbugs] [Bug 11704] New: automatically tries to build libc++ using OSX Makefile Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11704 Bug #: 11704 Summary: automatically tries to build libc++ using OSX Makefile Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hello, I have a checkout of llvm, and checkouts of clang under tools/ and compiler-rt and libcxx under projects/ as recommended. I configure with the simple: /path/to/configure --prefix=/path/to/inst --enable-optimized, then run make and make install. Apparently, this now automatically tries to handle libc++ (which is great), except that it uses the Makefile in there which only stands some chance of working on OSX. Besides, the compilation is triggered by make install, not by make. And things are done in the checkout, not in the build directory. Since the build system is not ready, it might be better not to automatically do anything with libcxx? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 14:44:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 20:44:13 +0000 Subject: [LLVMbugs] [Bug 11705] New: fatal error: error in backend: expected relocatable expression on Linux x86 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11705 Bug #: 11705 Summary: fatal error: error in backend: expected relocatable expression on Linux x86 Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: kuba.staszak at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7839 --> http://llvm.org/bugs/attachment.cgi?id=7839 C++ test $ clang++ pgen.cc fatal error: error in backend: expected relocatable expression Crashes on Linux x86, works on OSX 64bit. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 16:10:02 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 22:10:02 +0000 Subject: [LLVMbugs] [Bug 11706] New: missing #endif in doc for analyzer_noreturn Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11706 Bug #: 11706 Summary: missing #endif in doc for analyzer_noreturn Product: Website Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Documentation AssignedTo: unassignedbugs at nondot.org ReportedBy: Len.Lattanzi at Gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified http://clang-analyzer.llvm.org/annotations.html#attr_analyzer_noreturn is missing an #endif after #ifndef CLANG_ANALYZER_NORETURN #if __has_feature(attribute_analyzer_noreturn) #define CLANG_ANALYZER_NORETURN __attribute__((analyzer_noreturn)) #else #define CLANG_ANALYZER_NORETURN #endif yeah a nit. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 16:35:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 22:35:42 +0000 Subject: [LLVMbugs] [Bug 11706] missing #endif in doc for analyzer_noreturn In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11706 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |FIXED --- Comment #1 from Ted Kremenek 2012-01-04 16:35:42 CST --- Fixed in r147556. Thanks for reporting 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 Wed Jan 4 16:38:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 22:38:11 +0000 Subject: [LLVMbugs] [Bug 11707] New: Clang producing pointless alloca for vector literal Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11707 Bug #: 11707 Summary: Clang producing pointless alloca for vector literal Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified While working on another bug, I noticed that we're compiling stuff like this (from test/CodeGen/alignment.c): typedef float __attribute__((vector_size(16), aligned(4))) packedfloat4; void test2(packedfloat4 *p) { *p = (packedfloat4) { 3.2f, 2.3f, 0.1f, 0.0f }; } into: define void @test2(<4 x float>* %p) nounwind uwtable ssp { entry: %p.addr = alloca <4 x float>*, align 8 %.compoundliteral = alloca <4 x float>, align 4 store <4 x float>* %p, <4 x float>** %p.addr, align 8 store <4 x float> , <4 x float>* %.compoundliteral %0 = load <4 x float>* %.compoundliteral %1 = load <4 x float>** %p.addr, align 8 store <4 x float> %0, <4 x float>* %1, align 4 ret void } There is no reason for the ".compoundliteral" alloca. We should be able to evaluate the expression as a ConstantVector r-value. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 17:10:25 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 23:10:25 +0000 Subject: [LLVMbugs] [Bug 11573] segfault on expr/expr.const/p2-0x.cpp In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11573 Pawel Worach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #9 from Pawel Worach 2012-01-04 17:10:25 CST --- This appears to be 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 Wed Jan 4 17:17:08 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 04 Jan 2012 23:17:08 +0000 Subject: [LLVMbugs] [Bug 11705] fatal error: error in backend: expected relocatable expression on Linux x86 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11705 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Eli Friedman 2012-01-04 17:17:08 CST --- r147561. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 22:11:22 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 04:11:22 +0000 Subject: [LLVMbugs] [Bug 11708] New: clang does not generate DWARF macro information Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11708 Bug #: 11708 Summary: clang does not generate DWARF macro information Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nallegra at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified DWARF defines a .debug_macinfo section that contains a list of preprocessor macros in the source file, but as far as I can tell, unlike gcc, clang does not know how to generate this section. (The data would be useful for some projects I'm working on.) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 22:15:17 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 04:15:17 +0000 Subject: [LLVMbugs] [Bug 10828] No warning for Most Vexing Parse of 0-argument function In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10828 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Richard Smith 2012-01-04 22:15:17 CST --- In r147599: :5:6: warning: empty parentheses interpreted as a function declaration [-Wvexing-parse] C 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 Wed Jan 4 23:35:25 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 05:35:25 +0000 Subject: [LLVMbugs] [Bug 11709] New: va_list on ARM is different from AAPCS 7.1.4 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11709 Bug #: 11709 Summary: va_list on ARM is different from AAPCS 7.1.4 Product: clang Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: borninjm at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7840 --> http://llvm.org/bugs/attachment.cgi?id=7840 TestCase of GCC's ARM AAPCS 7.1.4 requires that va_list match the structure shown va_list struct __va_list { void* __ap; } but clang generates va_list on ARM as following typedef void* __builtin_va_list; It does not pass the testcase of GCC - gcc.target/arm/va_list.c (see the attachement) Wee can handle this issue by modifying lib/Basic/Targets.cpp class ARMTargetInfo { ... virtual const char *getVAListDeclaration() const { return (ABI == "aapcs" || ABI == "aapcs-linux") ? "typedef struct __va_list { void* __ap; } __builtin_va_list;" :"typedef void* __builtin_va_list;"; } ... } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 00:48:44 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 06:48:44 +0000 Subject: [LLVMbugs] [Bug 11710] New: -fno-eliminate-unused-debug-types is not supported by clang (or llvm-gcc) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11710 Bug #: 11710 Summary: -fno-eliminate-unused-debug-types is not supported by clang (or llvm-gcc) Product: new-bugs Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nallegra at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified It is possible to instruct GCC to produce debugging information for all defined types, even if they are unused, by passing -fno-eliminate-unused-debug-types. For example, this can be used to get information about the structures defined in an include file: gcc-4.2 -fno-eliminate-unused-debug-types -gdwarf-2 -include /usr/include/mach-o/loader.h -x c /dev/null -c -o /tmp/output.o There is also the option -gfull which, according to gcc's man page, "emits debugging information for all symbols and types", but for some reason this does not produce the same effect. clang does not support -fno-eliminate-unused-debug-types; llvm-gcc accepts it, but appears to ignore it. clang maps -gfull to -g -fno-eliminate-unused-debug-symbols, but doesn't do anything with the latter. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 06:27:45 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 12:27:45 +0000 Subject: [LLVMbugs] [Bug 11705] fatal error: error in backend: expected relocatable expression on Linux x86 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11705 Jakub Staszak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #3 from Jakub Staszak 2012-01-05 06:27:45 CST --- Still crashes with -O. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 06:34:05 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 12:34:05 +0000 Subject: [LLVMbugs] [Bug 11711] New: Clang fails on FreeBSD testsuite Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11711 Bug #: 11711 Summary: Clang fails on FreeBSD testsuite Product: clang Version: 3.0 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ed at 80386.nl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider the following collection of C header files: http://svnweb.freebsd.org/base/head/sys/sys/cdefs.h?view=markup http://svnweb.freebsd.org/base/head/include/tgmath.h?view=markup http://svnweb.freebsd.org/base/head/include/complex.h?view=markup http://svnweb.freebsd.org/base/head/include/math.h?view=markup Now if we build this regression test: http://svnweb.freebsd.org/base/head/tools/regression/include/tgmath/tgmath.c?view=markup We will see that it works with at least GCC 4.2, 4.6 and 4.7, but fails with Clang here and there: not ok 1 - acos not ok 2 - asin not ok 3 - atan not ok 7 - cos not ok 8 - sin not ok 9 - tan not ok 10 - cosh not ok 11 - sinh not ok 12 - tanh not ok 13 - exp not ok 14 - log not ok 15 - pow not ok 16 - sqrt not ok 17 - fabs not ok 18 - atan2 not ok 20 - ceil not ok 24 - exp2 not ok 27 - floor not ok 31 - fmod not ok 39 - log10 Also, GCC 4.2 is slow and takes 4 seconds to build this file. Clang takes 8 seconds. GCC 4.7 needs less than 2 seconds. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 07:42:39 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 13:42:39 +0000 Subject: [LLVMbugs] [Bug 11712] New: value-initialization not performed on variable initialized by empty argument pack expansion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11712 Bug #: 11712 Summary: value-initialization not performed on variable initialized by empty argument pack expansion Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified clang incorrectly performs default-initialization, not value-initialization, on a variable initialized with an empty expression-list: template T build(U ...u) { T val(u...); return val; } int n = build(); // uninitialized, should be 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 Thu Jan 5 08:33:06 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 14:33:06 +0000 Subject: [LLVMbugs] [Bug 11713] New: clang++ fails to compile boost::bind with template function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11713 Bug #: 11713 Summary: clang++ fails to compile boost::bind with 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: juergen.hunold at ivembh.de CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7841 --> http://llvm.org/bugs/attachment.cgi?id=7841 self-containing testcase I've got some code using boost::bind and custom templates. Stripped down testcase attached. Tested clang: clang version 3.1 (trunk 147599) Target: x86_64-unknown-linux-gnu Thread model: posix The test case compile with gcc-4.6.1 gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) that is from stock ubuntu 11.10 The original code also compiles and work with msvc-9.0 and gcc-4.6.3 mingw The error message from clang (start) is: bind.cpp:35:5: error: no matching function for call to 'bind' boost::bind(do_work >, BOOST_ROOT/boost/bind/bind.hpp:1314:5: note: candidate template ignored: couldn't infer template argument 'R' BOOST_BIND(F f, A1 a1, A2 a2) lots of failed template instantion backtrace stripped ;-)) This happens with Boost trunk, but should be reproducible with Boost 1.48.0, 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 Thu Jan 5 11:54:43 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 17:54:43 +0000 Subject: [LLVMbugs] [Bug 11359] Crash in simple lambda expression In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11359 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution| |FIXED --- Comment #2 from Richard Smith 2012-01-05 11:54:43 CST --- Eli fixed this recently. :1:14: error: lambda expressions are not supported yet 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 Thu Jan 5 11:56:03 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 17:56:03 +0000 Subject: [LLVMbugs] [Bug 11648] C++ lambda segfault [with minimal testcase and bt] In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11648 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution| |DUPLICATE --- Comment #2 from Richard Smith 2012-01-05 11:56:03 CST --- Eli fixed this recently. :1:23: error: lambda expressions are not supported yet int main() { int n = ([](){return 10;})(); } ^ *** This bug has been marked as a duplicate of bug 11359 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 16:34:18 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 22:34:18 +0000 Subject: [LLVMbugs] [Bug 11712] value-initialization not performed on variable initialized by empty argument pack expansion In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11712 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2012-01-05 16:34:18 CST --- r147620. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 17:03:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 23:03:42 +0000 Subject: [LLVMbugs] [Bug 11705] fatal error: error in backend: expected relocatable expression on Linux x86 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11705 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Eli Friedman 2012-01-05 17:03:42 CST --- r147625. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 17:22:29 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 05 Jan 2012 23:22:29 +0000 Subject: [LLVMbugs] [Bug 11697] Failure to link with LTO and -fvisibility-inlines-hidden In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11697 Rafael ?vila de Esp?ndola 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 Jan 5 18:18:09 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 06 Jan 2012 00:18:09 +0000 Subject: [LLVMbugs] [Bug 11716] New: Crash referring to label from a constexpr function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11716 Bug #: 11716 Summary: Crash referring to label from a constexpr function Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu, richard-llvm at metafoo.co.uk Classification: Unclassified Testcase: constexpr long a() { return (0 && ({lbl1:lbl2: 0;})), (long)&&lbl1 - (long)&&lbl2; } void b() { static long b = a(); } Crashes in IRGen with: Referring to a basic block in another function! indirectbr i8* undef, [label %lbl1, label %lbl2] Broken module found, compilation aborted! Not sure whether we should try to enforce some restriction on Evaluate or just add the relevant safety check to CGExprConstant. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 22:48:02 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 06 Jan 2012 04:48:02 +0000 Subject: [LLVMbugs] [Bug 11717] New: OCaml declare_qualified_global does not respect address space argument Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11717 Bug #: 11717 Summary: OCaml declare_qualified_global does not respect address space argument Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Archive library AssignedTo: unassignedbugs at nondot.org ReportedBy: jrk at csail.mit.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Without the below patch, it currently ignores the address space argument. define_qualified_global, however, *does* work, using LLVMAddGlobal as I have mirrored in the patch. diff --git a/bindings/ocaml/llvm/llvm_ocaml.c b/bindings/ocaml/llvm/llvm_ocaml.c index b64bba1..412e0bf 100644 --- a/bindings/ocaml/llvm/llvm_ocaml.c +++ b/bindings/ocaml/llvm/llvm_ocaml.c @@ -877,7 +877,7 @@ CAMLprim LLVMValueRef llvm_declare_qualified_global(LLVMType LLVMPointerType(Ty, Int_val(AddressSpace))); return GlobalVar; } - return LLVMAddGlobal(M, Ty, String_val(Name)); + return LLVMAddGlobalInAddressSpace(M, Ty, String_val(Name), Int_val(AddressSp } /* string -> llmodule -> llvalue option */ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 22:55:50 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 06 Jan 2012 04:55:50 +0000 Subject: [LLVMbugs] [Bug 11550] Missing warning for unused variables of a class type with user declare constructor In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11550 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Rafael ?vila de Esp?ndola 2012-01-05 22:55:50 CST --- Fixed in r147652. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 06:20:59 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 06 Jan 2012 12:20:59 +0000 Subject: [LLVMbugs] [Bug 11711] -fno-builtin still uses builtins In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11711 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |csdavec at swan.ac.uk Resolution| |FIXED --- Comment #5 from David Chisnall 2012-01-06 06:20:59 CST --- Fixed in r147655. We were doing the constant folding thing for builtins even if -fno-builtin was specified. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 10:20:45 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 06 Jan 2012 16:20:45 +0000 Subject: [LLVMbugs] [Bug 11718] New: ExeDepsFix seems to use exponential amount of memory on large functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11718 Bug #: 11718 Summary: ExeDepsFix seems to use exponential amount of memory on large functions Product: libraries Version: 3.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: ddneff at hotmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified With large functions, the ExeDepsFix pass seems to use exponential amounts of memory. A 100K instruction function with ~2k basic blocks took over 96GB of memory (not sure exactly how much is required to complete, my machine only has 96GB). I think this may be related to using a SmallVector for DomainValue::Instrs and then inserting duplicate instructions into this vector. Swapping out this SmallVector for a SmallPtrSet seems to fix the problem; I don't know if that is a great solution, but memory useage for this use case drops from 96GB to practically nothing (assuming I didn't break the algorithm somehow). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 14:54:30 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 06 Jan 2012 20:54:30 +0000 Subject: [LLVMbugs] [Bug 11681] Problem with glibc headers and -D_FORTIFY_SOURCE=2 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11681 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #13 from Rafael ?vila de Esp?ndola 2012-01-06 14:54:30 CST --- (In reply to comment #10) > Ah, OK, that makes sense. __va_arg_pack is bug 11681. > > I'm tempted to just mark this invalid. As far as I can tell, your testcase in > invalid, and just gets lucky on lucky on gcc >= 4.3. Makes sense. Looks like glibc has broken code for "gcc" <= 4.2. Once 7219 is fixed we might open o new bug for "support impersonating a newer 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 Fri Jan 6 15:02:33 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 06 Jan 2012 21:02:33 +0000 Subject: [LLVMbugs] [Bug 11719] New: Vector Alignment Is not Defined for Small Size Vector for Clang Vector Extension on ARM Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11719 Bug #: 11719 Summary: Vector Alignment Is not Defined for Small Size Vector for Clang Vector Extension on ARM Product: clang Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: yinma at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7844 --> http://llvm.org/bugs/attachment.cgi?id=7844 File to produce the bus err LLVM/Clang doesn't give the definition for vector type which size is smaller than 64bit. Without this definition, LLVM/Clang will generate wrong assembly code for ARM due to incorrect alignment information and cause executable program bus err. The attached file t.c is the test case to show the bus err. "clang -ccc-host-triple armv7-none-linux-gnueabi -mfloat-abi=softfp -mfpu=neon -O3 t.c" is the command line. With the optimization, load a short3 will be promoted to alignment 8 and use ldr.64 to load. ldr.64 is required to have memory address alignment 4 at least. However, for short3 type, the natural aligement is alignment 6, with the second element in array, it cannot hold alignment 4, So the instruction gets bus err. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 15:53:55 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 06 Jan 2012 21:53:55 +0000 Subject: [LLVMbugs] [Bug 11719] Vector Alignment Is not Defined for Small Size Vector for Clang Vector Extension on ARM In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11719 yinma at codeaurora.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #11 from yinma at codeaurora.org 2012-01-06 15:53:55 CST --- not a bug any more. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 17:06:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 06 Jan 2012 23:06:13 +0000 Subject: [LLVMbugs] [Bug 11720] New: Excessive memory consumption Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11720 Bug #: 11720 Summary: Excessive memory consumption Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: kbelco at sandia.gov CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified I've been running Boost trunk regression tests with trunk clang and wanted to point out this test on Linux consumes rather a lot of memory, and continues to consume memory if I let it run. I've pasted the compile line in case that helps. I'm unable to build clang trunk optimized on Linux, not sure why and don't know whether that would dramatically affect the compiler memory footprint anyways. I haven't checked to see if the problem exists on the Mac. Memory 42g before I killed it. 24604 kbelco 25 0 42.7g 42g 14m R 100.2 16.9 3:24.48 clang 0 R kbelco 24604 24603 99 85 0 - 12665762 - 15:19 ? 00:03:51 /home/kbelco/llvm_linux/build/Debug+Asserts/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name fail_quantity_scalar_add.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.17.50.0.6 -momit-leaf-frame-pointer -g -coverage-file /scratch/kbelco/boost/results/boost/bin.v2/libs/units/test/fail_quantity_scalar_add.test/clang-linux-trunk/debug/fail_quantity_scalar_add.o -resource-dir /home/kbelco/llvm_linux/build/Debug+Asserts/bin/../lib/clang/3.1 -D BOOST_ALL_NO_LIB=1 -I .. -fmodule-cache-path /var/tmp/clang-module-cache -I /sierra/Sntools/extras/compilers/intel/Compiler/11.1/064/tbb/include -internal-isystem /usr/include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /home/kbelco/llvm_linux/build/Debug+Asserts/bin/../lib/clang/3.1/include -internal-externc-isystem /usr/include -internal-externc-isystem /home/kbelco/gcc-4.4.4/include/c++/4.4.4 -internal-externc-isystem /home/kbelco/gcc-4.4.4/include/c++/4.4.4/x86_64-unknown-linux-gnu -O0 -Wall -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /scratch/kbelco/boost/boost/status -ferror-limit 19 -fmessage-length 0 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o /scratch/kbelco/boost/results/boost/bin.v2/libs/units/test/fail_quantity_scalar_add.test/clang-linux-trunk/debug/fail_quantity_scalar_add.o -x c++ ../libs/units/test/fail_quantity_scalar_add.cpp Preprocessed file is attached, command used to generate PP source is: /home/kbelco/llvm_linux/build/Debug+Asserts/bin/clang -E -c -g -D BOOST_ALL_NO_LIB=1 -I .. -I /sierra/Sntools/extras/compilers/intel/Compiler/11.1/064/tbb/include -internal-isystem /usr/local/include -internal-isystem /home/kbelco/llvm_linux/build/Debug+Asserts/bin/../lib/clang/3.1/include -internal-externc-isystem /usr/include -internal-externc-isystem /home/kbelco/gcc-4.4.4/include/c++/4.4.4 -internal-externc-isystem /home/kbelco/gcc-4.4.4/include/c++/4.4.4/x86_64-unknown-linux-gnu -O0 -Wall -std=c++11 -o fail_quantity_scalar_add.o -x c++ ../libs/units/test/fail_quantity_scalar_add.cpp -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 20:41:45 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 07 Jan 2012 02:41:45 +0000 Subject: [LLVMbugs] [Bug 11721] New: accepts invalid with forward declaration in a anonymous namespace Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11721 Bug #: 11721 Summary: accepts invalid with forward declaration in a anonymous namespace Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified clang accepts, but GCC and Comeau reject: namespace{ class bar; } class foo { friend class bar; void f(); }; namespace { class bar : public foo { void g(foo *p) { p->f(); } }; } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 21:25:14 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 07 Jan 2012 03:25:14 +0000 Subject: [LLVMbugs] [Bug 8632] [MC] Clang integrated-as doesn't support .cfi_startproc, .cfi_signal_frame, etc. ASM directives In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8632 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #6 from Rafael ?vila de Esp?ndola 2012-01-06 21:25:14 CST --- With r147717 we now produce a bad error message. There is a lot to be improved in MC, but it is better to have individual bugs for each 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 Sat Jan 7 01:40:33 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 07 Jan 2012 07:40:33 +0000 Subject: [LLVMbugs] [Bug 11699] non-linear algorithm in x86_32 register allocator In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11699 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Jakob Stoklund Olesen 2012-01-07 01:40:33 CST --- Fixed in r147726. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 7 14:11:06 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 07 Jan 2012 20:11:06 +0000 Subject: [LLVMbugs] [Bug 11722] New: False positive 'dead assignment' when using exception Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11722 Bug #: 11722 Summary: False positive 'dead assignment' when using exception Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: llvm at boxie.eu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7850 --> http://llvm.org/bugs/attachment.cgi?id=7850 Value stored to 'result' is never read Bug reported by the clang static analyzer. Description: Value stored to 'result' is never read File: /[...]/test/main.cpp Line: 11 The code prints the value 1 to console. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 7 15:03:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 07 Jan 2012 21:03:46 +0000 Subject: [LLVMbugs] [Bug 10859] Macro expansion notes are not colored In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10859 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Chandler Carruth 2012-01-07 15:03:46 CST --- Yep, sorry for loosing track of the PR and thanks for the reminder. =] -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 7 20:29:21 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 08 Jan 2012 02:29:21 +0000 Subject: [LLVMbugs] [Bug 11723] New: Clang doesn't substitute into template parameter list of type template parameter pack if the pack is unused Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11723 Bug #: 11723 Summary: Clang doesn't substitute into template parameter list of type template parameter pack if the pack is unused Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified This code should not be accepted, but clang (and GCC) accept it struct A { template< typename ...T, template::value, int >::type ... > class... > A(T...); }; A a(1, 2.0, 3); -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 8 06:42:17 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 08 Jan 2012 12:42:17 +0000 Subject: [LLVMbugs] [Bug 11724] New: Crash when using union in C++11: "Constant expressions should be initialized" UNREACHABLE Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11724 Bug #: 11724 Summary: Crash when using union in C++11: "Constant expressions should be initialized" UNREACHABLE Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: devlists at shadowlab.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7851 --> http://llvm.org/bugs/attachment.cgi?id=7851 Reduced test case clang crash while trying to compile the following simple code in c++11 mode: ------- MachOObjectFile.cpp union DataRefImpl { int c; }; void getRelocationValueString(DataRefImpl Rel) { DataRefImpl RelNext = Rel; } ----------------- clang++ -std=c++11 MachOObjectFile.cpp Constant expressions should be initialized. UNREACHABLE executed at /Users/jddupas/Projects/OpenSource/llvm/tools/clang/lib/CodeGen/CGExprConstant.cpp:910! ? Stack dump: 0. Program arguments: /opt/llvm/stage1/bin/clang -cc1 -triple x86_64-apple-macosx10.7.2 -emit-obj -mrelax-all -disable-free -main-file-name MachOObjectFile.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 127.2 -resource-dir /opt/llvm/stage1/bin/../lib/clang/3.1 -fmodule-cache-path /var/folders/nz/b9j_xhvx7rzbh2m570r_1dsr0000gn/T/clang-module-cache -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/jddupas/Desktop -ferror-limit 19 -fmessage-length 170 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/nz/b9j_xhvx7rzbh2m570r_1dsr0000gn/T/MachOObjectFile-T3mCnF.o -x c++ MachOObjectFile.cpp 1. parser at end of file 2. MachOObjectFile.cpp:6:6: LLVM IR generation of declaration 'getRelocationValueString' 3. MachOObjectFile.cpp:6:6: Generating code for declaration 'getRelocationValueString' 4. MachOObjectFile.cpp:6:48: LLVM IR generation of compound statement ('{}') -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 8 12:57:09 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 08 Jan 2012 18:57:09 +0000 Subject: [LLVMbugs] [Bug 11725] New: Miscompilation in x86-32 mode possibly involving spill slots Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11725 Bug #: 11725 Summary: Miscompilation in x86-32 mode possibly involving spill slots Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7852 --> http://llvm.org/bugs/attachment.cgi?id=7852 Pre-processed input See the attached input as output of clang -emit-llvm -O2 -S. If compiled with "llc -O0", it works. It fails if compiled with "llc -O1", but works if "opt -O1" is run first. The interesting combinations are "no opt and llc -O1" and "opt -O1 and llc -O1". Attached is the change in the assembler output that breaks the function. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 00:17:28 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 09 Jan 2012 06:17:28 +0000 Subject: [LLVMbugs] [Bug 11726] New: Assertion with -Wlarge-by-value-copy and unknown type in template Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11726 Bug #: 11726 Summary: Assertion with -Wlarge-by-value-copy and unknown type in template Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: laurie_llvmbugzilla at intrepid-geophysics.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This code generates an assertion when compiled with "/Users/loz/Projects/thirdparty/llvm_head/Release+Asserts/bin/clang" -Wlarge-by-value-copy -x c++ parallelUtilsAll-JI3ZpQ.ii: template class a { enum b { x }; b foo() { return x; } }; The real code was in Intel TBB, version 3.0.20110315, in tbb_allocator.h, but I minimised it to the above using the delta tool (delta.tigris.org). Here is the assertion, using svn revision 147764: parallelUtilsAll-JI3ZpQ.ii:1:10: error: unknown type name 'T' template class a ^ Unknown builtin type! UNREACHABLE executed at ASTContext.cpp:879! 0 clang 0x0000000110eaf922 _ZL15PrintStackTracePv + 34 1 clang 0x0000000110eaff19 _ZL13SignalHandleri + 777 2 libsystem_c.dylib 0x00007fff858e2cfa _sigtramp + 26 3 clang 0x00000001102a5fad llvm::DenseMap, llvm::DenseMapInfo >::InsertIntoBucket(clang::DeclarationName const&, clang::StoredDeclsList const&, std::pair*) + 413 4 clang 0x0000000110eafb66 abort + 22 5 clang 0x0000000110e9f314 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 468 6 clang 0x000000011024c0c6 clang::ASTContext::getTypeInfo(clang::Type const*) const + 518 7 clang 0x000000011024c440 clang::ASTContext::getTypeInfo(clang::Type const*) const + 1408 8 clang 0x000000011024c9ef clang::ASTContext::getTypeSizeInChars(clang::QualType) const + 31 9 clang 0x000000010fdcf491 clang::Sema::DiagnoseSizeOfParametersAndReturnValue(clang::ParmVarDecl* const*, clang::ParmVarDecl* const*, clang::QualType, clang::NamedDecl*) + 81 10 clang 0x000000010fdd0b2d clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 365 11 clang 0x000000010fd14404 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 244 12 clang 0x000000010fcca366 clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 534 13 clang 0x000000010fcc9c24 clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 132 14 clang 0x000000010fce3b32 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 3154 15 clang 0x000000010fce28ff clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, bool) + 4879 16 clang 0x000000010fcd1029 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 5625 17 clang 0x000000010fd15cf5 clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 645 18 clang 0x000000010fd157fa clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 954 19 clang 0x000000010fd1533d clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 477 20 clang 0x000000010fccf3a9 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 537 21 clang 0x000000010fd1f49a clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1738 22 clang 0x000000010fd1ed59 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 249 23 clang 0x000000010fcc828b clang::ParseAST(clang::Sema&, bool) + 283 24 clang 0x000000010fc95796 clang::CodeGenAction::ExecuteAction() + 1062 25 clang 0x000000010fa88122 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 978 26 clang 0x000000010fa6f0b8 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2776 27 clang 0x000000010fa666b7 cc1_main(char const**, char const**, char const*, void*) + 5495 28 clang 0x000000010fa6b452 main + 706 29 clang 0x000000010fa65134 start + 52 Stack dump: 0. Program arguments: /Users/loz/Projects/thirdparty/llvm_head/Release+Asserts/bin/clang -cc1 -triple x86_64-apple-macosx10.7.2 -emit-obj -mrelax-all -disable-free -main-file-name parallelUtilsAll-JI3ZpQ.ii -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 127.2 -resource-dir /Users/loz/Projects/thirdparty/llvm_head/Release+Asserts/bin/../lib/clang/3.1 -fmodule-cache-path /var/folders/mg/9ts97qln017gnyp6fh1ts6380000gr/T/clang-module-cache -fdeprecated-macro -fdebug-compilation-dir /Users/loz/deltasample -Wlarge-by-value-copy 64 -ferror-limit 19 -fmessage-length 263 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/mg/9ts97qln017gnyp6fh1ts6380000gr/T/parallelUtilsAll-JI3ZpQ-A2UJWb.o -x c++ parallelUtilsAll-JI3ZpQ.ii 1. parallelUtilsAll-JI3ZpQ.ii:11:2: current parser token ';' 2. parallelUtilsAll-JI3ZpQ.ii:1:13: parsing struct/union/class body 'a' 3. parallelUtilsAll-JI3ZpQ.ii:8:3: parsing function body 'foo' clang: error: unable to execute command: Illegal instruction: 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 Mon Jan 9 05:42:14 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 09 Jan 2012 11:42:14 +0000 Subject: [LLVMbugs] [Bug 11727] New: Where are the man pages? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11727 Bug #: 11727 Summary: Where are the man pages? Product: Documentation Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: haziz at mac.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I installed Clang 3.1/LLVM 3.0 on a server as a local install. Clang, which I use exclusively for C compiling, works fine, but I cannot access the man pages. Where are the man pages created by the standard source compile? I installed based on the instructions on the Clang website: http://clang.llvm.org/get_started.html Does this also generate a set of man pages? If yes where are they. If not how do I generate them? FWIW I ran the configure and make commands on the llvm, clang and compiler-rt repositories exactly as directed on the above website. On searching I found references on setting up a MANPATH enviromental variable, but have never done so in the past (I have with PATH, suspect MANPATH is similar). Please be detailed in your description of how to do it. I am a relative newbie at this. Any assistance would be appreciated. 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 Jan 9 07:55:47 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 09 Jan 2012 13:55:47 +0000 Subject: [LLVMbugs] [Bug 11728] New: segfault with a C++ code when used with -pthread Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11728 Bug #: 11728 Summary: segfault with a C++ code when used with -pthread Product: clang Version: 2.9 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: slayoo at igf.fuw.edu.pl CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7855 --> http://llvm.org/bugs/attachment.cgi?id=7855 bug.cpp and inc.cpp files which trigger a segfault during compilation on my machine Trying to compile the attached code I get the following behaviour: $ clang++ -fsyntax-only -I/opt/local/include -pthread bug.cpp -> OK $ clang++ -S -I/opt/local/include bug.cpp -> OK $ clang++ -S -I/opt/local/include -pthread bug.cpp clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) $ clang++ -E -I/opt/local/include -pthread bug.cpp > code.cpp $ clang++ -S -I/opt/local/include -pthread code.cpp -> OK It might be tricky to reproduce... Please let me know how to get a backtrace from this segfault? so I'll post it here. Some relevant version info: - boost 1.48 - clang 2.9 (tags/RELEASE_29/final) - OS X 10.6.6 (10J567) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 09:12:06 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 09 Jan 2012 15:12:06 +0000 Subject: [LLVMbugs] [Bug 11729] New: #pragma iwdep support Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11729 Bug #: 11729 Summary: #pragma iwdep support Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ysangkok+llvmbugzilla at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33426 #pragma ivdep Says the compiler may assume the following loop nest does not have loop carried data dependenices. Supported at least by SGI CC and the Intel compiler. The SGI compiler restricts the pragma to innermost loops. The Intel compiler restricts the pragma to affect assumed data-dependencies only, that is, if data dependence analysis statically can prove a data-dependency this dependency is _not_ ignored. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 12:25:25 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 09 Jan 2012 18:25:25 +0000 Subject: [LLVMbugs] [Bug 11730] New: [AVX, SSE] inefficient code generated for vector compares due to sext to i32 moved across phi node Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11730 Bug #: 11730 Summary: [AVX,SSE] inefficient code generated for vector compares due to sext to i32 moved across phi node Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7856 --> http://llvm.org/bugs/attachment.cgi?id=7856 sext instructions immediately after vector compares, good code The attached two test cases demonstrate an interesting situation that leads to much worse code than usual for vector computation on SSE and AVX (at least). As context, when doing vector comparisons with those targets, it's usually important to immediately sext the result of the comparison to an value. (Which is what the instructions actually return; the x86 code generator picks up on this pattern and then emits just the desired vector comparison instruction.) In the attached test case, the originally-generated code had the sexts right after the vector compares, but then a later optimization pass noticed that two values feeding into a phi node both had sext to after them, so it removed the two original sexts and added a new one after the phi node. As a result, the x86 code generator doesn't pick up the pattern and generates very inefficient code that first painfully does a zext conversion to and then later painfully converts this back to the originally desired sext value. The two attachments are the same except for one has the sexts placed back after the vector compares and the other has the one with the single sext after the phi node. When run through llc -mattr=+avx, the second one has big sequences of the following as a result: movzbl %r15b, %edx vpinsrw $0, %edx, %xmm0, %xmm0 movzbl %r12b, %edx vpinsrw $1, %edx, %xmm0, %xmm0 movzbl %bl, %edx vpinsrw $2, %edx, %xmm0, %xmm0 movzbl %r9b, %edx vpinsrw $3, %edx, %xmm0, %xmm0 movzbl %r10b, %edx vpinsrw $4, %edx, %xmm0, %xmm0 movzbl %r14b, %edx vpinsrw $5, %edx, %xmm0, %xmm0 movzbl %r11b, %edx vpinsrw $6, %edx, %xmm0, %xmm0 movzbl %sil, %edx vpinsrw $7, %edx, %xmm0, %xmm6 vpextrw $1, %xmm6, %edx vmovd %xmm6, %esi vmovd %esi, %xmm0 vpinsrd $1, %edx, %xmm0, %xmm0 vpextrw $2, %xmm6, %edx vpinsrd $2, %edx, %xmm0, %xmm0 vpextrw $3, %xmm6, %edx vpinsrd $3, %edx, %xmm0, %xmm0 vpslld $31, %xmm0, %xmm0 vpsrad $31, %xmm0, %xmm7 vpextrw $5, %xmm6, %edx vpextrw $4, %xmm6, %esi vmovd %esi, %xmm0 vpinsrd $1, %edx, %xmm0, %xmm0 vpextrw $6, %xmm6, %edx vpinsrd $2, %edx, %xmm0, %xmm0 vpextrw $7, %xmm6, %edx vpinsrd $3, %edx, %xmm0, %xmm0 vpslld $31, %xmm0, %xmm0 vpsrad $31, %xmm0, %xmm0 vinsertf128 $1, %xmm0, %ymm7, %ymm0 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 13:01:34 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 09 Jan 2012 19:01:34 +0000 Subject: [LLVMbugs] [Bug 11731] New: llc -mcpu=cortex-m0 generates illegal opcodes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11731 Bug #: 11731 Summary: llc -mcpu=cortex-m0 generates illegal opcodes Product: new-bugs Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dwelch at dwelch.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified If you examine either the ARMv6-M TRM or even better the ARMv7-M TRM you will see that most of the thumb2 instructions for the cortex-m3 (ARMv7-M) are not supported by the cortex-m0 (ARMv6-M). llc does not complain about the use of -mcpu=cortex-m0 but it does produce instructions not supported by the cortex-m0, as if the backend assumes the two are the same. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 17:47:14 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 09 Jan 2012 23:47:14 +0000 Subject: [LLVMbugs] [Bug 11726] Assertion with -Wlarge-by-value-copy and unknown type in template In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11726 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2012-01-09 17:47:14 CST --- r147812. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 19:10:49 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 01:10:49 +0000 Subject: [LLVMbugs] [Bug 11732] New: Spurious ARC release of caught exception in @catch block Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11732 Bug #: 11732 Summary: Spurious ARC release of caught exception in @catch block Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: paul.q.stevenson at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following fragment: extern void Func(); int main() { @try { Func(); } @catch(id x) { } } generates this llvm code when compiled with -fobjc-arc on the current llvm/clang trunk: define i32 @main() nounwind uwtable { entry: %retval = alloca i32, align 4 %exn.slot = alloca i8* %x = alloca i8*, align 8 store i32 0, i32* %retval call void (...)* @Func() br label %eh.cont eh.cont: ; preds = %entry, %catch %0 = load i32* %retval ret i32 %0 catch: ; No predecessors! %exn = load i8** %exn.slot %exn.adjusted = call i8* @objc_begin_catch(i8* %exn) nounwind store i8* %exn.adjusted, i8** %x %strongdestroy = load i8** %x call void @objc_release(i8* %strongdestroy) nounwind, !clang.imprecise_release !0 call void @objc_end_catch() nounwind br label %eh.cont } The catch block releases the caught exception, which appears contrary to Apple docs (e.g. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Exceptions/Tasks/HandlingExceptions.html) and is different from the behavior of release 3.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 Jan 9 19:36:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 01:36:16 +0000 Subject: [LLVMbugs] [Bug 11733] New: static_assert on Unicode string literals seems to get wrong values Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11733 Bug #: 11733 Summary: static_assert on Unicode string literals seems to get wrong values Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: seth.cantrell at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The code: static_assert(u8"\U0001F306"[0] == 0xF0, "The UTF-8 encoding of U+1F306 should be F0 9F 8C 86"); Results in the diagnostic: error: static_assert failed "The UTF-8 encoding of U+1F306 should be F0 9F 8C 86" static_assert(u8"\U0001F306"[0] == 0xF0, ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ Whereas the code: char const *s = u8"\U0001F306"; Produces the IR @.str = private unnamed_addr constant [5 x i8] c"\F0\9F\8C\86\00", align 1 Clang is producing the correct string encoding for the IR, but this is not reflected in the static_assert evaluation of the string literal. I'm not sure exactly what value static_assert believes the string literal to contain. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 20:02:40 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 02:02:40 +0000 Subject: [LLVMbugs] [Bug 11733] static_assert on Unicode string literals seems to get wrong values In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11733 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk, | |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #1 from Eli Friedman 2012-01-09 20:02:40 CST --- Try: static_assert(u8"\U0001F306"[0] == (signed char)0xF0, ""); -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 20:28:27 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 02:28:27 +0000 Subject: [LLVMbugs] [Bug 11731] llc -mcpu=cortex-m0 generates illegal opcodes In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11731 dwelch at dwelch.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from dwelch at dwelch.com 2012-01-09 20:28:27 CST --- My apologies, I am not able to repeat the problem I was seeing. it must have been user 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 Mon Jan 9 22:38:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 04:38:42 +0000 Subject: [LLVMbugs] [Bug 11724] Crash when using union in C++11: "Constant expressions should be initialized" UNREACHABLE In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11724 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Richard Smith 2012-01-09 22:38:42 CST --- Thanks, fixed in r147839. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 00:58:27 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 06:58:27 +0000 Subject: [LLVMbugs] [Bug 11734] New: When assigning a real number to complex one, zero out the imaginary part Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11734 Bug #: 11734 Summary: When assigning a real number to complex one, zero out the imaginary part Product: libc++ Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: radford at blackbean.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7859 --> http://llvm.org/bugs/attachment.cgi?id=7859 Patch to fix assigning a real to a complex number. The following incorrectly prints (5,4). Patch attached. int main(int c, char **v) { std::complex x(3,4); x = 5; std::cout << x << "\n"; 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 Tue Jan 10 06:32:05 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 12:32:05 +0000 Subject: [LLVMbugs] [Bug 11728] segfault with a C++ code when used with -pthread In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11728 Sylwester Arabas changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Sylwester Arabas 2012-01-10 06:32:05 CST --- Indeed, the crash no longer happens with clang 3.1 (trunk 146339). Sorry for bothering. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 08:57:56 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 14:57:56 +0000 Subject: [LLVMbugs] [Bug 11735] New: Poor optimization of switch statement Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11735 Bug #: 11735 Summary: Poor optimization of switch statement Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: jmuizelaar at mozilla.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified for the following code: int foo(int a) { switch(a) { case 5: return 17; case 9: return 12; case 11: return 10; case 18: return 5; case 2: return 3; case 6: return 1; case 1: return 19; default: return 6; } } clang produces: .globl __Z3fooi __Z3fooi: ## @_Z3fooi Ltmp2: ## BB#0: ## %entry pushq %rbp movq %rsp, %rbp ## kill: EDI EDI RDI cmpl $17, %edi jg LBB0_5 ## BB#1: ## %entry decl %edi cmpl $10, %edi ja LBB0_10 ## BB#2: ## %entry movl $17, %eax leaq LJTI0_0(%rip), %rdx movslq (%rdx,%rdi,4), %rcx addq %rdx, %rcx jmpq *%rcx LBB0_3: ## %sw.bb1 movl $12, %eax popq %rbp ret LBB0_4: ## %sw.bb2 movl $10, %eax popq %rbp ret LBB0_5: ## %entry cmpl $18, %edi jne LBB0_10 ## BB#6: ## %sw.bb3 movl $5, %eax popq %rbp ret LBB0_7: ## %sw.bb4 movl $3, %eax popq %rbp ret LBB0_8: ## %sw.bb5 movl $1, %eax popq %rbp ret LBB0_9: ## %sw.bb6 movl $19, %eax popq %rbp ret LBB0_10: ## %sw.default movl $6, %eax LBB0_11: ## %return popq %rbp ret Ltmp6: Leh_func_end0: .align 2, 0x90 L$start$jt32$0: L0_0_set_9 = LBB0_9-LJTI0_0 L0_0_set_7 = LBB0_7-LJTI0_0 L0_0_set_10 = LBB0_10-LJTI0_0 L0_0_set_11 = LBB0_11-LJTI0_0 L0_0_set_8 = LBB0_8-LJTI0_0 L0_0_set_3 = LBB0_3-LJTI0_0 L0_0_set_4 = LBB0_4-LJTI0_0 LJTI0_0: .long L0_0_set_9 .long L0_0_set_7 .long L0_0_set_10 .long L0_0_set_10 .long L0_0_set_11 .long L0_0_set_8 .long L0_0_set_10 .long L0_0_set_10 .long L0_0_set_3 .long L0_0_set_10 .long L0_0_set_4 where as gcc 4.6 produces: .text .align 4,0x90 .globl __Z3fooi __Z3fooi: LFB0: subl $1, %edi movl $6, %eax cmpl $17, %edi ja L2 leaq _CSWTCH.1(%rip), %rax movl (%rax,%rdi,4), %eax L2: rep ret LFE0: .const .align 5 _CSWTCH.1: .long 19 .long 3 .long 6 .long 6 .long 17 .long 1 .long 6 .long 6 .long 12 .long 6 .long 10 .long 6 .long 6 .long 6 .long 6 .long 6 .long 6 .long 5 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 09:00:05 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 15:00:05 +0000 Subject: [LLVMbugs] [Bug 9794] [byval] byval disables tail calls generating lots of copies In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9794 Jeff Muizelaar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Jeff Muizelaar 2012-01-10 09:00:05 CST --- clang currently produces: jmp _g ## TAILCALL so this seems to be 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 Jan 10 09:16:07 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 15:16:07 +0000 Subject: [LLVMbugs] [Bug 11734] When assigning a real number to complex one, zero out the imaginary part In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11734 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2012-01-10 09:16:07 CST --- Fix Committed revision 147853. 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 Jan 10 12:57:23 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 18:57:23 +0000 Subject: [LLVMbugs] [Bug 11720] Excessive memory consumption In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11720 K. Noel Belcourt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #3 from K. Noel Belcourt 2012-01-10 12:57:23 CST --- It seems changes to clang trunk have either masked or fixed the problem. Guess we'll close this for now as I am no longer able to reproduce this either. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 13:07:51 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 19:07:51 +0000 Subject: [LLVMbugs] [Bug 11177] 3.0rc1: bindings/ocaml/llvm/Release/META.llvm not created In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11177 Sylvestre Ledru changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Sylvestre Ledru 2012-01-10 13:07:51 CST --- It has been fixed by r144183. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 16:18:33 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 22:18:33 +0000 Subject: [LLVMbugs] [Bug 11736] New: %R Unsupported operand type for movw/movt on ARMv6T2 and later Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11736 Bug #: 11736 Summary: %R Unsupported operand type for movw/movt on ARMv6T2 and later Product: libraries Version: trunk Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: xerxes at zafena.se CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7860 --> http://llvm.org/bugs/attachment.cgi?id=7860 fix when movw/movt operand is a register.patch The attached patch are a proposed fix the UNREACHABLE/unimplemented in ARMCodeEmitter::getMovi32Value when the passed MachineOperand .isReg() This bug got introduced with LLVM 2.8 for ARMv6T2 and later and are still found in the current SVN trunk. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 16:26:35 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 22:26:35 +0000 Subject: [LLVMbugs] [Bug 11691] llc assertion failure generating arm neon vst2 with pointer update In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11691 Jim Grosbach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Jim Grosbach 2012-01-10 16:26:35 CST --- The pseudos were using the wrong base classes, getting everything after than confused. Fixed in r147876. There may be more of this sort of thing due to the pretty hefty refactoring of those instructions and intrinsics that's been going on lately. Hopefully not too many. Thanks for the great test 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 Tue Jan 10 16:50:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 22:50:16 +0000 Subject: [LLVMbugs] [Bug 11737] New: typo correction applied to implicit begin/end calls in for-range statement Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11737 Bug #: 11737 Summary: typo correction applied to implicit begin/end calls in for-range statement Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified struct S{}; bool begun(S); void f() { for (auto i : S()) {} } :1:51: error: use of undeclared identifier 'begin'; did you mean 'begun'? struct S{}; bool begun(S); void f() { for (auto i : S()) {} } ^ begun :1:18: note: 'begun' declared here struct S{}; bool begun(S); void f() { for (auto i : 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 Tue Jan 10 17:02:55 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 10 Jan 2012 23:02:55 +0000 Subject: [LLVMbugs] [Bug 11738] New: clang segfaults when file changes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11738 Bug #: 11738 Summary: clang segfaults when file changes 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: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The following bug is probably very stupid, and I don't mind if it gets closed, but I thought I would report it anyway. Take any reasonable sized C++ file, call it X.cc (I preprocessed a boost file to get a ~2M file) Execute the following command: for i in `seq 10000`; do cat X.cc > t.cc; done & While that is spinning in the background, type: clang++ t.cc -c A few times, and you are likely to see a crash like the one before. I am fairly sure this is not from clang++ just seeing a truncated file, as I have tried to truncate the file I was using in many places, and have not seen clang crash (I actually found this bug when my fuzzer started misbehaving and changing the file while clang was compiling. I get a segfault like the one below. Note the files mentioned at the bottom, writen to /tmp, compile fine (well, often with errors, but no segfaults). 0 clang 0x0000000001b5f98f 1 clang 0x0000000001b5fe19 2 libpthread.so.0 0x00007f93be567060 3 clang 0x0000000000fbd1ac 4 clang 0x0000000000fc1af2 clang::SourceManager::getLineNumber(clang::FileID, unsigned int, bool*) const + 482 5 clang 0x0000000000fc2862 clang::SourceManager::getPresumedLoc(clang::SourceLocation) const + 450 6 clang 0x0000000000f78283 clang::Preprocessor::HandleDigitDirective(clang::Token&) + 2739 7 clang 0x0000000000f7dd33 clang::Preprocessor::HandleDirective(clang::Token&) + 1411 8 clang 0x0000000000f60128 clang::Lexer::LexTokenInternal(clang::Token&) + 2104 9 clang 0x0000000000f6181f clang::Lexer::LexTokenInternal(clang::Token&) + 7983 10 clang 0x0000000000882a38 11 clang 0x000000000087c73a clang::Parser::ExpectAndConsume(clang::tok::TokenKind, unsigned int, char const*, clang::tok::TokenKind) + 762 12 clang 0x00000000008905ee clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1886 13 clang 0x000000000089695c clang::Parser::ParseSimpleDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, bool, clang::Parser::ForRangeInit*) + 652 14 clang 0x0000000000896b02 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 178 15 clang 0x000000000087eb4d clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 893 16 clang 0x000000000087f628 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 168 17 clang 0x00000000008543cd clang::ParseAST(clang::Sema&, bool) + 269 18 clang 0x000000000060101d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 317 19 clang 0x00000000005e7a1a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1114 20 clang 0x00000000005dc4b2 cc1_main(char const**, char const**, char const*, void*) + 866 21 clang 0x00000000005e62be main + 702 22 libc.so.6 0x00007f93bd83430d __libc_start_main + 237 23 clang 0x00000000005dbff9 Stack dump: 0. Program arguments: /scratch/dist/clang/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name t.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.53.20110810 -momit-leaf-frame-pointer -coverage-file t.o -resource-dir /scratch/dist/clang/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward -internal-isystem /usr/local/include -internal-isystem /scratch/dist/clang/bin/../lib/clang/3.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/caj/temp -ferror-limit 19 -fmessage-length 136 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 1. clang: error: unable to execute command: Bus error clang: error: clang frontend command failed due to signal (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/t-VkNgCT.ii clang: note: diagnostic msg: /tmp/t-VkNgCT.sh -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 18:02:00 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 00:02:00 +0000 Subject: [LLVMbugs] [Bug 11739] New: Have a fixit for |const char[] kFoo = "foo"; | et al Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11739 Bug #: 11739 Summary: Have a fixit for |const char[] kFoo = "foo";| et al Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified After writing a bunch of Java, I sometimes write something like: const char[] kFoo = "foo" Clang and gcc both point out that this is wrong: test.c:1:11: error: expected identifier or '(' const char[] kFoo = "foo"; ^ 1 error generated. This is a decent warning, but it would be fantastic if clang could also say "This isn't Java: put [] behind kFoo instead" (probably without the "This isn't java" part :-) ). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 18:15:38 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 00:15:38 +0000 Subject: [LLVMbugs] [Bug 11725] Miscompilation in x86-32 mode possibly involving spill slots In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11725 J?rg Sonnenberger 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 Jan 10 19:04:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 01:04:11 +0000 Subject: [LLVMbugs] [Bug 11740] New: can't use clang -g to assemble .s file with .file directive Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11740 Bug #: 11740 Summary: can't use clang -g to assemble .s file with .file directive Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat x.s .file "x.ll" $ clang -g x.s -c -o x.o x.s:1:2: error: input can't have .file dwarf directives when -g is used to generate dwarf debug info for assembly code .file "x.ll" ^ Yes, I'd like to pass -g to the compiler even when its input is a .s file. Even if the compiler isn't generating debug info so to speak. Please don't error on 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 Jan 10 19:13:48 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 01:13:48 +0000 Subject: [LLVMbugs] [Bug 11741] New: Missing "set but unused" warning Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11741 Bug #: 11741 Summary: Missing "set but unused" warning Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Gcc warns on void f(void) { int a; a = 1; } test.c: In function ?f?: test.c:2:7: warning: variable ?a? set but not used [-Wunused-but-set-variable] We don't. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 22:59:38 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 04:59:38 +0000 Subject: [LLVMbugs] [Bug 11742] New: c++11: constant emitter needs to zero-initialize padding for trivially-copyable types Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11742 Bug #: 11742 Summary: c++11: constant emitter needs to zero-initialize padding for trivially-copyable types Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Padding for objects with static storage duration is currently emitted as undef. This is non-conforming in C++11, because: 1) zero initialization is performed prior to constant initialization (unlike C) 2) zero initialization initializes padding to 0 bits (unlike C++98) 3) for trivially-copyable types, it is permissible to inspect the effective array of unsigned char (of size sizeof(T)) comprising the object Hence a conforming program can tell whether the padding has been zero-initialized. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 01:30:54 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 07:30:54 +0000 Subject: [LLVMbugs] [Bug 11735] Poor optimization of switch statement In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11735 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2012-01-11 01:30:54 CST --- Yep, this would be a great thing to have. *** This bug has been marked as a duplicate of bug 884 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 07:33:23 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 13:33:23 +0000 Subject: [LLVMbugs] [Bug 11743] New: Segfault in slightly crazy invalid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11743 Bug #: 11743 Summary: Segfault in slightly crazy invalid code Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified It is getting much harder to fuzz clang into crashing than it used to be, and the resulting code is much crazier looking (which is good). The following (invalid) code causes clang to segfault. It seems to be the malformed destructor call which is to blame. template struct integral_constant ; template int d() ; template struct X : integral_constant().~_T > { }; t.cc:6:30: error: pseudo-destructor expression must be called immediately with '()' struct X : integral_constant().~_T > ^ () Assertion failed: (!isNull() && "Cannot retrieve a NULL type pointer"), function getCommonPtr, file /Users/caj/work/code/clang/llvm/tools/clang/lib/Sema/../../include/clang/AST/Type.h, line 478. 0 clang 0x0000000102f2152e _ZL15PrintStackTracePv + 46 1 clang 0x0000000102f21ad9 _ZL13SignalHandleri + 297 2 libsystem_c.dylib 0x00007fff8ce36cfa _sigtramp + 26 3 libsystem_c.dylib 0x0000040001354634 _sigtramp + 18446607736219228500 4 clang 0x0000000102f217fb raise + 27 5 clang 0x0000000102f218b2 abort + 18 6 clang 0x0000000102f21891 __assert_rtn + 129 7 clang 0x00000001013469d1 clang::QualType::getCommonPtr() const + 97 8 clang 0x0000000101353f69 clang::QualType::getCanonicalType() const + 25 9 clang 0x00000001013439fc clang::ASTContext::getCanonicalType(clang::QualType) const + 28 10 clang 0x0000000101e5e17b (anonymous namespace)::StmtProfiler::VisitType(clang::QualType) + 59 11 clang 0x0000000101e5be26 (anonymous namespace)::StmtProfiler::VisitCXXPseudoDestructorExpr(clang::CXXPseudoDestructorExpr const*) + 134 12 clang 0x0000000101e59ccd clang::StmtVisitorBase::Visit(clang::Stmt const*) + 2189 13 clang 0x0000000101e5de76 (anonymous namespace)::StmtProfiler::VisitStmt(clang::Stmt const*) + 118 14 clang 0x0000000101e5e26d (anonymous namespace)::StmtProfiler::VisitExpr(clang::Expr const*) + 29 15 clang 0x0000000101e5c00d (anonymous namespace)::StmtProfiler::VisitCallExpr(clang::CallExpr const*) + 29 16 clang 0x0000000101e59d75 clang::StmtVisitorBase::Visit(clang::Stmt const*) + 2357 17 clang 0x0000000101e593fa clang::Stmt::Profile(llvm::FoldingSetNodeID&, clang::ASTContext const&, bool) const + 90 18 clang 0x0000000101e63738 clang::TemplateArgument::Profile(llvm::FoldingSetNodeID&, clang::ASTContext const&) const + 568 19 clang 0x0000000101e7221f clang::TemplateSpecializationType::Profile(llvm::FoldingSetNodeID&, clang::TemplateName, clang::TemplateArgument const*, unsigned int, clang::ASTContext const&) + 95 20 clang 0x0000000101ca107c clang::ASTContext::getCanonicalTemplateSpecializationType(clang::TemplateName, clang::TemplateArgument const*, unsigned int) const + 572 21 clang 0x0000000101ca0cba clang::ASTContext::getTemplateSpecializationType(clang::TemplateName, clang::TemplateArgument const*, unsigned int, clang::QualType) const + 458 22 clang 0x00000001015c9159 clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation, clang::TemplateArgumentListInfo&) + 1577 23 clang 0x00000001015caa00 clang::Sema::ActOnTemplateIdType(clang::CXXScopeSpec&, clang::OpaquePtr, clang::SourceLocation, clang::SourceLocation, clang::ASTTemplateArgsPtr, clang::SourceLocation) + 912 24 clang 0x000000010130a9d6 clang::Parser::AnnotateTemplateIdTokenAsType() + 454 25 clang 0x00000001012ca606 clang::Parser::ParseBaseTypeSpecifier(clang::SourceLocation&, clang::SourceLocation&) + 934 26 clang 0x00000001012ce442 clang::Parser::ParseBaseSpecifier(clang::Decl*) + 402 27 clang 0x00000001012ce172 clang::Parser::ParseBaseClause(clang::Decl*) + 178 28 clang 0x00000001012cd68d clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 925 29 clang 0x00000001012ccc35 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, bool) + 7813 30 clang 0x00000001012b7e32 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 7842 31 clang 0x0000000101307af7 clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 471 32 clang 0x0000000101307663 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 1299 33 clang 0x0000000101307064 clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 212 34 clang 0x00000001012b5b64 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 388 35 clang 0x0000000101312ea6 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1910 36 clang 0x00000001013126e9 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 361 37 clang 0x00000001012acff2 clang::ParseAST(clang::Sema&, bool) + 338 38 clang 0x0000000100f85878 clang::ASTFrontendAction::ExecuteAction() + 264 39 clang 0x000000010124ae7b clang::CodeGenAction::ExecuteAction() + 1051 40 clang 0x0000000100f854c7 clang::FrontendAction::Execute() + 199 41 clang 0x0000000100f52104 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 884 42 clang 0x0000000100f244f1 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 961 43 clang 0x0000000100f0e725 cc1_main(char const**, char const**, char const*, void*) + 965 44 clang 0x0000000100f1e429 main + 473 45 clang 0x0000000100f0e334 start + 52 Stack dump: 0. Program arguments: /assert-clang/bin/clang -cc1 -triple x86_64-apple-macosx10.7.2 -emit-obj -mrelax-all -disable-free -main-file-name t.cc -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 123.2.1 -coverage-file t.o -resource-dir /assert-clang/bin/../lib/clang/3.1 -fmodule-cache-path /var/folders/c2/j2pf8rdj4w1dr624t90z2q700000gn/T/clang-module-cache -fdeprecated-macro -fdebug-compilation-dir /Users/caj/temp -ferror-limit 19 -fmessage-length 138 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 1. t.cc:6:12: at annotation token 2. t.cc:6:1: parsing struct/union/class body 'X' clang: error: unable to execute command: Illegal instruction: 4 clang: error: clang frontend command failed due to signal (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/c2/j2pf8rdj4w1dr624t90z2q700000gn/T/t-cSv4Of.ii clang: note: diagnostic msg: /var/folders/c2/j2pf8rdj4w1dr624t90z2q700000gn/T/t-cSv4Of.sh ~/temp$ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 08:48:45 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 14:48:45 +0000 Subject: [LLVMbugs] [Bug 11744] New: Assertion failure with multi-dimensional arrays and templates Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11744 Bug #: 11744 Summary: Assertion failure with multi-dimensional arrays and templates Product: clang Version: 3.0 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: whitehorn at wisc.edu CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7862 --> http://llvm.org/bugs/attachment.cgi?id=7862 Test case Not really sure how to describe this one, since it seems to depend on basically everything aspect of the attached test case. Here's the output: Assertion failed: (isa(Val) && "cast() argument of incompatible type!"), function cast, file /usr/src/lib/clang/libclangsema/../../../contrib/llvm/include/llvm/Support/Casting.h, line 194. Stack dump: 0. Program arguments: /usr/bin/clang++ -cc1 -triple x86_64-unknown-freebsd10.0 -emit-obj -mrelax-all -disable-free -main-file-name reduced.ii -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -resource-dir /usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/reduced-F7zBfW.o -x c++-cpp-output reduced.ii 1. parser at end of file 2. reduced.ii:7:7: instantiating function definition 'F' clang++: error: unable to execute command: Abort trap: 6 (core dumped) clang++: error: clang frontend command failed due to signal 2 (use -v to see invocation) clang++: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang++: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 10:01:57 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 16:01:57 +0000 Subject: [LLVMbugs] [Bug 10234] clang should warn if a class and its subclass have a method with the same signature but no "virtual" in base class In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10234 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #5 from Nico Weber 2012-01-11 10:01:57 CST --- Looks like this won't fly, then. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 11:45:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 17:45:42 +0000 Subject: [LLVMbugs] [Bug 10281] Clang cannot compile on centos with gcc 4.4 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10281 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from NAKAMURA Takumi 2012-01-11 11:45:42 CST --- I suppose it had been fixed (maybe in r133156). FYI, I have been using centos5 x86-64 with gcc44-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 Wed Jan 11 12:06:15 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 18:06:15 +0000 Subject: [LLVMbugs] [Bug 11740] can't use clang -g to assemble .s file with .file directive In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11740 Kevin Enderby 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 Wed Jan 11 13:15:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 19:15:11 +0000 Subject: [LLVMbugs] [Bug 11745] New: incorrect class layout with duplicate empty base classes of small nonempty class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11745 Bug #: 11745 Summary: incorrect class layout with duplicate empty base classes of small nonempty class Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Given: template struct X : T {}; struct E {}; struct Test1 : X, X, X, X {}; struct Test2 : X, X, X, X { char c; }; sizeof(Test1) is 4, as expected, and the E base subobjects all have distinct addresses. sizeof(Test2) is 1, and the second, third and fourth E base subobjects lie outside the full-object! In particular, this static assert fails: Test2 a[2]; static_assert((E*)(X*)&a[0] != (E*)(X*)&a[1], "should not happen"); -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 13:35:43 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 19:35:43 +0000 Subject: [LLVMbugs] [Bug 10107] Address of compound literal fails in gnu++0x but not C99 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10107 Enea Zaffanella changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |zaffanella at cs.unipr.it Resolution|INVALID | --- Comment #3 from Enea Zaffanella 2012-01-11 13:35:43 CST --- As of r147790, clang still crashes on the following line of code, if -W[no-]address-of-temporary is used: $ cat bug.cc int (*pa)[1] = &(int[]) { 1 }; $ clang++ -c bug.cc bug.cc:1:16: error: taking the address of a temporary object of type 'int [1]' [-Waddress-of-temporary] int (*pa)[1] = &(int[]) { 1 }; ^~~~~~~~~~~~~~ 1 error generated. $ clang++ -Waddress-of-temporary -c bug.cc bug.cc:1:16: warning: taking the address of a temporary object of type 'int [1]' [-Waddress-of-temporary] int (*pa)[1] = &(int[]) { 1 }; ^~~~~~~~~~~~~~ clang: /tools/clang/lib/AST/ExprConstant.cpp:2479: bool EvaluateLValue(const clang::Expr*, ::LValue&, ::EvalInfo&): Assertion `(E->isGLValue() || E->getType()->isFunctionType() || E->getType()->isVoidType() || isa(E)) && "can't evaluate expression as an lvalue"' failed. [...] -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 14:39:48 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 20:39:48 +0000 Subject: [LLVMbugs] [Bug 9002] llvm configure thinks clang is dragonegg In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9002 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Eric Christopher 2012-01-11 14:39:48 CST --- I've fixed this in a different way by reworking how and in what order we configure a compiler. It would still happen if the same autoconf code was used because clang accepts unknown arguments. Calling it good 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 Jan 11 14:44:47 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 20:44:47 +0000 Subject: [LLVMbugs] [Bug 11746] New: False positive warning with 'instancetype' and deprecated method of same name in NSString Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11746 Bug #: 11746 Summary: False positive warning with 'instancetype' and deprecated method of same name in NSString Product: new-bugs Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sean at rogue-research.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7863 --> http://llvm.org/bugs/attachment.cgi?id=7863 repro case Using clang r147866 on Mac OS X 10.7, the code below causes this warning: $ /path/to/my/clang -fsyntax-only test.m test.m:18:11: warning: 'initWithContentsOfURL:' is deprecated [-Wdeprecated-declarations] return [[[self alloc] initWithContentsOfURL:inURL] autorelease]; ^ NSString has a deprecated method initWithContentsOfURL:, but in my own class it's not deprecated. I would have thought that between my own use of instancetype and clang's special casing of alloc[1] that this should not warn. [1] as described here: Here's the code (also attached): ----------- #import @interface Awesome : NSObject { } - (instancetype)initWithContentsOfURL:(NSURL*)inURL; // designated initializer + (instancetype)awsomeWithContentsOfURL:(NSURL*)inURL; @end @implementation Awesome - (instancetype)initWithContentsOfURL:(NSURL*)inURL { self = [super init]; return self; } + (instancetype)awsomeWithContentsOfURL:(NSURL*)inURL { return [[[self alloc] initWithContentsOfURL:inURL] autorelease]; } @end int main (int argc, char *argv[]) { (void)argc; (void)argv; 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 Wed Jan 11 15:26:49 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 21:26:49 +0000 Subject: [LLVMbugs] [Bug 11746] False positive warning with 'instancetype' and deprecated method of same name in NSString In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11746 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |DUPLICATE --- Comment #2 from Eli Friedman 2012-01-11 15:26:49 CST --- *** This bug has been marked as a duplicate of bug 11577 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 16:46:51 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 11 Jan 2012 22:46:51 +0000 Subject: [LLVMbugs] [Bug 11747] New: clang incorrectly rejects reinterpret_cast(0) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11747 Bug #: 11747 Summary: clang incorrectly rejects reinterpret_cast(0) Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: int x = reinterpret_cast(0); As far as I can tell, this is legal per C++11 [expr.reinterpret.cast]p2. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 20:53:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 12 Jan 2012 02:53:24 +0000 Subject: [LLVMbugs] [Bug 11748] New: Return from new not assumed to be non-null Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11748 Bug #: 11748 Summary: Return from new not assumed to be non-null Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: jmuizelaar at mozilla.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Jeff noticed this one. We compile void f(int *); void g() { int *a = new int; f(a); delete a; } to define void @_Z1gv() uwtable optsize { entry: %call = tail call noalias i8* @_Znwm(i64 4) optsize %0 = bitcast i8* %call to i32* tail call void @_Z1fPi(i32* %0) optsize %isnull = icmp eq i8* %call, null br i1 %isnull, label %delete.end, label %delete.notnull delete.notnull: tail call void @_ZdlPv(i8* %call) nounwind optsize br label %delete.end delete.end: ret void } gcc produces _Z1gv: pushq %rbx movl $4, %edi call _Znwm movq %rax, %rbx movq %rax, %rdi call _Z1fPi movq %rbx, %rdi popq %rbx jmp _ZdlPv -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 11:24:27 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 12 Jan 2012 17:24:27 +0000 Subject: [LLVMbugs] [Bug 11749] New: [AVX2] Assertion hits with i64-based shufflevector in X86ISelLowering.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11749 Bug #: 11749 Summary: [AVX2] Assertion hits with i64-based shufflevector in X86ISelLowering.cpp Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7864 --> http://llvm.org/bugs/attachment.cgi?id=7864 test case When the attached test case is compiled with llc -mattr=+avx2, the following assertion hits: Assertion failed: ((VT.is128BitVector() || VT.is256BitVector()) && "Unsupported vector type for horizontal add/sub"), function isHorizontalBinOp, file X86ISelLowering.cpp, line 14255. (This assertion doesn't hit with -mattr=+avx). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 12:10:12 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 12 Jan 2012 18:10:12 +0000 Subject: [LLVMbugs] [Bug 11750] New: [AVX2] incorrect code generated Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11750 Bug #: 11750 Summary: [AVX2] incorrect code generated Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7865 --> http://llvm.org/bugs/attachment.cgi?id=7865 test case The attached test case gives a different result when run with avx2 than with avx1. (As per the AVX2 simulator from http://software.intel.com/en-us/articles/intel-software-development-emulator/). Some initial digging and instrumentation of the original test case with print statements suggest that all is well up through the indirect function call "callq *%rax" (including the value returned from that). In the relatively small bit of code after that, something seems to get clobbered. I apologize for not having a more precise bug report with a specific pointer to incorrect instructions but at least it's only 100 lines of bitcode. Unfortunately I don't have any cycles to dig into this more deeply into next week, so figured I should file a bug with what I have. % llc -mattr=+avx2 t.ll -o t.s && clang t.cpp t.s && ~/sde/sde -- a.out result[0] = 1.000000 (expected 1.000000) result[1] = -1.000000 (expected -1.000000) result[2] = 3.000000 (expected 3.000000) result[3] = 4.000000 (expected 4.000000) result[4] = -1.000000 (expected 5.000000) result[5] = -1.000000 (expected 6.000000) result[6] = -1.000000 (expected 7.000000) result[7] = 8.000000 (expected 8.000000) err 3 % % llc -mattr=+avx t.ll -o t.s && clang t.cpp t.s && ~/sde/sde -- a.out result[0] = 1.000000 (expected 1.000000) result[1] = -1.000000 (expected -1.000000) result[2] = 3.000000 (expected 3.000000) result[3] = 4.000000 (expected 4.000000) result[4] = 5.000000 (expected 5.000000) result[5] = 6.000000 (expected 6.000000) result[6] = 7.000000 (expected 7.000000) % -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 15:06:50 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 12 Jan 2012 21:06:50 +0000 Subject: [LLVMbugs] [Bug 11672] Please provide an soname for libclang In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11672 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Rafael ?vila de Esp?ndola 2012-01-12 15:06:50 CST --- Fixed in r148045. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 15:28:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 12 Jan 2012 21:28:16 +0000 Subject: [LLVMbugs] [Bug 11672] Please provide an soname for libclang In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11672 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Rafael ?vila de Esp?ndola 2012-01-12 15:28:16 CST --- The patch had some problems and got reverted: * It was passing the -soname option on the darwin linker * Looks like we also have to add the .1 extension to the library name: ldd ./Release+Asserts/bin/c-index-test .... libclang.so.1 => not found -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 15:31:07 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 12 Jan 2012 21:31:07 +0000 Subject: [LLVMbugs] [Bug 11752] New: ifstream - reopening a file does not see the beginning. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11752 Bug #: 11752 Summary: ifstream - reopening a file does not see the beginning. Product: libc++ Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: enhancement Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: ohsumit at molbio.mgh.harvard.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7871 --> http://llvm.org/bugs/attachment.cgi?id=7871 The test program Hello. I tried this both on the latest Xcode (4.2.1) for Mac OS X, as well as what I built under Linux and similar results occurred. Specifically, please check out the included program that opens the test file test.txt that just has strings line1, line2, and line3 on 3 lines. The first time, the program opens it and prints the first two lines, everything is fine. The second time, even though I even tried seekg'ing back to the beginning (shouldn't have to), it still reads the last line first. The commands I used are attached below. Notice how it works fine when I do *not* include -stdlib=c++. Note all the below commands were done on my Mac OS X Lion. Any help would be most appreciated. Many thanks, - Toshi ------------------ commands --------------- bash-3.2$ cat test.txt line1 line2 line3 bash-3.2$ clang++ --version Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.2.0 Thread model: posix bash-3.2$ clang++ -stdlib=libc++ test.cpp bash-3.2$ ./a.out Round 1: first line = line1 second line = line2 Round 2: first line = line3 second line = line1 bash-3.2$ clang++ test.cpp bash-3.2$ ./a.out Round 1: first line = line1 second line = line2 Round 2: first line = line1 second line = line2 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 16:43:55 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 12 Jan 2012 22:43:55 +0000 Subject: [LLVMbugs] [Bug 11745] incorrect class layout with duplicate empty base classes of small nonempty class In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11745 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2012-01-12 16:43:55 CST --- r148056. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 17:36:03 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 12 Jan 2012 23:36:03 +0000 Subject: [LLVMbugs] [Bug 11753] New: Incorrect code generated for 64bit types on ARM Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11753 Bug #: 11753 Summary: Incorrect code generated for 64bit types on ARM Product: clang Version: 3.0 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mcharleb at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7873 --> http://llvm.org/bugs/attachment.cgi?id=7873 Test program to demonstrate the bug LLVM is not handling 64bit types like gcc on ARM and the behavior is seemingly incorrect. When I run the attached program (test64.c), I get the following output: $ qemu-arm ./test64-gcc src32 = 0xfeedc0de dest32 = 0xfeedc0de src64 = 0xdeadbeefabcdef0a realign: src64 = 0xdeadbeefabcdef0a dest64 = 0xdeadbeefabcdef0a $ qemu-arm ./test64-llvm src32 = 0xfeedc0de dest32 = 0xfeedc0de src64 = 0x6fd7ddeadbeef realign: src64 = 0xdeadbeefabcdef0a dest64 = 0x6fd8ddeadbeef The problem is in the way LLVM allocates registers for the src64 and dest64 parameters. It uses r1 and r2 (not paired registers) and GCC always uses r2 and r3 and prints the data correctly. The line with "realign" adds an additional parameter to the call to printf so the 64bit type is placed in r2 and r3. The LLVM generated assembly is also doing a bunch of unnecessary str instructions of the input registers used, at the end of functions. The stack is then popped and the str instructions are useless. I have annotated the the sections of problematic code generated by LLVM in the attached test64-llvm.excerpt. The code generated by gcc is provided in the test64-gcc.excerpt attachement for comparison. The makefile and clang wrapper script used to build the executables is also provided. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 17:38:10 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 12 Jan 2012 23:38:10 +0000 Subject: [LLVMbugs] [Bug 11752] ifstream - reopening a file does not see the beginning. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11752 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Howard Hinnant 2012-01-12 17:38:10 CST --- Fix Committed revision 148069. 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 Jan 12 20:40:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 02:40:24 +0000 Subject: [LLVMbugs] [Bug 11754] New: clang allows declaring constexpr instance function on type with virtual base Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11754 Bug #: 11754 Summary: clang allows declaring constexpr instance function on type with virtual base Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu, richard-llvm at metafoo.co.uk Classification: Unclassified Testcase: struct A {}; struct B : virtual A { constexpr int 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 Thu Jan 12 20:47:37 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 02:47:37 +0000 Subject: [LLVMbugs] [Bug 11755] New: clang allows declaring main constexpr Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11755 Bug #: 11755 Summary: clang allows declaring main constexpr Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: constexpr int main() { return 0; } This is illegal per [basic.start.main]p3. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 23:05:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 05:05:13 +0000 Subject: [LLVMbugs] [Bug 11749] [AVX2] Assertion hits with i64-based shufflevector in X86ISelLowering.cpp In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11749 Craig Topper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Craig Topper 2012-01-12 23:05:13 CST --- Fixed in r148096. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 23:42:05 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 05:42:05 +0000 Subject: [LLVMbugs] [Bug 11754] clang allows declaring constexpr instance function on type with virtual base In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11754 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Richard Smith 2012-01-12 23:42:05 CST --- r148094. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 02:16:07 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 08:16:07 +0000 Subject: [LLVMbugs] [Bug 11315] Bug in clang with throwing exceptions with noreturn functions? In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11315 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |wendling at apple.com Resolution| |WORKSFORME --- Comment #3 from Bill Wendling 2012-01-13 02:16:07 CST --- I can't reproduce this with ToT clang on Darwin. Also, the C back-end is not really the best way to look at the code-gen. :-) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 03:55:40 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 09:55:40 +0000 Subject: [LLVMbugs] [Bug 11756] New: Greedy Register Allocator crashes on compiling db5 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11756 Bug #: 11756 Summary: Greedy Register Allocator crashes on compiling db5 Product: clang Version: 3.0 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: c.kworr at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When compiling Oracle (Berkeley) db5.2 clang crashes with: ./libtool --mode=compile clang -c -I. -I./../src -D_THREAD_SAFE -O2 -pipe -fno-strict-aliasing ../src/db/partition.c libtool: compile: clang -c -I. -I./../src -D_THREAD_SAFE -O2 -pipe -fno-strict-aliasing ../src/db/partition.c -fPIC -DPIC -o .libs/partition.o Assertion failed: (MI && "Missing def"), function traceSiblingValue, file /usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/InlineSpiller.cpp, line 575. Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple i386-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name partition.c -pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -target-cpu i486 -momit-leaf-frame-pointer -coverage-file .libs/partition.o -resource-dir /usr/bin/../lib/clang/3.0 -D _THREAD_SAFE -D PIC -I . -I ./../src -fmodule-cache-path /tmp/clang-module-cache -O2 -ferror-limit 19 -fmessage-length 128 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o .libs/partition.o -x c ../src/db/partition.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '../src/db/partition.c'. 4. Running pass 'Greedy Register Allocator' on function '@__partc_get' clang: error: unable to execute command: Abort trap: 6 (core dumped) clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Preprocessed source(s) are located at: clang: note: diagnostic msg: /tmp/partition-cRq8Ry.i gmake: *** [partition.lo] ??????? 1 # clang -v FreeBSD clang version 3.0 (branches/release_30 142614) 20111021 Target: i386-unknown-freebsd9.0 Thread model: posix http://limbo.xim.bz/partition-cRq8Ry.i -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 06:03:35 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 12:03:35 +0000 Subject: [LLVMbugs] [Bug 11757] New: Missed copy elision when using operator new Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11757 Bug #: 11757 Summary: Missed copy elision when using operator new Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: Mozza314 at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified It seems clang misses the copy elision when an rvalue of some class is used for copy construction through operator new. This is demonstrated by the assertion failure of the following code: #include #include class CopyCounter { private: static int mCount; public: CopyCounter() { } CopyCounter(const CopyCounter&) { ++mCount; } static int Get() { return mCount; } }; int CopyCounter::mCount = 0; int main() { CopyCounter* f = new CopyCounter(CopyCounter()); assert(CopyCounter::Get() == 0); delete f; return 0; } I have tested this on 2.9 but I expect trunk is also affected because of a similar problem reported to me by someone using a relatively recent checkout of trunk. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 07:15:48 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 13:15:48 +0000 Subject: [LLVMbugs] [Bug 11301] Firefox build fails with -O4 during linking of libxul on Linux In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11301 Markus Trippelsdorf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Markus Trippelsdorf 2012-01-13 07:15:48 CST --- (In reply to comment #1) > Could you attach an example that reproduces this error? The link error is gone now! Just built Firefox successfully with -O4. % clang -v clang version 3.1 (trunk 148024) Target: x86_64-unknown-linux-gnu Thread model: posix about:buildconfig Source Built from http://hg.mozilla.org/mozilla-central/rev/9b5f1ccdb021 Build platform target x86_64-unknown-linux-gnu Build tools Compiler Version Compiler flags clang -pedantic -Wall -W -Wno-unused -Wpointer-arith -Wdeclaration-after-statement -W -Wno-long-long -march=native -fno-strict-aliasing -pthread -ffunction-sections -pipe -DNDEBUG -DTRIMMED -O4 -fomit-frame-pointer clang++ -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -march=native -Wno-delete-non-virtual-dtor -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -ffunction-sections -pipe -DNDEBUG -DTRIMMED -O4 -fomit-frame-pointer Configure arguments --enable-application=browser --prefix=/usr --libdir=/usr/lib --with-system-jpeg --with-pthreads --with-system-zlib --with-system-bz2 --with-system-hunspell --with-system-sqlite --with-system-libevent --with-system-lcms --disable-installer --disable-updater --enable-official-branding --enable-startup-notification --disable-necko-wifi --disable-accessibility --disable-elf-hack --enable-jemalloc --enable-optimize=-O4 --disable-debug --disable-tests --disable-debug-symbols --enable-strip --enable-install-strip --enable-default-toolkit=cairo-gtk2 -enable-system-cairo --disable-crashreporter --disable-parental-controls --disable-safe-browsing --enable-profile-guided-optimization -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 08:03:39 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 14:03:39 +0000 Subject: [LLVMbugs] [Bug 11758] New: declarations made visible by using-directive are hidden by namespace members during unqualified name lookup Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11758 Bug #: 11758 Summary: declarations made visible by using-directive are hidden by namespace members during unqualified name lookup Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: zilla at kayari.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified namespace N { void f(); void g(); void h(); namespace { void f(int) { } } namespace unique { } using namespace unique; namespace unique { void g(int) { } } } void N::h() { f(1); g(1); } c.cc:16:3: error: no matching function for call to 'f' f(1); ^ c.cc:3:8: note: candidate function not viable: requires 0 arguments, but 1 was provided void f(); ^ c.cc:17:3: error: no matching function for call to 'g' g(1); ^ c.cc:4:8: note: candidate function not viable: requires 0 arguments, but 1 was provided void g(); ^ 2 errors generated. The using-directive should mean unique::g is considered a member of N for the purposes of unqualified name lookup, [basic.lookup.unqual]/2. The unnamed namespace should behave the same, [namespace.unnamed]/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 Jan 13 08:11:03 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 14:11:03 +0000 Subject: [LLVMbugs] [Bug 11759] New: bogus ambiguity error for extern "C" function redeclared in different namespaces Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11759 Bug #: 11759 Summary: bogus ambiguity error for extern "C" function redeclared in different namespaces Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: zilla at kayari.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified [dcl.link]/6 says At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Clang++ disagrees, so the example from [namespace.udir]/6 fails namespace A { class X { }; extern "C" int g(); extern "C++" int h(); } namespace B { void X(int); extern "C" int g(); extern "C++" int h(int); } using namespace A; using namespace B; void f() { // X(1); // error: name X found in two namespaces g(); // okay: name g refers to the same entity h(); // okay: overload resolution selects A::h } d.cc:15:3: error: call to 'g' is ambiguous g(); // okay: name g refers to the same entity ^ d.cc:3:18: note: candidate function extern "C" int g(); ^ d.cc:8:18: note: candidate function extern "C" int g(); ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 09:53:31 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 15:53:31 +0000 Subject: [LLVMbugs] [Bug 11759] bogus ambiguity error for extern "C" function redeclared in different namespaces In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11759 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Douglas Gregor 2012-01-13 09:53:31 CST --- Yeah, this is a longstanding bug. *** This bug has been marked as a duplicate of bug 7927 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 12:09:52 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 18:09:52 +0000 Subject: [LLVMbugs] [Bug 11760] New: llvm-cov crashes in llvm::GCOVFunction::read with trivial test case Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11760 Bug #: 11760 Summary: llvm-cov crashes in llvm::GCOVFunction::read with trivial test case Product: new-bugs Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sean at rogue-research.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7878 --> http://llvm.org/bugs/attachment.cgi?id=7878 repro case Using "clang version 3.1 (trunk 147866)", llvm-cov crashes with simple test case: To repro: - uncompress attached file - cd llvm-cov.crash - edit the first line of the Makefile to provide the path to your llvm install directory - make - make docov - make crash The llvm-gov process then reproducibly crashes as follows: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 llvm-cov 0x000000010311ee9f llvm::GCOVFunction::read(llvm::GCOVBuffer&, llvm::GCOVFormat) + 631 1 llvm-cov 0x000000010311f386 llvm::GCOVFile::read(llvm::GCOVBuffer&) + 246 2 llvm-cov 0x000000010311d154 main + 1188 3 llvm-cov 0x000000010311cca4 start + 52 This is on Mac OS X 10.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 Fri Jan 13 15:02:21 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 21:02:21 +0000 Subject: [LLVMbugs] [Bug 11761] New: Bad IR generated for amd64 (Instruction does not dominate all uses!) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11761 Bug #: 11761 Summary: Bad IR generated for amd64 (Instruction does not dominate all uses!) Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7879 --> http://llvm.org/bugs/attachment.cgi?id=7879 Test case Compile attached test input with clang -O for amd64 (Linux and NetBSD tested). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 15:53:47 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 21:53:47 +0000 Subject: [LLVMbugs] [Bug 11760] llvm-cov crashes in llvm::GCOVFunction::read with trivial test case In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11760 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Devang Patel 2012-01-13 15:53:47 CST --- It works for me. I have r148125. Can you try again ? It produces following output. coverage.cpp : #include : : using namespace std; : : void A() : { : cout << "A" << endl; : : return; : } : : void B() : { 1: cout << "B" << endl; : 1: return; : } : : void C() : { : cout << "C" << endl; : : return; : } : : : : int main(int argc, const char* argv[]) { : cout << "argc=" << argc << endl; : if (argc < 2) { 1: A(); 1: C(); 1: } else { : B(); : } 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 Jan 13 16:54:34 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 13 Jan 2012 22:54:34 +0000 Subject: [LLVMbugs] [Bug 11762] New: Missing support for .cfi_signal_frame Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11762 Bug #: 11762 Summary: Missing support for .cfi_signal_frame Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, matthewbg at google.com Classification: Unclassified Matt tells me we are missing support for .cfi_signal_frame and that it is used by the gdb testsuite. We should probably implement 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 Fri Jan 13 18:40:02 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 14 Jan 2012 00:40:02 +0000 Subject: [LLVMbugs] [Bug 10113] Explicit template instantiation with default visibility fails to generate global symbols for certain types In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10113 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #26 from Rafael ?vila de Esp?ndola 2012-01-13 18:40:02 CST --- Fixed in r148163. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 18:40:06 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 14 Jan 2012 00:40:06 +0000 Subject: [LLVMbugs] [Bug 11690] Support building chromium in shared_library mode In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11690 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #8 from Rafael ?vila de Esp?ndola 2012-01-13 18:40:06 CST --- Fixed in r148163. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 19:23:49 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 14 Jan 2012 01:23:49 +0000 Subject: [LLVMbugs] [Bug 11763] New: memcpy call with overlapping (same) regions is created by LLVM Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11763 Bug #: 11763 Summary: memcpy call with overlapping (same) regions is created by LLVM Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: kcc at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified According to the C/C++ standard, the arguments of memcpy can not overlap. But LLVM generates code like memcpy(x, x, size_of_x); Reproducer: % cat memcpy_bug.cc struct LargeStruct { int foo[100]; }; void copy(LargeStruct *a, LargeStruct *b) { *a = *b; } % clang++ -O2 memcpy_bug.cc -S && cat memcpy_bug.s | grep call callq memcpy % g++ -O2 memcpy_bug.cc -S && cat memcpy_bug.s | grep call % (BTW, I remember reporting similar bugs to gcc and they were 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 Jan 13 19:47:28 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 14 Jan 2012 01:47:28 +0000 Subject: [LLVMbugs] [Bug 11763] memcpy call with overlapping (same) regions is created by LLVM In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11763 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |WONTFIX --- Comment #1 from Eli Friedman 2012-01-13 19:47:28 CST --- This was done intentionally in r65699; in practice, memcpy implementations handle exact overlap correctly, and other implementations of struct assignment cause issues. (We're allowed to generate "illegal" calls to memcpy because LLVM is generating platform-specific assembly, not C 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 Jan 13 21:19:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 14 Jan 2012 03:19:46 +0000 Subject: [LLVMbugs] [Bug 11761] Bad IR generated for amd64 (Instruction does not dominate all uses!) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11761 Andrew Trick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Andrew Trick 2012-01-13 21:19:46 CST --- Fixed in r148177. Another insertion point bug. Phis popped up where they weren't 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 Sat Jan 14 04:12:19 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 14 Jan 2012 10:12:19 +0000 Subject: [LLVMbugs] [Bug 10178] multiple typeinfo name In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10178 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #15 from Benjamin Kramer 2012-01-14 04:12:19 CST --- NOTOURBUG -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 14 08:21:47 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 14 Jan 2012 14:21:47 +0000 Subject: [LLVMbugs] [Bug 11764] New: decltype(MyClass()) doesn't work as a trailing return type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11764 Bug #: 11764 Summary: decltype(MyClass()) doesn't work as a trailing return type Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jyasskin at google.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Given the following program: #include #include #include template struct array_ref { array_ref(const std::vector& v) {} }; template auto make_array_ref(const T& t) -> decltype(array_ref(t)) { return array_ref(t); } template void WriteType(T t) { std::cout << typeid(decltype(array_ref(t))).name() << '\n'; } int main() { std::vector v; WriteType(v); make_array_ref(v); } ----------- clang++ -std=c++11 gives the following error: test.cc:12:12: error: no viable conversion from 'array_ref' to 'decltype(array_ref(t))' return array_ref(t); ^~~~~~~~~~~~~~~~~ 1 error generated. The lack of 'aka' is bug 10405, but I believe the code should compile as-is. It does with gcc-4.6, and the decltype() expression is exactly the same as the returned expression. Further, when I comment out make_array_ref(), clang and gcc print "9array_refIiE" (array_ref), which is the type of the return value. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 14 09:09:53 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 14 Jan 2012 15:09:53 +0000 Subject: [LLVMbugs] [Bug 11765] New: Assertion in register scavenger Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11765 Bug #: 11765 Summary: Assertion in register scavenger Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7880 --> http://llvm.org/bugs/attachment.cgi?id=7880 Testcase Consider the attached .ll file Running llc -mcpu=cortex-a9 -join-liveintervals=0 yields the assertion in the register scavenger. -join-liveintervals=1 inhibits 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 Sat Jan 14 12:12:58 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 14 Jan 2012 18:12:58 +0000 Subject: [LLVMbugs] [Bug 11766] New: clang c++ ambigious conversion by constructor and operator Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11766 Bug #: 11766 Summary: clang c++ ambigious conversion by constructor and operator Product: clang Version: 2.8 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: robercik_st at interia.pl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Code below doesn't issue a warning about ambigious conversion of Orange to Apple. class Orange; class Apple { public: Apple(){} Apple(const Orange &){} }; class Orange { public: operator Apple() { return Apple(); } }; void z(Apple){} int main( int argc,char **argv ) { Orange a; z(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 Sun Jan 15 00:31:06 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 15 Jan 2012 06:31:06 +0000 Subject: [LLVMbugs] [Bug 11764] decltype(MyClass()) doesn't work as a trailing return type In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11764 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution| |FIXED --- Comment #1 from Richard Smith 2012-01-15 00:31:06 CST --- Fixed in r148210. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 15 09:03:37 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 15 Jan 2012 15:03:37 +0000 Subject: [LLVMbugs] [Bug 11767] New: TableGen allows (illegal) anonymous 'defm's inside of multiclasses Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11767 Bug #: 11767 Summary: TableGen allows (illegal) anonymous 'defm's inside of multiclasses Product: new-bugs Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: stephen.mcgruer+bugzilla at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Currently in LLVM it is legal to define two multiclasses (and an example instruction) like so: multiclass A { def rr : Pseudo<(outs Reg:$dst), (ins Reg:$src1, Reg:$src2), !strconcat(OpString, " $dst,$src1,$src2", [(set Reg:$dst, (OpNode Reg:$src1, $src2))]>; } multiclass B { // A Bad-Thing to do, but *legal*! defm : A; } def ADD : B<"add", add>; This passes llvm-tblegen (or whatever make runs on .td files), and generates an include file XXXInstrInfo.inc with the contents: namespace XXX { enum { ... ADDanonymous.0 = 18, ... } } This is obviously non-legal C++ code, so if it is later included anywhere, a compile error is thrown: "error: expected ?}? before numeric constant" While this is not a serious issue, as it will fail at compile time as soon as the instruction tablegen file is used, it would be nice in my opinion if tablegen was able to disallow anonymous "defm"s (and likely "def"s too, but I have not tested that case) inside of multiclasses. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 15 11:22:19 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 15 Jan 2012 17:22:19 +0000 Subject: [LLVMbugs] [Bug 9029] No typo correction after new In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9029 Anton changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |anton.yartsev at Gmail.com 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 Mon Jan 16 07:49:18 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 16 Jan 2012 13:49:18 +0000 Subject: [LLVMbugs] [Bug 11768] New: __sync_synchronize non-sse lowering doesn't clobber flags Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11768 Bug #: 11768 Summary: __sync_synchronize non-sse lowering doesn't clobber flags 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: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified While building icu with clang trunk r148116 on FreeBSD/i386, I ran into several crashes when the build-time tool 'genrb' was run. This was caused by multiple problems in code generation. After some reducing, one of them turned out to be with __sync_synchronize(). Take the following sample, much reduced from the icu testcase: extern void *ptr; void foo(); void bar(); void baz(void) { int flag = (ptr == (void*)0); __sync_synchronize(); if (flag) foo(); else bar(); } This is compiled with clang -O2 -S, giving (on i386): baz: # @baz # BB#0: # %entry xorl %eax, %eax cmpl $0, ptr lock orl %eax, (%esp) jne .LBB0_2 # BB#1: # %if.then jmp foo # TAILCALL .LBB0_2: # %if.else jmp bar # TAILCALL So 'jne' is done, incorrectly assuming 'lock orl' didn't clobber the flags. Compare this to the amd64 version: baz: # @baz .cfi_startproc # BB#0: # %entry movq ptr(%rip), %rax mfence testq %rax, %rax jne .LBB0_2 # BB#1: # %if.then xorb %al, %al jmp foo # TAILCALL .LBB0_2: # %if.else xorb %al, %al jmp bar # TAILCALL Here, 'testq' is executed *after* 'mfence', as it should. Another comparison is with gcc 4.6 on i386: baz: .LFB0: .cfi_startproc movl ptr, %eax lock orl $0, (%esp) testl %eax, %eax je .L4 jmp bar .p2align 4,,7 .L4: jmp foo .cfi_endproc Here, it also compares after 'lock orl'. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 07:50:51 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 16 Jan 2012 13:50:51 +0000 Subject: [LLVMbugs] [Bug 11464] LinkModules fails to remap types In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11464 Heikki Kultala changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |hkultala at cs.tut.fi 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 Mon Jan 16 10:11:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 16 Jan 2012 16:11:46 +0000 Subject: [LLVMbugs] [Bug 11769] New: AVX codegen crash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11769 Bug #: 11769 Summary: AVX codegen crash Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7884 --> http://llvm.org/bugs/attachment.cgi?id=7884 Reproducer The attached test crashes when compiled with -matter=+avx. The problem is that LowerVECTOR_SHUFFLE decides to give up on the lowering on a certain vectorshuffle instruction because it believes that the DAGCombiner would catch this pattern. I think that the pattern is (extract(shufflevector(load))). When the dagcombiner fails to remove this pattern, we fail with 'unable to select pattern'. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 10:21:08 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 16 Jan 2012 16:21:08 +0000 Subject: [LLVMbugs] [Bug 11770] New: missing sret in some cases Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11770 Bug #: 11770 Summary: missing sret in some cases Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Compiling typedef struct { long long int quot; long long int rem; } lldiv_t; #ifdef foo lldiv_t lldiv(long long int num) __attribute__ ((weak, alias ("_lldiv"))); #endif lldiv_t _lldiv(long long num) { } without -Dfoo produces define void @_lldiv(%struct.lldiv_t* noalias nocapture sret %agg.result,.... and with -Dfoo: define void @_lldiv(%struct.lldiv_t* noalias nocapture %agg.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 Mon Jan 16 10:42:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 16 Jan 2012 16:42:42 +0000 Subject: [LLVMbugs] [Bug 11768] __sync_synchronize non-sse lowering doesn't clobber flags In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11768 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2012-01-16 10:42:42 CST --- r148240; very nice bug 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 Jan 16 11:59:47 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 16 Jan 2012 17:59:47 +0000 Subject: [LLVMbugs] [Bug 11464] LinkModules fails to remap types In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11464 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #8 from Chris Lattner 2012-01-16 11:59:47 CST --- Please open new bugs for new problems. Just because this looks related, doesn't mean its the same 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 Mon Jan 16 12:05:44 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 16 Jan 2012 18:05:44 +0000 Subject: [LLVMbugs] [Bug 11771] New: Vectors shift operator broken Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11771 Bug #: 11771 Summary: Vectors shift operator broken Product: new-bugs Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: schnetter at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The shift operator >> on int2 seems broken. The example code below extracts the sign bit of a float2, but does not work correctly: typedef int int2 __attribute__((__ext_vector_type__(2))); typedef float float2 __attribute__((__ext_vector_type__(2))); int2 signbit(float2 f) { int bits = 8 * sizeof(float); return *(int2*)&f >> (int2)(bits-1); } #include int main() { float2 x = (float2){-1.0f,-1.0f}; int2 s = signbit(x); printf("%d %d\n", s.s0, s.s1); return 0; } I expect the output "-1 -1", but receive the output "-1 0" instead. This used to work correctly with earlier versions of llvm 3.1svn. I also notice that the assembler code generated for "signbit" is much more complicated than necessary. I expect a single machine instruction, but more than 20 instructions are generated that unpack and re-pack the vector. I am using llvm and clang 148237. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 12:09:54 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 16 Jan 2012 18:09:54 +0000 Subject: [LLVMbugs] [Bug 11655] clang alignment mismatch with gcc for ppc architecture In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11655 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #3 from Eli Friedman 2012-01-16 12:09:54 CST --- If it works for you, it's likely fixed; I didn't notice this was reported against clang 2.9. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 12:22:31 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 16 Jan 2012 18:22:31 +0000 Subject: [LLVMbugs] [Bug 11772] New: [AVX2] x86 isel crash with 16-wide vector and shl Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11772 Bug #: 11772 Summary: [AVX2] x86 isel crash with 16-wide vector and shl 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: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7885 --> http://llvm.org/bugs/attachment.cgi?id=7885 test case With top of tree and the attached test case, if I run: % llc -mattr=+avx2 bugpoint-reduced-simplified.ll I get this crash: Stack dump: 0. Program arguments: llc -mattr=+avx2 bugpoint-reduced-simplified.ll 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@f_fu' [1] 24920 segmentation fault llc -mattr=+avx2 bugpoint-reduced-simplified.ll This compiles correctly with AVX1. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 18:36:10 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 00:36:10 +0000 Subject: [LLVMbugs] [Bug 11775] New: [AVX] opportunity for better code by transforming vec w/one element used to scalar Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11775 Bug #: 11775 Summary: [AVX] opportunity for better code by transforming vec w/one element used to scalar Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7887 --> http://llvm.org/bugs/attachment.cgi?id=7887 examples The attached test case has two versions of a loop over float values in memory, where each time through the loop an 8-wide vector of floats is loaded and added to an accumulated <8 x float> sum, which the function returns. In the first version, foo(), the %iter_val42342 value is a vector that has value <0,1,2,3,4,5,6,7> the first time through the loop, <8,9,10,...> the second time through, and so forth. As it turns out, this value is only used in an extractelement instruction, the result of which is used to index into the array of floats. Here is the generated code for the loop body (with top of tree, llc -mattr=+avx): LBB0_1: ## %foreach_full_body ## =>This Inner Loop Header: Depth=1 addl $8, %ecx vmovd %ecx, %xmm3 vinsertf128 $1, %xmm3, %ymm3, %ymm3 vpermilps $0, %ymm3, %ymm3 ## ymm3 = ymm3[0,0,0,0,4,4,4,4] vmovd %xmm2, %edx shll $2, %edx movslq %edx, %rdx vmovups (%rdi,%rdx), %ymm2 vaddps %ymm2, %ymm0, %ymm0 vextractf128 $1, %ymm3, %xmm2 vextractf128 $1, %ymm1, %xmm4 vpaddd %xmm4, %xmm2, %xmm2 vpaddd %xmm1, %xmm3, %xmm3 cmpl %eax, %ecx vinsertf128 $1, %xmm2, %ymm3, %ymm2 jl LBB0_1 The code is going through all of the work to maintain all of the vector values, even though only one is needed (doubly-painful with AVX and only 4-wide integer instructions.) This is also inhibiting other optimizations. In the bar() function in the attached, I've manually transformed this vector into a scalar value. The resulting code is much nicer. LBB1_1: ## %foreach_full_body ## =>This Inner Loop Header: Depth=1 movslq %ecx, %rcx vmovups (%rdi,%rcx), %ymm1 vaddps %ymm1, %ymm0, %ymm0 addl $32, %ecx addl $8, %edx cmpl %eax, %edx jl LBB1_1 This suggests that it might be worthwhile to look for computations on vectors where only one of the elements is used, and to lower these down to the corresponding scalar computation if possible. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 19:04:50 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 01:04:50 +0000 Subject: [LLVMbugs] [Bug 6484] Improve diagnostic when there is an extraneous '}' In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=6484 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nicolasweber at gmx.de Resolution| |FIXED --- Comment #1 from Nico Weber 2012-01-16 19:04:50 CST --- r148270 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 20:44:35 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 02:44:35 +0000 Subject: [LLVMbugs] [Bug 11777] New: ppc "Ptr must be a pointer to Val type!" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11777 Bug #: 11777 Summary: ppc "Ptr must be a pointer to Val type!" Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: anall at andreanall.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7888 --> http://llvm.org/bugs/attachment.cgi?id=7888 Reduced test $ clang++ -arch ppc -c ~/x.cc -emit-llvm Assertion failed: (getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"), function AssertOK, file /Users/anall/llvm/llvm/lib/VMCore/Instructions.cpp, line 1086. 0 clang 0x000000010141a032 llvm::SmallVectorImpl::resize(unsigned int) + 4146 1 clang 0x000000010141a549 llvm::SmallVectorImpl::resize(unsigned int) + 5449 2 libSystem.B.dylib 0x00007fff854d066a _sigtramp + 26 3 libSystem.B.dylib 0x0000000000000050 _sigtramp + 2058549760 4 clang 0x000000010141a276 llvm::SmallVectorImpl::resize(unsigned int) + 4726 5 clang 0x000000010141a235 llvm::SmallVectorImpl::resize(unsigned int) + 4661 6 clang 0x000000010139e736 std::_Rb_tree, std::pair const, llvm::InlineAsm*>, std::_Select1st const, llvm::InlineAsm*> >, std::less >, std::allocator const, llvm::InlineAsm*> > >::_M_insert_unique(std::pair const, llvm::InlineAsm*> const&) + 25718 7 clang 0x0000000101104104 std::back_insert_iterator > > std::__copy_aux, false, llvm::GraphTraits >, std::back_insert_iterator > > >(llvm::po_iterator, false, llvm::GraphTraits >, llvm::po_iterator, false, llvm::GraphTraits >, std::back_insert_iterator > >) + 142532 8 clang 0x00000001001b64db std::vector, std::allocator > >::_M_insert_aux(__gnu_cxx::__normal_iterator*, std::vector, std::allocator > > >, std::pair const&) + 57131 9 clang 0x00000001001b65b9 std::vector, std::allocator > >::_M_insert_aux(__gnu_cxx::__normal_iterator*, std::vector, std::allocator > > >, std::pair const&) + 57353 10 clang 0x00000001001a53f0 std::vector, std::allocator > >::_M_insert_aux(__gnu_cxx::__normal_iterator*, std::vector, std::allocator > > >, llvm::TrackingVH const&) + 19408 11 clang 0x000000010017f96c std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, clang::serialization::ModuleFile* const&) + 150652 12 clang 0x0000000100235280 std::vector, std::allocator > >::operator=(std::vector, std::allocator > > const&) + 6208 13 clang 0x0000000100235ab5 std::vector, std::allocator > >::operator=(std::vector, std::allocator > > const&) + 8309 14 clang 0x000000010023dd2a std::vector, std::allocator > >::operator=(std::vector, std::allocator > > const&) + 41706 15 clang 0x000000010023b496 std::vector, std::allocator > >::operator=(std::vector, std::allocator > > const&) + 31318 16 clang 0x000000010023caab std::vector, std::allocator > >::operator=(std::vector, std::allocator > > const&) + 36971 17 clang 0x0000000100241267 std::vector, std::allocator > >::operator=(std::vector, std::allocator > > const&) + 55335 18 clang 0x000000010025aeaf clang::CanQual::CreateUnsafe(clang::QualType) + 22943 19 clang 0x000000010023353a llvm::ParseIR(llvm::MemoryBuffer*, llvm::SMDiagnostic&, llvm::LLVMContext&) + 1226 20 clang 0x0000000100266131 clang::CanQual::CreateUnsafe(clang::QualType) + 68641 21 clang 0x0000000100232904 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, clang::CXXRecordDecl const* const&) + 6148 22 clang 0x0000000100023502 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, clang::CompilerInstance* const&) + 14610 23 clang 0x000000010000b145 std::_Rb_tree, std::less, std::allocator >::_M_insert_unique(std::string const&) + 3461 24 clang 0x0000000100002be5 25 clang 0x00000001000075ef std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, std::string const&) + 1455 26 clang 0x0000000100001734 27 clang 0x0000000000000027 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 21:38:58 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 03:38:58 +0000 Subject: [LLVMbugs] [Bug 11778] New: incorrectly narrowing switch cases before checking for duplicates Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11778 Bug #: 11778 Summary: incorrectly narrowing switch cases before checking for duplicates Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified :1:34: warning: overflow converting case value to switch condition type (256 to 0) [-Wswitch] int f(char c) { switch(c) { case 256: case 0: return 1; } return 0; } ^ :1:44: error: duplicate case value '0' int f(char c) { switch(c) { case 256: case 0: return 1; } return 0; } ^ :1:34: note: previous case defined here int f(char c) { switch(c) { case 256: case 0: return 1; } return 0; } ^ This is incorrect: the promoted type of the switch condition is 'int', and there are no duplicate case values in this switch statement. The warning is also incorrect, but it seems wise to produce some kind of warning for this case: 'condition value can never equal case value' or similar. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 21:55:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 03:55:24 +0000 Subject: [LLVMbugs] [Bug 11779] New: 'ret' instruction unwanted interaction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11779 Bug #: 11779 Summary: 'ret' instruction unwanted interaction Product: libraries Version: 3.0 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: mooneer at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I am in the process of porting the Kite programming language to LLVM. While implementing the "return" statement, I encountered a very unusual problem. Example Kite code: method x() [ return 1; ]; x()|print; Generated LLVM intermediate code: ; ModuleID = '__root_module' @0 = internal unnamed_addr constant [5 x i8] c"x__o\00" @1 = internal unnamed_addr constant [6 x i8] c"print\00" define i32* @__static_init____o(i32* %this) { entry: %0 = alloca i32* store i32* %this, i32** %0 %1 = call i32* @kite_method_alloc(i32* bitcast (i32* (i32*)* @x__o to i32*), i32 1) %2 = load i32** %0 %3 = call i32** @kite_dynamic_object_get_property(i32* %2, i8* getelementptr inbounds ([5 x i8]* @0, i32 0, i32 0), i1 true) store i32* %1, i32** %3 %4 = load i32** %0 %5 = call i32* @x__o(i32* %4) %6 = call i32* @kite_find_funccall(i32* %5, i8* getelementptr inbounds ([6 x i8]* @1, i32 0, i32 0), i32 1) %7 = bitcast i32* %6 to i32* (i32*)* %8 = call i32* %7(i32* %5) ret i32* %8 } define i32* @x__o(i32* %this) { entry: %0 = alloca i32* store i32* %this, i32** %0 %1 = call i32* @System__integer__obj__i(i32 1) ret i32* %1 ret i32* %1 } declare i32* @System__integer__obj__i(i32) declare i32* @kite_method_alloc(i32*, i32) declare i32** @kite_dynamic_object_get_property(i32*, i8*, i1) declare i32* @kite_find_funccall(i32*, i8*, i32) Execution result: System.exceptions.NotImplemented: Could not find method print that takes 0 argument(s). in (main program) + 0x7a GDB shows that System__integer__obj__i is returning the correct result, but kite_find_funccall receives a different first parameter than that which obj__i returns. I've worked around the issue for the time being and suppressed the generation of one of the ret instructions, but logic dictates that anything below the first 'ret' statement is effectively not there at all. TO DUPLICATE: 1. Clone the Git repository: https://github.com/tmiw/kite-llvm. 2. Comment out lines 1312-1313 and 1325 in src/codegen/llvm_node_codegen.cpp. 3. vim Makefile 4. make 5. ./kite example_code.kt (where example_code.kt is the example Kite code above). ./kite -xd will display the LLVM intermediate code without executing it. Let me know if you need anything else. 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 Jan 16 22:25:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 04:25:42 +0000 Subject: [LLVMbugs] [Bug 11779] 'ret' instruction unwanted interaction In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11779 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |clattner at apple.com Resolution| |INVALID --- Comment #2 from Chris Lattner 2012-01-16 22:25:42 CST --- It's not clear what you're complaining about here. LLVM IR is well specified and defined that way for a reason. If you'd like to propose an IR change, it is best to email llvmdev instead of file bugs. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 22:32:34 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 04:32:34 +0000 Subject: [LLVMbugs] [Bug 11780] New: using assert in generated files embeds the build dir in the output Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11780 Bug #: 11780 Summary: using assert in generated files embeds the build dir in the output Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified while debugging a bootstrap failure I noticed that the the build dir name was included in some object files. The problem is that an gets expanded to ((!isalignmentExpr) ? static_cast (0) : __assert_fail ("!isalignmentExpr", "/home/espindola/llvm/build/tools/clang/lib/AST/../../include/clang/AST/Attrs.inc", 161, __PRETTY_FUNCTION__)); I am not sure what is the best way to fix this. Maybe we just need another macro, maybe the code with the assert should be factored to a .cpp file. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 22:46:33 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 04:46:33 +0000 Subject: [LLVMbugs] [Bug 11772] [AVX2] x86 isel crash with 16-wide vector and shl In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11772 Craig Topper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Craig Topper 2012-01-16 22:46:33 CST --- Fixed in r148285. Though it could probably use a better fix in DAG combine or getNode. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 01:24:09 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 07:24:09 +0000 Subject: [LLVMbugs] [Bug 11781] New: clang segmentation fault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11781 Bug #: 11781 Summary: clang segmentation fault Product: clang Version: 3.0 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: genyo at tbricks.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified 0 clang 0x0000000106712312 _ZL15PrintStackTracePv + 34 1 clang 0x00000001067127e9 _ZL13SignalHandleri + 633 2 libsystem_c.dylib 0x00007fff9064acfa _sigtramp + 26 3 libsystem_c.dylib 0x0000000000000003 _sigtramp + 18446603338093646627 4 clang 0x0000000105ae5a30 llvm::MCAssembler::isSymbolLinkerVisible(llvm::MCSymbol const&) const + 48 5 clang 0x0000000105af417d (anonymous namespace)::MCMachOStreamer::Finish() + 269 6 clang 0x0000000105aee7f7 llvm::AsmPrinter::doFinalization(llvm::Module&) + 1527 7 clang 0x0000000105a683d7 llvm::FPPassManager::runOnModule(llvm::Module&) + 199 8 clang 0x0000000105a63fd4 llvm::MPPassManager::runOnModule(llvm::Module&) + 276 9 clang 0x0000000105a63b58 llvm::PassManagerImpl::run(llvm::Module&) + 280 10 clang 0x0000000105a63a3d llvm::PassManager::run(llvm::Module&) + 13 11 clang 0x0000000105f3293d clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 4381 12 clang 0x0000000105a4b3f6 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 246 13 clang 0x0000000105973276 clang::ParseAST(clang::Sema&, bool) + 422 14 clang 0x0000000105971caf clang::CodeGenAction::ExecuteAction() + 671 15 clang 0x000000010595da9b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 875 16 clang 0x000000010595bb18 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2696 17 clang 0x0000000105950315 cc1_main(char const**, char const**, char const*, void*) + 5333 18 clang 0x000000010593347b main + 667 19 clang 0x00000001059331d4 start + 52 20 clang 0x00000000000000ae start + 18446744069321051918 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-apple-macosx10.7.2 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name FixApplication.cpp -pic-level 1 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 127.2 -g -coverage-file ../../../../build.i386-apple-darwin/platform/obj64/src/servers/market_data/fix/market_data_fix/src/FixApplication.o.tmp -resource-dir /usr/bin/../lib/clang/3.0 -dependency-file ../../../../build.i386-apple-darwin/platform/obj64/src/servers/market_data/fix/market_data_fix/src/FixApplication.o.srcdep -MP -MT ../../../../build.i386-apple-darwin/platform/obj64/src/servers/market_data/fix/market_data_fix/src/FixApplication.o -D DARWIN -D DARWIN64 -D __DARWIN__ -D _XOPEN_SOURCE -D DTRACE_ENABLED=1 -D _POSIX_PTHREAD_SEMANTICS -D _REENTRANT -D _GNU_SOURCE -I ./src -I ./../../../../src/libraries/calendar/headers -I ./../../../../src/libraries/cpphelper/headers -I ./../../../../build.i386-apple-darwin/include64/ace-5.7 -I ./../../../../src/share/compat/headers -I ./../../../../build.i386-apple-darwin/include64/boost-1_40 -I ./../../../../src/libraries/log/headers -I ./../../../../src/libraries/filter/headers -I ./../../../../src/libraries/util/headers -I ./../../../../build.i386-apple-darwin/include64/libarchive -I ./../../../../src/libraries/mic/headers -I ./../../../../src/libraries/types/headers/types/little_endian -I ./../../../../src/libraries/types/headers/types/little_endian/ieee754 -I ./../../../../src/libraries/types/headers -I ./../../../../src/libraries/error/headers -I ./../../../../src/libraries/timezone/headers -I ./../../../../src/libraries/xmlx/headers -I ./../../../../build.i386-apple-darwin/include64/libxml2 -I ./../../../../src/libraries/currency/headers -I ./../../../../src/libraries/market_data/headers -I ./../../../../src/libraries/combination/headers -I ./../../../../src/libraries/protocol/headers -I ./../../../../src/libraries/error_stack/headers -I ./../../../../src/libraries/message/headers -I ./../../../../src/libraries/transport/headers -I ./../../../../src/libraries/TProactor/headers -I ./../../../../src/libraries/bonjour/headers -I ./../../../../src/libraries/config/headers -I ./../../../../build.i386-apple-darwin/include64 -I ./../../../../src/libraries/qos/headers -I ./../../../../src/libraries/storage/headers -I ./../../../../build.i386-apple-darwin/include64/bdb-5.1.25 -I ./../../../../src/libraries/trading_reference_data/headers -I ./../../../../src/libraries/service_status/headers -I ./../../../../src/libraries/admin/core/headers -I ./../../../../src/libraries/log_backend/headers -I ./../../../../src/libraries/csv/headers -I ./../../../../src/libraries/user/headers -I ./../../../../src/libraries/venue/headers -I ./../../../../build.i386-apple-darwin/include64/umem -I ./../../../../src/libraries/protocol_impl/headers -I ./../../../../src/libraries/audit/headers -I ./../../../../src/libraries/resource/headers -I ./../../../../src/libraries/server/headers -I ./../../../../src/libraries/zeroconf_extender/headers -I ./../../../../src/libraries/subscription/headers -I ./../../../../src/libraries/rbac/core/headers -I ./../../../../src/libraries/transport_fix/headers -I ./../../../../src/libraries/ustring/headers -I ./../../../../build.i386-apple-darwin/include64 -I ./../../../../build.i386-apple-darwin/include64 -I ./../../../../build.i386-apple-darwin/platform/obj64/src/servers/market_data/fix/market_data_fix/include -Wall -Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-self-assign -Wno-constant-logical-operand -Wno-unused-function -fconst-strings -fdeprecated-macro -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o ../../../../build.i386-apple-darwin/platform/obj64/src/servers/market_data/fix/market_data_fix/src/FixApplication.o.tmp -x c++ src/FixApplication.cpp 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'src/FixApplication.cpp'. clang: error: unable to execute command: Segmentation fault: 11 (core dumped) clang: error: clang frontend command failed due to signal 2 (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 Jan 17 02:34:51 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 08:34:51 +0000 Subject: [LLVMbugs] [Bug 11779] 'ret' instruction unwanted interaction In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11779 Mooneer Salem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #4 from Mooneer Salem 2012-01-17 02:34:51 CST --- (In reply to comment #3) > I also didn't understand the problem description. Are you saying that if you > change > > ret i32* %1 > ret i32* %1 > > to > > ret i32* %1 > > in @x__o then your program starts working? That's correct. It seems that the existence of two ret instructions causes some sort of interaction that results in the function returning something other than the contents of %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 Tue Jan 17 03:17:28 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 09:17:28 +0000 Subject: [LLVMbugs] [Bug 11769] AVX codegen crash In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11769 Nadav Rotem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Nadav Rotem 2012-01-17 03:17:28 CST --- Fixed in 148298. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 03:20:34 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 09:20:34 +0000 Subject: [LLVMbugs] [Bug 11655] clang alignment mismatch with gcc for ppc architecture In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11655 mackyle at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Version|2.9 |3.0 Resolution|WORKSFORME | --- Comment #5 from mackyle at gmail.com 2012-01-17 03:20:34 CST --- When run against the released clang 3.0: $ clang-mp-3.0 --version clang-mp-3.0(46723) malloc: *** error for object 0x14d2674: Non-aligned pointer being freed *** set a breakpoint in malloc_error_break to debug clang-mp-3.0(46723) malloc: *** error for object 0x14d2674: Non-aligned pointer being freed *** set a breakpoint in malloc_error_break to debug clang-mp-3.0(46723) malloc: *** error for object 0x14d2674: Non-aligned pointer being freed *** set a breakpoint in malloc_error_break to debug clang version 3.0 (tags/RELEASE_30/final) Target: i386-apple-darwin9.8.0 Thread model: posix The output of example.c when compiled for -arch ppc (powerpc-apple-darwin9) is still: offsetof(struct badsize,f4) = 24 sizeof(struct badsize) = 32 but it should be: offsetof(struct badsize,f4) = 20 sizeof(struct badsize) = 28 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 03:32:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 09:32:46 +0000 Subject: [LLVMbugs] [Bug 9195] -Wformat=0 should be understood as an alias for -Wno-format In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9195 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Hans Wennborg 2012-01-17 03:32:46 CST --- Fixed in r148300. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 06:09:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 12:09:46 +0000 Subject: [LLVMbugs] [Bug 11782] New: Bad cast in llvm::SCEVExpander::getAddRecExprPHILiterally Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11782 Bug #: 11782 Summary: Bad cast in llvm::SCEVExpander::getAddRecExprPHILiterally Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7892 --> http://llvm.org/bugs/attachment.cgi?id=7892 Test case The attached input hits: llvm/include/llvm/Support/Casting.h:194: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = llvm::Instruction, Y = llvm::Value*, typename llvm::cast_retty::ret_type = llvm::Instruction*]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. from within getAddRecExprPHILiterally. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 06:16:33 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 12:16:33 +0000 Subject: [LLVMbugs] [Bug 11783] New: [LSR] Assertion `isa(LastIncExpr) && "expect recurrence at IV user"' failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11783 Bug #: 11783 Summary: [LSR] Assertion `isa(LastIncExpr) && "expect recurrence at IV user"' failed Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7893 --> http://llvm.org/bugs/attachment.cgi?id=7893 Test case Attached is a reduced test 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 Tue Jan 17 06:39:07 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 12:39:07 +0000 Subject: [LLVMbugs] [Bug 11784] New: Assertion `(E->getObjectKind() == OK_ObjCProperty || !Ctx.getLangOptions().CPlusPlus) && "C++ struct assignment should be resolved by the " "copy assignment operator."' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11784 Bug #: 11784 Summary: Assertion `(E->getObjectKind() == OK_ObjCProperty || !Ctx.getLangOptions().CPlusPlus) && "C++ struct assignment should be resolved by the " "copy assignment operator."' failed. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7894 --> http://llvm.org/bugs/attachment.cgi?id=7894 Test case Minimized test case is 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 Tue Jan 17 08:19:15 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 14:19:15 +0000 Subject: [LLVMbugs] [Bug 11785] New: llvm linker fails to link code because of a type problem. caused by revision 146932 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11785 Bug #: 11785 Summary: llvm linker fails to link code because of a type problem. caused by revision 146932 Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Linker AssignedTo: unassignedbugs at nondot.org ReportedBy: hkultala at cs.tut.fi CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7895 --> http://llvm.org/bugs/attachment.cgi?id=7895 tarball containg bytecode files whoose linkage fails. This code links correctly with llvm-svn revision 146931. But with revision 146932 this breaks. the .o files in the tarball are bitcode files, and .a files are ar achive containing bitcode files how to reproduce: unpack the tar.bz2 package, go to the directory, run: llvm-ld -disable-opt *.o *.a -o foo The error message is: Load result type does not match pointer operand type! %6 = load %0** getelementptr inbounds ([258 x %0*]* @__malloc_av_, i32 0, i32 2), align 4, !tbaa !3 My guess is that the type mapping changes in r146932 are incomplete; it seems that many types with same name are mapped together to be same type, but when they are structs containing structs, those "inner structs" are not mapped together correctly and then the types look different even they are the same. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 12:54:07 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 18:54:07 +0000 Subject: [LLVMbugs] [Bug 11786] New: Fatal error generating code for atomic operations [x86-64] Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11786 Bug #: 11786 Summary: Fatal error generating code for atomic operations [x86-64] Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified With this IR, produced while attempting to find a reduced test case for a libc++ miscompilation bug, I get a fatal error in the codegen: ; ModuleID = 'atom.c' target datalayout = "e-p:64:64:64-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-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-unknown-freebsd9.0" @.str = private unnamed_addr constant [4 x i8] c"%p\0A\00", align 1 define i32 @main() nounwind uwtable { %1 = alloca i32, align 4 %a = alloca i32*, align 8 %b = alloca i32*, align 8 %2 = alloca i32, align 4 %3 = alloca i8, align 1 store i32 0, i32* %1 store i32* inttoptr (i64 3 to i32*), i32** %a, align 8 store i32* inttoptr (i64 3 to i32*), i32** %b, align 8 %4 = load atomic i32** %a seq_cst, align 8 %5 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x i8]* @.str, i32 0, i32 0), i32* %4) store i32 5, i32* %2 %6 = bitcast i32** %a to i64* %7 = bitcast i32** %b to i64* %8 = bitcast i32* %2 to i64* %9 = load i64* %7, align 8 %10 = load i64* %8, align 8 %11 = cmpxchg i64* %6, i64 %9, i64 %10 seq_cst store i64 %11, i64* %7, align 8 %12 = icmp eq i64 %11, %9 %13 = zext i1 %12 to i8 store i8 %13, i8* %3 %14 = load i8* %3 %15 = trunc i8 %14 to i1 %16 = load atomic i32** %a seq_cst, align 8 %17 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x i8]* @.str, i32 0, i32 0), i32* %16) ret i32 0 } declare i32 @printf(i8*, ...) This is the error: fatal error: error in backend: Cannot select: 0x802a47e10: i64 = any_extend 0x802a47d10 [ID=47] 0x802a47d10: i1,ch = AtomicLoad 0x802a47a10, 0x802a44610 [ORD=22] [ID=46] 0x802a44610: i64 = FrameIndex<1> [ORD=3] [ID=5] Replacing the cmpxchg with a load gives me a different error, this time complaining about being able to match the atomic load. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 14:07:26 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 20:07:26 +0000 Subject: [LLVMbugs] [Bug 11787] New: Unneeded copy when passing by value Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11787 Bug #: 11787 Summary: Unneeded copy when passing by value Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: jmuizelaar at mozilla.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code: typedef struct { struct { double x; double y; double z; double w; } a; struct { double x; double y; double z; double w; } b; struct { double x; double y; double z; double w; } c; struct { double x; double y; double z; double w; } d; } matrix; matrix make_matrix(); void set_matrix(matrix); void p() { matrix k = make_matrix(); set_matrix(k); } generates this: _p: ## @p pushq %rbp movq %rsp, %rbp pushq %rbx subq $264, %rsp ## imm = 0x108 leaq -136(%rbp), %rbx movq %rbx, %rdi xorb %al, %al callq _make_matrix movl $16, %ecx movq %rsp, %rdi movq %rbx, %rsi rep;movsq callq _set_matrix addq $264, %rsp ## imm = 0x108 popq %rbx popq %rbp ret It would be nice if we could avoid the copy of the matrix -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 14:43:51 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 20:43:51 +0000 Subject: [LLVMbugs] [Bug 11732] Spurious ARC release of caught exception in @catch block In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11732 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Eli Friedman 2012-01-17 14:43:51 CST --- r148325. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 15:28:20 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 21:28:20 +0000 Subject: [LLVMbugs] [Bug 11784] Assertion `(E->getObjectKind() == OK_ObjCProperty || !Ctx.getLangOptions().CPlusPlus) && "C++ struct assignment should be resolved by the " "copy assignment operator."' failed. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11784 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2012-01-17 15:28:20 CST --- r148335. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 15:33:19 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 21:33:19 +0000 Subject: [LLVMbugs] [Bug 11779] 'ret' instruction unwanted interaction In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11779 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |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 Tue Jan 17 16:12:03 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 22:12:03 +0000 Subject: [LLVMbugs] [Bug 11788] New: It's complicated... Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11788 Bug #: 11788 Summary: It's complicated... Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping at exherbo.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7896 --> http://llvm.org/bugs/attachment.cgi?id=7896 dump I have clang 3.1-git (448ce0f1b419bb434761422bc5f050bf4b57b703) installed. It uses libstdc++-4.6.2 I also have libc++-git installed. I'm trying to compile llvm+clang with --enable-libcpp(*). When compiling clans' lib/Parse/ParseDeclCXX.cpp, I get the following: % clang++ -I/home/pipping/build-llvm/include -I/home/pipping/build-llvm/tools/clang/lib/Parse -I/home/pipping/llvm-src/include -I/home/pipping/llvm-src/tools/clang/lib/Parse -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/pipping/llvm-src/tools/clang/lib/Parse/../../include -I/home/pipping/build-llvm/tools/clang/lib/Parse/../../include -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fPIC -fno-strict-aliasing -c /home/pipping/llvm-src/tools/clang/lib/Parse/ParseDeclCXX.cpp -O0 -emit-llvm *** glibc detected *** /usr/bin/clang: double free or corruption (!prev): 0x0000000003a6fa50 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x71d25)[0x7ffff57b9d25] /lib64/libc.so.6(cfree+0x6c)[0x7ffff57bebcc] /usr/bin/clang[0x8101d8] /usr/bin/clang[0x811b7f] /usr/bin/clang(_ZN5clang4Sema21CreateOverloadedBinOpENS_14SourceLocationEjRKNS_17UnresolvedSetImplEPNS_4ExprES6_+0xea3)[0x935c53] /usr/bin/clang[0x8b08bb] /usr/bin/clang(_ZN5clang4Sema10ActOnBinOpEPNS_5ScopeENS_14SourceLocationENS_3tok9TokenKindEPNS_4ExprES7_+0x6d9)[0x8960c9] /usr/bin/clang(_ZN5clang6Parser26ParseRHSOfBinaryExpressionENS_12ActionResultIPNS_4ExprELb1EEENS_4prec5LevelE+0x7b1)[0x77ecb1] /usr/bin/clang(_ZN5clang6Parser25ParseAssignmentExpressionEv+0xb3)[0x77e4d3] /usr/bin/clang(_ZN5clang6Parser15ParseExpressionEv+0xc)[0x77e40c] /usr/bin/clang(_ZN5clang6Parser18ParseExprStatementERNS_16ParsedAttributesE+0x2d)[0x74c75d] /usr/bin/clang(_ZN5clang6Parser27ParseStatementOrDeclarationERNS_15ASTOwningVectorIPNS_4StmtELj32EEEbPNS_14SourceLocationE+0x672)[0x74c202] /usr/bin/clang(_ZN5clang6Parser16ParseIfStatementERNS_16ParsedAttributesEPNS_14SourceLocationE+0x1bf)[0x74d6df] /usr/bin/clang(_ZN5clang6Parser27ParseStatementOrDeclarationERNS_15ASTOwningVectorIPNS_4StmtELj32EEEbPNS_14SourceLocationE+0x6d9)[0x74c269] /usr/bin/clang(_ZN5clang6Parser26ParseCompoundStatementBodyEb+0x479)[0x750bc9] /usr/bin/clang(_ZN5clang6Parser27ParseStatementOrDeclarationERNS_15ASTOwningVectorIPNS_4StmtELj32EEEbPNS_14SourceLocationE+0x39a)[0x74bf2a] /usr/bin/clang(_ZN5clang6Parser16ParseIfStatementERNS_16ParsedAttributesEPNS_14SourceLocationE+0x1bf)[0x74d6df] /usr/bin/clang(_ZN5clang6Parser27ParseStatementOrDeclarationERNS_15ASTOwningVectorIPNS_4StmtELj32EEEbPNS_14SourceLocationE+0x6d9)[0x74c269] /usr/bin/clang(_ZN5clang6Parser16ParseIfStatementERNS_16ParsedAttributesEPNS_14SourceLocationE+0x28b)[0x74d7ab] /usr/bin/clang(_ZN5clang6Parser27ParseStatementOrDeclarationERNS_15ASTOwningVectorIPNS_4StmtELj32EEEbPNS_14SourceLocationE+0x6d9)[0x74c269] /usr/bin/clang(_ZN5clang6Parser26ParseCompoundStatementBodyEb+0x479)[0x750bc9] /usr/bin/clang(_ZN5clang6Parser27ParseStatementOrDeclarationERNS_15ASTOwningVectorIPNS_4StmtELj32EEEbPNS_14SourceLocationE+0x39a)[0x74bf2a] /usr/bin/clang(_ZN5clang6Parser16ParseIfStatementERNS_16ParsedAttributesEPNS_14SourceLocationE+0x1bf)[0x74d6df] /usr/bin/clang(_ZN5clang6Parser27ParseStatementOrDeclarationERNS_15ASTOwningVectorIPNS_4StmtELj32EEEbPNS_14SourceLocationE+0x6d9)[0x74c269] /usr/bin/clang(_ZN5clang6Parser26ParseCompoundStatementBodyEb+0x479)[0x750bc9] /usr/bin/clang(_ZN5clang6Parser26ParseFunctionStatementBodyEPNS_4DeclERNS0_10ParseScopeE+0xae)[0x751ffe] /usr/bin/clang(_ZN5clang6Parser23ParseFunctionDefinitionERNS0_17ParsingDeclaratorERKNS0_18ParsedTemplateInfoE+0x66a)[0x75d56a] /usr/bin/clang(_ZN5clang6Parser14ParseDeclGroupERNS0_15ParsingDeclSpecEjbPNS_14SourceLocationEPNS0_12ForRangeInitE+0x3f3)[0x7695f3] /usr/bin/clang(_ZN5clang6Parser36ParseDeclarationOrFunctionDefinitionERNS0_15ParsingDeclSpecENS_15AccessSpecifierE+0x2b7)[0x75c987] /usr/bin/clang(_ZN5clang6Parser36ParseDeclarationOrFunctionDefinitionERNS_16ParsedAttributesENS_15AccessSpecifierE+0x18d)[0x75cb5d] /usr/bin/clang(_ZN5clang6Parser24ParseExternalDeclarationERNS0_25ParsedAttributesWithRangeEPNS0_15ParsingDeclSpecE+0xaec)[0x75bf4c] /usr/bin/clang(_ZN5clang6Parser17ParseTopLevelDeclERNS_9OpaquePtrINS_12DeclGroupRefEEE+0x100)[0x75b3f0] /usr/bin/clang(_ZN5clang8ParseASTERNS_4SemaEb+0x11b)[0x74199b] /usr/bin/clang(_ZN5clang13CodeGenAction13ExecuteActionEv+0x35b)[0x64258b] /usr/bin/clang(_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE+0x3dd)[0x51d9dd] /usr/bin/clang(_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE+0xb00)[0x507140] /usr/bin/clang(_Z8cc1_mainPPKcS1_S0_Pv+0x1656)[0x4fe456] /usr/bin/clang(main+0x27e)[0x50381e] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7ffff5766e5d] /usr/bin/clang[0x4fcd39] ======= Memory map: ======== 00400000-00fb1000 r-xp 00000000 08:03 142045 /usr/bin/clang 011b0000-01223000 rw-p 00bb0000 08:03 142045 /usr/bin/clang 01223000-03acc000 rw-p 00000000 00:00 0 [heap] 7ffff0000000-7ffff0021000 rw-p 00000000 00:00 0 7ffff0021000-7ffff4000000 ---p 00000000 00:00 0 7ffff5420000-7ffff542d000 r--p 00000000 08:04 4063748 /home/pipping/build-llvm/tools/clang/include/clang/Basic/DiagnosticParseKinds.inc 7ffff542d000-7ffff5435000 r--p 00000000 08:03 852391 /usr/include/c++/4.6.2/bits/deque.tcc 7ffff5435000-7ffff5446000 r--p 00000000 08:03 852439 /usr/include/c++/4.6.2/bits/stl_deque.h 7ffff5446000-7ffff5454000 r--p 00000000 08:04 3932803 /home/pipping/llvm-src/tools/clang/include/clang/AST/TypeLoc.h 7ffff5454000-7ffff5459000 r--p 00000000 08:04 3672844 /home/pipping/llvm-src/include/llvm/ADT/Twine.h 7ffff5459000-7ffff5460000 r--p 00000000 08:04 3932899 /home/pipping/llvm-src/tools/clang/include/clang/Basic/TargetInfo.h 7ffff5460000-7ffff5466000 r--p 00000000 08:04 3932800 /home/pipping/llvm-src/tools/clang/include/clang/AST/TemplateBase.h 7ffff5466000-7ffff546b000 r--p 00000000 08:04 4063728 /home/pipping/build-llvm/tools/clang/include/clang/AST/StmtNodes.inc 7ffff546b000-7ffff5472000 r--p 00000000 08:04 3932764 /home/pipping/llvm-src/tools/clang/include/clang/AST/CanonicalType.h 7ffff5472000-7ffff5478000 r--p 00000000 08:04 3932776 /home/pipping/llvm-src/tools/clang/include/clang/AST/DeclarationName.h 7ffff5478000-7ffff5497000 r--p 00000000 08:04 3932766 /home/pipping/llvm-src/tools/clang/include/clang/AST/Decl.h 7ffff5497000-7ffff54ab000 r--p 00000000 08:04 3932754 /home/pipping/llvm-src/tools/clang/include/clang/AST/ASTContext.h 7ffff54ab000-7ffff54b9000 r--p 00000000 08:04 3932794 /home/pipping/llvm-src/tools/clang/include/clang/AST/Stmt.h 7ffff54b9000-7ffff54be000 r--p 00000000 08:04 3672793 /home/pipping/llvm-src/include/llvm/ADT/APFloat.h 7ffff54be000-7ffff54e8000 r--p 00000000 08:04 3932779 /home/pipping/llvm-src/tools/clang/include/clang/AST/Expr.h 7ffff54e8000-7ffff5503000 r--p 00000000 08:04 3932769 /home/pipping/llvm-src/tools/clang/include/clang/AST/DeclCXX.h 7ffff5503000-7ffff5584000 rw-p 00000000 00:00 0 7ffff5584000-7ffff5596000 r--p 00000000 08:04 4063724 /home/pipping/build-llvm/tools/clang/include/clang/AST/Attrs.inc 7ffff5596000-7ffff559b000 r--p 00000000 08:04 3673236 /home/pipping/llvm-src/include/llvm/Support/raw_ostream.h 7ffff559b000-7ffff55ab000 r--p 00000000 08:04 3672794 /home/pipping/llvm-src/include/llvm/ADT/APInt.h 7ffff55ab000-7ffff55b0000 r--p 00000000 08:04 3932801 /home/pipping/llvm-src/tools/clang/include/clang/AST/TemplateName.h 7ffff55b0000-7ffff55db000 r--p 00000000 08:04 3932802 /home/pipping/llvm-src/tools/clang/include/clang/AST/Type.h 7ffff55db000-7ffff55e9000 r--p 00000000 08:04 3932768 /home/pipping/llvm-src/tools/clang/include/clang/AST/DeclBase.h 7ffff55e9000-7ffff55f0000 r--p 00000000 08:04 3672805 /home/pipping/llvm-src/include/llvm/ADT/FoldingSet.h 7ffff55f0000-7ffff55f5000 r--p 00000000 08:04 3932786 /home/pipping/llvm-src/tools/clang/include/clang/AST/NestedNameSpecifier.h 7ffff55f5000-7ffff55fb000 r--p 00000000 08:04 3933038 /home/pipping/llvm-src/tools/clang/include/clang/Sema/AttributeList.h 7ffff55fb000-7ffff560d000 r--p 00000000 08:04 3933041 /home/pipping/llvm-src/tools/clang/include/clang/Sema/DeclSpec.h 7ffff560d000-7ffff5612000 r--p 00000000 08:04 3933052 /home/pipping/llvm-src/tools/clang/include/clang/Sema/Ownership.h 7ffff5612000-7ffff565a000 r--p 00000000 08:04 3933057 /home/pipping/llvm-src/tools/clang/include/clang/Sema/Sema.h 7ffff565a000-7ffff5663000 r--p 00000000 08:04 3932847 /home/pipping/llvm-src/tools/clang/include/clang/Basic/Builtins.def 7ffff5663000-7ffff5670000 r--p 00000000 08:03 852445 /usr/include/c++/4.6.2/bits/stl_list.h 7ffff5670000-7ffff5731000 rw-p 00000000 00:00 0 7ffff5731000-7ffff5737000 r--p 00000000 08:04 3933001 /home/pipping/llvm-src/tools/clang/include/clang/Lex/Lexer.h 7ffff5737000-7ffff5748000 r--p 00000000 08:03 852507 /usr/include/c++/4.6.2/functional 7ffff5748000-7ffff58c7000 r-xp 00000000 08:03 41559 /lib64/libc-2.13.so 7ffff58c7000-7ffff5ac6000 ---p 0017f000 08:03 41559 /lib64/libc-2.13.so 7ffff5ac6000-7ffff5aca000 r--p 0017e000 08:03 41559 /lib64/libc-2.13.so 7ffff5aca000-7ffff5acb000 rw-p 00182000 08:03 41559 /lib64/libc-2.13.so 7ffff5acb000-7ffff5ad0000 rw-p 00000000 00:00 0 7ffff5ad0000-7ffff5ae5000 r-xp 00000000 08:03 795688 /usr/lib64/libgcc_s-4.7.so.1 7ffff5ae5000-7ffff5ce4000 ---p 00015000 08:03 795688 /usr/lib64/libgcc_s-4.7.so.1 7ffff5ce4000-7ffff5ce5000 rw-p 00014000 08:03 795688 /usr/lib64/libgcc_s-4.7.so.1 7ffff5ce5000-7ffff5dce000 r-xp 00000000 08:03 794273 /usr/lib64/libstdc++.so.6.0.17 7ffff5dce000-7ffff5fcd000 ---p 000e9000 08:03 794273 /usr/lib64/libstdc++.so.6.0.17 7ffff5fcd000-7ffff5fd5000 r--p 000e8000 08:03 794273 /usr/lib64/libstdc++.so.6.0.17 7ffff5fd5000-7ffff5fd7000 rw-p 000f0000 08:03 794273 /usr/lib64/libstdc++.so.6.0.17 7ffff5fd7000-7ffff5fec000 rw-p 00000000 00:00 0 7ffff5fec000-7ffff606d000 r-xp 00000000 08:03 42399 /lib64/libm-2.13.so 7ffff606d000-7ffff626c000 ---p 00081000 08:03 42399 /lib64/libm-2.13.so 7ffff626c000-7ffff626d000 r--p 00080000 08:03 42399 /lib64/libm-2.13.so 7ffff626d000-7ffff626e000 rw-p 00081000 08:03 42399 /lib64/libm-2.13.so 7ffff626e000-7ffff6270000 r-xp 00000000 08:03 42449 /lib64/libdl-2.13.so 7ffff6270000-7ffff6470000 ---p 00002000 08:03 42449 /lib64/libdl-2.13.so 7ffff6470000-7ffff6471000 r--p 00002000 08:03 42449 /lib64/libdl-2.13.so 7ffff6471000-7ffff6472000 rw-p 00003000 08:03 42449 /lib64/libdl-2.13.so 7ffff6472000-7ffff6489000 r-xp 00000000 08:03 42775 /lib64/libpthread-2.13.so 7ffff6489000-7ffff6689000 ---p 00017000 08:03 42775 /lib64/libpthread-2.13.so 7ffff6689000-7ffff668a000 r--p 00017000 08:03 42775 /lib64/libpthread-2.13.so 7ffff668a000-7ffff668b000 rw-p 00018000 08:03 42775 /lib64/libpthread-2.13.so 7ffff668b000-7ffff668f000 rw-p 00000000 00:00 0 7ffff668f000-7ffff7914000 r-xp 00000000 08:03 142016 /usr/lib64/libLLVM-3.1svn.so 7ffff7914000-7ffff7b13000 ---p 01285000 08:03 142016 /usr/lib64/libLLVM-3.1svn.so 7ffff7b13000-7ffff7dce000 rw-p 01284000 08:03 142016 /usr/lib64/libLLVM-3.1svn.so 7ffff7dce000-7ffff7ddd000 rw-p 00000000 00:00 0 7ffff7ddd000-7ffff7dfc000 r-xp 00000000 08:03 42807 /lib64/ld-2.13.so 7ffff7e01000-7ffff7e06000 r--p 00000000 08:03 852458 /usr/include/c++/4.6.2/bits/stl_uninitialized.h 7ffff7e06000-7ffff7e0c000 r--p 00000000 08:04 3672833 /home/pipping/llvm-src/include/llvm/ADT/SmallVector.h 7ffff7e0c000-7ffff7e12000 r--p 00000000 08:03 42458 /usr/include/string.h 7ffff7e12000-7ffff7e1a000 r--p 00000000 08:03 852403 /usr/include/c++/4.6.2/bits/istream.tcc 7ffff7e1a000-7ffff7e22000 r--p 00000000 08:03 852513 /usr/include/c++/4.6.2/istream 7ffff7e22000-7ffff7e2c000 r--p 00000000 08:03 852408 /usr/include/c++/4.6.2/bits/locale_facets.tcc 7ffff7e2c000-7ffff7e43000 r--p 00000000 08:03 852407 /usr/include/c++/4.6.2/bits/locale_facets.h 7ffff7e43000-7ffff7e4a000 r--p 00000000 08:03 852533 /usr/include/c++/4.6.2/streambuf 7ffff7e4a000-7ffff7e54000 r--p 00000000 08:03 852384 /usr/include/c++/4.6.2/bits/basic_string.tcc 7ffff7e54000-7ffff7e6f000 r--p 00000000 08:03 852383 /usr/include/c++/4.6.2/bits/basic_string.h 7ffff7e6f000-7ffff7e75000 r--p 00000000 08:03 852440 /usr/include/c++/4.6.2/bits/stl_function.h 7ffff7e75000-7ffff7e7b000 r--p 00000000 08:03 852405 /usr/include/c++/4.6.2/bits/locale_classes.h 7ffff7e7b000-7ffff7e81000 r--p 00000000 08:03 43856 /usr/include/bits/confname.h 7ffff7e81000-7ffff7e8c000 r--p 00000000 08:03 43841 /usr/include/unistd.h 7ffff7e8c000-7ffff7e96000 r--p 00000000 08:03 44150 /usr/include/pthread.h 7ffff7e96000-7ffff7e9c000 r--p 00000000 08:03 935334 /usr/include/c++/4.6.2/x86_64-pc-linux-gnu/bits/gthr-default.h 7ffff7e9c000-7ffff7ea3000 r--p 00000000 08:03 852402 /usr/include/c++/4.6.2/bits/ios_base.h 7ffff7ea3000-7ffff7ea8000 r--p 00000000 08:03 852387 /usr/include/c++/4.6.2/bits/char_traits.h 7ffff7ea8000-7ffff7eb0000 r--p 00000000 08:03 42438 /usr/include/stdio.h 7ffff7eb0000-7ffff7eb8000 r--p 00000000 08:03 42470 /usr/include/wchar.h 7ffff7eb8000-7ffff7ebd000 r--p 00000000 08:03 852522 /usr/include/c++/4.6.2/ostream 7ffff7ebd000-7ffff7ec2000 r--p 00000000 08:03 852441 /usr/include/c++/4.6.2/bits/stl_heap.h 7ffff7ec2000-7ffff7ec8000 r--p 00000000 08:03 852376 /usr/include/c++/4.6.2/bits/algorithmfwd.h 7ffff7ec8000-7ffff7ed1000 r--p 00000000 08:03 42419 /usr/include/stdlib.h 7ffff7ed1000-7ffff7f06000 r--p 00000000 08:03 852435 /usr/include/c++/4.6.2/bits/stl_algo.h 7ffff7f0d000-7ffff7f18000 r--p 00000000 08:04 3932858 /home/pipping/llvm-src/tools/clang/include/clang/Basic/Diagnostic.h 7ffff7f18000-7ffff7f20000 r--p 00000000 08:04 3932878 /home/pipping/llvm-src/tools/clang/include/clang/Basic/IdentifierTable.h 7ffff7f20000-7ffff7f26000 r--p 00000000 08:03 852469 /usr/include/c++/4.6.2/bits/vector.tcc 7ffff7f26000-7ffff7f2d000 r--p 00000000 08:03 852437 /usr/include/c++/4.6.2/bits/stl_bvector.h 7ffff7f2d000-7ffff7f39000 r--p 00000000 08:03 852459 /usr/include/c++/4.6.2/bits/stl_vector.h 7ffff7f39000-7ffff7f41000 r--p 00000000 08:03 852447 /usr/include/c++/4.6.2/bits/stl_multimap.h 7ffff7f41000-7ffff7f4a000 r--p 00000000 08:03 852446 /usr/include/c++/4.6.2/bits/stl_map.h 7ffff7f4a000-7ffff7f56000 r--p 00000000 08:03 852457 /usr/include/c++/4.6.2/bits/stl_tree.h 7ffff7f56000-7ffff7f5b000 r--p 00000000 08:04 3672838 /home/pipping/llvm-src/include/llvm/ADT/StringRef.h 7ffff7f5b000-7ffff7f69000 r--p 00000000 08:04 3932894 /home/pipping/llvm-src/tools/clang/include/clang/Basic/SourceManager.h 7ffff7f69000-7ffff7f6f000 r--p 00000000 08:04 3932902 /home/pipping/llvm-src/tools/clang/include/clang/Basic/TokenKinds.def 7ffff7f6f000-7ffff7f78000 r--p 00000000 08:03 852442 /usr/include/c++/4.6.2/bits/stl_iterator.h 7ffff7f78000-7ffff7f83000 r--p 00000000 08:03 852436 /usr/include/c++/4.6.2/bits/stl_algobase.h 7ffff7f83000-7ffff7f92000 r--p 00000000 08:03 852515 /usr/include/c++/4.6.2/limits 7ffff7f92000-7ffff7f98000 r--p 00000000 08:03 142322 /usr/lib64/clang/3.1/include/stdint.h 7ffff7f98000-7ffff7fa4000 r--p 00000000 08:03 935323 /usr/include/c++/4.6.2/x86_64-pc-linux-gnu/bits/c++config.h 7ffff7fa4000-7ffff7fae000 r--p 00000000 08:03 852480 /usr/include/c++/4.6.2/cmath 7ffff7fae000-7ffff7fb3000 r--p 00000000 08:04 3672800 /home/pipping/llvm-src/include/llvm/ADT/DenseMap.h 7ffff7fb3000-7ffff7fc9000 r--p 00000000 08:04 3933025 /home/pipping/llvm-src/tools/clang/include/clang/Parse/Parser.h 7ffff7fc9000-7ffff7fe3000 r--p 00000000 08:04 3933551 /home/pipping/llvm-src/tools/clang/lib/Parse/ParseDeclCXX.cpp 7ffff7fe3000-7ffff7fea000 rw-p 00000000 00:00 0 7ffff7fec000-7ffff7ffa000 r--p 00000000 08:04 3933013 /home/pipping/llvm-src/tools/clang/include/clang/Lex/Preprocessor.h 7ffff7ffa000-7ffff7ffb000 rw-p 00000000 00:00 0 7ffff7ffb000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso] 7ffff7ffc000-7ffff7ffd000 r--p 0001f000 08:03 42807 /lib64/ld-2.13.so 7ffff7ffd000-7ffff7ffe000 rw-p 00020000 08:03 42807 /lib64/ld-2.13.so 7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 7ffffffa0000-7ffffffff000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Note that clang does not return at that point -- it justs hangs at that point. Adding -O0 -emit-llvm leads to similar output. Using -O0 -save-temps leads to a hang. I get a hang, too, when compiling the resulting dump. I'm attaching the aforementioned dump (xz-compressed). (*) To that end, I manually undefined HAVE_DLFCN_H -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 16:40:36 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 22:40:36 +0000 Subject: [LLVMbugs] [Bug 11655] clang alignment mismatch with gcc for ppc architecture In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11655 Anton changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Version|3.0 |2.9 Resolution| |FIXED --- Comment #6 from Anton 2012-01-17 16:40:36 CST --- r148345 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 16:58:50 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 17 Jan 2012 22:58:50 +0000 Subject: [LLVMbugs] [Bug 11771] Vectors shift operator broken In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11771 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #6 from Eli Friedman 2012-01-17 16:58:50 CST --- float2 fabs2(float2 f) { float4 a = *(float4*)&a; a = fabs4(a); return a.lo; } That has undefined behavior; try "float4 a = (float4)(f,f);"? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 18:55:01 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 00:55:01 +0000 Subject: [LLVMbugs] [Bug 11788] It's complicated... In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11788 Elias Pipping changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #4 from Elias Pipping 2012-01-17 18:55:01 CST --- Guess I just happened to come across a broken revision. Updating helped. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 19:03:05 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 01:03:05 +0000 Subject: [LLVMbugs] [Bug 11656] switch block causes frontend to segfault In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11656 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution| |FIXED --- Comment #3 from Aaron Ballman 2012-01-17 19:03:05 CST --- Fixed in r148243 and r148359 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 21:50:56 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 03:50:56 +0000 Subject: [LLVMbugs] [Bug 11789] New: STR2WSTR(__FUNCTION__) should work in microsoft mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11789 Bug #: 11789 Summary: STR2WSTR(__FUNCTION__) should work in microsoft mode Product: clang Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified #include #define _FOO_STR2WSTR(s) L##s #define FOO_STR2WSTR(s) _FOO_STR2WSTR(s) int main() { //const wchar_t* kFoo = L__FUNCTION__; // doesn't work in cl.exe const wchar_t* kWFoo = FOO_STR2WSTR(__FUNCTION__); // works in cl } Both gcc and clang don't allow this, but cl.exe does. (gcc and clang support it for e.g. __FILE__.) This is used in msvc's c++ standard headers. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 23:13:55 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 05:13:55 +0000 Subject: [LLVMbugs] [Bug 11756] Greedy Register Allocator crashes on compiling db5 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11756 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Jakob Stoklund Olesen 2012-01-17 23:13:55 CST --- I verified that this is an instance of the bug Pete fixed in r146428. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 23:16:18 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 05:16:18 +0000 Subject: [LLVMbugs] [Bug 11790] New: Don't set __GNUC__ and friends in microsoft mode, set _MSC_VER instead Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11790 Bug #: 11790 Summary: Don't set __GNUC__ and friends in microsoft mode, set _MSC_VER instead Product: clang Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Probably important for many projects. Chromium for example uses this for compiler detection: // Compiler detection. #if defined(__GNUC__) #define COMPILER_GCC 1 #elif defined(_MSC_VER) #define COMPILER_MSVC 1 #else #error Please add support for your compiler in build/build_config.h #endif ...and uses that to decide whether to #include or http://llvm.org/bugs/show_bug.cgi?id=11791 Bug #: 11791 Summary: Support pseudodestructors on void in microsoft mode Product: clang Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified cl.exe accepts this program: template void _DebugHeapDelete(_Ty *_Ptr) { if (_Ptr != 0) { _Ptr->~_Ty(); } } void f() { int* a = 0; _DebugHeapDelete((void*)a); } clang rejects it (it's accepted without the void* cast). This appears in the xdebug header of msvc's library. (Workaround: Don't do debug builds.) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 00:17:04 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 06:17:04 +0000 Subject: [LLVMbugs] [Bug 11792] New: Improve windows sdk lookup logic in WindowsToolChain.cc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11792 Bug #: 11792 Summary: Improve windows sdk lookup logic in WindowsToolChain.cc Product: clang Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7898 --> http://llvm.org/bugs/attachment.cgi?id=7898 patch sketch I somehow ended up with a registry that looks like .../Microsoft SDKs/Windows/ v7.0A/ InstallationFolder (tons of subfolders v7.1 (no values) Just WinSDKIntelliSysRefAssist So for some reason I don't have a real v7.1 SDK. The current toolchain looks for the highest version first, and after that for "InstallationFolder" in there. Instead, it should pick the highest version with "InstallationFolder" present. A rough sketch of a patch is 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 Wed Jan 18 01:00:41 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 07:00:41 +0000 Subject: [LLVMbugs] [Bug 11793] New: access control somehow suppressed in for-in loop container expression Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11793 Bug #: 11793 Summary: access control somehow suppressed in for-in loop container expression Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified This is bizarre, but I am not seeing the expected error in the following code: class A { int x[10]; // private }; void test(A *a) { for (unsigned value : a->x) { // should be illegal } } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 10:39:15 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 16:39:15 +0000 Subject: [LLVMbugs] [Bug 11771] Vectors shift operator broken In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11771 Erik Schnetter changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #7 from Erik Schnetter 2012-01-18 10:39:15 CST --- I modified my test case to avoid this undefined behaviour (to the best of my knowledge). Unfortunately, this slightly shifts the problem in my overall code. I attach a new self-contained code that shows the failure. It should be silent if all is fine; however, when built with $ clang -o test_2fabs test_2fabs.cl using $ clang -v clang version 3.1 (trunk 148238) Target: x86_64-apple-darwin11.2.0 Thread model: posix this code outputs $ ./test_2fabs FAIL: signbit type=float2 val=-0 res=-1 good=-1 FAIL: signbit type=float2 val=-0.10000000149011612 res=0 good=-1 FAIL: signbit type=float2 val=-0.10000000149011612 res=-1 good=-1 FAIL: signbit type=float2 val=-0 res=0 good=-1 indicating that the "signbit2" implementation contained in this code near the top fails to correctly extract the sign bit for the second vector component. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 15:07:57 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 21:07:57 +0000 Subject: [LLVMbugs] [Bug 11794] New: EarlyCSE stack overflow on long functions. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11794 Bug #: 11794 Summary: EarlyCSE stack overflow on long functions. Product: tools Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: opt AssignedTo: unassignedbugs at nondot.org ReportedBy: lenny at colorado.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7900 --> http://llvm.org/bugs/attachment.cgi?id=7900 Running this Python script will generate a file which when compiled with the EarlyCSE optimizer enabled (-O2 will enable it) causes the stack to be blown. Basically, the issue is that EarlyCSE::processNode() is recursive and with a very large function, such as the machine generated one I have, it blows the stack. The attached script generates a function which re-creates the problem. On my 64-bit FreeBSD 7.3 build machine I come across this issue with a function as short as 5800 lines, possibly shorter. gcc 4.3 does not display 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 Wed Jan 18 15:59:10 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 18 Jan 2012 21:59:10 +0000 Subject: [LLVMbugs] [Bug 11795] New: Clang accepts direct constructor call Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11795 Bug #: 11795 Summary: Clang accepts direct constructor call Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jason.haslam at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Clang (incorrectly?) accepts: struct A { A (); A (int); int i; }; A::A (int x) { A::A (); i = x; } GCC 4.5 and above rejects this with the error: cannot call constructor directly -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 18:37:34 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 00:37:34 +0000 Subject: [LLVMbugs] [Bug 11576] Use in block doesn't count as use to prevent dead store warning In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11576 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Ted Kremenek 2012-01-18 18:37:34 CST --- This should now be fixed. Are you still seeing 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 Wed Jan 18 19:13:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 01:13:46 +0000 Subject: [LLVMbugs] [Bug 11796] New: Incorrect diagnostic implicitly declaring library function in C89 mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11796 Bug #: 11796 Summary: Incorrect diagnostic implicitly declaring library function in C89 mode Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase (compile with clang -std=c89 -pedantic-errors): int f() { return strcmp("foo", "bar"); } Output: :1:18: error: implicitly declaring C library function 'strcmp' with type 'int (const char *, const char *)' [-Werror] int f() { return strcmp("foo", "bar"); } ^ :1:18: note: please include the header or explicitly provide a declaration for 'strcmp' 1 error generated. This code is valid in C89, so we shouldn't give an error. (Granted, I wouldn't suggest writing code like 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 Wed Jan 18 20:15:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 02:15:42 +0000 Subject: [LLVMbugs] [Bug 11797] New: #pragma GCC visibility push(default) not working properly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11797 Bug #: 11797 Summary: #pragma GCC visibility push(default) not working properly Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: rafael.espindola at gmail.com ReportedBy: rafael.espindola at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified When building with -fvisibility=hidden clang produces a hidden symbol for foo: namespace std __attribute__ ((__visibility__ ("default"))) { } #pragma GCC visibility push(default) void foo() { } #pragma GCC visibility pop -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 23:22:52 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 05:22:52 +0000 Subject: [LLVMbugs] [Bug 11798] New: FastISel does not setCallsExternalVAFunctionWithFloatingPointArguments or emit '_fltused' on win32 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11798 Bug #: 11798 Summary: FastISel does not setCallsExternalVAFunctionWithFloatingPointArguments or emit '_fltused' on win32 Product: new-bugs Version: 3.0 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: arcata at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When fast isel is used, the MMI setCallsExternalVAFunctionWithFloatingPointArguments flag does not get set when variadic functions are called with floating-point arguments, so the _fltused symbol required by MSVC's linker to enable floating-point support does not get emitted. This can be observed by adding the following RUN: lines to test/CodeGen/X86/fltused.ll: ; RUN: llc < %s -fast-isel-verbose -O0 -mtriple i686-pc-win32 | FileCheck %s --check-prefix WIN32 ; RUN: llc < %s -fast-isel-verbose -O0 -mtriple x86_64-pc-win32 | FileCheck %s --check-prefix WIN64 The addition of -O0 causes the test to fail for i686-pc-win32. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 01:58:39 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 07:58:39 +0000 Subject: [LLVMbugs] [Bug 11799] New: pretty-printing produces wrong lvalue cast Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11799 Bug #: 11799 Summary: pretty-printing produces wrong lvalue cast Product: clang Version: 3.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mm.5p4mbox at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Running "clang -cc1 -ast-print file.cpp" on following source: void fun(int& x); int main() { unsigned int y = 0; fun((int&)y); } Produces following fun call - fun((int)y) Printed code does not compile. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 02:03:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 08:03:16 +0000 Subject: [LLVMbugs] [Bug 11800] New: pretty-printing produces wrong argument list for constructor of template argument class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11800 Bug #: 11800 Summary: pretty-printing produces wrong argument list for constructor of template argument class Product: clang Version: 3.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mm.5p4mbox at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Running "clang -cc1 -ast-print file.cpp" on following source: template void fun() { S s(1,2); } Produces following wrong body for fun: template void fun() { S s(( 1,2 )); } Printed code works differently - instead of passing two arguments to S constructor, it passes one argument and uses "," as comma operator. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 02:06:07 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 08:06:07 +0000 Subject: [LLVMbugs] [Bug 11801] New: pretty-printing loses decimal point for double literals Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11801 Bug #: 11801 Summary: pretty-printing loses decimal point for double literals Product: clang Version: 3.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mm.5p4mbox at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Running "clang -cc1 -ast-print file.cpp" on following source: int main() { double x = 1/2.; } Produces following source: int main() { double x = 1 / 2; } Obviously x is not 0.5 anymore. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 06:35:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 12:35:42 +0000 Subject: [LLVMbugs] [Bug 11802] New: Assertion failed: (isPtrIV == IndVar->getType()->isPointerTy() && "IndVar type must match IVInit type"), function LinearFunctionTestReplace, file /usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp, line 159 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11802 Bug #: 11802 Summary: Assertion failed: (isPtrIV == IndVar->getType()->isPointerTy() && "IndVar type must match IVInit type"), function LinearFunctionTestReplace, file /usr/src/lib/clang/libllvmscalaropts/../../../contrib/ llvm/lib/Transforms/Scalar/IndVarSimplify.cpp, line 159 Product: clang Version: 3.0 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: c.kworr at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Happens on i386 host: CPU: AMD Athlon(tm) XP 2500+ (1833.95-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Family = 6 Model = a Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 When compiling last ghostscript 9.04 following happens: clang -DHAVE_MKSTEMP -DHAVE_FONTCONFIG -DHAVE_SETLOCALE -DHAVE_DBUS -O2 -pipe -fno-strict-aliasing -g -fPIC -DUPD_SIGNAL= 0 -I. -I/tmp/ports/usr/ports/print/ghostscript9/work/ghostscript-9.04/lcms/include -I/tmp/ports/usr/ports/print/ghostscript9/w ork/ghostscript-9.04/jasper/src/libjasper/include -I/usr/local/include/libpng -I/usr/local/include -I/usr/local/include/freety pe2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclar ation-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long" -O2 -pipe -fno-strict- aliasing -DUSE_LIBICONV_GNU -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/local/lib/ghostscript/9.04\" -I./soobj -I./base -DWHIC H_CMS="lcms" -o ./soobj/siscale.o -c ./base/siscale.c Assertion failed: (isPtrIV == IndVar->getType()->isPointerTy() && "IndVar type must match IVInit type"), function LinearFunction TestReplace, file /usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp, line 1597 . Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple i386-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name siscale.c -pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -target-cpu i486 -momit-leaf-frame-pointer -g -coverage-file ./soobj/siscale.o -resource-dir /usr/bin/../lib/clang/3.0 -D HAVE_MKSTEMP -D HAVE_FONTCONFIG -D HAVE_SETLOCAL E -D HAVE_DBUS -D UPD_SIGNAL=0 -D HAVE_STDINT_H -D GX_COLOR_INDEX_TYPE=unsigned long long -D USE_LIBICONV_GNU -D GS_DEVS_SHARED -D GS_DEVS_SHARED_DIR="/usr/local/lib/ghostscript/9.04" -D WHICH_CMS=lcms -I . -I /tmp/ports/usr/ports/print/ghostscript9/work/g hostscript-9.04/lcms/include -I /tmp/ports/usr/ports/print/ghostscript9/work/ghostscript-9.04/jasper/src/libjasper/include -I /u sr/local/include/libpng -I /usr/local/include -I /usr/local/include/freetype2 -I ./soobj -I ./base -fmodule-cache-path /tmp/clan g-module-cache -O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-ali asing -Wdeclaration-after-statement -fconst-strings -ferror-limit 19 -fmessage-length 128 -fno-builtin -fgnu-runtime -fobjc-runt ime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fno-common -fdiagnostics-show-option -fcolor-diagnostics -o ./soobj/sisc ale.o -x c ./base/siscale.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module './base/siscale.c'. 4. Running pass 'Loop Pass Manager' on function '@zoom_x' 5. Running pass 'Induction Variable Simplification' on basic block '%for.body20' clang: error: unable to execute command: Abort trap: 6 (core dumped) clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diag nostic information. clang: note: diagnostic msg: Preprocessed source(s) are located at: clang: note: diagnostic msg: /tmp/siscale-sPvTkk.i Preprocessed source is at http://limbo.xim.bz/siscale-sPvTkk.i FreeBSD clang version 3.0 (tags/RELEASE_30/final 145349) 20111210 Target: i386-unknown-freebsd9.0 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 Thu Jan 19 12:19:29 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 18:19:29 +0000 Subject: [LLVMbugs] [Bug 11803] New: Disregarding [except.handle]/p1 (catching incomplete types) leads to incorrect dynamic_cast Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11803 Bug #: 11803 Summary: Disregarding [except.handle]/p1 (catching incomplete types) leads to incorrect dynamic_cast Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hhinnant at apple.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Consider this code: #include struct A; void foo(); int main() { try { foo(); } catch (A& a) { } catch (...) { } } struct B {virtual ~B() {}}; struct A : B {}; void foo() { A a; B* bp = &a; assert(dynamic_cast(bp) != 0); } This asserts. But if you comment out the catch (A&) frame: // catch (A& a) // { // } It runs correctly. The issue: When clang sees the catch(A&) (and A is incomplete at this point) it lays down the wrong kind of type_info: a __class_type_info. And that never gets corrected. So when it comes time to do the dynamic_cast, later when A is complete, the dynamic_cast malfunctions because the type_info for A should be a __si_class_type_info. Without the correct type_info, the dynamic_cast malfunctions. 15.3 [except.handle]/p1 says that the original program is ill-formed (and clang does give a warning about it): 1 The exception-declaration in a handler describes the type(s) of exceptions that can cause that handler to be entered. The exception-declaration shall not denote an incomplete type, an abstract class type, or an rvalue reference type. The exception-declaration shall not denote a pointer or reference to an incomplete type, other than void*, const void*, volatile void*, or const volatile void*. The reason clang has this behavior is because of: http://llvm.org/bugs/show_bug.cgi?id=6527 The Itanium ABI says this about emitting type_info's for incomplete class types: This RTTI class may also be used for incomplete class types when referenced by a pointer RTTI, in which case it must be prevented from preempting the RTTI for the complete class type, for instance by emitting it as a static object (without external linkage). It appears that clang doesn't emit the incomplete type_info type as a static. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 12:30:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 18:30:16 +0000 Subject: [LLVMbugs] [Bug 11804] New: Assertion violation in EvaluateLValue for compound literal Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11804 Bug #: 11804 Summary: Assertion violation in EvaluateLValue for compound literal Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: twoodfin at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified const static short* OutputTable[] = { (short[]){1,2,3} }; generates an assertion violation when compiled with clang++: clang: ExprConstant.cpp:913: bool EvaluateLValue(const clang::Expr*, {anonymous}::LValue&, {anonymous}::EvalInfo&): Assertion `(E->isGLValue() || E->getType()->isFunctionType() || E->getType()->isVoidType() || isa(E)) && "can't evaluate expression as an lvalue"' failed. clang version 3.1 (trunk 143304) Target: x86_64-unknown-linux-gnu Thread model: posix gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) is happy with the 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 Thu Jan 19 14:39:43 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 20:39:43 +0000 Subject: [LLVMbugs] [Bug 11804] Assertion violation in EvaluateLValue for compound literal In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11804 Tom Woodfin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #2 from Tom Woodfin 2012-01-19 14:39:43 CST --- You're right. Fixed by 148493. Apologies for the outdated 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 Thu Jan 19 15:44:35 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 21:44:35 +0000 Subject: [LLVMbugs] [Bug 11795] Clang accepts direct constructor call In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11795 Jason Haslam changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Jason Haslam 2012-01-19 15:44:35 CST --- Okay so A::A is the injected class name, not the constructor name? That seems to match my best, albeit very limited, understanding of the standard. I'll go ahead and close this as invalid. For reference, the GCC PR was http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 17:30:38 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 23:30:38 +0000 Subject: [LLVMbugs] [Bug 11805] New: pretty-printing produces wrong definition of anonymous structure variable Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11805 Bug #: 11805 Summary: pretty-printing produces wrong definition of anonymous structure variable Product: clang Version: 3.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mm.5p4mbox at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Running "clang -cc1 -ast-print file.cpp" on following source: int main() { static const struct { int x; } t = { 1 }; } Produces wrong code that doesn't compile. It produces following: int main() { struct { int x; } static const struct t = { 1 }; } There shouldn't be "struct" keyword before "t" variable name. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 17:33:22 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 19 Jan 2012 23:33:22 +0000 Subject: [LLVMbugs] [Bug 11806] New: pretty-printing produces wrong cast in initialization code when many variables are defined in one statement Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11806 Bug #: 11806 Summary: pretty-printing produces wrong cast in initialization code when many variables are defined in one statement Product: clang Version: 3.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mm.5p4mbox at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Running "clang -cc1 -ast-print file.cpp" on following source: struct S; void fun(const void *a, const void *b) { struct S* A = (struct S*)a, *B = (struct S*)b; } Produces following code that does not compile: struct S; void fun(const void *a, const void *b) { struct S *A = (struct S *)a, *B = (*)b; } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 19:20:50 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 01:20:50 +0000 Subject: [LLVMbugs] [Bug 11799] pretty-printing produces wrong lvalue cast In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11799 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2012-01-19 19:20:50 CST --- *** This bug has been marked as a duplicate of bug 11806 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 19:21:00 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 01:21:00 +0000 Subject: [LLVMbugs] [Bug 11800] pretty-printing produces wrong argument list for constructor of template argument class In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11800 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2012-01-19 19:21:00 CST --- *** This bug has been marked as a duplicate of bug 11806 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 19:21:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 01:21:11 +0000 Subject: [LLVMbugs] [Bug 11801] pretty-printing loses decimal point for double literals In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11801 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2012-01-19 19:21:11 CST --- *** This bug has been marked as a duplicate of bug 11806 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 19:21:57 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 01:21:57 +0000 Subject: [LLVMbugs] [Bug 11805] pretty-printing produces wrong definition of anonymous structure variable In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11805 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2012-01-19 19:21:57 CST --- *** This bug has been marked as a duplicate of bug 11806 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 19:23:00 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 01:23:00 +0000 Subject: [LLVMbugs] [Bug 4221] -ast-print doesn't print tag definitions correctly In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=4221 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #3 from Chris Lattner 2012-01-19 19:23:00 CST --- *** This bug has been marked as a duplicate of bug 11806 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 19:23:10 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 01:23:10 +0000 Subject: [LLVMbugs] [Bug 7078] clang -ast-print output doesn't build In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7078 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2012-01-19 19:23:10 CST --- *** This bug has been marked as a duplicate of bug 11806 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 05:36:50 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 11:36:50 +0000 Subject: [LLVMbugs] [Bug 11809] New: --coverage writes the .gcda files to the wrong directory Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11809 Bug #: 11809 Summary: --coverage writes the .gcda files to the wrong directory Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: magnus.reftel at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7911 --> http://llvm.org/bugs/attachment.cgi?id=7911 Hello world + shell script that demonstrates the difference When a program built with gcc --coverage runs, the .gcda files are written to (subdirectories of) the directory where the binary resides. When a program built with clang --coverage runs, the .gcda files are written to (subdirectories of) the directory where the binary resides, unless the program called chdir. If the program called chdir, then the files are instead written to (subdirectories of) the directory to which the program changed. This means that it's not possible to predict where the .gcda files will end up, unless the calls to chdir that the program may make can be predicted. The attached test case builds a hello world program with Clang and GCC and runs if from different directories, with and without changing directory to illustrate the difference in behaviour. This problem was found in r148114. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 06:06:36 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 12:06:36 +0000 Subject: [LLVMbugs] [Bug 4162] missing important CXXFLAGS for GNU toolchain in llvm-config In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=4162 arrowdodger <6yearold at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |6yearold at gmail.com Resolution| |FIXED --- Comment #2 from arrowdodger <6yearold at gmail.com> 2012-01-20 06:06:36 CST --- The "-fpermissive" flag is not used anywhere anymore. The "-fvisibility-inlines-hidden" flag have been added to the CMake build in r148530. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 06:10:17 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 12:10:17 +0000 Subject: [LLVMbugs] [Bug 11810] New: Inline asm: "undef" rejected for 'i' constraint Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11810 Bug #: 11810 Summary: Inline asm: "undef" rejected for 'i' constraint Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified On the following testcase llc outputs: error: invalid operand for inline asm constraint 'i' It accepts the asm if "undef" is replaced by "0". I think undef should be accepted. target datalayout = "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-f128:128:128-n8:16:32:64" target triple = "x86_64--linux-gnu" define void @foo() { entry: call void asm "# bar on $0", "i,~{fpsr},~{flags}"(i32 undef) nounwind ret void } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 08:08:15 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 14:08:15 +0000 Subject: [LLVMbugs] [Bug 11811] New: Greedy Register Allocator taking a loooong time on module with many cleanups Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11811 Bug #: 11811 Summary: Greedy Register Allocator taking a loooong time on module with many cleanups Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7912 --> http://llvm.org/bugs/attachment.cgi?id=7912 Original C++ testcase This is the gcc testcase cleanup1.C (attached). At -O1 gcc takes less than 4 seconds to compile it, while dragonegg takes 20 minutes or so. Almost all of the time is spent in codegen, and almost all of that is in register allocation, namely Global Splitting. To reproduce, run llc on the attached gzipped .ll file. $ llc cleanup1.ll -time-passes ... ===-------------------------------------------------------------------------=== Register Allocation ===-------------------------------------------------------------------------=== Total Execution Time: 919.5335 seconds (920.2625 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 908.0848 ( 98.8%) 0.2160 ( 93.1%) 908.3008 ( 98.8%) 908.9710 ( 98.8%) Global Splitting 10.9647 ( 1.2%) 0.0160 ( 6.9%) 10.9807 ( 1.2%) 11.0408 ( 1.2%) Evict 0.1200 ( 0.0%) 0.0000 ( 0.0%) 0.1200 ( 0.0%) 0.1249 ( 0.0%) Spiller ... ===-------------------------------------------------------------------------=== ... Pass execution timing report ... ===-------------------------------------------------------------------------=== Total Execution Time: 929.9901 seconds (930.7424 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 919.4535 ( 98.9%) 0.2320 ( 56.9%) 919.6855 ( 98.9%) 920.4247 ( 98.9%) Greedy Register Allocator 2.8242 ( 0.3%) 0.0000 ( 0.0%) 2.8242 ( 0.3%) 2.8260 ( 0.3%) Simple Register Coalescing -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 08:17:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 14:17:24 +0000 Subject: [LLVMbugs] [Bug 11812] New: Error in llvm.usub.with.overflow.i32 intrinsic [ARM] Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11812 Bug #: 11812 Summary: Error in llvm.usub.with.overflow.i32 intrinsic [ARM] Product: libraries Version: 2.8 Platform: Other OS/Version: Linux Status: NEW Severity: release blocker Priority: P Component: LLVM assembly language parser AssignedTo: unassignedbugs at nondot.org ReportedBy: malvikus at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7914 --> http://llvm.org/bugs/attachment.cgi?id=7914 Test llvm.usub.with.overflow.i32 for unsigned overflow When I run simplified test (for testing llvm.usub.with.overflow.i32 intrinsic) I've got wrong result. This test: store i32 1073741824, i32* @R6 store i32 536870912, i32* @R5 %FIRST = load i32* @R6 %SECOND = load i32* @R5 %RESULT = call {i32, i1} @llvm.usub.with.overflow.i32(i32 %FIRST, i32 %SECOND) %CARRY = extractvalue {i32, i1} %RESULT, 1 %VALUE = extractvalue {i32, i1} %RESULT, 0 call i32 (i8*, ...)* @printf(i8* noalias getelementptr inbounds ([10 x i8]* @str_main_14, i64 0, i64 0), i1 %CARRY) call i32 (i8*, ...)* @printf(i8* noalias getelementptr inbounds ([10 x i8]* @str_main_14, i64 0, i64 0), i32 %VALUE) I've got wrong result - 0 in CARRY (should be 1 as unsigned overflow). This code generate following asm-code: add r1, r0, #-536870912 ; 0xe0000000 (in GDB) the same as add r1, r0, #14, 4 @ -536870912 (generated by llc) which is wrong as is losing carry flag. Should be following: adds r1, r0, #-536870912 How I've compiled: 1) llvm-as temp/test.ll -o temp/mycode.bc 2) llc -O0 temp/mycode.bc -o temp/mycode.s 3) arm-ololo-linux-gnueabi-gcc -O0 temp/mycode.s -o temp/mycode.llvm.exe -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 09:54:53 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 15:54:53 +0000 Subject: [LLVMbugs] [Bug 11760] llvm-cov crashes in llvm::GCOVFunction::read with trivial test case In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11760 Sean McBride changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 10:23:52 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 16:23:52 +0000 Subject: [LLVMbugs] [Bug 11771] Vectors shift operator broken In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11771 Erik Schnetter changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #10 from Erik Schnetter 2012-01-20 10:23:52 CST --- This problem seems corrected in clang version 3.1 (trunk 148489). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 10:24:25 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 16:24:25 +0000 Subject: [LLVMbugs] [Bug 11555] OpenCL shift counts can overflow In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11555 Erik Schnetter changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Erik Schnetter 2012-01-20 10:24:25 CST --- This problem seems corrected on clang version 3.1 (trunk 148489). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 10:34:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 16:34:24 +0000 Subject: [LLVMbugs] [Bug 11605] OpenCL operator && does not accept vector arguments In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11605 Erik Schnetter changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Erik Schnetter 2012-01-20 10:34:24 CST --- This seems to work in clang version 3.1 (trunk 148489). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 13:07:57 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 19:07:57 +0000 Subject: [LLVMbugs] [Bug 11750] [AVX2] incorrect code generated In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11750 Matt Pharr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Matt Pharr 2012-01-20 13:07:57 CST --- Confirmed fixed. Marking resolved/fixed. 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 Jan 20 13:34:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 19:34:16 +0000 Subject: [LLVMbugs] [Bug 11782] Bad cast in llvm::SCEVExpander::getAddRecExprPHILiterally In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11782 Andrew Trick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED AssignedTo|unassignedbugs at nondot.org |atrick at apple.com --- Comment #1 from Andrew Trick 2012-01-20 13:34:16 CST --- Fixed in r148535. Sorry, the checkin comments incorrectly states PR11783. --this was fixed after a long slog that addled my brain. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 13:49:38 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 19:49:38 +0000 Subject: [LLVMbugs] [Bug 11813] New: SmallVector protected constructor breaks clang SemaTemplateDeduction.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11813 Bug #: 11813 Summary: SmallVector protected constructor breaks clang SemaTemplateDeduction.cpp Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: chisophugis at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified compilation error output from Clang: SemaTemplateDeduction.cpp:1337:52: error: calling a protected constructor of class 'llvm::SmallVectorImpl' SmallVectorImpl DeducedOrig(0); ^ /home/sean/pg/others/llvm/include/llvm/ADT/SmallVector.h:275:12: note: declared protected here explicit SmallVectorImpl(unsigned N) ^ "git blame" pinpoints the change to this commit: commit 3feccbaaee2fe639fd089cdb78ad623f662a5796 Author: Benjamin Kramer Date: Fri Jan 20 16:39:46 2012 +0000 Protect SmallVectorImpl's constructor and a few other methods that aren't meant to be public. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 148550 91177308-0d34-0410-b5e6-96231b3b80d8 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 13:54:57 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 19:54:57 +0000 Subject: [LLVMbugs] [Bug 11813] SmallVector protected constructor breaks clang SemaTemplateDeduction.cpp In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11813 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |FIXED --- Comment #1 from Benjamin Kramer 2012-01-20 13:54:57 CST --- r148549 (one commit before r148550). Please make sure your llvm and clang checkouts are in sync. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 14:36:49 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 20:36:49 +0000 Subject: [LLVMbugs] [Bug 11814] New: Don't hardcode Andale Mono as the font Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11814 Bug #: 11814 Summary: Don't hardcode Andale Mono as the font Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: mohamed at bana.org.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Can someone please apply this patch: Index: lib/Rewrite/HTMLRewrite.cpp =================================================================== --- lib/Rewrite/HTMLRewrite.cpp (revision 146622) +++ lib/Rewrite/HTMLRewrite.cpp (working copy) @@ -292,7 +292,7 @@ " body { font-family:Helvetica, sans-serif; font-size:10pt }\n" " h1 { font-size:14pt }\n" " .code { border-collapse:collapse; width:100%; }\n" - " .code { font-family: \"Andale Mono\", monospace; font-size:10pt }\n" + " .code { font-family: \"Monospace\", monospace; font-size:10pt }\n" " .code { line-height: 1.2em }\n" " .comment { color: green; font-style: oblique }\n" " .keyword { color: blue }\n" I am not even sure why Andale Mono is hardcoded. On Linux when I view the output of scan-build it comes out horrible. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 14:40:10 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 20:40:10 +0000 Subject: [LLVMbugs] [Bug 11814] Don't hardcode Andale Mono as the font In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11814 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |FIXED --- Comment #1 from Ted Kremenek 2012-01-20 14:40:10 CST --- Fixed: r148567 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 15:24:57 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 21:24:57 +0000 Subject: [LLVMbugs] [Bug 11783] [LSR] Assertion `isa(LastIncExpr) && "expect recurrence at IV user"' failed In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11783 Andrew Trick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED AssignedTo|unassignedbugs at nondot.org |atrick at apple.com --- Comment #1 from Andrew Trick 2012-01-20 15:24:57 CST --- Fixed in r148572. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 16:40:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 22:40:24 +0000 Subject: [LLVMbugs] [Bug 11815] New: Segmentation fault assigning lambda to local with auto Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11815 Bug #: 11815 Summary: Segmentation fault assigning lambda to local with auto Product: clang Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: benjamin.kircher at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7915 --> http://llvm.org/bugs/attachment.cgi?id=7915 Preprocessed sources of example above Might be related to lambda expressions and auto type inference (see also bug #10943 and bug #10818). Not sure. Not even sure that this report is helpful. Code where it crashes is basically like this: #include #include void foo() { std::vector strvec; auto bar = [&](const std::string& str) { strvec.push_back(str); }; // <---- parser is here when crash happens } int main(int argc, char** argv) { foo(); return 0; } Version: Debian clang version 3.0-5 (tags/RELEASE_30/final) (based on LLVM 3.0) Target: i386-pc-linux-gnu Thread model: posix Dump: $ clang++ -std=c++0x -Wall foo.cpp foo.cpp:7:26: error: use of undeclared identifier 'str' strvec.push_back(str); ^ 0 libLLVM-3.0.so.1 0xb7194708 1 libLLVM-3.0.so.1 0xb7194d9c 2 0xb77f3400 __kernel_sigreturn + 0 3 clang 0x086b8b83 clang::Sema::DeduceAutoType(clang::TypeSourceInfo*, clang::Expr*, clang::TypeSourceInfo*&) + 35 4 clang 0x08516e1d clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) + 2477 5 clang 0x0845e977 clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&) + 1623 6 clang 0x084625a4 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1300 7 clang 0x08467c23 clang::Parser::ParseSimpleDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, bool, clang::Parser::ForRangeInit*) + 803 8 clang 0x08467e42 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 178 9 clang 0x08438f9d clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 413 10 clang 0x08436244 clang::Parser::ParseCompoundStatementBody(bool) + 1652 11 clang 0x08436ba4 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 164 12 clang 0x084536f9 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1049 13 clang 0x08462306 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 630 14 clang 0x0844e808 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 216 15 clang 0x0844ef66 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 742 16 clang 0x084511b6 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 3670 17 clang 0x08451904 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 180 18 clang 0x08424318 clang::ParseAST(clang::Sema&, bool) + 296 19 clang 0x081ffe27 clang::ASTFrontendAction::ExecuteAction() + 103 20 clang 0x082f5712 clang::CodeGenAction::ExecuteAction() + 66 21 clang 0x08200783 clang::FrontendAction::Execute() + 275 22 clang 0x081e6f25 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 325 23 clang 0x081ce926 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1126 24 clang 0x081c729c cc1_main(char const**, char const**, char const*, void*) + 876 25 clang 0x081c4935 main + 629 26 libc.so.6 0xb61d2e46 __libc_start_main + 230 27 clang 0x081c6ddd Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name foo.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.21.90.20111025 -momit-leaf-frame-pointer -resource-dir /usr/bin/../lib/clang/3.0 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/include/c++/4.6 -internal-isystem /usr/include/c++/4.6/i486-linux-gnu -internal-isystem /usr/include/c++/4.6/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include/i486-linux-gnu -internal-externc-isystem /usr/include -Wall -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 179 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/foo-RrGMlX.o -x c++ foo.cpp 1. foo.cpp:8:6: current parser token ';' 2. foo.cpp:4:12: parsing function body 'foo' 3. foo.cpp:4:12: in compound statement ('{}') clang: error: unable to execute command: 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 Fri Jan 20 16:53:58 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 22:53:58 +0000 Subject: [LLVMbugs] [Bug 11815] Segmentation fault assigning lambda to local with auto In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11815 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |WORKSFORME --- Comment #1 from Eli Friedman 2012-01-20 16:53:58 CST --- Lambda support is completely broken in 3.0. We should fail more cleanly on trunk if you try to use a lambda; complete lambda support is in progress. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 17:51:44 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 23:51:44 +0000 Subject: [LLVMbugs] [Bug 11816] New: 32-bit Linux Fedora Core 16 c99 mode: cannot find crt1.o crti.o -lgcc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11816 Bug #: 11816 Summary: 32-bit Linux Fedora Core 16 c99 mode: cannot find crt1.o crti.o -lgcc Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In compiling a C99 program with clang 2.9-4 on 32-bit Intel Core2 Duo Linux (Fedora Core 16), I get problems with the linker: clang version 2.9 (tags/RELEASE_29/final) Target: i386-redhat-linux-gnu Thread model: posix "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o a.out crt1.o crti.o crtbegin.o -L -L/../../.. tflt2int.o /lindata/fpcets/clang/294/c/support.a -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o crtn.o /usr/bin/ld: cannot find crt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory /usr/bin/ld: cannot find crtbegin.o: No such file or directory /usr/bin/ld: cannot find -lgcc /usr/bin/ld: cannot find -lgcc_s clang: error: linker command failed with exit code 1 (use -v to see invocation) I have no such problem with Fedora Core 15 (but it has clang 2.8-14) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 17:51:58 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 20 Jan 2012 23:51:58 +0000 Subject: [LLVMbugs] [Bug 11817] New: [Sparc] error in translated Sparc assembly code regarding branching Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11817 Bug #: 11817 Summary: [Sparc] error in translated Sparc assembly code regarding branching 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: sudida21 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7916 --> http://llvm.org/bugs/attachment.cgi?id=7916 byte 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 Jan 20 18:23:41 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 00:23:41 +0000 Subject: [LLVMbugs] [Bug 11802] Assertion failed: (isPtrIV == IndVar->getType()->isPointerTy() && "IndVar type must match IVInit type"), function LinearFunctionTestReplace, file /usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp, line 159 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11802 Andrew Trick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED AssignedTo|unassignedclangbugs at nondot. |atrick at apple.com |org | --- Comment #2 from Andrew Trick 2012-01-20 18:23:41 CST --- I verified that clang trunk compiles this case using: /extra/mirror/build/Debug+Asserts/bin/clang -cc1 -triple i386-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name siscale.c -pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -target-cpu i486 -momit-leaf-frame-pointer -g -coverage-file ./soobj/siscale.o -resource-dir /usr/bin/../lib/clang/3.0 -O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fconst-strings -ferror-limit 19 -fmessage-length 128 -fno-builtin -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fno-common -fdiagnostics-show-option -fcolor-diagnostics -o siscale.o -x c siscale-sPvTkk.i This was probably fixed in r143183, well before the release, but wasn't merged into the release branch. At the time, I was concerned about disrupting the release cycle, but now that I understand the process better, I definitely should have merged it in knowing that people would likely hit 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 Fri Jan 20 18:25:53 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 00:25:53 +0000 Subject: [LLVMbugs] [Bug 11818] New: Debug info broken, gdb can't find value of variables (value optimized out) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11818 Bug #: 11818 Summary: Debug info broken, gdb can't find value of variables (value optimized out) Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: jonathan+llvm at pinacea.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7918 --> http://llvm.org/bugs/attachment.cgi?id=7918 Source test program without right debug info I've found a bug when compiling C code (without optimization), I can set breakpoint but I can't get a correct or any value sometimes from the local variables of the function or from the arguments. Quick example : I break into a function declared like this : static bool function1(int count, char *text) gdb$ info locals status = 128 gdb$ info args count = text = I found this when using -faddress-sanitizer on another program (see the discussion from the address-sanitizer mailing-list http://groups.google.com/group/address-sanitizer/t/cea13a8b4a2fc0ab) Attached is the source of a test program that doesn't show values when breaking in debugger. For me it's mostly triggered when using -faddress-sanitizer when compiling. I was using latest r148535 on a Linux system. (I didn't know exactly where to file this bug, Product/Component) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 18:35:38 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 00:35:38 +0000 Subject: [LLVMbugs] [Bug 3596] bugpoint doesn't notice that program Aborts In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=3596 Andrew Trick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |atrick at apple.com Resolution| |FIXED AssignedTo|unassignedbugs at nondot.org |atrick at apple.com --- Comment #5 from Andrew Trick 2012-01-20 18:35:38 CST --- I think this was fixed by r131186 and 131780. If not, please reopen. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 18:40:14 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 00:40:14 +0000 Subject: [LLVMbugs] [Bug 11816] 32-bit Linux Fedora Core 16 c99 mode: cannot find crt1.o crti.o -lgcc In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11816 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #1 from Eli Friedman 2012-01-20 18:40:14 CST --- Please try a more recent version 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 Fri Jan 20 19:09:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 01:09:16 +0000 Subject: [LLVMbugs] [Bug 11819] New: [AVX] incorrect code for shuffles Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11819 Bug #: 11819 Summary: [AVX] incorrect code for shuffles Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7919 --> http://llvm.org/bugs/attachment.cgi?id=7919 test case See the attached test case which does a permutation of an 8-wide i32 vector; until the checkin below, it generated the following output: % llc -mattr=+avx t.ll -o t.o -filetype=obj && g++ -m64 t.cpp t.o && ./a.out result[0] = 3 (expected 3) result[1] = 4 (expected 4) result[2] = 5 (expected 5) result[3] = 6 (expected 6) result[4] = 7 (expected 7) result[5] = 8 (expected 8) result[6] = 1 (expected 1) result[7] = 2 (expected 2) With top-of-tree, it generates incorrect values: result[0] = 3 (expected 3) result[1] = 4 (expected 4) result[2] = 1 (expected 5) *** ERROR *** result[3] = 2 (expected 6) *** ERROR *** result[4] = 3 (expected 7) *** ERROR *** result[5] = 4 (expected 8) *** ERROR *** result[6] = 1 (expected 1) result[7] = 2 (expected 2) Bisecting tells me that r148537 is the commit that broke this: Author: Craig Topper Date: Fri Jan 20 09:29:03 2012 +0000 Improve 256-bit shuffle splitting to allow 2 sources in each 128-bit lane. As long as only a single lane of the source is used in the lane in the destination. This makes the splitting match much closer to what happens with 256-bit shuffles when AVX is disabled and only 128-bit XMM is allowed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 148537 91177308-0d34-0410-b5e6-96231b3b80d8 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 19:26:32 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 01:26:32 +0000 Subject: [LLVMbugs] [Bug 11820] New: clang CFG analysis misses potentially-evaluated operands in cases involving VLAs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11820 Bug #: 11820 Summary: clang CFG analysis misses potentially-evaluated operands in cases involving VLAs Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: kremenek at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified clang's CFG analysis misses potentially-evaluated operands in some cases involving VLAs. See test/Sema/vla-2.c in clang for a testcase. AnalysisBasedWarnings::IssueWarnings works around this issue by failing out if it tries to check whether an expression that isn't part of the CFG is reachable. r138372 was a step in the wrong direction, but there are other related issues. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 21:09:45 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 03:09:45 +0000 Subject: [LLVMbugs] [Bug 11821] New: missed load widening opportunity Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11821 Bug #: 11821 Summary: missed load widening opportunity Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: kcc at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I was trying to figure out how to fix the AddressSanitizer false positive cause by load widening. http://code.google.com/p/address-sanitizer/issues/detail?id=20 I noticed that the effect of GVN is rather unstable. The code "x[16] + x[21]" gets load-widened while "x[21] + x[16]" does not. Looks like in the first case the second load is recognized as a dependency of the first load, and in second case -- not. clang r148551, linux 64-bit. % cat gvn.c void init(char*); int GVN1() { char x[22]; init(x); return x[16] + x[21]; } int GVN2() { char x[22]; init(x); return x[21] + x[16]; } % clang -O2 -S -emit-llvm -o - gvn.c 2>&1 | grep "define\|load" define i32 @GVN1() nounwind uwtable { %1 = load i64* %0, align 16 define i32 @GVN2() nounwind uwtable { %0 = load i8* %arrayidx, align 1, !tbaa !0 %1 = load i8* %arrayidx1, align 16, !tbaa !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 Jan 20 22:16:15 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 04:16:15 +0000 Subject: [LLVMbugs] [Bug 7409] Extra errors after bad typedef In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7409 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Nick Lewycky 2012-01-20 22:16:15 CST --- This looks fixed: pr7409.cc:3:20: error: type 'long' cannot be used prior to '::' because it has no members typedef typename T::foo foo; ^ pr7409.cc:7:11: note: in instantiation of template class 'Foo' requested here Foo f; ^ 1 error generated. One real error about the misuse of T = long and a note for the instantiation stack. This is still a little sub-par because I think the error message should print out that T was long in the message text, but the original topic of this bug is 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 Sat Jan 21 01:04:43 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 07:04:43 +0000 Subject: [LLVMbugs] [Bug 11822] New: Clang doesn't check that "#pragma GCC visibility push" and "pragma GCC visibility pop" are matched Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11822 Bug #: 11822 Summary: Clang doesn't check that "#pragma GCC visibility push" and "pragma GCC visibility pop" are matched Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified gcc rejects a file with just #pragma GCC visibility pop but we accept it. GCC accepts namespace foo __attribute__((visibility("default"))) { #pragma GCC visibility push(default) } #pragma GCC visibility pop but it is probably safe to reject. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 03:54:54 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 09:54:54 +0000 Subject: [LLVMbugs] [Bug 11823] New: dragonegg port to mingw causes link error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11823 Bug #: 11823 Summary: dragonegg port to mingw causes link error Product: dragonegg Version: 3.0 Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: New Bugs AssignedTo: baldrick at free.fr ReportedBy: ralphengels at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Based on some work by xunxun i ported dragonegg to mingw but im running into some problems. small snip from a wxwidgets compile. gcc_mswudll\monodll_taskbar.o:fake:(.text+0x52): undefined reference to `RegisterWindowMessageW at 4@4' gcc_mswudll\monodll_taskbar.o:fake:(.text+0x66): undefined reference to `RegisterWindowMessageW at 4@4' what happens is that the plugin causes the symbols to have double at's at the end and linking fails. The funny thing is that the 64 bit mingw works so im a bit lost. I use gcc-4.6.2 as base for the plugin. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 09:37:56 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 21 Jan 2012 15:37:56 +0000 Subject: [LLVMbugs] [Bug 11819] [AVX] incorrect code for shuffles In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11819 Matt Pharr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Matt Pharr 2012-01-21 09:37:56 CST --- Confirmed! Marking resolved/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 Sat Jan 21 18:01:22 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 22 Jan 2012 00:01:22 +0000 Subject: [LLVMbugs] [Bug 11824] New: Cross compilation on linux close to impossible Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11824 Bug #: 11824 Summary: Cross compilation on linux close to impossible Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: lu_zero at gentoo.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7921 --> http://llvm.org/bugs/attachment.cgi?id=7921 Half complete poc The current clang doesn't seem to use the host triple properly when it tries to get the crt stubs. I started to fix them so chost-clang test.c can work as supposed. I'm currently lost with some path generation armv7a-unknown-linux-gnueabi-clang -v test.c --sysroot=/usr/armv7a-unknown-linux-gnueabi/ /usr/armv7a-unknown-linux-gnueabi/ clang version 3.0 (tags/RELEASE_30/final) Target: armv7a-unknown-linux-gnueabi Thread model: posix /usr/armv7a-unknown-linux-gnueabi/ /usr/armv7a-unknown-linux-gnueabi//usr/lib/crt1.o /usr/armv7a-unknown-linux-gnueabi/ /usr/armv7a-unknown-linux-gnueabi//usr/lib/crti.o /usr/armv7a-unknown-linux-gnueabi/ /usr/armv7a-unknown-linux-gnueabi//usr/lib/crtbegin.o "/usr/bin/clang" -cc1 -triple armv7-unknown-linux-gnueabi -S -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-abi aapcs-linux -target-cpu cortex-a8 -mfloat-abi soft -target-feature +soft-float-abi -target-linker-version 2.21.1 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.0 -isysroot /usr/armv7a-unknown-linux-gnueabi/ -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/armv7a-unknown-linux-gnueabi//usr/local/include -internal-isystem /usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/armv7a-unknown-linux-gnueabi//usr/include -internal-externc-isystem /usr/armv7a-unknown-linux-gnueabi//usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include -ferror-limit 19 -fmessage-length 80 -fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-8otd7j.s -x c test.c clang -cc1 version 3.0 based upon llvm 3.0 hosted on x86_64-pc-linux-gnu ignoring nonexistent directory "/usr/armv7a-unknown-linux-gnueabi//usr/local/include" ignoring nonexistent directory "/usr/armv7a-unknown-linux-gnueabi//usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include" #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/clang/3.0/include /usr/armv7a-unknown-linux-gnueabi//usr/include End of search list. "/usr/bin/armv7a-unknown-linux-gnueabi-as" -mfpu=neon -o /tmp/test-C14jd9.o /tmp/test-8otd7j.s "/usr/bin/armv7a-unknown-linux-gnueabi-ld" --sysroot=/usr/armv7a-unknown-linux-gnueabi/ -X --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /lib/ld-linux.so.3 -o a.out /usr/armv7a-unknown-linux-gnueabi//usr/lib/crt1.o /usr/armv7a-unknown-linux-gnueabi//usr/lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/crtbegin.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../armv7a-unknown-linux-gnueabi/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../.. -L/usr/armv7a-unknown-linux-gnueabi//lib -L/usr/armv7a-unknown-linux-gnueabi//usr/lib /tmp/test-C14jd9.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/crtend.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../lib64/crtn.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/crtbegin.o: file not recognized: File format not recognized clang: error: linker command failed with exit code 1 (use -v to see invocation) clang -v -ccc-host-triple armv7a-unknown-linux-gnueabi test.c --sysroot=/usr/armv7a-unknown-linux-gnueabi//usr/armv7a-unknown-linux-gnueabi/ clang version 3.0 (tags/RELEASE_30/final) Target: armv7a-unknown-linux-gnueabi Thread model: posix /usr/armv7a-unknown-linux-gnueabi/ /usr/armv7a-unknown-linux-gnueabi//usr/lib/crt1.o /usr/armv7a-unknown-linux-gnueabi/ /usr/armv7a-unknown-linux-gnueabi//usr/lib/crti.o /usr/armv7a-unknown-linux-gnueabi/ /usr/armv7a-unknown-linux-gnueabi//usr/lib/crtbegin.o "/usr/bin/clang" -cc1 -triple armv7-unknown-linux-gnueabi -S -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-abi aapcs-linux -target-cpu cortex-a8 -mfloat-abi soft -target-feature +soft-float-abi -target-linker-version 2.21.1 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.0 -isysroot /usr/armv7a-unknown-linux-gnueabi/ -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/armv7a-unknown-linux-gnueabi//usr/local/include -internal-isystem /usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/armv7a-unknown-linux-gnueabi//usr/include -internal-externc-isystem /usr/armv7a-unknown-linux-gnueabi//usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include -ferror-limit 19 -fmessage-length 80 -fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-5rVpdW.s -x c test.c clang -cc1 version 3.0 based upon llvm 3.0 hosted on x86_64-pc-linux-gnu ignoring nonexistent directory "/usr/armv7a-unknown-linux-gnueabi//usr/local/include" ignoring nonexistent directory "/usr/armv7a-unknown-linux-gnueabi//usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include" #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/clang/3.0/include /usr/armv7a-unknown-linux-gnueabi//usr/include End of search list. "/usr/bin/armv7a-unknown-linux-gnueabi-as" -mfpu=neon -o /tmp/test-N6lSSB.o /tmp/test-5rVpdW.s "/usr/bin/armv7a-unknown-linux-gnueabi-ld" --sysroot=/usr/armv7a-unknown-linux-gnueabi/ -X --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /lib/ld-linux.so.3 -o a.out /usr/armv7a-unknown-linux-gnueabi//usr/lib/crt1.o /usr/armv7a-unknown-linux-gnueabi//usr/lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/crtbegin.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../armv7a-unknown-linux-gnueabi/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../.. -L/usr/armv7a-unknown-linux-gnueabi//lib -L/usr/armv7a-unknown-linux-gnueabi//usr/lib /tmp/test-N6lSSB.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/crtend.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../lib64/crtn.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/crtbegin.o: file not recognized: File format not recognized Part of the patch is similar to something crafted for freebsd/netbsd and possibly could be generalized for those targets as well. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 19:06:41 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 22 Jan 2012 01:06:41 +0000 Subject: [LLVMbugs] [Bug 11825] New: SimplifyCFG phi and getelementptr crash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11825 Bug #: 11825 Summary: SimplifyCFG phi and getelementptr crash Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Transformation Utilities AssignedTo: unassignedbugs at nondot.org ReportedBy: empann at hotmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7922 --> http://llvm.org/bugs/attachment.cgi?id=7922 Test case that crashes SimplifyCFG The optimizer crashes in SimplifyCFG when it tries to optimize code not reachable. I am generating IR for an LTrim function (remove leading spaces in strings), which the SimplifyCFG fails on cases when the string is empty. If I would implement the same function in C++, it would look like this: struct String { unsigned char* ptr; int offset, len; }; inline String trim(unsigned char* orig_ptr, int offset, int len){ unsigned char* ptr = orig_ptr + offset; while(len > 0 && *ptr <= ' '){ offset++; len--; ptr++; } String a = {ptr, offset, len}; return a; } As everything is inlined, len can in some cases be 0 (or become 0 after optimizations). The ptr++ instruction is a GEP-instruction with a PHI-node as operand, but as the PHI-node gets simplified to only have one incoming (because the loop is never entered, since len=0), it gets replaced, resulting in a GEP-instruction like this during the SimplifyCFG-pass: %ptr = getelementptr i8* %ptr, i64 1 which is quite bad. Note that everything happens during the first pass (SimplifyCFG). When that intstruction gets inspected, in the end Value::isDereferenceablePointer gets called that calls itself over and over until stack overflow... Running "opt -O1 infrek.ll" results in an endless recursion: (gdb) bt #0 llvm::Value::isDereferenceablePointer (this=0x12ae970) at Value.cpp:374 #1 0x0000000000c37034 in llvm::Value::isDereferenceablePointer (this=0x12ae970) at Value.cpp:374 #2 0x0000000000c37034 in llvm::Value::isDereferenceablePointer (this=0x12ae970) at Value.cpp:374 #3 0x0000000000c37034 in llvm::Value::isDereferenceablePointer (this=0x12ae970) at Value.cpp:374 #4 0x0000000000c37034 in llvm::Value::isDereferenceablePointer (this=0x12ae970) at Value.cpp:374 #5 0x0000000000c37034 in llvm::Value::isDereferenceablePointer (this=0x12ae970) at Value.cpp:374 #6 0x0000000000c37034 in llvm::Value::isDereferenceablePointer (this=0x12ae970) at Value.cpp:374 #7 0x0000000000c37034 in llvm::Value::isDereferenceablePointer (this=0x12ae970) at Value.cpp:374 #8 0x0000000000a8b446 in llvm::isSafeToSpeculativelyExecute (V=0x12aecb8, TD=0x0) at ValueTracking.cpp:1920 #9 0x000000000092135c in DominatesMergePoint (V=0x12aecb8, BB=0x12ae430, AggressiveInsts=0x7fffffffce30, CostRemaining=@0x7fffffffcef0) at SimplifyCFG.cpp:300 #10 0x00000000009213e7 in DominatesMergePoint (V=0x12aed70, BB=0x12ae430, AggressiveInsts=0x7fffffffce30, CostRemaining=@0x7fffffffcef0) at SimplifyCFG.cpp:313 #11 0x0000000000925660 in FoldTwoEntryPHINode (PN=0x12aee70, TD=0x12b0230) at SimplifyCFG.cpp:1270 #12 0x000000000092c5cf in run (this=0x7fffffffd1a0, BB=0x12ae430) at SimplifyCFG.cpp:2935 #13 0x000000000092c8e2 in llvm::SimplifyCFG (BB=0x12ae430, TD=0x12b0230) at SimplifyCFG.cpp:2969 #14 0x00000000008286aa in IterativeSimplifyCFG (F=..., TD=0x12b0230) at SimplifyCFGPass.cpp:295 #15 0x000000000082876c in runOnFunction (this=0x12b5090, F=...) at SimplifyCFGPass.cpp:312 #16 0x0000000000c1c7fe in llvm::FPPassManager::runOnFunction (this=0x12b0070, F=...) at PassManager.cpp:1518 #17 0x0000000000c1c4f0 in llvm::FunctionPassManagerImpl::run (this=0x12afd20, F=...) at PassManager.cpp:1468 #18 0x0000000000c1c19b in llvm::FunctionPassManager::run (this=0x12ae1d0, F=...) at PassManager.cpp:1397 #19 0x00000000006d7fcf in main (argc=3, argv=0x7fffffffd6d8) at opt.cpp:688 I attach the infrek.ll file which I have tried to reduce as much as possible. I am using LLVM from trunk that is built today (2012-01-21). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 23:08:26 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 22 Jan 2012 05:08:26 +0000 Subject: [LLVMbugs] [Bug 11826] New: inserting into a map, int> doesn't parse in microsoft mode with msvc2010's c++ library Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11826 Bug #: 11826 Summary: inserting into a map, int> doesn't parse in microsoft mode with msvc2010's c++ library Product: clang Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified #include using namespace std; void f() { map, int> m; pair p(3, 4); m[p] = 5; } C:\src\chrome\src>c:\src\llvm-build\bin\Release\clang.exe -fsyntax-only foo.cc In file included from foo.cc:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\map:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtree:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xfunctional:7: In file included from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xstring:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory:8: In file included from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility:8: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility:149:5: error: call to deleted constructor of 'const std::pair' : first(_Val1), second(_STD move(_Val2)) ^ ~~~~~ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility:231:5: note: in instantiation of member function 'std::_Pair_base, int>::_Pair_base' requested here : _Mybase(_Val1, ^ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\map:215:5: note: in instantiation of member function 'std::pair, int>::pair' requested here value_type(_Keyval, mapped_type())); ^ foo.cc:7:4: note: in instantiation of member function 'std::map, int, std::less >, std::allocator, int> > >::operator[]' requested here m[p] = 5; ^ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility:172:9: note: function has been explicitly marked deleted here struct pair ^ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility:143:5: error: call to deleted constructor of 'const std::pair' : first(_STD move(_Val1)), ^ ~~~~~~~~~~~~~~~~ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility:253:5: note: in instantiation of member function 'std::_Pair_base, int>::_Pair_base' requested here : _Mybase(_STD forward<_Other1>(_Right.first), ^ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory:202:30: note: in instantiation of function template specialization 'std::pair, int>::pair, int>' requested here ::new ((void _FARQ *)_Ptr) _Ty(_STD forward<_Ty>(_Val)); ^ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory:280:9: note: in instantiation of member function 'std::allocator, int> >::construct' requested here _Alval.construct(_Pdest, _STD forward<_Ty2>(_Src)); ^ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtree:591:3: note: in instantiation of function template specialization 'std::_Cons_val, int> >, std::pair, int>, std::pair, int> >' requested here _Cons_val(this->_Alval, _STD addressof(this->_Myval(_Wherenode)), ^ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtree:767:10: note: in instantiation of function template specialization 'std::_Tree_val, int, std::less >, std::allocator, int> >, false> >::_Buynode, int> >' requested here this->_Buynode(_STD forward<_Valty>(_Val)))); ^ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\map:214:19: note: in instantiation of function template specialization 'std::_Tree, int, std::less >, std::allocator, int> >, false> >::insert, int> >' requested here _Where = this->insert(_Where, ^ foo.cc:7:4: note: in instantiation of member function 'std::map, int, std::less >, std::allocator, int> > >::operator[]' requested here m[p] = 5; ^ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility:172:9: note: function has been explicitly marked deleted here struct pair ^ 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 Sun Jan 22 04:35:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 22 Jan 2012 10:35:24 +0000 Subject: [LLVMbugs] [Bug 11827] New: cast in LLVM-3.0 typename cast_retty::ret_type llvm::cast(llvm::Value *const &): Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11827 Bug #: 11827 Summary: cast in LLVM-3.0 typename cast_retty::ret_type llvm::cast(llvm::Value *const &): Product: clang Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tyom_88 at mail.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified clang: /home/artyom/llvm-3.0/llvm/include/llvm/Support/Casting.h:194: typename cast_retty::ret_type llvm::cast(llvm::Value *const &): Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. 0 clang 0x000000000198681f 1 clang 0x0000000001986d39 2 libpthread.so.0 0x00007f7e08c69060 3 libc.so.6 0x00007f7e07f4b3a5 gsignal + 53 4 libc.so.6 0x00007f7e07f4eb0b abort + 379 5 libc.so.6 0x00007f7e07f43d4d __assert_fail + 221 6 clang 0x000000000169e4ee 7 clang 0x00000000018f1fcf llvm::FPPassManager::runOnFunction(llvm::Function&) + 351 8 clang 0x00000000018f22bb llvm::FPPassManager::runOnModule(llvm::Module&) + 75 9 clang 0x00000000018f240b llvm::MPPassManager::runOnModule(llvm::Module&) + 283 10 clang 0x00000000018f29d1 llvm::PassManagerImpl::run(llvm::Module&) + 289 11 clang 0x00000000018f2eea llvm::PassManager::run(llvm::Module&) + 10 12 clang 0x00000000007ccb3e clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 4798 13 clang 0x00000000007cb077 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 263 14 clang 0x00000000008d7d19 clang::ParseAST(clang::Sema&, bool) + 441 15 clang 0x00000000007ca571 clang::CodeGenAction::ExecuteAction() + 769 16 clang 0x00000000006ab177 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 967 17 clang 0x0000000000695b30 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2848 18 clang 0x000000000068d932 cc1_main(char const**, char const**, char const*, void*) + 5650 19 clang 0x0000000000691dd5 main + 757 20 libc.so.6 0x00007f7e07f3630d __libc_start_main + 237 21 clang 0x000000000068c25d Stack dump: 0. Program arguments: /home/artyom/llvm-3.0/build/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name sqlite3.c -mrelocation-model static -flattening -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.53.20110810 -momit-leaf-frame-pointer -coverage-file sqlite3.bc -resource-dir /home/artyom/llvm-3.0/build/bin/../lib/clang/3.0 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /home/artyom/llvm-3.0/build/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /usr/include -ferror-limit 19 -fmessage-length 168 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o sqlite3.bc -x c sqlite3.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'Function Pass Manager' on module 'sqlite3.c'. 4. Running pass 'Flattening control flow' on function '@sqlite3VdbeExec' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Preprocessed source(s) are located at: clang: note: diagnostic msg: /tmp/sqlite3-0eqrHk.i -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 22 05:12:10 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 22 Jan 2012 11:12:10 +0000 Subject: [LLVMbugs] [Bug 11824] Cross compilation on linux close to impossible In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11824 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |asl at math.spbu.ru Resolution| |DUPLICATE --- Comment #1 from Anton Korobeynikov 2012-01-22 05:12:10 CST --- Yes, this is well-known problem. The proper solution is the so-called 'universal driver'. *** This bug has been marked as a duplicate of bug 4127 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 22 05:13:45 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 22 Jan 2012 11:13:45 +0000 Subject: [LLVMbugs] [Bug 11827] cast in LLVM-3.0 typename cast_retty::ret_type llvm::cast(llvm::Value *const &): In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11827 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |asl at math.spbu.ru Resolution| |INVALID --- Comment #1 from Anton Korobeynikov 2012-01-22 05:13:45 CST --- Looks like the bug of the custom pass ("Flattening control flow"). From ML it's clear that it's doing something like cast(Val), where Val is just 'unsigned'. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 22 06:19:23 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 22 Jan 2012 12:19:23 +0000 Subject: [LLVMbugs] [Bug 8226] [Unit Test][SupportTests.CastingTest.cast] Failure: Incorrect results In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8226 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from NAKAMURA Takumi 2012-01-22 06:19:23 CST --- Applied in r148659. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 22 06:44:39 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 22 Jan 2012 12:44:39 +0000 Subject: [LLVMbugs] [Bug 11828] New: new warning in llvm-c/Core.h Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11828 Bug #: 11828 Summary: new warning in llvm-c/Core.h Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: eliben at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Introduced in r148553, new enum value for LLVMAtrribute: LLVMAddressSafety = 1ULL << 32 On Visual Studio 2008, 32-bit build, this generates a warning: warning C4341: 'LLVMAddressSafety' : signed value is out of range for enum constant C:\work\llvm_trunk\include\llvm-c\Core.h 123 Indeed, 1 << 32 is out of range of an enum in a 32-bit build. Enums are not guaranteed to be able to hold anything larger than an int. This warning may be indicative of a real problem in client code of llvm-c which attempts to use this enum -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 22 18:05:34 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 00:05:34 +0000 Subject: [LLVMbugs] [Bug 11825] SimplifyCFG phi and getelementptr crash In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11825 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nicholas at mxc.ca Resolution| |FIXED --- Comment #1 from Nick Lewycky 2012-01-22 18:05:34 CST --- Fixed in r148671! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 22 18:30:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 00:30:11 +0000 Subject: [LLVMbugs] [Bug 11829] New: Assertion in register scavenger Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11829 Bug #: 11829 Summary: Assertion in register scavenger Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7927 --> http://llvm.org/bugs/attachment.cgi?id=7927 Testcase Consider the attached .ll file. It triggers an assertion in register scavenger (and machine code verifier error) regardless whether copyprop pass enabled or not. To reproduce: $ llc bugpoint-reduced-simplified.ll -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 22 19:38:31 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 01:38:31 +0000 Subject: [LLVMbugs] [Bug 7895] c++ crash initializing incomplete array type In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7895 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #2 from Eli Friedman 2012-01-22 19:38:31 CST --- No, looks like it got fixed along the 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 Jan 22 21:19:49 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 03:19:49 +0000 Subject: [LLVMbugs] [Bug 11826] inserting into a map, int> doesn't parse with msvc2010's c++ library (issue with rvalue references and implicitly deleted constructors) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11826 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Nico Weber 2012-01-22 21:19:49 CST --- r148675 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 22 21:48:04 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 03:48:04 +0000 Subject: [LLVMbugs] [Bug 11785] llvm linker fails to link code because of a type problem. caused by revision 146932 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11785 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Rafael ?vila de Esp?ndola 2012-01-22 21:48:04 CST --- I don't think the root problem has been fixed, but 148676 fixes a non determinism and hides this bug for me. Please do open a new one if you see a crash like 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 Sun Jan 22 23:52:07 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 05:52:07 +0000 Subject: [LLVMbugs] [Bug 11791] Support pseudodestructors on void in microsoft mode In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11791 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Nico Weber 2012-01-22 23:52:07 CST --- r148682 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 02:25:23 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 08:25:23 +0000 Subject: [LLVMbugs] [Bug 11830] New: Build with -DCMAKE_SKIP_RPATH=ON -DBUILD_SHARED_LIBS=ON is broken Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11830 Bug #: 11830 Summary: Build with -DCMAKE_SKIP_RPATH=ON -DBUILD_SHARED_LIBS=ON is broken Product: Build scripts Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: cmake AssignedTo: unassignedbugs at nondot.org ReportedBy: ojab at ojab.ru CC: llvmbugs at cs.uiuc.edu, ofv at wanadoo.es Classification: Unclassified LLVM/clang r148681, Linux x86_64: [ 7%] Building Intrinsics.gen... ../../bin/llvm-tblgen: symbol lookup error: ../../bin/llvm-tblgen: undefined symbol: _ZN4llvm9DebugFlagE -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 05:52:03 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 11:52:03 +0000 Subject: [LLVMbugs] [Bug 11831] New: -ccc-host-triple causes assert Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11831 Bug #: 11831 Summary: -ccc-host-triple causes assert Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hkultala at cs.tut.fi CC: llvmbugs at cs.uiuc.edu Classification: Unclassified clang -O0 -ccc-host-triple tce-tut-llvm -emit-llvm -c foo2.c -o foo.bc where foo2.c can be empty file causes assertion: clang: /home/hkultala26/src/llvm-trunk/llvm/include/llvm/ADT/SmallVector.h:154: const T& llvm::SmallVectorTemplateCommon::operator[](unsigned int) const [with T = const char*]: Assertion `begin() + idx < end()' failed. 0 libLLVM-3.1svn.so 0x00007f8067de1d8f 1 libLLVM-3.1svn.so 0x00007f8067de4002 2 libpthread.so.0 0x00007f8067003b40 3 libc.so.6 0x00007f8066301ba5 gsignal + 53 4 libc.so.6 0x00007f80663056b0 abort + 384 5 libc.so.6 0x00007f80662faa71 __assert_fail + 241 6 clang 0x00000000005b5858 clang::driver::Driver::BuildCompilation(llvm::ArrayRef) + 4152 7 clang 0x000000000053581e main + 4814 8 libc.so.6 0x00007f80662ecd8e __libc_start_main + 254 9 clang 0x000000000052aef9 Stack dump: 0. Program arguments: clang -O0 -ccc-host-triple tce-tut-llvm -emit-llvm -c foo2.c -o foo.bc 1. Compilation construction Aborted when run inside gdb: Starting program: /home/hkultala26/tce/bin/clang -O0 -ccc-host-triple tce-tut-llvm -emit-llvm -c foo2.c -o foo.bc [Thread debugging using libthread_db enabled] clang: /home/hkultala26/src/llvm-trunk/llvm/include/llvm/ADT/SmallVector.h:154: const T& llvm::SmallVectorTemplateCommon::operator[](unsigned int) const [with T = const char*]: Assertion `begin() + idx < end()' failed. Program received signal SIGABRT, Aborted. 0x00007ffff598bba5 in raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0 0x00007ffff598bba5 in raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff598f6b0 in abort () at abort.c:92 #2 0x00007ffff5984a71 in __assert_fail (assertion=0x108a207 "begin() + idx < end()", file=, line=154, function=0x10a0fa0 "const T& llvm::SmallVectorTemplateCommon::operator[](unsigned int) const [with T = const char*]") at assert.c:81 #3 0x00000000005b5858 in operator[] (this=0x7fffffffd4e0, ArgList=...) at /home/hkultala26/src/llvm-trunk/llvm/include/llvm/ADT/SmallVector.h:154 #4 getValue (this=0x7fffffffd4e0, ArgList=...) at /home/hkultala26/src/llvm-trunk/llvm/tools/clang/lib/Driver/../../include/clang/Driver/Arg.h:87 #5 clang::driver::Driver::BuildCompilation (this=0x7fffffffd4e0, ArgList=...) at Driver.cpp:320 #6 0x000000000053581e in main (argc_=, argv_=) at driver.cpp:451 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 06:05:20 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 12:05:20 +0000 Subject: [LLVMbugs] [Bug 11832] New: clang crashes with std::initializer_list in non-static function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11832 Bug #: 11832 Summary: clang crashes with std::initializer_list in non-static function Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jonathan.sauer at gmx.de CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7928 --> http://llvm.org/bugs/attachment.cgi?id=7928 Complete crash log The following program crashes clang r148686: namespace std { typedef unsigned long size_t; // Reduced from libc++ template class initializer_list { // Comment these two lines to avoid the crash const _Ep* __begin_; size_t __size_; inline initializer_list(const _Ep* __b, size_t __s) noexcept {} public: }; } //#define STATIC static // Does not crash clang #define STATIC // Crashes clang void foo(std::initializer_list); STATIC void bar() { foo({ "foo" }); } STATIC void baz(const char* s) { foo({ s }); } This results in (full log attached): $ ~/LLVM/build/Release+Asserts/bin/clang++ -std=c++0x -v clang.cpp [...] Assertion failed: (getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"), function AssertOK, file /Users/rynnsauer/LLVM/llvm/lib/VMCore/Instructions.cpp, line 1082. [...] Interestingly, it does not crash if (a) the calling functions are static, or (b) std::initializer_list has no members. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 06:44:51 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 12:44:51 +0000 Subject: [LLVMbugs] [Bug 11833] New: recent build failure with spirit code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11833 Bug #: 11833 Summary: recent build failure with spirit code Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ps at kr.tuwien.ac.at CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7929 --> http://llvm.org/bugs/attachment.cgi?id=7929 original source file to reproduce (requires boost trunk or release branch) The attached file lit_char.cpp fails to build with boost release branch and trunk. The strange thing is: with clang 3.0 it works, with g++-4.5 and g++-4.6 it works. Preprocessing with g++ and feeding to clang trunk does not produce the bug. Preprocessing with clang 3.0 and feeding to clang trunk repreoduces the bug. The attached file lit_char.preprocessed_with_clang_3.0.cpp.bz2 does not require boost sources to reproduce the bug. Changing lit('!') to lit("!") fixes the problem, however as it works for other compiler versions I suppose it is a bug nevertheless. The attached file lit_char.preprocessed_with_clang_3.0.fixed.cpp.bz2 does not show the buggy behavior but requires source change. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 07:47:53 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 13:47:53 +0000 Subject: [LLVMbugs] =?utf-8?q?=5BBug_11834=5D_New=3A_On_Linux_the_CPUName_?= =?utf-8?q?depended_on_the_host=2C__while_on_Windows_=E2=80=9Cgeneric?= =?utf-8?q?=E2=80=9D_CPUName_is_chosen_=2E?= Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11834 Bug #: 11834 Summary: On Linux the CPUName depended on the host, while on Windows ?generic? CPUName is chosen. Product: new-bugs Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: marina.yatsina at intel.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7932 --> http://llvm.org/bugs/attachment.cgi?id=7932 Fix for the bug I was investigating a strange behavior I've encountered in X86Subtarget which caused different CPUName to be chosen for Windows and Linux. On Linux the chosen CPUName depends on the host, while on Windows ?generic? CPUName is chosen. I mapped the problem to commit 134741 to the LLVM trunk. The macros added in that commit are defined only for Linux and they are not defined for Windows. I've added a fix which I attached to this bug. commit 134741: http://www.llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86Subtarget.cpp?r1=134678&r2=134741&diff_format=h -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 08:36:56 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 14:36:56 +0000 Subject: [LLVMbugs] [Bug 11835] New: Error compiling haproxy Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11835 Bug #: 11835 Summary: Error compiling haproxy Product: clang Version: 3.0 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rimbalza at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hi, hope I found the right forum to post. I'm compiling haproxy 1.4.9 (from http://haproxy.1wt.eu/download/1.4/src/). Each optimization level greater than -O0 produces an executable that dumps on launching, in some init phase of the work. It produces the usual "-v" output without crashing. gdb tells me: Core was generated by `haproxy'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 str2listener (str=Unhandled dwarf expression opcode 0xe9 ) at cfgparse.c:204 204 memset(&ss, 0, sizeof(ss)); Compiling with march=native on 8.1-RELEASE-p1 FreeBSD 8.1-RELEASE-p1 i386. Hope this helps -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 12:08:40 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 18:08:40 +0000 Subject: [LLVMbugs] [Bug 11836] New: Poor code generated for float<->int conversion when NEON enabled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11836 Bug #: 11836 Summary: Poor code generated for float<->int conversion when NEON enabled Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: james.molloy at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7933 --> http://llvm.org/bugs/attachment.cgi?id=7933 Testcase. Compile with llc -mtriple armv7-none-gnueabi -mattr=+neon test.ll When the attached testcase is compiled with NEON enabled, it produces extremely bloated code. $ cat test.ll 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:64:128-a0:0:64-n32-S64" target triple = "armv7-none-linux-gnueabi" define float @f(<4 x i8>* nocapture %in) nounwind { %1 = load <4 x i8>* %in, align 4 %2 = extractelement <4 x i8> %1, i32 0 %3 = uitofp i8 %2 to float %4 = extractelement <4 x i8> %1, i32 1 %5 = uitofp i8 %4 to float %6 = extractelement <4 x i8> %1, i32 2 %7 = uitofp i8 %6 to float %8 = fadd float %3, %5 %9 = fadd float %8, %7 ret float %9 } $ llc -mtriple armv7-none-gnueabi -mattr=+neon -o - test.ll ... snip ... f: @ @f @ BB#0: sub sp, sp, #8 ldrb r1, [r0] ldrb r2, [r0, #1] ldrb r3, [r0, #2] ldrb r0, [r0, #3] strh r0, [sp, #6] strh r3, [sp, #4] strh r2, [sp, #2] strh r1, [sp] vldr d16, [sp] vmov.u16 r1, d16[1] vmov.u16 r2, d16[0] vmov.u16 r0, d16[2] uxtb r1, r1 uxtb r2, r2 uxtb r0, r0 vmov s1, r1 vmov s0, r2 vmov s2, r0 vcvt.f32.u32 s3, s0 vcvt.f32.u32 s1, s1 vcvt.f32.u32 s0, s2 vadd.f32 s1, s3, s1 vadd.f32 s0, s1, s0 vmov r0, s0 add sp, sp, #8 bx lr .Ltmp0: .size f, .Ltmp0-f That code has unnecessary moves to and from the vector unit, followed by a completely redundant unsigned extend. When compiling for vfp (no neon), decent code is generated: f: @ @f @ BB#0: ldrb r1, [r0] ldrb r2, [r0, #1] ldrb r0, [r0, #2] vmov s0, r2 vmov s2, r1 vmov s1, r0 vcvt.f32.u32 s0, s0 vcvt.f32.u32 s2, s2 vcvt.f32.u32 s1, s1 vadd.f32 s0, s2, s0 vadd.f32 s0, s0, s1 vmov r0, s0 bx lr -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 13:24:21 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 19:24:21 +0000 Subject: [LLVMbugs] [Bug 11837] New: "tail" marked on function with that may touch stack via byval param of caller Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11837 Bug #: 11837 Summary: "tail" marked on function with that may touch stack via byval param of caller Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jvoung at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7935 --> http://llvm.org/bugs/attachment.cgi?id=7935 ll showing issue In the attached test case, clang marks a call to memcpy "tail" even though one of the arguments is a pointer that may be pointing at the stack. The pointer may be pointing at the stack because it was derived from a "byval" parameter of the caller. Attached is the .ll for "SingleSource/UnitTests/byval-alignment.c" from the llvm test-suite, which shows this (see parameter "y" of function f0 being funneled to a tail call after a bitcast). Repro info: This was generated by running with clang -O3 (r148716), on x86-64, but without "-mllvm -disable-llvm-optzns" on the byval-alignment test. This seems related to: http://llvm.org/bugs/show_bug.cgi?id=7272 Though that bug says it's been fixed... This is also related to comment #1 in: http://llvm.org/bugs/show_bug.cgi?id=11420 Which noticed that: "BasicAA sees that the call to memcpy is a tail-call, and therefore concludes that it can't possibly touch stack memory." -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 13:38:40 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 19:38:40 +0000 Subject: [LLVMbugs] [Bug 11838] New: Clang fails to call temporary destructors in temporaries Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11838 Bug #: 11838 Summary: Clang fails to call temporary destructors in temporaries Product: clang Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: release blocker Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: asomerfield at serif.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Hi, We've just hit a blocker with Clang+LLVM ("Apple Compiler 3.0") in the latest XCode. Basically, Clang does not call destructors of temporaries inside a templated function. GCC+LLVM does not exhibit this behaviour. Example: #include class SomeObject { public: SomeObject() { printf("Constructed\r\n"); } SomeObject(const SomeObject& rhs) { printf("Copied\r\n"); } ~SomeObject() { printf("Destructed\r\n"); } }; class Test { public: template // Comment me out to see working case void DoTest() { GetObject(); } SomeObject GetObject() { return m_object; } SomeObject m_object; }; int main (int argc, const char * argv[]) { // Works //Test test; //test.DoTest(); // Broken Test test; test.DoTest(); return 0; } Running this code yields: Constructed Copied Destructed If you a.) Run this with GCC+LLVM OR b.) remove the template and comment in the "Works" code in main, you will get the correct output of: Constructed Copied Destructed Destructed We noticed this while tracking down an issue in our code which manifested as "ref-counted pointers failing to decrement sometimes :/" (imagine if GetObject() returned a ref-counted object by value). I don't think this is already fixed - I tried to find similar things in BugZilla but got nothing - we are using the latest Xcode on latest Mac OS X Lion using Sandybridge X86 hardware. The bug manifests in both -O0 (debug) and -O3 (release) - which leads me to guess it's not a dead-code optimisation problem. Cheers, 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 Mon Jan 23 13:52:59 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 19:52:59 +0000 Subject: [LLVMbugs] [Bug 11838] Clang fails to call temporary destructors in temporaries In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11838 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |WORKSFORME --- Comment #1 from Eli Friedman 2012-01-23 13:52:59 CST --- It's a known bug in template instantiation, and it has already been fixed in more recent versions 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 Mon Jan 23 15:54:15 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 23 Jan 2012 21:54:15 +0000 Subject: [LLVMbugs] [Bug 11762] Missing support for .cfi_signal_frame In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11762 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from Rafael ?vila de Esp?ndola 2012-01-23 15:54:15 CST --- Fixed in r148733. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 18:14:51 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 00:14:51 +0000 Subject: [LLVMbugs] [Bug 10315] [C++0x] "Call to deleted constructor" with move assignment operator In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10315 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nicolasweber at gmx.de Resolution|INVALID |DUPLICATE --- Comment #2 from Nico Weber 2012-01-23 18:14:51 CST --- *** This bug has been marked as a duplicate of bug 10217 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 19:13:31 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 01:13:31 +0000 Subject: [LLVMbugs] [Bug 11345] debug info generated for functions that are not emitted In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11345 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Eric Christopher 2012-01-23 19:13:31 CST --- Fixed this last week. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 19:21:21 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 01:21:21 +0000 Subject: [LLVMbugs] [Bug 5538] Lack of diagnostic when a static variable inside a class has the same name of the class type In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5538 Kaelyn Uhrain changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rikka at google.com Resolution| |FIXED --- Comment #1 from Kaelyn Uhrain 2012-01-23 19:21:21 CST --- Not sure when the fix went in, but as of the clang 3.0 release the sample code does trigger an error: $ clang++ example.cc example.cc:3:18: error: member 'A' has the same name as its class static int A; ^ 1 error generated. $ clang++ --version clang version 3.0 (tags/RELEASE_30/final) Target: x86_64-pc-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 Mon Jan 23 20:04:31 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 02:04:31 +0000 Subject: [LLVMbugs] [Bug 11839] New: Static analyzer gives no warnings in #included *.c files Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11839 Bug #: 11839 Summary: Static analyzer gives no warnings in #included *.c files Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: listrp at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat foo.c int foo( void ) { int x; if ( x ) return 1; /* uninitialized */ return 0; } $ cat main.c #include "foo.c" /* ignored by static analyzer? */ int main( void ) { return 0; } $ clang main.c --analyze $ clang --version clang version 3.1 (trunk 148340) Analysis of main.c is defective. Explicit analysis of foo.c does give a warning. $ clang foo.c --analyze foo.c:3:10: warning: Branch condition evaluates to a garbage value if ( x ) return 1; /* uninitialized */ ^ 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 Mon Jan 23 21:35:57 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 03:35:57 +0000 Subject: [LLVMbugs] [Bug 11840] New: libc++ linux compile error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11840 Bug #: 11840 Summary: libc++ linux compile error Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: qiwei.uk at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hi all, I have the following error when building libc++ on GNU/Linux (Debian Wheezy). + clang++ -c -g -Os -fPIC -std=c++0x -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wnewline-eof -Wpadded -Wmissing-prototypes -Wstrict-aliasing=2 -Wstrict-overflow=4 -nostdinc++ -I../include ../src/future.cpp ../src/future.cpp:42:10: error: value of type 'std::__1::future_errc' is not implicitly convertible to 'int' case future_errc::no_state: ^~~~~~~~~~~~~~~~~~~~~ ../src/future.cpp:40:10: error: value of type 'std::__1::future_errc' is not implicitly convertible to 'int' case future_errc::promise_already_satisfied: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../src/future.cpp:37:10: error: value of type 'std::__1::future_errc' is not implicitly convertible to 'int' case future_errc::future_already_retrieved: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../src/future.cpp:34:10: error: value of type 'std::__1::future_errc' is not implicitly convertible to 'int' case future_errc::broken_promise: ^~~~~~~~~~~~~~~~~~~~~~~~~~~ I have before this built llvm/clang using the latest SVN checkout. Thank you if you can help. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 23:34:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 05:34:13 +0000 Subject: [LLVMbugs] [Bug 11841] New: Another register scavenger assertion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11841 Bug #: 11841 Summary: Another register scavenger assertion Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7936 --> http://llvm.org/bugs/attachment.cgi?id=7936 Testcase The attached testcase started to fail after r148779 or around. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 00:16:23 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 06:16:23 +0000 Subject: [LLVMbugs] [Bug 10127] Clang does not implement N3031: decltype(type)::subtype does not compile In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10127 David Blaikie 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 Tue Jan 24 03:10:54 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 09:10:54 +0000 Subject: [LLVMbugs] [Bug 11842] New: assigment of enum value in struct with address space attribute causes assert Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11842 Bug #: 11842 Summary: assigment of enum value in struct with address space attribute causes assert Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hkultala at cs.tut.fi CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7938 --> http://llvm.org/bugs/attachment.cgi?id=7938 code causing the assert. compile with command: clang -cc1 -o foo.bc -x c++ foo.cc A code with a struct that has an address space attribute containing an enum causes an assertion when a value is assigned to the enum field in the struct. This code works with clang 3.0, broken only with relatively new ToT/3.1svn. compile with command: clang -cc1 -o foo.bc -x c++ foo.cc gives error: clang: SemaOverload.cpp:9786: clang::ExprResult clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int, const clang::UnresolvedSetImpl&, clang::Expr*, clang::Expr*): Assertion `Result.isInvalid() && "C++ binary operator overloading is missing candidates!"' failed. 0 libLLVM-3.1svn.so 0x00007fc7e4ee45ef 1 libLLVM-3.1svn.so 0x00007fc7e4ee6862 2 libpthread.so.0 0x00007fc7e4103b40 3 libc.so.6 0x00007fc7e3401ba5 gsignal + 53 4 libc.so.6 0x00007fc7e34056b0 abort + 384 5 libc.so.6 0x00007fc7e33faa71 __assert_fail + 241 6 clang 0x0000000000a6f7ea 7 clang 0x000000000098088e 8 clang 0x00000000009a8d28 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 520 9 clang 0x00000000009a8f76 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 278 10 clang 0x00000000008568ed clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) + 701 11 clang 0x00000000008573ff clang::Parser::ParseAssignmentExpression() + 47 12 clang 0x00000000008581c9 clang::Parser::ParseExpression() + 9 13 clang 0x00000000008173d3 clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 83 14 clang 0x00000000008157ab clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool, clang::SourceLocation*) + 2331 15 clang 0x0000000000812e11 clang::Parser::ParseCompoundStatementBody(bool) + 1793 16 clang 0x0000000000813418 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 168 17 clang 0x0000000000828aa2 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 2210 18 clang 0x000000000083912b clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 3323 19 clang 0x0000000000825e8d clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 157 20 clang 0x00000000008263f6 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 742 21 clang 0x000000000082b47b clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2283 22 clang 0x000000000084ccf0 clang::Parser::ParseLinkage(clang::Parser::ParsingDeclSpec&, unsigned int) + 1040 23 clang 0x0000000000825f88 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 408 24 clang 0x00000000008263f6 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 742 25 clang 0x000000000082b47b clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2283 26 clang 0x000000000082b920 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 160 27 clang 0x0000000000802da5 clang::ParseAST(clang::Sema&, bool) + 293 28 clang 0x000000000054e2c1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 321 29 clang 0x00000000005373a9 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1401 30 clang 0x000000000052d4a4 cc1_main(char const**, char const**, char const*, void*) + 484 31 clang 0x0000000000536147 main + 6999 32 libc.so.6 0x00007fc7e33ecd8e __libc_start_main + 254 33 clang 0x000000000052afb9 Stack dump: 0. Program arguments: clang -cc1 -o foo.bc -x c++ foo.cc 1. foo.cc:47:39: current parser token ';' 2. foo.cc:46:37: parsing function body 'alloc_from_global_memory' 3. foo.cc:46:37: in compound statement ('{}') 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 Tue Jan 24 05:00:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 11:00:13 +0000 Subject: [LLVMbugs] [Bug 11843] New: Stack protection not working properly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11843 Bug #: 11843 Summary: Stack protection not working properly Product: dragonegg Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: New Bugs AssignedTo: baldrick at free.fr ReportedBy: pbarrio at die.upm.es CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7939 --> http://llvm.org/bugs/attachment.cgi?id=7939 Resulting bitcode from dragonegg Generated IR segfaults when executing with lli. Native executable works fine. If option "-fno-stack-protector" is passed to dragonegg, it also works. $> gcc -fplugin=~/dragonegg.so -O1 -fplugin-arg-dragonegg-enable-gcc-optzns test.c -S -fplugin-arg-dragonegg-emit-ir -o test.ll $> lli test.ll The original code is: #include #include #include int main(int argc, char** argv){ char a[15] = "aaaaaaaaaaaaaa"; char b[15] = "bbbbbbbbbbbbbb"; char *c = (char*) malloc(sizeof(char)*(strlen(a)+strlen(b)+1)); memcpy(c, a, strlen(a)); memcpy(c + strlen(a), b, strlen(b) + 1); printf("a = %s, b = %s, c = %s\n", a, b, c); } If arrays "a" and "b" are shrinked to 7 chars, then it works as well. If these arrays are allocated with malloc or declared as globals (out of main), it also works. It's very likely to be a stack 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 Tue Jan 24 05:08:23 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 11:08:23 +0000 Subject: [LLVMbugs] [Bug 11844] New: scan-build does not run on XCode 4.2 code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11844 Bug #: 11844 Summary: scan-build does not run on XCode 4.2 code Product: clang Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: mandys.inbox at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When I run the latest (258) scan-build on code built using XCode 4.2 I get the following error:- 2012-01-24 10:19:37.498 xcodebuild[780:3803] DVTAssertions: Warning in /SourceCache/IDEXcode3ProjectSupport/IDEXcode3ProjectSupport-928/Xcode3Sources/XcodeIDE/Frameworks/DevToolsBase/pbxcore/SpecificationTypes/XCCommandLineToolSpecification.m:828 Details: Unable to get message category info for tool '/Applications/checker-258/libexec/ccc-analyzer'. Reason: i686-apple-darwin11-llvm-gcc-4.2: no input files Object: Method: -messageCategoryInfoForExecutablePath: Thread: {name = (null), num = 6} Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide. CompileC build/Appy.build/Debug-iphonesimulator/Appy.build/Objects-normal/i386/main.o Appy/main.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler cd /Users/Mo/dev/latest setenv LANG en_US.US-ASCII setenv PATH "/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin" /Applications/checker-258/libexec/ccc-analyzer -x objective-c -arch i386 -fmessage-length=0 -fdiagnostics-print-source-range-info -fdiagnostics-show-category=id -fdiagnostics-parseable-fixits -std=gnu99 -fobjc-arc -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-shorten-64-to-32 -DDEBUG -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk -fexceptions -fasm-blocks -mmacosx-version-min=10.6 -gdwarf-2 -Wno-sign-conversion -fobjc-abi-version=2 -fobjc-legacy-dispatch "-DIBOutlet=__attribute__((iboutlet))" "-DIBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName)))" "-DIBAction=void)__attribute__((ibaction)" -D__IPHONE_OS_VERSION_MIN_REQUIRED=50000 -iquote /Users/Mo/dev/latest/build/Appy.build/Debug-iphonesimulator/Appy.build/Appy-generated-files.hmap -I/Users/Mo/dev/latest/build/Appy.build/Debug-iphonesimulator/Appy.build/Appy-own-target-headers.hmap -I/Users/Mo/dev/latest/build/Appy.build/Debug-iphonesimulator/Appy.build/Appy-all-target-headers.hmap -iquote /Users/Mo/dev/latest/build/Appy.build/Debug-iphonesimulator/Appy.build/Appy-project-headers.hmap -I/Users/Mo/dev/latest/build/Debug-iphonesimulator/include -I/Users/Mo/dev/latest/build/Appy.build/Debug-iphonesimulator/Appy.build/DerivedSources/i386 -I/Users/Mo/dev/latest/build/Appy.build/Debug-iphonesimulator/Appy.build/DerivedSources -F/Users/Mo/dev/latest/build/Debug-iphonesimulator -F/Users/Mo/dev/latest -include /Users/Mo/dev/latest/Appy/Appy-Prefix.pch -MMD -MT dependencies -MF /Users/Mo/dev/latest/build/Appy.build/Debug-iphonesimulator/Appy.build/Objects-normal/i386/main.d -c /Users/Mo/dev/latest/Appy/main.m -o /Users/Mo/dev/latest/build/Appy.build/Debug-iphonesimulator/Appy.build/Objects-normal/i386/main.o cc1obj: error: unrecognized command line option "-Wno-sign-conversion" cc1obj: error: unrecognized command line option "-fdiagnostics-print-source-range-info" cc1obj: error: unrecognized command line option "-fdiagnostics-show-category=id" cc1obj: error: unrecognized command line option "-fdiagnostics-parseable-fixits" cc1obj: error: unrecognized command line option "-fobjc-arc" Command /Applications/checker-258/libexec/ccc-analyzer failed with exit code 1 ** BUILD FAILED ** The following build commands failed: CompileC build/Appy.build/Debug-iphonesimulator/Appy.build/Objects-normal/i386/main.o Appy/main.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler (1 failure) scan-build: Removing directory '/var/folders/p6/r86f0tb17tq2c5crbndb0q7m0000gn/T/scan-build-2012-01-24-1' because it contains no reports. I can fix this using a solution listed here: http://stackoverflow.com/questions/7820011/clang-scan-build-wont-work-with-xcode-4-2-llvm-3-0-build-configuration however even when using this "hack" the results imply the scanner does not recognise ARC'd code as I have numerous false warnings about potential memory leaks. Thanks for any help -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 05:39:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 11:39:42 +0000 Subject: [LLVMbugs] [Bug 11845] New: Clang scan-build does not recognise ARC'd code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11845 Bug #: 11845 Summary: Clang scan-build does not recognise ARC'd code Product: clang Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: release blocker Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: mandys.inbox at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I have run the 258 scan-build analyzer on my XCode 4.2 code and it seems to generate loads of false warnings about potential memory leaks implying the analyzer hasn't recognised the code has been ARCd. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 08:42:45 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 14:42:45 +0000 Subject: [LLVMbugs] [Bug 11846] New: For Snow Leopard : incompatibility between LLVM 3.0 and LLVM-GCC 2.9, but OK for both v. 2.9 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11846 Bug #: 11846 Summary: For Snow Leopard : incompatibility between LLVM 3.0 and LLVM-GCC 2.9, but OK for both v. 2.9 Product: compiler-rt Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: release blocker Priority: P Component: compiler-rt AssignedTo: unassignedbugs at nondot.org ReportedBy: doc0.delphin at voila.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7940 --> http://llvm.org/bugs/attachment.cgi?id=7940 LLVM 3.0 buit right Softwares are : Mac OS X v. 10.6.8 (Snow Leopard), XCode v. 3.2.6. The objective : using the last version of LLVM (3.0) and LLVM-GCC v. 2.9,a nd succeeding in building teh compilers (namely, c, c++, objetcive-c, fortran as a basis). The result is a bug : - first, early building LLVM v. 2.9 and LLVM-GCC v. 2.9 were compiled and installed successfully (however, LLVM-GCC was not tested with a test-suite library such as with GCC) ; - next, building, and installing, LLVM v. 3.0 then LLVM-GCC v. 2.9 issues an error (I repeated the process with the same error) : LLVM-GCC can't be build. The expectation : a successful suite of LLVM compilers built, installed, and tested successfully with Mac OS X (ideally, Leopard, Snow Leopard, and now Lion). Files attached : three ZIP files including : i) the bash file used to build and install LLVM and LLVM-GCC, ii) log files issued by configure, make, make check and so on if applicable. Many 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 Jan 24 09:01:15 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 15:01:15 +0000 Subject: [LLVMbugs] [Bug 11846] For Snow Leopard : incompatibility between LLVM 3.0 and LLVM-GCC 2.9, but OK for both v. 2.9 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11846 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |baldrick at free.fr Resolution| |INVALID --- Comment #3 from Duncan Sands 2012-01-24 09:01:15 CST --- LLVM 3.0 does not come with llvm-gcc because llvm-gcc is a dead project that is no longer being supported (this was already announced in the 2.9 release). Please use dragonegg or clang instead. It is normal that you can't build the 2.9 version of llvm-gcc with LLVM 3.0: it has always been the case that the llvm-gcc and LLVM versions have to match. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 12:35:54 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 18:35:54 +0000 Subject: [LLVMbugs] [Bug 11847] New: Crash on invalid in Microsoft anonymous struct extension Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11847 Bug #: 11847 Summary: Crash on invalid in Microsoft anonymous struct extension Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jason.haslam at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7943 --> http://llvm.org/bugs/attachment.cgi?id=7943 Possible fix. The following invalid program crashes clang: jason$ cat test.c typedef struct { UNKNOWN c; } A; typedef struct { A; } B; jason$ clang -target i386-pc-win32 test.c test.c:1:18: error: unknown type name 'UNKNOWN' typedef struct { UNKNOWN c; } A; ^ test.c:2:18: warning: anonymous structs are a Microsoft extension [-Wmicrosoft] typedef struct { A; } B; ^ Stack dump: 0. Program arguments: /Users/jason/Sources/llvm/build/release/bin/clang-3.1 -cc1 -triple i386-pc-win32 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -momit-leaf-frame-pointer -resource-dir /Users/jason/Sources/llvm/build/release/bin/../lib/clang/3.1 -fmodule-cache-path /var/folders/lf/36_5tdts1953gfg4mjwfmq8h0000gn/T/clang-module-cache -internal-isystem /Users/jason/Sources/llvm/build/release/bin/../lib/clang/3.1/include -internal-isystem C:/Program Files/Microsoft Visual Studio 10.0/VC/include -internal-isystem C:/Program Files/Microsoft Visual Studio 9.0/VC/include -internal-isystem C:/Program Files/Microsoft Visual Studio 9.0/VC/PlatformSDK/Include -internal-isystem C:/Program Files/Microsoft Visual Studio 8/VC/include -internal-isystem C:/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/Include -fdebug-compilation-dir /Users/jason/Desktop/test -ferror-limit 19 -fmessage-length 173 -mstackrealign -fms-extensions -fms-compatibility -fmsc-version=1300 -fdelayed-template-parsing -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/lf/36_5tdts1953gfg4mjwfmq8h0000gn/T/test-Ct8Uam.o -x c test.c 1. test.c:2:19: current parser token ';' 2. test.c:2:9: parsing struct/union body clang-3: error: unable to execute command: Segmentation fault: 11 clang-3: error: clang frontend command failed due to signal (use -v to see invocation) clang-3: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang-3: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at: clang-3: note: diagnostic msg: /var/folders/lf/36_5tdts1953gfg4mjwfmq8h0000gn/T/test-B8wNe4.i clang-3: note: diagnostic msg: /var/folders/lf/36_5tdts1953gfg4mjwfmq8h0000gn/T/test-B8wNe4.sh -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 13:01:47 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 19:01:47 +0000 Subject: [LLVMbugs] [Bug 11803] Disregarding [except.handle]/p1 (catching incomplete types) leads to incorrect dynamic_cast In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11803 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2012-01-24 13:01:47 CST --- Fixed in Clang r148838. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 15:02:32 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 21:02:32 +0000 Subject: [LLVMbugs] [Bug 11848] New: pack expansion of alias template with non-dependent substitution fails Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11848 Bug #: 11848 Summary: pack expansion of alias template with non-dependent substitution fails Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified template using I = int; template int f(I i, I ...is) { return i + f(is...); }; int k = f(1, 2, 3); This causes clang to assert: src/tools/clang/lib/AST/ASTContext.cpp:2680: clang::QualType clang::ASTContext::getPackExpansionType(clang::QualType, llvm::Optional): Assertion `Pattern->containsUnexpandedParameterPack() && "Pack expansions must expand one or more parameter packs"' failed. The root cause here is presumably that the alias template contains an unexpanded parameter pack, but its canonical type does not. I'm not entirely sure whether this is supposed to be legal: on one hand, the pattern clearly names a parameter pack, but on the other hand, an alias template is supposed to be equivalent to its substitution, and its substitution does not name a parameter pack. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 15:09:23 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 21:09:23 +0000 Subject: [LLVMbugs] [Bug 11849] New: trunk doesn't work with ObjC++: Assertion failed: (D && "Cannot get layout of forward declarations!") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11849 Bug #: 11849 Summary: trunk doesn't work with ObjC++: Assertion failed: (D && "Cannot get layout of forward declarations!") Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mayer.julian at googlemail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified hello all. i wanted to try trunk to see if a bad codegen bug in clang is fixed but i can't get it to work with my project from within xcode it works fine for some C and ObjC files but fails for my ObjC++ and one C++ file, it breaks with this assertion: Assertion failed: (D && "Cannot get layout of forward declarations!"), function getASTRecordLayout, file RecordLayoutBuilder.cpp, line 2066. 0 clang 0x00000001014851c2 llvm::SmallVectorImpl::swap(llvm::SmallVectorImpl&) + 14194 1 clang 0x00000001014857b9 llvm::SmallVectorImpl::swap(llvm::SmallVectorImpl&) + 15721 2 libSystem.B.dylib 0x00007fff84d711ba _sigtramp + 26 3 libSystem.B.dylib 0x0000000102033600 _sigtramp + 2100044896 4 clang 0x0000000101485406 llvm::SmallVectorImpl::swap(llvm::SmallVectorImpl&) + 14774 5 clang 0x00000001014853c7 llvm::SmallVectorImpl::swap(llvm::SmallVectorImpl&) + 14711 full invocation command, assertion details and preprocessed sources attached. tried trunk llvm+clang from yesterday and today (2 hours ago), same 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 Tue Jan 24 15:16:18 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 21:16:18 +0000 Subject: [LLVMbugs] [Bug 9527] warn if class type has alignment greater than "new" provides and doesn't overload operator new In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9527 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Nick Lewycky 2012-01-24 15:16:18 CST --- -Wover-aligned added in r148857. Unlike the original request, this only fires on places that actually attempt to construct such an object with the default allocator. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 15:18:19 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 21:18:19 +0000 Subject: [LLVMbugs] [Bug 11849] trunk doesn't work with ObjC++: Assertion failed: (D && "Cannot get layout of forward declarations!") In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11849 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |FIXED --- Comment #3 from Ted Kremenek 2012-01-24 15:18:19 CST --- This doesn't reproduce for me on TOT, revision 148852. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 15:30:09 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 21:30:09 +0000 Subject: [LLVMbugs] [Bug 9466] [-Wformat] clang: doesn't know about %Lu, %Ld, and %Lx In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9466 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Ted Kremenek 2012-01-24 15:30:09 CST --- Fixed: r148859 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 17:04:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 23:04:42 +0000 Subject: [LLVMbugs] [Bug 11849] trunk doesn't work with ObjC++: Assertion failed: (D && "Cannot get layout of forward declarations!") In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11849 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED 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 Jan 24 17:30:17 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 24 Jan 2012 23:30:17 +0000 Subject: [LLVMbugs] [Bug 11850] New: empty function parameter pack expansions before the end of the parameter list don't work Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11850 Bug #: 11850 Summary: empty function parameter pack expansions before the end of the parameter list don't work Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified This crashes clang: template struct S { int f(T...a, int b) { return b; } }; S<> s; int k = s.f(0); ... like so: lib/Sema/SemaTemplateInstantiateDecl.cpp:2549: void clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl *, bool, bool): Assertion `FParamIdx < Function->getNumParams()' failed. This is rejected: template void f(T...a, int b) {} template void f<>(int b); ... like so: :2:15: error: explicit instantiation of 'f' does not refer to a function template, member function, member class, or static data member template void f<>(int b); ^ I believe both of these cases should work. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 18:37:06 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 00:37:06 +0000 Subject: [LLVMbugs] [Bug 11841] Another register scavenger assertion In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11841 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Jakob Stoklund Olesen 2012-01-24 18:37:06 CST --- Fixed in r148879 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 19:06:07 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 01:06:07 +0000 Subject: [LLVMbugs] [Bug 11833] recent build failure with spirit code In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11833 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Eli Friedman 2012-01-24 19:06:07 CST --- r148893. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 19:20:54 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 01:20:54 +0000 Subject: [LLVMbugs] [Bug 11851] New: clang doesn't instantiate constexpr functions where necessary during overload resolution Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11851 Bug #: 11851 Summary: clang doesn't instantiate constexpr functions where necessary during overload resolution Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu, richard-llvm at metafoo.co.uk Classification: Unclassified Testcase: template constexpr int f() { return x; } template void ovf(int (&x)[f()]); void f() { int x[10]; ovf<10>(x); } As far as I can tell, this is valid C++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 Tue Jan 24 20:31:29 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 02:31:29 +0000 Subject: [LLVMbugs] [Bug 11358] fails to suggest missing "typename" before type In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11358 Nick Lewycky 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 Wed Jan 25 00:52:44 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 06:52:44 +0000 Subject: [LLVMbugs] [Bug 11852] New: C++ parser crashes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11852 Bug #: 11852 Summary: C++ parser crashes Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: xu_zhong_xing at 163.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified C++ parser crashes on this illegal code: struct S { S() : i(0) {} int i; void f() {} }; void f() { S cs; int S::*pm = &S::i; cs.*pm = 1; void S::(*pf)() = S::f; (*pf)(); } $ clang -cc1 -x c++ ptr-to-member.cpp clang: /home/xzx/llvm/tools/clang/lib/Parse/../../include/clang/Parse/Parser.h:1947: void clang::Parser::DeclaratorScopeObj::EnterDeclaratorScope(): Assertion `!EnteredScope && "Already entered the scope!"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 08:48:54 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 14:48:54 +0000 Subject: [LLVMbugs] [Bug 11853] New: ARM: IT instruction rejected in inline asm Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11853 Bug #: 11853 Summary: ARM: IT instruction rejected in inline asm Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: mans at mansr.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Inline asm statements using the Thumb2 IT instruction are rejected. Simple test case: void foo(void) { __asm__ ("it eq \n" "moveq r0, r0 \n"); } Error: it.c:3:14: error: invalid operand for instruction __asm__ ("it eq \n" ^ :1:8: note: instantiated into assembly here it eq ^ 1 error generated. Although a Thumb2 instruction, the IT mnemonic shall be permitted in ARM mode, and the condition verified to match the condition code(s) on the following instruction(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 Wed Jan 25 10:16:03 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 16:16:03 +0000 Subject: [LLVMbugs] [Bug 11848] pack expansion of alias template with non-dependent substitution fails In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11848 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2012-01-25 10:16:03 CST --- (In reply to comment #1) > r148905 fixes the crash and causes us to reject this case, as suggested by > Doug. However, during the fix, another related issue was found: > > template > struct Hidden1 { > template > Hidden1(typename T::template U ...ts); > }; > > struct Hide { > template using U = int; > }; > > Hidden1 h1; > > This still causes a crash. Fixed this last bit in r148960. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 12:00:00 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 18:00:00 +0000 Subject: [LLVMbugs] [Bug 11854] New: floating point division by 0.0 vs -ftrapv vs IEEE floating point semantics Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11854 Bug #: 11854 Summary: floating point division by 0.0 vs -ftrapv vs IEEE floating point semantics Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sean at rogue-research.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In C and C++ floating point division by 0 is undefined behaviour[1][2]. clang's -ftrapv flag catches it: -----test.c----- int main (int argc, char *argv[]) { (void)argc; (void)argv; double a = 10.0; double b = 0.0; double c = a / b; return c; } -----test.c----- $ clang -ftrapv test.c $ ./a.out Illegal instruction: 4 On the one hand, I like this, because I want to write portable code. OTOH, practically speaking, most environments use IEEE floating point semantics, where division by 0 gives NaN or Inf. Therefore, I'd like to suggest splitting -ftrapv into 2 flags. One very strict, as currently; and one that doesn't complain about things that are well defined in IEEE-754. [1] https://www.securecoding.cert.org/confluence/display/seccode/FLP03-C.+Detect+and+handle+floating+point+errors [2] C++98 5.6 Multiplicative operators [expr.mul]p4 says , "If the second operand of / or % is zero the behavior is undefined". It's the same in C++11 N3242. Floating point division is not distinguished from integral division... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 13:52:15 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 19:52:15 +0000 Subject: [LLVMbugs] [Bug 11853] ARM: IT instruction rejected in inline asm In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11853 Jim Grosbach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Jim Grosbach 2012-01-25 13:52:15 CST --- Quite right. Fixed in r148969. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 15:00:51 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 21:00:51 +0000 Subject: [LLVMbugs] [Bug 9911] Bad typo correction: variable name "fool" -> "bool" In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9911 Kaelyn Uhrain changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rikka at google.com Resolution| |FIXED --- Comment #2 from Kaelyn Uhrain 2012-01-25 15:00:51 CST --- Commit 148973 fixes the bogus typo correction of 'fool' to 'bool'--the main point of this bug report as confirmed by Matt. The parser problems for when the first argument has an unknown type name is a different can of worms with a separate internal bug (not sure if it has been filed upstream). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 15:04:23 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 21:04:23 +0000 Subject: [LLVMbugs] [Bug 11855] New: ARM: inline asm does not support pre-UAL conditional LDRH etc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11855 Bug #: 11855 Summary: ARM: inline asm does not support pre-UAL conditional LDRH etc Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: mans at mansr.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The inline asm parser should accept the old forms of conditional LDRH and friends, e.g. LDREQH should be an alias for LDRHEQ. GCC supports _only_ these forms in ARM mode, so this is essential for compatibility. Test case: void foo(void) { __asm__ ("ldreqh r0, [r1]"); } Fails like this: asm.c:3:14: error: invalid instruction __asm__ ("ldreqh r0, [r1]"); ^ :1:2: note: instantiated into assembly here ldreqh r0, [r1] ^ 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 Jan 25 15:14:09 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 21:14:09 +0000 Subject: [LLVMbugs] [Bug 11737] typo correction applied to implicit begin/end calls in for-range statement In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11737 Kaelyn Uhrain changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rikka at google.com Resolution| |FIXED --- Comment #1 from Kaelyn Uhrain 2012-01-25 15:14:09 CST --- A fix to suppress typo correction for synthesized function calls such as the 'begin' and 'end' in a for-range statement has been committed as r148979. For the example "struct S{}; bool begun(S); void f() { for (auto i : S()) {} }": :1:51: error: use of undeclared identifier 'begin' struct S{}; bool begun(S); void f() { for (auto i : S()) {} } ^ :1:51: note: range has type 'S' 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 Jan 25 15:36:01 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 21:36:01 +0000 Subject: [LLVMbugs] [Bug 11856] New: Bad diagnostic when member reference collides with global template function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11856 Bug #: 11856 Summary: Bad diagnostic when member reference collides with global template function Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jyasskin at google.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified In the following program, Foo() is trying to use a public member variable of "*it1". Because there's a global template with the same name, it interprets the subsequent '<' as starting a template instantiation, and then finds trouble many tokens later when there's no matching '>'. $ cat test.ii template T end(T); template void Foo() { T it1; if (it1->end < it1->end) { } } $ clang -fsyntax-only test.ii test.ii:6:26: error: expected '>' if (it1->end < it1->end) ^ test.ii:6:26: error: expected unqualified-id 2 errors generated. $ The error should at least mention the template it was trying to find a parameter for. A possible fixit is to add parentheses around "it1->end". This will come up more often in C++11, where there's a std::end<>() that lots of people will 'using' into their global namespaces. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 16:19:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 22:19:16 +0000 Subject: [LLVMbugs] [Bug 11744] Assertion failure with multi-dimensional arrays and templates In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11744 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2012-01-25 16:19:16 CST --- r148989. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 16:25:19 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 22:25:19 +0000 Subject: [LLVMbugs] [Bug 5329] Global ctor/dtor priorities not codegened correctly In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5329 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #9 from Anton Korobeynikov 2012-01-25 16:25:19 CST --- Fixed in r148990. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 16:47:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 22:47:11 +0000 Subject: [LLVMbugs] [Bug 11744] Assertion failure with multi-dimensional arrays and templates In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11744 Nathan Whitehorn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #2 from Nathan Whitehorn 2012-01-25 16:47:11 CST --- R148989 doesn't seem to actually fix the original test case. Trying to compile it with trunk (r148990) now gives this: 1. parser at end of file 2. Per-file LLVM IR generation 3. /tmp/weirdbug.cxx:7:14: Generating code for declaration 'B::F' 4. /tmp/weirdbug.cxx:7:18: LLVM IR generation of compound statement ('{}') clang-3: error: unable to execute command: Abort trap: 6 (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 Jan 25 16:56:14 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 22:56:14 +0000 Subject: [LLVMbugs] [Bug 11812] Error in llvm.usub.with.overflow.i32 intrinsic [ARM] In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11812 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #2 from Eli Friedman 2012-01-25 16:56:14 CST --- 1073741824-536870912 doesn't overflow using either signed or unsigned arithmetic. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 17:20:37 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 23:20:37 +0000 Subject: [LLVMbugs] [Bug 11744] Assertion failure with multi-dimensional arrays and templates In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11744 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Eli Friedman 2012-01-25 17:20:37 CST --- r148995. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 17:37:20 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 23:37:20 +0000 Subject: [LLVMbugs] [Bug 11829] Assertion in register scavenger In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11829 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #13 from Jakob Stoklund Olesen 2012-01-25 17:37:20 CST --- Second test case fixed in r148996. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 17:39:40 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 23:39:40 +0000 Subject: [LLVMbugs] [Bug 10327] unnecessary mov In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10327 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Jakob Stoklund Olesen 2012-01-25 17:39:40 CST --- Instead of fixing this in the register allocator, we got a late copy propagation 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 Wed Jan 25 17:48:04 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 25 Jan 2012 23:48:04 +0000 Subject: [LLVMbugs] [Bug 11857] New: "missing argument" diagnostic should include argument name Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11857 Bug #: 11857 Summary: "missing argument" diagnostic should include argument name Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I got this today: Instructions.cpp:1609:36: error: too few arguments to function call, expected 1, have 0 if (CDS->getElementAsInteger() >= V1Size*2) ~~~~~~~~~~~~~~~~~~~~~~~~ ^ In the special case of missing one argument, it would be spiffy to emit something like: error: too few arguments to function call, argument 'idx' was not specified where the name of the argument comes from the function/method prototype. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 20:04:09 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 02:04:09 +0000 Subject: [LLVMbugs] [Bug 11797] #pragma GCC visibility push(default) not working properly In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11797 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Rafael ?vila de Esp?ndola 2012-01-25 20:04:09 CST --- Fixed in r149014. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 23:12:12 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 05:12:12 +0000 Subject: [LLVMbugs] [Bug 11812] Error in llvm.usub.with.overflow.i32 intrinsic [ARM] In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11812 Malov Victor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED 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 Wed Jan 25 23:37:47 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 05:37:47 +0000 Subject: [LLVMbugs] [Bug 11812] Error in llvm.usub.with.overflow.i32 intrinsic [ARM] In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11812 Malov Victor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |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 Thu Jan 26 03:40:29 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 09:40:29 +0000 Subject: [LLVMbugs] [Bug 11858] New: clang should not default to -fno-math-errno Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11858 Bug #: 11858 Summary: clang should not default to -fno-math-errno Product: clang Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jay.foad at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified If I compile with optimisation, clang turns on -fno-math-errno. This is bad because it breaks valid programs. There's a test case below. If I compile with "clang -O" and run it, I get "result -nan, errno 0", which is wrong because errno should be EDOM. I'm using the 3.0rc3 release on Linux/x86_64. This behaviour was added under PR5971 but without much rationale. Also see the brief thread at http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-November/018644.html #include #include #include int main(int argc, const char *argv[]) { double d; errno = 0; d = sqrt(argc - 5); printf("result %g, errno %d\n", d, errno); 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 Thu Jan 26 04:04:58 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 10:04:58 +0000 Subject: [LLVMbugs] [Bug 11859] New: miscompilation of x264 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11859 Bug #: 11859 Summary: miscompilation of x264 Product: clang Version: 3.0 Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mroi at users.sourceforge.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Summary: clang 3.0 as shipping with Apple's Xcode developer tools miscompiles the H.264 encoder from the x264 project. The resulting x264 binary crashes. Steps to Reproduce: 1. Retrieve x264 here: http://git.videolan.org/?p=x264.git;a=snapshot;h=bcd41dbcaa4430b2118d9f6828c2b9635cf9d58d;sf=tgz 2. configure and compile it using clang: CC=clang ./configure && make 3. Get this sample video: http://movies.apple.com/movies/us/hd_gallery/gl1800/bbc-r_m720p.mov 4. Run the following command to encode (you need the ffmpeg tool installed): ffmpeg -i bbc-r_m720p.mov -f rawvideo - 2> /dev/null | ../x264/x264 --input-res 1280x720 --bitrate 4000 --slices 4 --sliced-threads --threads 4 --no-cabac --ref 3 --bframes 8 --b-pyramid none --no-weightb --weightp 0 --no-8x8dct --cqm flat --b-adapt 2 --direct auto --me umh --merange 16 --partitions all --subme 9 --trellis 2 --rc-lookahead 60 -o bbc-r_m720p.h264 - Expected Results: The video gets encoded all the way through. Actual Results: x264 crashes after 24 frames. Regression: I tested on Mac OS X, but the bug has been independently reproduced with clang on Linux. See here: http://mailman.videolan.org/pipermail/x264-devel/2012-January/009027.html Compiling the file encoder/analyse.c from x264 with -O1 instead of -O3 fixes the problem. Compiling x264 with llvm-gcc instead of clang also fixes 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 Jan 26 04:15:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 10:15:13 +0000 Subject: [LLVMbugs] [Bug 11823] dragonegg port to mingw causes link error In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11823 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #15 from Duncan Sands 2012-01-26 04:15:13 CST --- This commit confirmed as fixing the problem: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120123/135610.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 Thu Jan 26 06:34:34 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 12:34:34 +0000 Subject: [LLVMbugs] [Bug 11860] New: ARM: floating-point arguments of variadic functions passed incorrectly with AAPCS-VFP ABI Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11860 Bug #: 11860 Summary: ARM: floating-point arguments of variadic functions passed incorrectly with AAPCS-VFP ABI Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: mans at mansr.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7948 --> http://llvm.org/bugs/attachment.cgi?id=7948 Fix vararg calls with float arguments under AAPCS-VFP ABI Calls to variadic functions should always use the base AAPCS variant, even with AAPCS-VFP is in use. This is currently broken as demonstrated by this test: float foo(float x, ...); float bar(void) { return foo(0.0); } Using -mfloat-abi hard, this compiles to the following: 00000000 : 0: e92d4800 push {r11, lr} 4: ed9f0a01 vldr s0, [pc, #4] ; 10 8: ebfffffe bl 0 c: e8bd8800 pop {r11, pc} 10: 00000000 andeq r0, r0, r0 The attached patch fixes 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 Jan 26 11:57:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 17:57:13 +0000 Subject: [LLVMbugs] [Bug 11765] Assertion in register scavenger In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11765 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Jakob Stoklund Olesen 2012-01-26 11:57:13 CST --- Fixed in r149069. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 12:35:39 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 18:35:39 +0000 Subject: [LLVMbugs] [Bug 11861] New: -verify-coalescing fails Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11861 Bug #: 11861 Summary: -verify-coalescing fails Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7949 --> http://llvm.org/bugs/attachment.cgi?id=7949 Testcase Consider the attached testcase. Running llc -verify-coalescing produces and 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 Thu Jan 26 13:16:01 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 19:16:01 +0000 Subject: [LLVMbugs] [Bug 11862] New: [AVX] incorrect code in attempted callee-save of ymm registers on Windows Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11862 Bug #: 11862 Summary: [AVX] incorrect code in attempted callee-save of ymm registers on Windows Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7950 --> http://llvm.org/bugs/attachment.cgi?id=7950 test case The attached test case shows a simple recursive function that computes a vector result, using a mask to determine which vector elements to update (and continuing recursively until all elements have turned off their respective mask value.) On Windows, the first four vector values are computed correctly, but the last four are incorrect: > llc -mattr=+avx a.ll -o foo.obj > cl a.cpp foo.obj > a.exe result[0] = 1.000000, expected 1.000000 result[1] = 3.000000, expected 3.000000 result[2] = 6.000000, expected 6.000000 result[3] = 10.000000, expected 10.000000 result[4] = 0.000000, expected 15.000000 ERROR result[5] = 0.000000, expected 21.000000 ERROR result[6] = 0.000000, expected 28.000000 ERROR result[7] = 0.000000, expected 36.000000 ERROR > (If I comment out the target triple info in the bitcode, the correct results are computed on OSX.) Looking at the assembly on Windows, the issue seems to be that it's trying to callee save ymm6 and ymm7 before using them, but it is only storing the xmm part of the registers: vmovaps %xmm7, -32(%rbp) # 16-byte Spill vmovaps %xmm6, -16(%rbp) # 16-byte Spill (So that's obviously a problem when it just restores the xmm part before returning.) However, my weak understanding of Windows ABIs is that only the xmm part of xmm6-xmm15 is callee save. So perhaps the real issue is that the instructions after the recursive call treat all of ymm6 and ymm7 as having been callee saved? callq f___vyf vaddps %ymm6, %ymm0, %ymm0 vblendvps %ymm7, %ymm0, %ymm6, %ymm6 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 14:48:08 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 20:48:08 +0000 Subject: [LLVMbugs] [Bug 11863] New: attribute((nonnull)) not checked on c++ operators Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11863 Bug #: 11863 Summary: attribute((nonnull)) not checked on c++ operators Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: struct foo {}; bool operator!=(const foo &, void *) __attribute__((nonnull(2))); bool test(const foo &f) { return f != 0; } nlewycky at ducttape:~$ g++ str2.cc -fsyntax-only -Wall str2.cc: In function ?bool test(const foo&)?: str2.cc:6: warning: null argument where non-null required (argument 2) vs. nlewycky at ducttape:~$ clang++ str2.cc -fsyntax-only -Wall nlewycky at ducttape:~$ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 16:59:48 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 22:59:48 +0000 Subject: [LLVMbugs] [Bug 11862] [AVX] incorrect code in attempted callee-save of ymm registers on Windows In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11862 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Jakob Stoklund Olesen 2012-01-26 16:59:48 CST --- Fixed in r149088. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 17:28:08 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 26 Jan 2012 23:28:08 +0000 Subject: [LLVMbugs] [Bug 11348] Running scan-build on a ARC project results in tons of errors In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11348 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #7 from Ted Kremenek 2012-01-26 17:28:08 CST --- (In reply to comment #6) > Hi, I have had the same issue with ARC'd code (I raised bug 11845 before I > realised this was a duplicate). When I apply your latest revision I get this > issue: > > error: -fobjc-arc is not supported with fragile abi > > I therefore modified ccc-analyzer as follows:- > > added in '-fobjc-abi-version' => 2 in the CompileOptionMap > > This fixed the issue although the analyse took a long time (seems to firstly > compile all the sources, then run analyse on all sources). -fobjc-abi-version always has '=', so it should be: '-fobjc-abi-version' => 0 Does that not work? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 20:24:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 02:24:11 +0000 Subject: [LLVMbugs] [Bug 11793] access control somehow suppressed in for-in loop container expression In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11793 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from John McCall 2012-01-26 20:24:11 CST --- Fixed in r149109. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 20:54:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 02:54:46 +0000 Subject: [LLVMbugs] [Bug 11865] New: alias example that gas accepts and MC doesn't Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11865 Bug #: 11865 Summary: alias example that gas accepts and MC doesn't Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified i: .long g g = h h = i llvm-mc rejects it with test.s:4:5: error: invalid assignment to 'h' h = i -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 23:24:33 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 05:24:33 +0000 Subject: [LLVMbugs] [Bug 11866] New: linkonce_odr symbol shows up in library when using lto Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11866 Bug #: 11866 Summary: linkonce_odr symbol shows up in library when using lto Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Interprocedural Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Linking this IL file -------------------------- %struct.foo = type { i8 } define void @_Z3zedP3foo(%struct.foo* nocapture %x) uwtable optsize ssp { tail call void @_ZN3foo3barEv(%struct.foo* undef) optsize ret void } define linkonce_odr void @_ZN3foo3barEv(%struct.foo* nocapture %this) uwtable optsize noinline ssp align 2 { tail call void @_Z1fv() optsize ret void } declare void @_Z1fv() optsize ---------------------- with a regular object file defining _Z1fv with ld -shared -o t.so test.o test2.o -plugin LLVMgold.so -plugin-opt generate-api-file produces a .so with _ZN3foo3barEv visible (it is also included in the apifile). Given the definition of linkonce_odr, we should be able to avoid including 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 Fri Jan 27 01:55:03 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 07:55:03 +0000 Subject: [LLVMbugs] [Bug 11028] clang trunk r140637 is not defining preprocessor macros correctly on linux/ppc64 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11028 Jeremy Huddleston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Jeremy Huddleston 2012-01-27 01:55:03 CST --- r141772 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 01:59:43 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 07:59:43 +0000 Subject: [LLVMbugs] [Bug 11867] New: __SIZEOF_LONG_DOUBLE__ and __SIZE_TYPE__ are incorrect on Linux/ppc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11867 Bug #: 11867 Summary: __SIZEOF_LONG_DOUBLE__ and __SIZE_TYPE__ are incorrect on Linux/ppc Product: clang Version: trunk Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jeremyhu at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I mentioned this in #11028, but that ticket focused more on the __linux__ issue, so this is a separate followup. $ echo "" | /opt/llvm/bin/clang -E -dM - | sort -u > /tmp/clang.pp $ echo "" | /usr/bin/gcc -E -dM - | sort -u > /tmp/gcc.pp $ diff -Naurp /tmp/{gcc,clang}.pp | grep SIZE -#define __SIZE_MAX__ 4294967295U #define __SIZEOF_DOUBLE__ 8 #define __SIZEOF_FLOAT__ 4 #define __SIZEOF_INT__ 4 #define __SIZEOF_LONG__ 4 -#define __SIZEOF_LONG_DOUBLE__ 16 +#define __SIZEOF_LONG_DOUBLE__ 8 #define __SIZEOF_LONG_LONG__ 8 #define __SIZEOF_POINTER__ 4 #define __SIZEOF_PTRDIFF_T__ 4 #define __SIZEOF_SIZE_T__ 4 #define __SIZEOF_WCHAR_T__ 4 #define __SIZEOF_WINT_T__ 4 -#define __SIZE_TYPE__ unsigned int +#define __SIZE_TYPE__ long unsigned int +#define __SIZE_WIDTH__ 32 $ /opt/llvm/bin/clang --version clang version 3.1 (trunk 149121) Target: powerpc-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 Fri Jan 27 03:49:21 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 09:49:21 +0000 Subject: [LLVMbugs] [Bug 11868] New: Assertion with -verify-coalescing Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11868 Bug #: 11868 Summary: Assertion with -verify-coalescing Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7958 --> http://llvm.org/bugs/attachment.cgi?id=7958 Testcase Consider attached testcase. Right now llc -verify-coalescing just crashes (also showing some code 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 Fri Jan 27 04:16:10 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 10:16:10 +0000 Subject: [LLVMbugs] [Bug 11869] New: `extern "C" extern void foo(); ` shouldn't compile Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11869 Bug #: 11869 Summary: `extern "C" extern void foo();` shouldn't compile Product: clang Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: timurrrr at google.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat double_extern.cpp extern "C" extern void foo(); $ g++ -c double_extern.cpp double_extern.cpp:1: error: invalid use of ?extern? in linkage specification $ clang++ -c double_extern.cpp OK $ clang++ --version clang++ --version clang version 3.1 (trunk 145532) Target: x86_64-unknown-linux-gnu Thread model: posix Also I know that this bug is still present in Clang as a similar code was found in AddressSanitizer which is a part of Clang codebase. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 08:48:31 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 14:48:31 +0000 Subject: [LLVMbugs] [Bug 11428] errc, io_errc and future_errc constants should really be scoped enums In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11428 Elias Pipping changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |pipping at exherbo.org Resolution|FIXED | --- Comment #4 from Elias Pipping 2012-01-27 08:48:31 CST --- As a result of this change(*), libc++ fails to compile for me: + clang++ -c -g -Os -fPIC -std=c++0x -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wnewline-eof -Wpadded -Wmissing-prototypes -Wstrict-aliasing=2 -Wstrict-overflow=4 -nostdinc++ -I../include ../src/future.cpp ../src/future.cpp:42:10: error: value of type 'std::__1::future_errc' is not implicitly convertible to 'int' case future_errc::no_state: ^~~~~~~~~~~~~~~~~~~~~ ../src/future.cpp:40:10: error: value of type 'std::__1::future_errc' is not implicitly convertible to 'int' case future_errc::promise_already_satisfied: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../src/future.cpp:37:10: error: value of type 'std::__1::future_errc' is not implicitly convertible to 'int' case future_errc::future_already_retrieved: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../src/future.cpp:34:10: error: value of type 'std::__1::future_errc' is not implicitly convertible to 'int' case future_errc::broken_promise: ^~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 errors generated. This is on linux with clang from git. (*) `git bisect` told 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 Fri Jan 27 09:15:50 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 15:15:50 +0000 Subject: [LLVMbugs] [Bug 11840] libc++ linux compile error In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11840 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Howard Hinnant 2012-01-27 09:15:50 CST --- *** This bug has been marked as a duplicate of bug 11428 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 09:55:44 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 15:55:44 +0000 Subject: [LLVMbugs] [Bug 11870] New: false positive leak checking for objects in collection classes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11870 Bug #: 11870 Summary: false positive leak checking for objects in collection classes Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: mayer.julian at googlemail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified checker claims there is a leak in this piece of code although there obviously isn't: NSObject *o = [[NSObject alloc] init]; NSArray *a = [[NSArray alloc] initWithObjects:o, nil]; for (NSObject *i in a) [i release]; [a release]; main.m:15:23: warning: Potential leak of an object allocated on line 15 and stored into 'o' NSObject *o = [[NSObject alloc] init]; ^ 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 Fri Jan 27 10:38:52 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 16:38:52 +0000 Subject: [LLVMbugs] [Bug 11871] New: cin does not properly parse double from a certain input stream Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11871 Bug #: 11871 Summary: cin does not properly parse double from a certain input stream Product: libc++ Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: rework11 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7964 --> http://llvm.org/bugs/attachment.cgi?id=7964 libc++ cin parsing test Given "2+" or "2-" as an input stream from keyboard, cin fails to parse it and makes cin.fail() true instead of reading in "2" and leaving "+" or "-" behind in the input stream. Attachment is the code to reproduce this behavior; it occurs only when linked against libc++. After executing the code, type in any floating-point number immediately followed by a + or - character without a space in-between. -- Mac OS X 10.7.2 apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.2.0 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 Fri Jan 27 12:24:05 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 18:24:05 +0000 Subject: [LLVMbugs] [Bug 11872] New: Large stack object causes llc to use up all memory Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11872 Bug #: 11872 Summary: Large stack object causes llc to use up all memory Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Running llc on the following test uses up all memory on my machine. Probably codegen should detect and error out on huge stack frames. target triple = "x86_64-unknown-linux-gnu" %struct.frame_overflow__bitmap_t = type { [9223372036854775807 x i8] } define void @frame_overflow() { entry: %memtmp = alloca %struct.frame_overflow__bitmap_t, align 8 ret void } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 15:25:30 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 21:25:30 +0000 Subject: [LLVMbugs] [Bug 11845] Clang scan-build does not recognise ARC'd code In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11845 mandy changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #5 from mandy 2012-01-27 15:25:30 CST --- *** This bug has been marked as a duplicate of bug 11348 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 15:31:26 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 27 Jan 2012 21:31:26 +0000 Subject: [LLVMbugs] [Bug 11348] Running scan-build on a ARC project results in tons of errors In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11348 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #11 from Ted Kremenek 2012-01-27 15:31:26 CST --- Great. Marking this as resolved. Will pick up in checker-261. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 18:24:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 28 Jan 2012 00:24:16 +0000 Subject: [LLVMbugs] [Bug 11873] New: LLVM IR Code Generation Error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11873 Bug #: 11873 Summary: LLVM IR Code Generation Error Product: clang Version: 3.0 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: don.holly at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When calling a property name on an Objective-C class that is not synthesized, the IR code generation fails. I must explicitly call the getter/setter. No warnings are shown and the class fails to compile with the following errors: 1. /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m:362:1: current parser token '-' 2. /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m:340:1: LLVM IR generation of declaration 'OTPublisher::buildVideoPreviewLayer' 3. /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m:341:1: LLVM IR generation of compound statement ('{}') FULL TRACE: Distributed-CompileC /Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Intermediates/opentok-ios-sdk.build/Debug-iphoneos/opentok-ios-sdk.build/Objects-normal/armv7/OTPublisher.o opentok-ios-sdk/OTPublisher.m normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler cd /Users/dholly/Projects/tokbox/opentok-ios-sdk setenv DISTCC_COMPILER "Apple clang version 3.0 (tags/Apple/clang-211.9) (based on LLVM 3.0svn)" setenv DISTCC_DIR /Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Intermediates/opentok-ios-sdk.build/Debug-iphoneos/opentok-ios-sdk.build/distcc.tmp setenv DISTCC_HOSTS localhost setenv DISTCC_SYSTEM "10.7.2 (11C74, x86_64)" setenv LANG en_US.US-ASCII setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin" /Developer/usr/bin/distcc /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -x objective-c -arch armv7 -fmessage-length=0 -fdiagnostics-print-source-range-info -fdiagnostics-show-category=id -fdiagnostics-parseable-fixits -std=gnu99 -fobjc-arc -Wno-trigraphs -fpascal-strings -O0 -Wmissing-prototypes -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-shorten-64-to-32 -DDEBUG=1 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk -gdwarf-2 -Wno-sign-conversion -mthumb "-DIBOutlet=__attribute__((iboutlet))" "-DIBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName)))" "-DIBAction=void)__attribute__((ibaction)" -miphoneos-version-min=5.0 -I/Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Intermediates/opentok-ios-sdk.build/Debug-iphoneos/opentok-ios-sdk.build/Opentok.hmap -I/Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Products/Debug-iphoneos/include -I../ios-livu -I../ios-livu/AVCEncoder -I../ios-livu/ffmpeg -I../ios-livu/Livu -I../ios-livu/speex-1.2rc1 -I../ios-livu/sRTP -I../ios-livu/sRTSP -I../ios-livu/AVCEncoder/AVCEncoder -I../ios-livu/ffmpeg/include -I../ios-livu/ffmpeg/lib -I../ios-livu/Livu/ApplicationTests -I../ios-livu/Livu/assets -I../ios-livu/Livu/Classes -I../ios-livu/Livu/images -I../ios-livu/Livu/libLivu -I../ios-livu/Livu/LogicTests -I../ios-livu/Livu/MongooseDaemon -I../ios-livu/speex-1.2rc1/doc -I../ios-livu/speex-1.2rc1/include -I../ios-livu/speex-1.2rc1/iphone -I../ios-livu/speex-1.2rc1/libspeex -I../ios-livu/speex-1.2rc1/src -I../ios-livu/speex-1.2rc1/symbian -I../ios-livu/speex-1.2rc1/ti -I../ios-livu/speex-1.2rc1/win32 -I../ios-livu/sRTP/sRTP -I../ios-livu/sRTSP/sRTSP -I../ios-livu/ffmpeg/include/libavcodec -I../ios-livu/ffmpeg/include/libavdevice -I../ios-livu/ffmpeg/include/libavfilter -I../ios-livu/ffmpeg/include/libavformat -I../ios-livu/ffmpeg/include/libavutil -I../ios-livu/ffmpeg/include/libswscale -I../ios-livu/Livu/assets/appstore -I../ios-livu/Livu/assets/images -I../ios-livu/Livu/assets/iStock_000013027002Illustra -I../ios-livu/Livu/assets/svg -I../ios-livu/Livu/assets/website -I../ios-livu/Livu/images/icons -I../ios-livu/Livu/images/LivuConfigView -I../ios-livu/Livu/images/LivuView -I../ios-livu/speex-1.2rc1/include/speex -I../ios-livu/speex-1.2rc1/iphone/speex -I../ios-livu/speex-1.2rc1/libspeex/.deps -I../ios-livu/speex-1.2rc1/src/.deps -I../ios-livu/speex-1.2rc1/ti/speex_C54_test -I../ios-livu/speex-1.2rc1/ti/speex_C55_test -I../ios-livu/speex-1.2rc1/ti/speex_C64_test -I../ios-livu/speex-1.2rc1/win32/libspeex -I../ios-livu/speex-1.2rc1/win32/speexdec -I../ios-livu/speex-1.2rc1/win32/speexenc -I../ios-livu/speex-1.2rc1/win32/VS2003 -I../ios-livu/speex-1.2rc1/win32/VS2005 -I../ios-livu/speex-1.2rc1/win32/VS2008 -I../ios-livu/Livu/assets/images/icons -I../ios-livu/Livu/assets/images/LivuConfigView -I../ios-livu/Livu/assets/images/LivuView -I../ios-livu/speex-1.2rc1/iphone/speex/speex -I../ios-livu/speex-1.2rc1/win32/VS2003/libspeex -I../ios-livu/speex-1.2rc1/win32/VS2003/libspeexdsp -I../ios-livu/speex-1.2rc1/win32/VS2003/speexdec -I../ios-livu/speex-1.2rc1/win32/VS2003/speexenc -I../ios-livu/speex-1.2rc1/win32/VS2003/tests -I../ios-livu/speex-1.2rc1/win32/VS2005/libspeex -I../ios-livu/speex-1.2rc1/win32/VS2005/libspeexdsp -I../ios-livu/speex-1.2rc1/win32/VS2005/speexdec -I../ios-livu/speex-1.2rc1/win32/VS2005/speexenc -I../ios-livu/speex-1.2rc1/win32/VS2005/tests -I../ios-livu/speex-1.2rc1/win32/VS2008/libspeex -I../ios-livu/speex-1.2rc1/win32/VS2008/libspeexdsp -I../ios-livu/speex-1.2rc1/win32/VS2008/speexdec -I../ios-livu/speex-1.2rc1/win32/VS2008/speexenc -I../ios-livu/speex-1.2rc1/win32/VS2008/tests -I../ios-rtsp-poc/SupportingProjects -I../ios-rtsp-poc/SupportingProjects/DecoderWrapper -I../ios-rtsp-poc/SupportingProjects/Live555 -I../ios-rtsp-poc/SupportingProjects/RTSPClient -I../ios-rtsp-poc/SupportingProjects/Live555/src -I../ios-rtsp-poc/SupportingProjects/Live555/src/BasicUsageEnvironment -I../ios-rtsp-poc/SupportingProjects/Live555/src/groupsock -I../ios-rtsp-poc/SupportingProjects/Live555/src/liveMedia -I../ios-rtsp-poc/SupportingProjects/Live555/src/UsageEnvironment -I../ios-rtsp-poc/SupportingProjects/Live555/src/BasicUsageEnvironment/include -I../ios-rtsp-poc/SupportingProjects/Live555/src/groupsock/include -I../ios-rtsp-poc/SupportingProjects/Live555/src/liveMedia/include -I../ios-rtsp-poc/SupportingProjects/Live555/src/UsageEnvironment/include -I../ios-rumor -I../ios-rumor/ios-rumor -I../ios-rumor/ios-rumorTests -I../ios-rumor/sample -I../ios-rumor/ios-rumor/JSON -I../ios-rumor/ios-rumor/model -I../ios-rumor/ios-rumor/state -I../ios-rumor/ios-rumor/wowza -I../ios-rumor/sample/ios-rumor-sample -I../ios-rumor/sample/ios-rumor-sample/ios-rumor-sample -I../ios-rumor/sample/ios-rumor-sample/ios-rumor-sampleTests -I../ios-havelock -I../ios-havelock/ios-havelock -I../ios-havelock/ios-havelockTests -I../ios-havelock/sample -I../ios-havelock/ios-havelock/util -I../ios-havelock/ios-havelock/vo -I../ios-havelock/sample/ios-havelock-sample -I../ios-havelock/sample/ios-havelock-sample/ios-havelock-sample -I../ios-havelock/sample/ios-havelock-sample/ios-havelock-sampleTests -I../ios-common -I../ios-common/ios-common -I../ios-common/ios-commonTests -I../ios-common/ios-common/lib -I../ios-common/ios-common/utils -I../ios-common/ios-common/lib/AFNetworking -I../ios-common/ios-common/lib/TBXML -I/Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Intermediates/opentok-ios-sdk.build/Debug-iphoneos/opentok-ios-sdk.build/DerivedSources/armv7 -I/Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Intermediates/opentok-ios-sdk.build/Debug-iphoneos/opentok-ios-sdk.build/DerivedSources -fpch-preprocess -F/Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Products/Debug-iphoneos -include /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/opentok-ios-sdk-Prefix.pch -c /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m -o /Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Intermediates/opentok-ios-sdk.build/Debug-iphoneos/opentok-ios-sdk.build/Objects-normal/armv7/OTPublisher.o In file included from ../ios-livu/Livu/libLivu/LibLivu.h:12: In file included from /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m:21: ../ios-livu/Livu/Classes/OTNetworkPublisher.h:41:43: warning: cannot find protocol definition for 'AACEncoderDelegate' [3] @interface OTNetworkPublisher : NSObject { ^ 0 clang 0x0000000100de1022 _ZL15PrintStackTracePv + 34 1 clang 0x0000000100de14f9 _ZL13SignalHandleri + 633 2 libsystem_c.dylib 0x00007fff9540bcfa _sigtramp + 26 3 libsystem_c.dylib 0x00007fff5fbf93c0 _sigtramp + 18446744072811894496 4 clang 0x000000010064a2a0 clang::CodeGen::CodeGenFunction::EmitARCStoreStrong(clang::BinaryOperator const*, bool) + 448 5 clang 0x000000010063d274 clang::StmtVisitorBase::Visit(clang::Stmt*) + 3220 6 clang 0x0000000100116148 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 72 7 clang 0x00000001002abf99 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) + 57 8 clang 0x00000001002ae739 clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 41 9 clang 0x0000000100115772 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 194 10 clang 0x0000000100115d2b clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 267 11 clang 0x0000000100115ae8 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 152 12 clang 0x00000001001156d0 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 32 13 clang 0x000000010064459a clang::CodeGen::CodeGenFunction::GenerateObjCMethod(clang::ObjCMethodDecl const*) + 58 14 clang 0x000000010006e431 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 881 15 clang 0x000000010006e09f (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 95 16 clang 0x000000010006e011 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 161 17 clang 0x00000001000420f2 clang::ParseAST(clang::Sema&, bool) + 290 18 clang 0x0000000100040baf clang::CodeGenAction::ExecuteAction() + 671 19 clang 0x000000010002cafb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 875 20 clang 0x000000010002ab78 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2696 21 clang 0x000000010001f365 cc1_main(char const**, char const**, char const*, void*) + 5333 22 clang 0x000000010000256b main + 667 23 clang 0x00000001000022c4 start + 52 Stack dump: 0. Program arguments: /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -cc1 -triple thumbv7-apple-ios5.0.0 -S -disable-free -disable-llvm-verifier -main-file-name OTPublisher.m -pic-level 1 -mdisable-fp-elim -relaxed-aliasing -target-abi apcs-gnu -target-cpu cortex-a8 -mfloat-abi soft -target-feature +soft-float-abi -target-linker-version 123.4.1 -g -coverage-file /var/folders/gv/1hzh6zxj5rz4wb8r5wz038j80000gs/T/cc-4RWs7t.s -resource-dir /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/../lib/clang/3.0 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk -include /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/opentok-ios-sdk-Prefix.pch -D DEBUG=1 -D IBOutlet=__attribute__((iboutlet)) -D IBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName))) -D IBAction=void)__attribute__((ibaction) -I /Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Intermediates/opentok-ios-sdk.build/Debug-iphoneos/opentok-ios-sdk.build/Opentok.hmap -I /Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Products/Debug-iphoneos/include -I ../ios-livu -I ../ios-livu/AVCEncoder -I ../ios-livu/ffmpeg -I ../ios-livu/Livu -I ../ios-livu/speex-1.2rc1 -I ../ios-livu/sRTP -I ../ios-livu/sRTSP -I ../ios-livu/AVCEncoder/AVCEncoder -I ../ios-livu/ffmpeg/include -I ../ios-livu/ffmpeg/lib -I ../ios-livu/Livu/ApplicationTests -I ../ios-livu/Livu/assets -I ../ios-livu/Livu/Classes -I ../ios-livu/Livu/images -I ../ios-livu/Livu/libLivu -I ../ios-livu/Livu/LogicTests -I ../ios-livu/Livu/MongooseDaemon -I ../ios-livu/speex-1.2rc1/doc -I ../ios-livu/speex-1.2rc1/include -I ../ios-livu/speex-1.2rc1/iphone -I ../ios-livu/speex-1.2rc1/libspeex -I ../ios-livu/speex-1.2rc1/src -I ../ios-livu/speex-1.2rc1/symbian -I ../ios-livu/speex-1.2rc1/ti -I ../ios-livu/speex-1.2rc1/win32 -I ../ios-livu/sRTP/sRTP -I ../ios-livu/sRTSP/sRTSP -I ../ios-livu/ffmpeg/include/libavcodec -I ../ios-livu/ffmpeg/include/libavdevice -I ../ios-livu/ffmpeg/include/libavfilter -I ../ios-livu/ffmpeg/include/libavformat -I ../ios-livu/ffmpeg/include/libavutil -I ../ios-livu/ffmpeg/include/libswscale -I ../ios-livu/Livu/assets/appstore -I ../ios-livu/Livu/assets/images -I ../ios-livu/Livu/assets/iStock_000013027002Illustra -I ../ios-livu/Livu/assets/svg -I ../ios-livu/Livu/assets/website -I ../ios-livu/Livu/images/icons -I ../ios-livu/Livu/images/LivuConfigView -I ../ios-livu/Livu/images/LivuView -I ../ios-livu/speex-1.2rc1/include/speex -I ../ios-livu/speex-1.2rc1/iphone/speex -I ../ios-livu/speex-1.2rc1/libspeex/.deps -I ../ios-livu/speex-1.2rc1/src/.deps -I ../ios-livu/speex-1.2rc1/ti/speex_C54_test -I ../ios-livu/speex-1.2rc1/ti/speex_C55_test -I ../ios-livu/speex-1.2rc1/ti/speex_C64_test -I ../ios-livu/speex-1.2rc1/win32/libspeex -I ../ios-livu/speex-1.2rc1/win32/speexdec -I ../ios-livu/speex-1.2rc1/win32/speexenc -I ../ios-livu/speex-1.2rc1/win32/VS2003 -I ../ios-livu/speex-1.2rc1/win32/VS2005 -I ../ios-livu/speex-1.2rc1/win32/VS2008 -I ../ios-livu/Livu/assets/images/icons -I ../ios-livu/Livu/assets/images/LivuConfigView -I ../ios-livu/Livu/assets/images/LivuView -I ../ios-livu/speex-1.2rc1/iphone/speex/speex -I ../ios-livu/speex-1.2rc1/win32/VS2003/libspeex -I ../ios-livu/speex-1.2rc1/win32/VS2003/libspeexdsp -I ../ios-livu/speex-1.2rc1/win32/VS2003/speexdec -I ../ios-livu/speex-1.2rc1/win32/VS2003/speexenc -I ../ios-livu/speex-1.2rc1/win32/VS2003/tests -I ../ios-livu/speex-1.2rc1/win32/VS2005/libspeex -I ../ios-livu/speex-1.2rc1/win32/VS2005/libspeexdsp -I ../ios-livu/speex-1.2rc1/win32/VS2005/speexdec -I ../ios-livu/speex-1.2rc1/win32/VS2005/speexenc -I ../ios-livu/speex-1.2rc1/win32/VS2005/tests -I ../ios-livu/speex-1.2rc1/win32/VS2008/libspeex -I ../ios-livu/speex-1.2rc1/win32/VS2008/libspeexdsp -I ../ios-livu/speex-1.2rc1/win32/VS2008/speexdec -I ../ios-livu/speex-1.2rc1/win32/VS2008/speexenc -I ../ios-livu/speex-1.2rc1/win32/VS2008/tests -I ../ios-rtsp-poc/SupportingProjects -I ../ios-rtsp-poc/SupportingProjects/DecoderWrapper -I ../ios-rtsp-poc/SupportingProjects/Live555 -I ../ios-rtsp-poc/SupportingProjects/RTSPClient -I ../ios-rtsp-poc/SupportingProjects/Live555/src -I ../ios-rtsp-poc/SupportingProjects/Live555/src/BasicUsageEnvironment -I ../ios-rtsp-poc/SupportingProjects/Live555/src/groupsock -I ../ios-rtsp-poc/SupportingProjects/Live555/src/liveMedia -I ../ios-rtsp-poc/SupportingProjects/Live555/src/UsageEnvironment -I ../ios-rtsp-poc/SupportingProjects/Live555/src/BasicUsageEnvironment/include -I ../ios-rtsp-poc/SupportingProjects/Live555/src/groupsock/include -I ../ios-rtsp-poc/SupportingProjects/Live555/src/liveMedia/include -I ../ios-rtsp-poc/SupportingProjects/Live555/src/UsageEnvironment/include -I ../ios-rumor -I ../ios-rumor/ios-rumor -I ../ios-rumor/ios-rumorTests -I ../ios-rumor/sample -I ../ios-rumor/ios-rumor/JSON -I ../ios-rumor/ios-rumor/model -I ../ios-rumor/ios-rumor/state -I ../ios-rumor/ios-rumor/wowza -I ../ios-rumor/sample/ios-rumor-sample -I ../ios-rumor/sample/ios-rumor-sample/ios-rumor-sample -I ../ios-rumor/sample/ios-rumor-sample/ios-rumor-sampleTests -I ../ios-havelock -I ../ios-havelock/ios-havelock -I ../ios-havelock/ios-havelockTests -I ../ios-havelock/sample -I ../ios-havelock/ios-havelock/util -I ../ios-havelock/ios-havelock/vo -I ../ios-havelock/sample/ios-havelock-sample -I ../ios-havelock/sample/ios-havelock-sample/ios-havelock-sample -I ../ios-havelock/sample/ios-havelock-sample/ios-havelock-sampleTests -I ../ios-common -I ../ios-common/ios-common -I ../ios-common/ios-commonTests -I ../ios-common/ios-common/lib -I ../ios-common/ios-common/utils -I ../ios-common/ios-common/lib/AFNetworking -I ../ios-common/ios-common/lib/TBXML -I /Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Intermediates/opentok-ios-sdk.build/Debug-iphoneos/opentok-ios-sdk.build/DerivedSources/armv7 -I /Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Intermediates/opentok-ios-sdk.build/Debug-iphoneos/opentok-ios-sdk.build/DerivedSources -F/Users/dholly/Library/Developer/Xcode/DerivedData/TokTime-ajsckbtcxmahmqegalawmxqtazgv/Build/Products/Debug-iphoneos -O0 -Wno-trigraphs -Wmissing-prototypes -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-shorten-64-to-32 -Wno-sign-conversion -std=gnu99 -fno-dwarf2-cfi-asm -ferror-limit 19 -fmessage-length 0 -fdiagnostics-print-source-range-info -fdiagnostics-parseable-fixits -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-runtime-has-terminate -fobjc-nonfragile-abi -fobjc-arc -fobjc-exceptions -fexceptions -fsjlj-exceptions -fpascal-strings -fdiagnostics-show-option -fdiagnostics-show-category id -o /var/folders/gv/1hzh6zxj5rz4wb8r5wz038j80000gs/T/cc-4RWs7t.s -x objective-c /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m 1. /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m:362:1: current parser token '-' 2. /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m:340:1: LLVM IR generation of declaration 'OTPublisher::buildVideoPreviewLayer' 3. /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m:341:1: LLVM IR generation of compound statement ('{}') clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) distcc[61291] ERROR: compile /Users/dholly/Projects/tokbox/opentok-ios-sdk/opentok-ios-sdk/OTPublisher.m on localhost failed with exit code 254 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 19:25:30 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 28 Jan 2012 01:25:30 +0000 Subject: [LLVMbugs] [Bug 11874] New: bad diagnostics when class-name and function name conflict Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11874 Bug #: 11874 Summary: bad diagnostics when class-name and function name conflict 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: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: void foo(); class foo {}; class bar { bar() { const foo* f1 = 0; // Good but not perfect. foo* f2 = 0; // Bad diagnostic. foo f3; // Terrible diagnostic!! } }; This produces: b5933700.cc:6:11: error: must use 'class' tag to refer to type 'foo' in this scope const foo* f1 = 0; ^ class b5933700.cc:7:10: error: use of undeclared identifier 'f2' foo* f2 = 0; ^ b5933700.cc:8:8: error: expected ';' after expression foo f3; ^ ; b5933700.cc:8:9: error: use of undeclared identifier 'f3' foo f3; ^ b5933700.cc:8:5: warning: expression result unused [-Wunused-value] foo f3; ^~~ 1 warning and 4 errors generated. For f1 we get a nice diagnostic with a fixit, but the user doesn't know why this class needs a class keyword on it. (Uhm, this isn't C.) This is actually the only issue reported by the user. For f2 we aren't given an obvious declstmt vs. expression distinguishing point, so we're left multiplying against an undeclared variable. Oops. But our behaviour on f3 is atrocious with three errors on a single line, one of which is a wrong fixit, and should be easier to detect than the f2 case. We named a function then followed with a space and an undeclared name. Given that the function is also a type, we could've spotted that! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 20:48:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 28 Jan 2012 02:48:16 +0000 Subject: [LLVMbugs] [Bug 11875] New: MSVC-built clang passes wrong arguments to gcc when used in msys Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11875 Bug #: 11875 Summary: MSVC-built clang passes wrong arguments to gcc when used in msys Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: derek.buitenhuis at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Start off by compiling Clang as so: cmake -DSubversion_SVN_EXECUTABLE="C:/Users/.../Desktop/svn-win32-1.7.2/svn/bin/svn.exe" -DCMAKE_BUILD_TYPE="Release" -DLLVM_APPEND_VC_REV=ON -DCMAKE_INSTALL_PREFIX="C:/Msys/1.0/clang" -G "Visual Studio 10" ..\llvm msbuild LLVM.sln /t:ALL_BUILD /maxcpucount:4 /p:Configuration=Release /p:Platform=Win32 msbuild INSTALL.vcxproj /p:Configuration=Release /p:Platform=Win32 Now rename clang.exe to i686-w64-mingw32-clang.exe and clang++.exe to i686-w64-mingw32-clang++.exe Now let's try to compile something... $ echo "int main(){return 0;}" > a.c $ i686-w64-mingw32-clang.exe --sysroot=/mingw/i686-w64-mingw32/ a.c gcc.exe: error: i686-w64-mingw32: No such file or directory gcc.exe: error: unrecognized option '-target' i686-w64-mingw32-clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation) Hmm... $ i686-w64-mingw32-clang.exe --sysroot=/mingw/i686-w64-mingw32/ a.c -v clang version 3.1 (trunk 149146) Target: i686-w64-mingw32 Thread model: posix "c:/Msys/clang/bin/i686-w64-mingw32-clang.exe" -cc1 -triple i686-w64-mingw32 -S -disable-free -disable-llvm-verifier -main-file-name a.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -momit-leaf-frame-pointer -v -resource-dir "c:/Msys/clang/bin\\..\\lib\\clang\\3.1" -isysroot c:/Msys/1.0/mingw/i686-w64-mingw32/ -fmodule-cache-path "C:/Users/DAEMON~1/AppData/Local/Temp\\clang-module-cache" -fno-dwarf-directory-asm -fdebug-compilation-dir C:/Msys/1.0/home/Daemon404 -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-use-cxa-atexit -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -o C:/Users/DAEMON~1/AppData/Local/Temp/a-990940.s -x c a.c clang -cc1 version 3.1 based upon LLVM 3.1svn-r149146 default target i686-pc-win32 ignoring nonexistent directory "c:/Msys/1.0/mingw/i686-w64-mingw32//usr/local/include" ignoring nonexistent directory "c:/Msys/clang/bin/../lib/clang/3.1/../../../i686-w64-mingw32/include" ignoring nonexistent directory "c:/Msys/clang/bin/../lib/clang/3.1/../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "c:/Msys/1.0/mingw/i686-w64-mingw32//mingw/include" ignoring nonexistent directory "c:/mingw/include" #include "..." search starts here: #include <...> search starts here: c:/Msys/clang/bin/../lib/clang/3.1/include c:/Msys/clang/bin/../lib/clang/3.1/../../../include c:/Msys/1.0/mingw/i686-w64-mingw32//usr/include End of search list. "c:/Msys/1.0/mingw/bin/gcc.exe" -target i686-w64-mingw32 --sysroot=c:/Msys/1.0/mingw/i686-w64-mingw32/ -v -c -o C:/Users/DAEMON~1/AppData/Local/Temp/a-990941.o -x assembler C:/Users/DAEMON~1/AppData/Local/Temp/a-990940.s gcc.exe: error: i686-w64-mingw32: No such file or directory Using built-in specs. COLLECT_GCC=c:/Msys/1.0/mingw/bin/gcc.exe COLLECT_LTO_WRAPPER=c:/msys/1.0/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.6.2/lto-wrapper.exe gcc.exe: error: unrecognized option '-target' Target: i686-w64-mingw32 Configured with: ../src/configure --prefix=/mingw_new --with-sysroot=/mingw_new --with-build-sysroot=/mingw_new --build=i686-w64-mingw32 --target=i686-w64-mingw32 --enable-targets=all --with-gmp=/mingw_new/sup --with-mpfr=/mingw_new/sup --with-mpc=/mingw_new/sup --with-libelf=/mingw_new/sup --with-ppl=/mingw_new/sup --with-cloog=/mingw_new/sup --disable-ppl-version-check --disable-cloog-version-check --with-host-libstdcxx='-lstdc++ -lsupc++' --disable-shared --enable-static --disable-bootstrap --disable-win32-registry --enable-threads=win32 --enable-languages=c,c++ --enable-version-specific-runtime-libs --enable-multilib --disable-rpath --with-system-zlib --disable-werror --disable-nls --enable-decimal-float --disable-debug --enable-lto --enable-64bit --enable-largefile --enable-sjlj-exceptions --enable-fully-dynamic-string --enable-libssp --enable-libgomp Thread model: win32 gcc version 4.6.2 (multilib.generic.Komisar) (GCC) i686-w64-mingw32-clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation) This raises 2 questions: 1) Why is clang calling gcc.exe, and not i686-w64-mingw32-gcc.exe 2) Why is clang passing gcc a "-target i686-w64-mingw32" parameter, which clearly is not right. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 21:52:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 28 Jan 2012 03:52:13 +0000 Subject: [LLVMbugs] [Bug 11876] New: missed null dereference warning Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11876 Bug #: 11876 Summary: missed null dereference warning Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified I would like a couple new warnings. Testcase: class Cls {}; int foo(Cls &obj) { if (&obj == 0) return 0; return 1; } void bar() { foo(*(Cls*)0); } First of all, this was found in the wild, actually in clang/Stmt.h and reported on IRC. There's a null dereference in an attempt to form a null reference argument in bar. That should produce a warning. Secondly the callee has a check for whether the reference argument is a null. That should produce another 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 Fri Jan 27 22:03:35 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 28 Jan 2012 04:03:35 +0000 Subject: [LLVMbugs] [Bug 11828] new warning in llvm-c/Core.h In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11828 Kostya Serebryany changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Kostya Serebryany 2012-01-27 22:03:35 CST --- r148937 reverted the part of the change that caused the 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 Sat Jan 28 00:36:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 28 Jan 2012 06:36:46 +0000 Subject: [LLVMbugs] [Bug 11877] New: MC for ARM hits an assert on assembly with aliases Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11877 Bug #: 11877 Summary: MC for ARM hits an assert on assembly with aliases Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified ./bin/llvm-mc -triple arm-linux-gnueabi test.s -o test.o -filetype=obj asserts on i: .long g g = h h = i but with an x86 triple it works. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 00:42:21 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 28 Jan 2012 06:42:21 +0000 Subject: [LLVMbugs] [Bug 11865] alias example that gas accepts and MC doesn't In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11865 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Rafael ?vila de Esp?ndola 2012-01-28 00:42:21 CST --- Fixed in r149174. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 04:13:19 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 28 Jan 2012 10:13:19 +0000 Subject: [LLVMbugs] [Bug 11878] New: Narrowing conversion errors in locale.cpp on trunk clang Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11878 Bug #: 11878 Summary: Narrowing conversion errors in locale.cpp on trunk clang Product: libc++ Version: unspecified Platform: Macintosh OS/Version: All Status: NEW Severity: enhancement Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: pyry.jahkola at iki.fi CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Using a trunk version of clang, clang version 3.1 (http://llvm.org/git/clang.git a5ee6345b5af1c88262d02d248e76ad2423161a0) and having applied the fix to http://llvm.org/bugs/show_bug.cgi?id=11428 as suggested by Alberto Ganesh Barbati in the discussion, the compilation fails with the error: + clang++ -c -g -Os -arch i386 -arch x86_64 -std=c++0x -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wnewline-eof -Wpadded -Wmissing-prototypes -Wstrict-aliasing=2 -Wstrict-overflow=4 -nostdinc++ -I../include ../src/locale.cpp ../src/locale.cpp:1415:22: error: case value evaluates to -2, which cannot be narrowed to type 'size_t' (aka 'unsigned long') case -2: ^ ../src/locale.cpp:1412:22: error: case value evaluates to -1, which cannot be narrowed to type 'size_t' (aka 'unsigned long') case -1: ^ ../src/locale.cpp:1519:14: error: case value evaluates to -2, which cannot be narrowed to type 'size_t' (aka 'unsigned long') case -2: ^ ../src/locale.cpp:1518:14: error: case value evaluates to -1, which cannot be narrowed to type 'size_t' (aka 'unsigned long') case -1: ^ 4 errors generated. Apparently, the fix is to static_cast(...) the negative integer literals on the failing lines. (With these fixes, libcxx compiles on my version 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 Sat Jan 28 09:59:16 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 28 Jan 2012 15:59:16 +0000 Subject: [LLVMbugs] [Bug 11877] MC for ARM hits an assert on assembly with aliases In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11877 James Molloy changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from James Molloy 2012-01-28 09:59:16 CST --- r149180. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 18:38:04 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 29 Jan 2012 00:38:04 +0000 Subject: [LLVMbugs] [Bug 11831] -ccc-host-triple causes assert In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11831 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bob.wilson at apple.com Resolution| |FIXED --- Comment #2 from Bob Wilson 2012-01-28 18:38:04 CST --- I fixed this in clang svn r149048 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 20:34:43 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 29 Jan 2012 02:34:43 +0000 Subject: [LLVMbugs] [Bug 11879] New: Internal compiler error (assertion) during per-module optimization pass while building libc++ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11879 Bug #: 11879 Summary: Internal compiler error (assertion) during per-module optimization pass while building libc++ Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hivemaster at hotmail.de CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified With Clang revision 148703, compiling r148629 of libc++ results in an assertion during the opimization pass of locale.cpp. The preprocessed source is attached. Crash report: clang: /home/xeo/llvm/include/llvm/ADT/OwningPtr.h:34: llvm::OwningPtr::OwningPtr(const llvm::OwningPtr&) [with T = llvm::UndefValue]: Assertion `RHS.Ptr == 0 && "Only null OwningPtr's are copyable!"' failed. 0 clang 0x00000000027a882e 1 clang 0x00000000027a8621 2 libpthread.so.0 0x00007f142eaa5f60 3 libc.so.6 0x00007f142ddb8165 gsignal + 53 4 libc.so.6 0x00007f142ddbaf70 abort + 384 5 libc.so.6 0x00007f142ddb12b1 __assert_fail + 241 6 clang 0x000000000264ee0a 7 clang 0x000000000264ed6c 8 clang 0x000000000264af58 9 clang 0x0000000002648b07 10 clang 0x0000000002646877 11 clang 0x000000000263e13c llvm::UndefValue::get(llvm::Type*) + 50 12 clang 0x00000000023535e4 13 clang 0x0000000002731d68 llvm::MPPassManager::runOnModule(llvm::Module&) + 456 14 clang 0x000000000273227e llvm::PassManagerImpl::run(llvm::Module&) + 130 15 clang 0x00000000027327b9 llvm::PassManager::run(llvm::Module&) + 39 16 clang 0x0000000000cd8257 17 clang 0x0000000000cd8377 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 140 18 clang 0x0000000000cd4444 19 clang 0x0000000000e7fc31 clang::ParseAST(clang::Sema&, bool) + 761 20 clang 0x0000000000b43733 clang::ASTFrontendAction::ExecuteAction() + 265 21 clang 0x0000000000cd2fb4 clang::CodeGenAction::ExecuteAction() + 986 22 clang 0x0000000000b4338f clang::FrontendAction::Execute() + 213 23 clang 0x0000000000b1cd2b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 679 24 clang 0x0000000000aeebc7 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1002 25 clang 0x0000000000addb67 cc1_main(char const**, char const**, char const*, void*) + 990 26 clang 0x0000000000aea209 main + 484 27 libc.so.6 0x00007f142dda4c4d __libc_start_main + 253 28 clang 0x0000000000adcde9 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name locale.cpp -pic-level 2 -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -momit-leaf-frame-pointer -g -coverage-file locale.o -nostdinc++ -resource-dir /usr/local/bin/../lib/clang/3.1 -I ../include -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /usr/local/bin/../lib/clang/3.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -Os -Wall -Wextra -Wshadow -Wconversion -Wnewline-eof -Wpadded -Wmissing-prototypes -Wstrict-aliasing=2 -Wstrict-overflow=4 -std=c++0x -fdeprecated-macro -fdebug-compilation-dir /home/xeo/libcxx/lib -ferror-limit 19 -fmessage-length 80 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o locale.o -x c++ ../src/locale.cpp 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'Interprocedural Sparse Conditional Constant Propagation' on module '../src/locale.cpp'. clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/locale-dkWoca.ii clang: note: diagnostic msg: /tmp/locale-dkWoca.sh -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 23:39:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 29 Jan 2012 05:39:13 +0000 Subject: [LLVMbugs] [Bug 11880] New: Compiler crash on compiling (faulty?) IR Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11880 Bug #: 11880 Summary: Compiler crash on compiling (faulty?) IR Product: clang Version: 3.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dirkjan at ochtman.nl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I've got some code that seems to cause clang to crash. Code: target triple = "x86_64-apple-darwin11.0.0" declare i64 @write(i32, i8*, i64) declare i32 @asprintf(i8**, i8*, ...) %struct.str = type { i64, i8* } @str_NL = constant [1 x i8] c"\0a" define void @print(%struct.str* %str) { %1 = getelementptr inbounds %struct.str* %str, i64 0, i32 1 %2 = load i8** %1 %3 = getelementptr inbounds %struct.str* %str, i64 0, i32 0 %4 = load i64* %3 call i64 @write(i32 1, i8* %2, i64 %4) %6 = getelementptr inbounds [1 x i8]* @str_NL, i64 0, i64 0 call i64 @write(i32 1, i8* %6, i64 1) ret void } define %struct.str* @str(i64 %n) { %1 = alloca %struct.str %2 = getelementptr inbounds %struct.str %1, i32 1 %3 = call i32 (i8**, i8*, ...)* @asprintf(%2, [2 x i8] "%d", i64 %n) %4 = getelementptr inbounds %struct.str %1, i32 0 store i32 %3, i64* %4 ret %struct.str* %1 } @str0_data = constant [4 x i8] c"test" @str0 = internal constant %struct.str { i64 4, i8* getelementptr([4 x i8]* @str0_data, i32 0, i32 0) }, align 8 define i32 @main(i32 %argc, i8** %argv) nounwind ssp { call void @print(%struct.str* @str0) ret i32 0 } I was just working on the @str function, so there's probably something silly in there. Here's further diagnostic info as spit out by clang: 0 clang 0x0000000109359c52 llvm::SmallVectorImpl::resize(unsigned int) + 1650 1 clang 0x000000010935a0e9 llvm::SmallVectorImpl::resize(unsigned int) + 2825 2 libsystem_c.dylib 0x00007fff9117dcfa _sigtramp + 26 3 libsystem_c.dylib 0x00007fff67e1fd20 _sigtramp + 18446744073018155072 4 clang 0x0000000108273f74 clang::TextDiagnosticBuffer::~TextDiagnosticBuffer() + 3300 5 clang 0x00000001089e8248 clang::PartialDiagnostic::Storage::~Storage() + 5256 6 clang 0x00000001089e3ea2 clang::PragmaNamespace::getIfNamespace() + 18402 7 clang 0x000000010840c2e1 llvm::DenseMap, llvm::ValueMapConfig, llvm::DenseMapInfo > >, llvm::TrackingVH, llvm::DenseMapInfo, llvm::ValueMapConfig, llvm::DenseMapInfo > > >, llvm::DenseMapInfo > >::erase(llvm::ValueMapCallbackVH, llvm::ValueMapConfig, llvm::DenseMapInfo > > const&) + 3249 8 clang 0x0000000108240b0b llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 13115 9 clang 0x000000010822d024 llvm::SmallVectorImpl::insert(char const**, char const* const&) + 3348 10 clang 0x000000010822590c 11 clang 0x0000000108229628 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 760 12 clang 0x0000000108224434 13 clang 0x0000000000000026 Stack dump: 0. Program arguments: /Users/djc/src/clang/bin/clang -cc1 -triple x86_64-apple-macosx10.7.2 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name hello.lng.ll -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 128 -resource-dir /Users/djc/src/clang/bin/../lib/clang/3.0 -ferror-limit 19 -fmessage-length 100 -stack-protector 1 -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/kx/r0q_5lzx0jj0v8rkt8xq1qd40000gn/T/hello-tzCsPL.o -x ir tests/hello.lng.ll -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 29 03:09:21 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 29 Jan 2012 09:09:21 +0000 Subject: [LLVMbugs] [Bug 11860] ARM: floating-point arguments of variadic functions passed incorrectly with AAPCS-VFP ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11860 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Anton Korobeynikov 2012-01-29 03:09:21 CST --- Fixed in r149194 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 29 07:07:00 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 29 Jan 2012 13:07:00 +0000 Subject: [LLVMbugs] [Bug 11879] Internal compiler error (assertion) during per-module optimization pass while building libc++ In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11879 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |baldrick at free.fr Resolution| |FIXED --- Comment #2 from Duncan Sands 2012-01-29 07:07:00 CST --- I think you were just unlucky in the revision you checked out. This issue was resolved shortly after being introduced. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 29 11:10:31 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 29 Jan 2012 17:10:31 +0000 Subject: [LLVMbugs] [Bug 11881] New: error in backend: Cannot select Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11881 Bug #: 11881 Summary: error in backend: Cannot select Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: chenyang at cs.utah.edu, llvmbugs at cs.uiuc.edu Classification: Unclassified [regehr at gamow tmp]$ clang -v clang version 3.1 (trunk 149185) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp]$ clang -c -O2 small.c fatal error: error in backend: Cannot select: 0x2b7ebb0: i32 = shl 0x2b7f0b0, 0x2b9cea0 [ID=13] 0x2b7f0b0: i32 = add 0x2b9caa0, 0x2b9cca0 [ID=12] 0x2b9caa0: i32,ch = load 0x2b445b0, 0x2b9cba0, 0x2b7e5b0 [ID=11] 0x2b9cba0: i64 = X86ISD::Wrapper 0x2b7ecb0 [ID=10] 0x2b7ecb0: i64 = TargetGlobalAddress 0 [ID=6] 0x2b7e5b0: i64 = undef [ORD=3] [ID=1] 0x2b9cca0: i32 = Constant<-1> [ID=7] 0x2b9cea0: i32 = Constant<16> [ID=8] [regehr at gamow tmp]$ cat small.c int func_0 ( si1 ) { return 0; } short a; short func_2 ( ) { int b = a - 1; return b; } int g_117; void func_47 ( ) { int c = func_2 ( ) | func_0 ( 0 ); g_117 = -1L < 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 Sun Jan 29 12:04:26 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 29 Jan 2012 18:04:26 +0000 Subject: [LLVMbugs] [Bug 11882] New: clang segfault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11882 Bug #: 11882 Summary: clang segfault Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: chenyang at cs.utah.edu, llvmbugs at cs.uiuc.edu Classification: Unclassified Valgrind thinks it's a null ptr deref. [regehr at gamow tmp]$ clang -v clang version 3.1 (trunk 149185) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp]$ clang -O2 -c -w small.c 0 clang 0x0000000001dcbb7f 1 clang 0x0000000001dcddf2 2 libpthread.so.0 0x00007ffff7bcf8f0 3 clang 0x0000000001bed347 llvm::ScalarEvolution::getSCEV(llvm::Value*) + 23 4 clang 0x0000000001be53ba llvm::ScalarEvolution::ComputeLoadConstantCompareExitLimit(llvm::LoadInst*, llvm::Constant*, llvm::Loop const*, llvm::CmpInst::Predicate) + 666 5 clang 0x0000000001be5a36 llvm::ScalarEvolution::ComputeExitLimitFromICmp(llvm::Loop const*, llvm::ICmpInst*, llvm::BasicBlock*, llvm::BasicBlock*) + 918 6 clang 0x0000000001be5ee4 llvm::ScalarEvolution::ComputeExitLimitFromCond(llvm::Loop const*, llvm::Value*, llvm::BasicBlock*, llvm::BasicBlock*) + 468 7 clang 0x0000000001be6437 llvm::ScalarEvolution::ComputeExitLimit(llvm::Loop const*, llvm::BasicBlock*) + 711 8 clang 0x0000000001be67b6 llvm::ScalarEvolution::ComputeBackedgeTakenCount(llvm::Loop const*) + 790 9 clang 0x0000000001be6d5e llvm::ScalarEvolution::getBackedgeTakenInfo(llvm::Loop const*) + 718 10 clang 0x0000000001bfa239 llvm::ScalarEvolution::getBackedgeTakenCount(llvm::Loop const*) + 9 11 clang 0x00000000019cb775 12 clang 0x0000000001b86e44 llvm::LPPassManager::runOnFunction(llvm::Function&) + 1284 13 clang 0x0000000001d6aeeb llvm::FPPassManager::runOnFunction(llvm::Function&) + 587 14 clang 0x0000000001b15a7d 15 clang 0x0000000001d6a9c1 llvm::MPPassManager::runOnModule(llvm::Module&) + 497 16 clang 0x0000000001d6ab4b llvm::PassManagerImpl::run(llvm::Module&) + 187 17 clang 0x00000000007abc05 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1525 18 clang 0x00000000007a8ec1 19 clang 0x00000000009031ff clang::ParseAST(clang::Sema&, bool) + 511 20 clang 0x00000000007a7a94 clang::CodeGenAction::ExecuteAction() + 68 21 clang 0x000000000064e281 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 321 22 clang 0x000000000063720a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1418 23 clang 0x000000000062d2e0 cc1_main(char const**, char const**, char const*, void*) + 960 24 clang 0x0000000000635fc7 main + 7207 25 libc.so.6 0x00007ffff6ea9c4d __libc_start_main + 253 26 clang 0x000000000062abf9 Stack dump: 0. Program arguments: /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r149185-install/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -momit-leaf-frame-pointer -coverage-file small.o -resource-dir /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r149185-install/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -I /opt/intel/composer_xe_2011_sp1.7.256/mkl/include -I /opt/intel/composer_xe_2011_sp1.7.256/tbb/include -internal-isystem /usr/local/include -internal-isystem /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r149185-install/bin/../lib/clang/3.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -w -fdebug-compilation-dir /home/regehr/tmp -ferror-limit 19 -fmessage-length 83 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o small.o -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 '@func_21' 5. Running pass 'Induction Variable Simplification' on basic block '%lbl_818' clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/small-g3aany.i clang: note: diagnostic msg: /tmp/small-g3aany.sh [regehr at gamow tmp]$ cat small.c static int g_244[][0]; int g_814; void func_27 ( ); int func_21_l_773; void func_21 ( void ) { int p_23 = 0; int p_22 = 0; lbl_818: func_27 ( ); int *l_787 = &func_21_l_773; for ( g_814 = 0; g_814 <= 0; g_814 = 1 ) *l_787 = g_244[0][g_814]; if ( func_21_l_773 ) goto lbl_818; return; } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 29 12:53:36 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 29 Jan 2012 18:53:36 +0000 Subject: [LLVMbugs] [Bug 7445] Not all template symbols exported when compiling with -O2 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7445 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #6 from Rafael ?vila de Esp?ndola 2012-01-29 12:53:36 CST --- If found temp.explicit 8: An explicit instantiation ... is also an explicit instantiation ... of each of its members (not including members inherited from base classes) ... So it looks like you need and explicit instantiation of HashTable if you want __ZN2v88internal9HashTableINS0_21NumberDictionaryShapeEjE9FindEntryEj to always show up. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 29 19:51:34 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 01:51:34 +0000 Subject: [LLVMbugs] [Bug 11883] New: Crash when creating an instance of a struct with a reference to a function-local variable. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11883 Bug #: 11883 Summary: Crash when creating an instance of a struct with a reference to a function-local variable. Product: clang Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: kdesevis at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7968 --> http://llvm.org/bugs/attachment.cgi?id=7968 Code that causes the error The attached code causes clang++ to segfault during compilation. Placing x at global scope or never instantiating the struct avoids the 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 Jan 29 23:49:17 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 05:49:17 +0000 Subject: [LLVMbugs] [Bug 11884] New: LLVM fails to build when using --enable-shared flag during configuration Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11884 Bug #: 11884 Summary: LLVM fails to build when using --enable-shared flag during configuration Product: Build scripts Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: autoconf AssignedTo: unassignedbugs at nondot.org ReportedBy: crubio at cs.wisc.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following fails when trying to build LLVM (svn 149190): ./configure --enable-shared make Output: llvm[2]: Linking Debug+Asserts executable opt /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt >(char const (&) [20], llvm::cl::desc const&, llvm::cl::value_desc const&, llvm::cl::initializer const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1200: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `void llvm::cl::initializer::apply > >(llvm::cl::opt >&) const': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:292: undefined reference to `llvm::cl::opt >::setInitialValue(std::string const&)' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [30], llvm::cl::desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1185: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [8], llvm::cl::desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1185: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [2], llvm::cl::desc const&, llvm::cl::OptionHidden const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1193: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [26], llvm::cl::desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1185: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt >(char const (&) [16], llvm::cl::desc const&, llvm::cl::initializer const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1193: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `void llvm::cl::initializer::apply > >(llvm::cl::opt >&) const': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:292: undefined reference to `llvm::cl::opt >::setInitialValue(bool const&)' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [3], llvm::cl::desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1185: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [14], llvm::cl::desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1185: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [20], llvm::cl::desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1185: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [17], llvm::cl::desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1185: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [12], llvm::cl::desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1185: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o:/scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1193: more undefined references to `llvm::cl::opt >::done()' follow /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt(char const (&) [2], llvm::cl::desc const&, llvm::cl::value_desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1193: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `llvm::cl::opt >::opt, llvm::cl::value_desc>(llvm::cl::FormattingFlags const&, llvm::cl::desc const&, llvm::cl::initializer const&, llvm::cl::value_desc const&)': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:1200: undefined reference to `llvm::cl::opt >::done()' /scratch/rubio/llvm-current/build/tools/opt/Debug+Asserts/opt.o: In function `void llvm::cl::initializer::apply > >(llvm::cl::opt >&) const': /scratch/rubio/llvm-current/llvm/include/llvm/Support/CommandLine.h:292: undefined reference to `llvm::cl::opt >::setInitialValue(std::string const&)' clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [/scratch/rubio/llvm-current/build/Debug+Asserts/bin/opt] Error 1 make[2]: Leaving directory `/scratch/rubio/llvm-current/build/tools/opt' make[1]: *** [opt/.makeall] Error 2 make[1]: Leaving directory `/scratch/rubio/llvm-current/build/tools' make: *** [all] Error 1 But if we configure without the --enable-shared flag, then we can successfully build. This is not a problem with LLVM 3.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 Jan 30 00:12:10 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 06:12:10 +0000 Subject: [LLVMbugs] [Bug 11885] New: Missing metadata llvm.dbg.sp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11885 Bug #: 11885 Summary: Missing metadata llvm.dbg.sp Product: libraries Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: crubio at cs.wisc.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In release 3.0 and newer, retrieving the metadata "llvm.dbg.sp" by invoking: M.getNamedMetadata("llvm.dbg.sp"); results in NULL. On the other hand, my attempt to retrieve the same metadata using an older LLVM version (137737) was successful. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 01:25:13 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 07:25:13 +0000 Subject: [LLVMbugs] [Bug 11886] New: `llvm-config --libs` includes libraries for all targets, even if only some of those was built Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11886 Bug #: 11886 Summary: `llvm-config --libs` includes libraries for all targets, even if only some of those was built Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: llvm-config AssignedTo: unassignedbugs at nondot.org ReportedBy: ojab at ojab.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ cmake ../llvm -DLLVM_TARGETS_TO_BUILD=X86 -DBUILD_SHARED_LIBS=ON && make install ? $ llvm-config --libs -lLLVMAsmParser -lLLVMHexagonCodeGen -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMMipsAsmParser -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMDebugInfo -lLLVMJIT -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMipo -lLLVMBitWriter -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMTableGen -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMCBackendCodeGen -lLLVMCBackendInfo -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMAsmPrinter -lLLVMARMInfo -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMBlazeAsmParser -lLLVMMBlazeDisassembler -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMMCDisassembler -lLLVMInterpreter -lLLVMPTXCodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lgtest_main -lgtest -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport Which leads to errors like https://bugs.freedesktop.org/show_bug.cgi?id=44564 because of using `llvm-config --libs` in LDFLAGS mklib: Making Linux shared library: r600_dri.so.tmp /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../x86_64-unknown-linux-gnu/bin/ld: cannot find -lLLVMHexagonCodeGen /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../x86_64-unknown-linux-gnu/bin/ld: cannot find -lLLVMHexagonDesc I assume that this can be expected behavior and desired libs should be chosen using fine-grained requests like `llvm-config --libs engine bitwriter`, not sure 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 Mon Jan 30 04:45:31 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 10:45:31 +0000 Subject: [LLVMbugs] [Bug 11887] New: clang++ crashes with this C++11 code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11887 Bug #: 11887 Summary: clang++ crashes with this C++11 code Product: clang Version: 3.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: poletti.marco at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified clang++ crashes with the attached C++11 code. The console output is also attached. g++ also has problems with this code, and I'm not sure whether it actually should compile. But clang++ should not crash anyway. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 06:26:06 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 12:26:06 +0000 Subject: [LLVMbugs] [Bug 11875] MSVC-built clang passes wrong arguments to gcc when used in msys In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11875 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chandler Carruth 2012-01-30 06:26:06 CST --- This fell out of the flag renaming from '-ccc-host-triple' -> '-target'. Fixed in r149244. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 12:47:54 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 18:47:54 +0000 Subject: [LLVMbugs] [Bug 11885] Missing metadata llvm.dbg.sp In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11885 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Devang Patel 2012-01-30 12:47:54 CST --- Yes, that is expected. I am not sure what exactly you're trying to do but DebugInfoFinder from include/llvm/DebugInfo.h may be your friend. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 14:38:17 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 20:38:17 +0000 Subject: [LLVMbugs] [Bug 11884] LLVM fails to build when using --enable-shared flag during configuration In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11884 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bob.wilson at apple.com Resolution| |DUPLICATE --- Comment #2 from Bob Wilson 2012-01-30 14:38:17 CST --- I'm pretty sure this is a dup of pr11642. Once that was fixed, we changed to build with -fvisibility-inlines-hidden. You'll need to build with a newer version of clang that includes the fix for pr11642. *** This bug has been marked as a duplicate of bug 11642 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 14:58:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 20:58:42 +0000 Subject: [LLVMbugs] [Bug 11888] New: Friend method unable to call protected member function. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11888 Bug #: 11888 Summary: Friend method unable to call protected member function. Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: lukes.dylan at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7972 --> http://llvm.org/bugs/attachment.cgi?id=7972 The offending example, preprocessed. The actual code is the last ~30 lines. The rest is stdlib spew. In some (unknown) cases, calling a protected member function from a friend function fails. If the friend function is defined in the header file, it does not fail with the following warning. clang++ -std=c++11 foo.cc 1 ? In file included from ast.cc:1: ast.cc:6:8: error: 'display' is a protected member of 'wsc::ast::Node' node.display(o); ^ ./ast.hh:31:20: note: declared protected here virtual void display(std::ostream &) const = 0; ^ 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 Mon Jan 30 15:59:00 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 21:59:00 +0000 Subject: [LLVMbugs] [Bug 11889] New: 'bind' doesn't fail when called with non-callable first argument Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11889 Bug #: 11889 Summary: 'bind' doesn't fail when called with non-callable first argument Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: hivemaster at hotmail.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified 'std::bind(1,2)' should fail, but doesn't. (r149243) The standard states the following? for 'std::bind' at 20.8.9.1.2/1 [func.bind.bind]: template unspecified bind(F&& f, BoundArgs&&... bound_args); Requires: [...] INVOKE(fd, w1, w2, ..., wN) (20.8.2) shall be a valid expression for some values w1, w2, ..., wN, where N == sizeof...(bound_args). And at 20.8.2/1, 'INVOKE(f, t1, t2, ..., tN)' is defined as 'f(t1, t2, ..., tN)' when 'f' is not a member pointer. Clearly, the expression '1(2)' isn't valid, and as such the 'std::bind' call should fail (in whatever 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 Mon Jan 30 16:26:55 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 22:26:55 +0000 Subject: [LLVMbugs] [Bug 11890] New: X86 intel syntax misprints st(0) operand with AT&T syntax Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11890 Bug #: 11890 Summary: X86 intel syntax misprints st(0) operand with AT&T syntax Product: new-bugs Version: 3.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: arcata at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following IR: ``` define double @foo(double %x, double %y, double %z) nounwind readnone { %1 = fsub double %x, %y %2 = fsub double %1, %z %3 = fsub double %1, %2 ret double %3 } ``` compiles to the following asm with `llc -O0 -mtriple=i386-pc-linux -mattr=-sse -x86-asm-syntax=intel References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11867 Jeremy Huddleston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #14 from Jeremy Huddleston 2012-01-30 17:38:41 CST --- r149285 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 17:45:00 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 30 Jan 2012 23:45:00 +0000 Subject: [LLVMbugs] [Bug 11890] X86 intel syntax misprints st(0) operand with AT&T syntax In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11890 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Devang Patel 2012-01-30 17:45:00 CST --- It works for me, when I use mainline sources as of today. $llc -O0 -mtriple=i386-pc-linux -mattr=-sse -x86-asm-syntax=intel < /tmp/f.ll .file "" .text .globl foo .align 16, 0x90 .type foo, at function foo: # @foo # BB#0: fld QWORD PTR [ESP + 20] fld QWORD PTR [ESP + 12] fld QWORD PTR [ESP + 4] fsubrp ST(1) fsubr ST(1), ST(0) fsubrp ST(1) ret .Ltmp0: ... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 18:42:22 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 00:42:22 +0000 Subject: [LLVMbugs] [Bug 11887] clang++ crashes with this C++11 code In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11887 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |WORKSFORME --- Comment #3 from Eli Friedman 2012-01-30 18:42:22 CST --- This doesn't crash with trunk. Note that lambda support in clang is still incomplete. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 19:08:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 01:08:11 +0000 Subject: [LLVMbugs] [Bug 11881] error in backend: Cannot select In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11881 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #3 from Eli Friedman 2012-01-30 19:08:11 CST --- r149315. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 19:50:04 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 01:50:04 +0000 Subject: [LLVMbugs] [Bug 11891] New: clang accepts-invalid with templates and abstract classes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11891 Bug #: 11891 Summary: clang accepts-invalid with templates and abstract classes Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: struct A { virtual void x() = 0; }; template struct B { static void f(T); }; void f() { B::f(*(A*)0); } This is clearly ridiculous, but clang somehow 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 Mon Jan 30 19:58:23 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 01:58:23 +0000 Subject: [LLVMbugs] [Bug 11892] New: generated code crashes powerpc-darwin8 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11892 Bug #: 11892 Summary: generated code crashes powerpc-darwin8 Product: new-bugs Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: fang at csl.cornell.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I've built llvm/clang on svn trunk (r149127) on powerpc-darwin8. Test results page: http://www.csl.cornell.edu/~fang/sw/llvm/ [fangism:~/temp/clang] fang% clang++ --version clang version 3.1 (trunk) Target: powerpc-apple-darwin8.11.0 Thread model: posix I tried to compile a simple C++ program and run it: [fangism:~/temp/clang] fang% cat settest.cc #include using std::set; int main(int argc, char* argv[]) { std::set foo; foo.insert(13); return 0; } [fangism:~/temp/clang] fang% make clang++ -c settest.cc -o settest.o clang++ settest.o -o settest but it crashes: [fangism:~/temp/clang] fang% gdb ./settest GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"... warning: --arch option not supported in this gdb. Reading symbols for shared libraries .... done (gdb) run Starting program: /Users/fang/temp/clang/settest Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000008 0x94c4bed4 in std::_Rb_tree_insert_and_rebalance () (gdb) where #0 0x94c4bed4 in std::_Rb_tree_insert_and_rebalance () #1 0x00004af8 in std::_Rb_tree, std::less, std::allocator >::_M_insert () #2 0x00004558 in std::_Rb_tree, std::less, std::allocator >::insert_unique () #3 0x00004360 in std::set, std::allocator >::insert () #4 0x00003670 in main () the executable correctly links to the system's libstdc++: [fangism:~/temp/clang] fang% otool -L ./settest ./settest: /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12) assembly dump: [fangism:~/temp/clang] fang% otool -t -v -V -p _main ./settest | c++filt ./settest: (__TEXT,__text) section _main: 00003600 mfspr r0,lr 00003604 stw r31,0xfffc(r1) 00003608 stw r0,0x8(r1) 0000360c stwu r1,0xff60(r1) 00003610 or r31,r1,r1 00003614 li r5,0x0 00003618 stw r5,0x98(r31) 0000361c stw r3,0x94(r31) 00003620 stw r4,0x90(r31) 00003624 addi r5,r31,0x78 00003628 stw r3,0x58(r31) 0000362c or r3,r5,r5 00003630 stw r5,0x54(r31) 00003634 stw r4,0x50(r31) 00003638 bl 0x3dc0 ; symbol stub for: std::set, std::allocator >::set() 0000363c li r3,0xd 00003640 stw r3,0x74(r31) 00003644 lwz r3,0x50(r31) 00003648 lwz r4,0x58(r31) 0000364c addi r5,r31,0x68 00003650 addi r6,r31,0x74 00003654 stw r3,0x4c(r31) 00003658 or r3,r5,r5 0000365c lwz r5,0x54(r31) 00003660 stw r4,0x48(r31) 00003664 or r4,r5,r5 00003668 or r5,r6,r6 0000366c bl 0x3da0 ; symbol stub for: std::set, std::allocator >::insert(int const&) 00003670 b 0x3674 00003674 li r3,0x0 00003678 stw r3,0x98(r31) 0000367c li r3,0x1 00003680 stw r3,0x5c(r31) 00003684 addi r3,r31,0x78 00003688 bl 0x3e00 ; symbol stub for: std::set, std::allocator >::~set() 0000368c lwz r3,0x98(r31) 00003690 addi r1,r1,0xa0 00003694 lwz r0,0x8(r1) 00003698 lwz r31,0xfffc(r1) 0000369c mtspr lr,r0 000036a0 blr 000036a4 stw r3,0x64(r31) 000036a8 stw r4,0x60(r31) 000036ac addi r3,r31,0x78 000036b0 bl 0x3e00 ; symbol stub for: std::set, std::allocator >::~set() 000036b4 b 0x36b8 000036b8 lwz r3,0x64(r31) 000036bc stw r3,0x44(r31) 000036c0 b 0x36d0 000036c4 stw r3,0x40(r31) 000036c8 stw r4,0x3c(r31) 000036cc bl 0x4220 ; symbol stub for: std::terminate() 000036d0 lwz r3,0x44(r31) 000036d4 bl 0x39c0 ; symbol stub for: __Unwind_Resume symbol dump of executable: [fangism:~/temp/clang] fang% nm settest | c++filt 00005a98 s EH_frame0 00005ae8 s EH_frame1 00005964 s GCC_except_table0 000059b0 s GCC_except_table24 00005a18 s GCC_except_table41 00005a38 s GCC_except_table45 00005a58 s GCC_except_table58 00005a78 s GCC_except_table62 0000600c D _NXArgc 00006008 D _NXArgv U __Unwind_Resume 00004ea0 S __gnu_cxx::new_allocator >::deallocate(std::_Rb_tree_node*, unsigned long) 00005030 S __gnu_cxx::new_allocator >::allocate(unsigned long, void const*) 00005e00 S __ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeIiEE8allocateEmPKv.eh 00005660 S __gnu_cxx::new_allocator >::new_allocator(__gnu_cxx::new_allocator > const&) 00005560 S __gnu_cxx::new_allocator >::new_allocator() 000054f0 S __gnu_cxx::new_allocator >::~new_allocator() 00005950 S __gnu_cxx::new_allocator::destroy(int*) 00004db0 S __gnu_cxx::new_allocator::construct(int*, int const&) 00005020 S __gnu_cxx::new_allocator::new_allocator() 00004f50 S __gnu_cxx::new_allocator::~new_allocator() 000050c0 S __gnu_cxx::new_allocator >::max_size() const 000048f0 S std::_Rb_tree_iterator::operator==(std::_Rb_tree_iterator const&) const 000047a0 S std::less::operator()(int const&, int const&) const 00004d60 S std::_Rb_tree, std::less, std::allocator >::get_allocator() const 000047e0 S std::_Identity::operator()(int const&) const 00005410 S std::allocator >::allocator(std::allocator const&) 00005600 S std::allocator >::allocator(std::allocator > const&) 00005500 S std::allocator >::allocator(std::allocator const&) 00005470 S std::allocator >::~allocator() 000054b0 S std::allocator >::~allocator() 00005260 S std::allocator::allocator() 00004f60 S std::allocator::allocator >(std::allocator > const&) 000052a0 S std::allocator::allocator() 00004fc0 S std::allocator::allocator >(std::allocator > const&) 00004e00 S std::allocator::~allocator() 00004f10 S std::allocator::~allocator() 00004890 S std::_Rb_tree_iterator::_Rb_tree_iterator(std::_Rb_tree_node*) 00005c4c S __ZNSt17_Rb_tree_iteratorIiEC1EPSt13_Rb_tree_nodeIiE.eh 00005120 S std::_Rb_tree_iterator::_Rb_tree_iterator(std::_Rb_tree_node*) 00004b30 S std::_Rb_tree_iterator::operator--() 00005d0c S __ZNSt17_Rb_tree_iteratorIiEmmEv.eh 000046a0 S std::_Rb_tree_const_iterator::_Rb_tree_const_iterator(std::_Rb_tree_iterator const&) 00005bec S __ZNSt23_Rb_tree_const_iteratorIiEC1ERKSt17_Rb_tree_iteratorIiE.eh 00004700 S std::_Rb_tree_const_iterator::_Rb_tree_const_iterator(std::_Rb_tree_iterator const&) 00004320 S std::set, std::allocator >::insert(int const&) 00005b2c S __ZNSt3setIiSt4lessIiESaIiEE6insertERKi.eh 000042e0 S std::set, std::allocator >::set() 00005afc S __ZNSt3setIiSt4lessIiESaIiEEC1Ev.eh 00005160 S std::set, std::allocator >::set() 00005e30 S __ZNSt3setIiSt4lessIiESaIiEEC2Ev.eh 000043c0 S std::set, std::allocator >::~set() 00005b5c S __ZNSt3setIiSt4lessIiESaIiEED1Ev.eh 00005680 S std::set, std::allocator >::~set() 00005ef8 S __ZNSt3setIiSt4lessIiESaIiEED2Ev.eh 00004970 S std::pair, bool>::pair(std::_Rb_tree_iterator const&, bool const&) 00005cac S __ZNSt4pairISt17_Rb_tree_iteratorIiEbEC1ERKS1_RKb.eh 000050e0 S std::pair, bool>::pair(std::_Rb_tree_iterator const&, bool const&) 00004630 S std::pair, bool>::pair(std::_Rb_tree_const_iterator const&, bool const&) 00005bbc S __ZNSt4pairISt23_Rb_tree_const_iteratorIiEbEC1ERKS1_RKb.eh 00004720 S std::pair, bool>::pair(std::_Rb_tree_const_iterator const&, bool const&) 00004d10 S std::_Rb_tree, std::less, std::allocator >::_M_get_node() 00005da0 S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE11_M_get_nodeEv.eh 00004e40 S std::_Rb_tree, std::less, std::allocator >::_M_put_node(std::_Rb_tree_node*) 00005dd0 S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE11_M_put_nodeEPSt13_Rb_tree_nodeIiE.eh 00005890 S std::_Rb_tree, std::less, std::allocator >::destroy_node(std::_Rb_tree_node*) 00005fbc S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE12destroy_nodeEPSt13_Rb_tree_nodeIiE.eh 000053a0 S std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::_Rb_tree_impl(std::allocator > const&, std::less const&) 00005ec8 S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE13_Rb_tree_implIS3_Lb0EEC1ERKSaISt13_Rb_tree_nodeIiEERKS3_.eh 00005570 S std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::_Rb_tree_impl(std::allocator > const&, std::less const&) 00005810 S std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::~_Rb_tree_impl() 00005850 S std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::~_Rb_tree_impl() 00004400 S std::_Rb_tree, std::less, std::allocator >::insert_unique(int const&) 00005b8c S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE13insert_uniqueERKi.eh 00004bf0 S std::_Rb_tree, std::less, std::allocator >::_M_create_node(int const&) 00005d6c S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE14_M_create_nodeERKi.eh 00004920 S std::_Rb_tree, std::less, std::allocator >::begin() 00005c7c S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE5beginEv.eh 00004780 S std::_Rb_tree, std::less, std::allocator >::_M_end() 00004800 S std::_Rb_tree, std::less, std::allocator >::_S_key(std::_Rb_tree_node const*) 00005c1c S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE6_S_keyEPKSt13_Rb_tree_nodeIiE.eh 00004b80 S std::_Rb_tree, std::less, std::allocator >::_S_key(std::_Rb_tree_node_base const*) 00005d3c S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE6_S_keyEPKSt18_Rb_tree_node_base.eh 00004850 S std::_Rb_tree, std::less, std::allocator >::_S_left(std::_Rb_tree_node_base*) 00004760 S std::_Rb_tree, std::less, std::allocator >::_M_begin() 00005780 S std::_Rb_tree, std::less, std::allocator >::_M_erase(std::_Rb_tree_node*) 00005f8c S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE8_M_eraseEPSt13_Rb_tree_nodeIiE.eh 00004870 S std::_Rb_tree, std::less, std::allocator >::_S_right(std::_Rb_tree_node_base*) 00005140 S std::_Rb_tree, std::less, std::allocator >::_S_value(std::_Rb_tree_node const*) 00004bd0 S std::_Rb_tree, std::less, std::allocator >::_S_value(std::_Rb_tree_node_base const*) 000049e0 S std::_Rb_tree, std::less, std::allocator >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, int const&) 00005cdc S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE9_M_insertEPSt18_Rb_tree_node_baseS7_RKi.eh 000051f0 S std::_Rb_tree, std::less, std::allocator >::_Rb_tree(std::less const&, std::allocator const&) 00005e64 S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEEC1ERKS3_RKS4_.eh 000052e0 S std::_Rb_tree, std::less, std::allocator >::_Rb_tree(std::less const&, std::allocator const&) 00005e94 S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEEC2ERKS3_RKS4_.eh 000056c0 S std::_Rb_tree, std::less, std::allocator >::~_Rb_tree() 00005f28 S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEED1Ev.eh 00005700 S std::_Rb_tree, std::less, std::allocator >::~_Rb_tree() 00005f58 S __ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEED2Ev.eh U std::__throw_bad_alloc() U std::_Rb_tree_decrement(std::_Rb_tree_node_base*) U std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) U std::terminate() U operator delete(void*) U operator new(unsigned long) 00003504 t ___cxa_atexit U ___cxa_begin_catch U ___cxa_end_catch U ___cxa_rethrow 000024f0 T ___darwin_gcc3_preregister_frame_info 00001000 A ___dso_handle U ___gxx_personality_v0 U ___keymgr_dwarf2_register_sections U ___keymgr_global 00006000 D ___progname U __cthread_init_routine 00002258 t __dyld_func_lookup U __dyld_register_func_for_add_image U __dyld_register_func_for_remove_image U __init_keymgr U __keymgr_get_and_lock_processwide_ptr U __keymgr_set_and_unlock_processwide_ptr 00001000 A __mh_execute_header 00001ef4 t __start U _abort 00002c60 t _add_routine 00003584 t _atexit 000031e4 t _atexit_common U _calloc 00006190 S _catch_exception_raise 00006194 S _catch_exception_raise_state 00006198 S _catch_exception_raise_state_identity 0000266c t _check_cxa_atexit 0000619c S _clock_alarm_reply 000025f4 t _cxa_atexit_check_1 000025cc t _cxa_atexit_check_2 00002f30 t _cxa_atexit_wrapper 00002268 t _darwin_unwind_dyld_add_image_hook 00002350 t _darwin_unwind_dyld_remove_image_hook U _dlopen U _dlsym 000061a0 S _do_mach_notify_dead_name 000061a4 S _do_mach_notify_no_senders 000061a8 S _do_mach_notify_port_deleted 000061ac S _do_mach_notify_send_once 000061b0 S _do_seqnos_mach_notify_dead_name 000061b4 S _do_seqnos_mach_notify_no_senders 000061b8 S _do_seqnos_mach_notify_port_deleted 000061bc S _do_seqnos_mach_notify_send_once 00006004 D _environ U _errno U _exit 00002738 t _find_atexit_10_3 U _free 00002970 t _get_globals U _mach_init_routine 00003600 T _main 00005ab4 S _main.eh U _malloc 000030c8 t _our_atexit 00006010 d _pointer_to__darwin_gcc3_preregister_frame_info 000061c0 S _receive_samples 00002dac t _run_routines U _strcmp 00002240 t dyld_stub_binding_helper 00001ec0 T start Indirect symbols: [fangism:~/temp/clang] fang% otool -I -V ./settest | c++filt ./settest: Indirect symbols for (__TEXT,__symbol_stub) 0 entries address index name Indirect symbols for (__TEXT,__picsymbol_stub) 0 entries address index name Indirect symbols for (__TEXT,__symbol_stub1) 2 entries address index name 0x000036e0 162 _exit 0x000036f0 149 ___keymgr_dwarf2_register_sections Indirect symbols for (__TEXT,__picsymbolstub1) 85 entries address index name 0x00003840 157 _abort 0x00003860 152 __dyld_register_func_for_add_image 0x00003880 153 __dyld_register_func_for_remove_image 0x000038a0 155 __keymgr_get_and_lock_processwide_ptr 0x000038c0 154 __init_keymgr 0x000038e0 163 _free 0x00003900 156 __keymgr_set_and_unlock_processwide_ptr 0x00003920 158 _calloc 0x00003940 159 _dlopen 0x00003960 165 _malloc 0x00003980 160 _dlsym 0x000039a0 166 _strcmp 0x000039c0 138 __Unwind_Resume 0x000039e0 28 __gnu_cxx::new_allocator >::deallocate(std::_Rb_tree_node*, unsigned long) 0x00003a00 29 __gnu_cxx::new_allocator >::allocate(unsigned long, void const*) 0x00003a20 31 __gnu_cxx::new_allocator >::new_allocator(__gnu_cxx::new_allocator > const&) 0x00003a40 32 __gnu_cxx::new_allocator >::new_allocator() 0x00003a60 33 __gnu_cxx::new_allocator >::~new_allocator() 0x00003a80 34 __gnu_cxx::new_allocator::destroy(int*) 0x00003aa0 35 __gnu_cxx::new_allocator::construct(int*, int const&) 0x00003ac0 36 __gnu_cxx::new_allocator::new_allocator() 0x00003ae0 37 __gnu_cxx::new_allocator::~new_allocator() 0x00003b00 38 __gnu_cxx::new_allocator >::max_size() const 0x00003b20 39 std::_Rb_tree_iterator::operator==(std::_Rb_tree_iterator const&) const 0x00003b40 40 std::less::operator()(int const&, int const&) const 0x00003b60 41 std::_Rb_tree, std::less, std::allocator >::get_allocator() const 0x00003b80 42 std::_Identity::operator()(int const&) const 0x00003ba0 43 std::allocator >::allocator(std::allocator const&) 0x00003bc0 44 std::allocator >::allocator(std::allocator > const&) 0x00003be0 45 std::allocator >::allocator(std::allocator const&) 0x00003c00 46 std::allocator >::~allocator() 0x00003c20 47 std::allocator >::~allocator() 0x00003c40 48 std::allocator::allocator() 0x00003c60 49 std::allocator::allocator >(std::allocator > const&) 0x00003c80 50 std::allocator::allocator() 0x00003ca0 51 std::allocator::allocator >(std::allocator > const&) 0x00003cc0 52 std::allocator::~allocator() 0x00003ce0 53 std::allocator::~allocator() 0x00003d00 54 std::_Rb_tree_iterator::_Rb_tree_iterator(std::_Rb_tree_node*) 0x00003d20 56 std::_Rb_tree_iterator::_Rb_tree_iterator(std::_Rb_tree_node*) 0x00003d40 57 std::_Rb_tree_iterator::operator--() 0x00003d60 59 std::_Rb_tree_const_iterator::_Rb_tree_const_iterator(std::_Rb_tree_iterator const&) 0x00003d80 61 std::_Rb_tree_const_iterator::_Rb_tree_const_iterator(std::_Rb_tree_iterator const&) 0x00003da0 62 std::set, std::allocator >::insert(int const&) 0x00003dc0 64 std::set, std::allocator >::set() 0x00003de0 66 std::set, std::allocator >::set() 0x00003e00 68 std::set, std::allocator >::~set() 0x00003e20 70 std::set, std::allocator >::~set() 0x00003e40 72 std::pair, bool>::pair(std::_Rb_tree_iterator const&, bool const&) 0x00003e60 74 std::pair, bool>::pair(std::_Rb_tree_iterator const&, bool const&) 0x00003e80 75 std::pair, bool>::pair(std::_Rb_tree_const_iterator const&, bool const&) 0x00003ea0 77 std::pair, bool>::pair(std::_Rb_tree_const_iterator const&, bool const&) 0x00003ec0 78 std::_Rb_tree, std::less, std::allocator >::_M_get_node() 0x00003ee0 80 std::_Rb_tree, std::less, std::allocator >::_M_put_node(std::_Rb_tree_node*) 0x00003f00 82 std::_Rb_tree, std::less, std::allocator >::destroy_node(std::_Rb_tree_node*) 0x00003f20 84 std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::_Rb_tree_impl(std::allocator > const&, std::less const&) 0x00003f40 86 std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::_Rb_tree_impl(std::allocator > const&, std::less const&) 0x00003f60 87 std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::~_Rb_tree_impl() 0x00003f80 88 std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::~_Rb_tree_impl() 0x00003fa0 89 std::_Rb_tree, std::less, std::allocator >::insert_unique(int const&) 0x00003fc0 91 std::_Rb_tree, std::less, std::allocator >::_M_create_node(int const&) 0x00003fe0 93 std::_Rb_tree, std::less, std::allocator >::begin() 0x00004000 95 std::_Rb_tree, std::less, std::allocator >::_M_end() 0x00004020 96 std::_Rb_tree, std::less, std::allocator >::_S_key(std::_Rb_tree_node const*) 0x00004040 98 std::_Rb_tree, std::less, std::allocator >::_S_key(std::_Rb_tree_node_base const*) 0x00004060 100 std::_Rb_tree, std::less, std::allocator >::_S_left(std::_Rb_tree_node_base*) 0x00004080 101 std::_Rb_tree, std::less, std::allocator >::_M_begin() 0x000040a0 102 std::_Rb_tree, std::less, std::allocator >::_M_erase(std::_Rb_tree_node*) 0x000040c0 104 std::_Rb_tree, std::less, std::allocator >::_S_right(std::_Rb_tree_node_base*) 0x000040e0 105 std::_Rb_tree, std::less, std::allocator >::_S_value(std::_Rb_tree_node const*) 0x00004100 106 std::_Rb_tree, std::less, std::allocator >::_S_value(std::_Rb_tree_node_base const*) 0x00004120 107 std::_Rb_tree, std::less, std::allocator >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, int const&) 0x00004140 109 std::_Rb_tree, std::less, std::allocator >::_Rb_tree(std::less const&, std::allocator const&) 0x00004160 111 std::_Rb_tree, std::less, std::allocator >::_Rb_tree(std::less const&, std::allocator const&) 0x00004180 113 std::_Rb_tree, std::less, std::allocator >::~_Rb_tree() 0x000041a0 115 std::_Rb_tree, std::less, std::allocator >::~_Rb_tree() 0x000041c0 139 std::__throw_bad_alloc() 0x000041e0 140 std::_Rb_tree_decrement(std::_Rb_tree_node_base*) 0x00004200 141 std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) 0x00004220 142 std::terminate() 0x00004240 143 operator delete(void*) 0x00004260 144 operator new(unsigned long) 0x00004280 145 ___cxa_begin_catch 0x000042a0 146 ___cxa_end_catch 0x000042c0 147 ___cxa_rethrow Indirect symbols for (__DATA,__nl_symbol_ptr) 6 entries address index name 0x00006014 164 _mach_init_routine 0x00006018 161 _errno 0x0000601c 151 __cthread_init_routine 0x00006020 150 ___keymgr_global 0x00006024 118 ___dso_handle 0x00006028 148 ___gxx_personality_v0 Indirect symbols for (__DATA,__la_symbol_ptr) 87 entries address index name 0x0000602c 162 _exit 0x00006030 149 ___keymgr_dwarf2_register_sections 0x00006034 157 _abort 0x00006038 152 __dyld_register_func_for_add_image 0x0000603c 153 __dyld_register_func_for_remove_image 0x00006040 155 __keymgr_get_and_lock_processwide_ptr 0x00006044 154 __init_keymgr 0x00006048 163 _free 0x0000604c 156 __keymgr_set_and_unlock_processwide_ptr 0x00006050 158 _calloc 0x00006054 159 _dlopen 0x00006058 165 _malloc 0x0000605c 160 _dlsym 0x00006060 166 _strcmp 0x00006064 138 __Unwind_Resume 0x00006068 28 __gnu_cxx::new_allocator >::deallocate(std::_Rb_tree_node*, unsigned long) 0x0000606c 29 __gnu_cxx::new_allocator >::allocate(unsigned long, void const*) 0x00006070 31 __gnu_cxx::new_allocator >::new_allocator(__gnu_cxx::new_allocator > const&) 0x00006074 32 __gnu_cxx::new_allocator >::new_allocator() 0x00006078 33 __gnu_cxx::new_allocator >::~new_allocator() 0x0000607c 34 __gnu_cxx::new_allocator::destroy(int*) 0x00006080 35 __gnu_cxx::new_allocator::construct(int*, int const&) 0x00006084 36 __gnu_cxx::new_allocator::new_allocator() 0x00006088 37 __gnu_cxx::new_allocator::~new_allocator() 0x0000608c 38 __gnu_cxx::new_allocator >::max_size() const 0x00006090 39 std::_Rb_tree_iterator::operator==(std::_Rb_tree_iterator const&) const 0x00006094 40 std::less::operator()(int const&, int const&) const 0x00006098 41 std::_Rb_tree, std::less, std::allocator >::get_allocator() const 0x0000609c 42 std::_Identity::operator()(int const&) const 0x000060a0 43 std::allocator >::allocator(std::allocator const&) 0x000060a4 44 std::allocator >::allocator(std::allocator > const&) 0x000060a8 45 std::allocator >::allocator(std::allocator const&) 0x000060ac 46 std::allocator >::~allocator() 0x000060b0 47 std::allocator >::~allocator() 0x000060b4 48 std::allocator::allocator() 0x000060b8 49 std::allocator::allocator >(std::allocator > const&) 0x000060bc 50 std::allocator::allocator() 0x000060c0 51 std::allocator::allocator >(std::allocator > const&) 0x000060c4 52 std::allocator::~allocator() 0x000060c8 53 std::allocator::~allocator() 0x000060cc 54 std::_Rb_tree_iterator::_Rb_tree_iterator(std::_Rb_tree_node*) 0x000060d0 56 std::_Rb_tree_iterator::_Rb_tree_iterator(std::_Rb_tree_node*) 0x000060d4 57 std::_Rb_tree_iterator::operator--() 0x000060d8 59 std::_Rb_tree_const_iterator::_Rb_tree_const_iterator(std::_Rb_tree_iterator const&) 0x000060dc 61 std::_Rb_tree_const_iterator::_Rb_tree_const_iterator(std::_Rb_tree_iterator const&) 0x000060e0 62 std::set, std::allocator >::insert(int const&) 0x000060e4 64 std::set, std::allocator >::set() 0x000060e8 66 std::set, std::allocator >::set() 0x000060ec 68 std::set, std::allocator >::~set() 0x000060f0 70 std::set, std::allocator >::~set() 0x000060f4 72 std::pair, bool>::pair(std::_Rb_tree_iterator const&, bool const&) 0x000060f8 74 std::pair, bool>::pair(std::_Rb_tree_iterator const&, bool const&) 0x000060fc 75 std::pair, bool>::pair(std::_Rb_tree_const_iterator const&, bool const&) 0x00006100 77 std::pair, bool>::pair(std::_Rb_tree_const_iterator const&, bool const&) 0x00006104 78 std::_Rb_tree, std::less, std::allocator >::_M_get_node() 0x00006108 80 std::_Rb_tree, std::less, std::allocator >::_M_put_node(std::_Rb_tree_node*) 0x0000610c 82 std::_Rb_tree, std::less, std::allocator >::destroy_node(std::_Rb_tree_node*) 0x00006110 84 std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::_Rb_tree_impl(std::allocator > const&, std::less const&) 0x00006114 86 std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::_Rb_tree_impl(std::allocator > const&, std::less const&) 0x00006118 87 std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::~_Rb_tree_impl() 0x0000611c 88 std::_Rb_tree, std::less, std::allocator >::_Rb_tree_impl, false>::~_Rb_tree_impl() 0x00006120 89 std::_Rb_tree, std::less, std::allocator >::insert_unique(int const&) 0x00006124 91 std::_Rb_tree, std::less, std::allocator >::_M_create_node(int const&) 0x00006128 93 std::_Rb_tree, std::less, std::allocator >::begin() 0x0000612c 95 std::_Rb_tree, std::less, std::allocator >::_M_end() 0x00006130 96 std::_Rb_tree, std::less, std::allocator >::_S_key(std::_Rb_tree_node const*) 0x00006134 98 std::_Rb_tree, std::less, std::allocator >::_S_key(std::_Rb_tree_node_base const*) 0x00006138 100 std::_Rb_tree, std::less, std::allocator >::_S_left(std::_Rb_tree_node_base*) 0x0000613c 101 std::_Rb_tree, std::less, std::allocator >::_M_begin() 0x00006140 102 std::_Rb_tree, std::less, std::allocator >::_M_erase(std::_Rb_tree_node*) 0x00006144 104 std::_Rb_tree, std::less, std::allocator >::_S_right(std::_Rb_tree_node_base*) 0x00006148 105 std::_Rb_tree, std::less, std::allocator >::_S_value(std::_Rb_tree_node const*) 0x0000614c 106 std::_Rb_tree, std::less, std::allocator >::_S_value(std::_Rb_tree_node_base const*) 0x00006150 107 std::_Rb_tree, std::less, std::allocator >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, int const&) 0x00006154 109 std::_Rb_tree, std::less, std::allocator >::_Rb_tree(std::less const&, std::allocator const&) 0x00006158 111 std::_Rb_tree, std::less, std::allocator >::_Rb_tree(std::less const&, std::allocator const&) 0x0000615c 113 std::_Rb_tree, std::less, std::allocator >::~_Rb_tree() 0x00006160 115 std::_Rb_tree, std::less, std::allocator >::~_Rb_tree() 0x00006164 139 std::__throw_bad_alloc() 0x00006168 140 std::_Rb_tree_decrement(std::_Rb_tree_node_base*) 0x0000616c 141 std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) 0x00006170 142 std::terminate() 0x00006174 143 operator delete(void*) 0x00006178 144 operator new(unsigned long) 0x0000617c 145 ___cxa_begin_catch 0x00006180 146 ___cxa_end_catch 0x00006184 147 ___cxa_rethrow Let me know if there's any additional information I can provide to help debug this. I also get the same results as above with release-3.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 Jan 30 20:00:11 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 02:00:11 +0000 Subject: [LLVMbugs] [Bug 11893] New: When noexcept is violated clang should call __cxa_begin_catch(unwind_arg) prior to calling std::terminate Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11893 Bug #: 11893 Summary: When noexcept is violated clang should call __cxa_begin_catch(unwind_arg) prior to calling std::terminate Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hhinnant at apple.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified This test: #include #include #include #include void handler1() { std::cout << "handler 1\n"; std::abort(); } void handler2() { std::cout << "handler 2\n"; std::abort(); } struct A { ~A() {std::set_terminate(handler2);} }; void f2() { std::set_terminate(handler1); throw std::runtime_error("throw in f2"); } void f1() noexcept { A a; f2(); } int main() { f1(); } Should output: handler 1 When run against the trunk libc++abi. Note that the trunk libc++abi won't run with the trunk libc++, but this will change soon (within a few days). When the noexcept is violated, clang currently outputs a call to std::terminate(). Just prior to that call clang needs to call __cxa_begin_catch(unwind_arg) to make this work. Reference [except.handle]/p7: Also, an implicit handler is considered active when std::terminate() or std::unexpected() is entered due to a throw. With the Itanium ABI, the way you make a handler active is by calling __cxa_begin_catch(unwind_arg). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 23:58:06 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 05:58:06 +0000 Subject: [LLVMbugs] [Bug 11888] Friend method unable to call protected member function. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11888 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #1 from Eli Friedman 2012-01-30 23:58:06 CST --- Your definition of operator>> is defining a different function from the one declared in the friend declaration: specifically, they are in different namespaces. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 00:27:49 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 06:27:49 +0000 Subject: [LLVMbugs] [Bug 11894] New: Add InitializeNativeTargetDisassembler function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11894 Bug #: 11894 Summary: Add InitializeNativeTargetDisassembler function Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: ojab at ojab.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7974 --> http://llvm.org/bugs/attachment.cgi?id=7974 Add InitializeNativeTargetDisassembler function InitializeNativeTargetDisassembler - The main program should call this function to initialize the native target disassembler, similar to InitializeNativeTargetAsmPrinter/InitializeNativeTargetAsmParser/etc. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 00:51:09 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 06:51:09 +0000 Subject: [LLVMbugs] [Bug 4665] no warning when assigning signed value to an unsigned variable In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=4665 Jason Switzer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Jason Switzer 2012-01-31 00:51:09 CST --- > The author of this bug was trying to use -Wall, which I'm not sure is > valid for clang (it is for GCC, which reports this under -Wsign-compare). This was a mistake, it meant to say GCC reports this under -Wconversion, similar to Clang. Also, though neighter GCC nor Clang turn on this option for -Wall, Clang does turn it on with -Weverything. After reviewing this with dblaikie on IRC, we both agreed this bug has been fixed by 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 Tue Jan 31 03:04:07 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 09:04:07 +0000 Subject: [LLVMbugs] [Bug 1508] typeinfos and personality functions should be attached to the invoke In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1508 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #21 from Duncan Sands 2012-01-31 03:04:07 CST --- Bill fixed 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 Jan 31 03:08:24 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 09:08:24 +0000 Subject: [LLVMbugs] [Bug 1914] Should turn invoke of a resume into a branch In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1914 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Duncan Sands 2012-01-31 03:08:24 CST --- This was fixed in 3.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 Tue Jan 31 05:26:42 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 11:26:42 +0000 Subject: [LLVMbugs] [Bug 11895] New: SimplifyLibCalls should be merged into instcombine Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11895 Bug #: 11895 Summary: SimplifyLibCalls should be merged into instcombine Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Simplify libcalls was previously split out of instcombine so that it could be turned off with -fno-builtin. Now that we have TargetLibraryInfo around, we don't need to do this. Merging it into Instcombine's visitCall optimization logic would eliminate some phase ordering problems that it can have, and is a generally good cleanup anyway. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 05:28:39 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 11:28:39 +0000 Subject: [LLVMbugs] [Bug 9038] llvm/Target/TargetOptions.h should become an immutablepass In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9038 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2012-01-31 05:28:39 CST --- Nick Lewycky fixed this by making it a class that is passed down into Target. No need for it to be a 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 Tue Jan 31 05:41:20 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 11:41:20 +0000 Subject: [LLVMbugs] [Bug 11896] New: [DSE] Dead store elimination doesn't know about memset_pattern or calloc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11896 Bug #: 11896 Summary: [DSE] Dead store elimination doesn't know about memset_pattern or calloc Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The example in PR5117 is now optimized to: %call = tail call i8* @calloc(i64 10000, i64 4) nounwind %0 = bitcast i8* %call to i32* call void @llvm.memset.p0i8.i64(i8* %call, i8 0, i64 40000, i32 4, i1 false) call void @memset_pattern16(i8* %call, i8* bitcast ([4 x i32]* @.memset_pattern to i8*), i64 40000) nounwind The first memset is dead, because calloc provides zero-filled memory. Further, the memset_pattern makes both the memset and the calloc-ness dead. This could be replaced with a call to malloc + memset_pattern16. -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 05:43:52 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 11:43:52 +0000 Subject: [LLVMbugs] [Bug 5117] Simplification of multiple array initializations In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=5117 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Chris Lattner 2012-01-31 05:43:52 CST --- In fact, this is just a special case of the broader bug tracking lack of high-level loop optimizations for this sort of thing, aka PR 6956. *** This bug has been marked as a duplicate of bug 6956 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 05:49:46 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 11:49:46 +0000 Subject: [LLVMbugs] [Bug 11897] New: Should have IR support for the 'ifunc' attribute Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11897 Bug #: 11897 Summary: Should have IR support for the 'ifunc' attribute Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Not a specifically high priority, but it would be nice for clang to eventually support the 'ifunc' attribute, which models a feature available on both ELF and MachO systems: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html This seems natural to implement as a bit on GlobalAlias or something like that. If we had IR support for this, in addition to supporting the ifunc attribute for user code, we could also have globalopt statically evaluate them in some cases (i.e. to optimize them out), etc. It's not clear from the GCC Documentation, but there is no reason that the attribute could not also work for data, to support efficient lazy initialization. For example: int G __attribute__ ((ifunc ("my_g"))); static void *my_g() { static int X; X = foo(); 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 Tue Jan 31 07:34:53 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 13:34:53 +0000 Subject: [LLVMbugs] =?utf-8?q?=5BBug_11834=5D_On_Linux_the_CPUName_depende?= =?utf-8?q?d_on_the_host=2C__while_on_Windows_=E2=80=9Cgeneric=E2=80=9D_CP?= =?utf-8?q?UName_is_chosen_=2E?= In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11834 Marina Yatsina changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Marina Yatsina 2012-01-31 07:34:53 CST --- Patch committed to llvm trunk by Evan Cheng http://www.llvm.org/viewvc/llvm-project?view=rev&revision=149294 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 10:28:15 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 16:28:15 +0000 Subject: [LLVMbugs] [Bug 1343] JIT support for inline assembly In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=1343 Jim Grosbach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Jim Grosbach 2012-01-31 10:28:15 CST --- Yes, the MC-JIT has full support for inline asm. I'm fine with closing this as being covered by that. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 13:20:32 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 19:20:32 +0000 Subject: [LLVMbugs] [Bug 11898] New: bogus DW_FORM_strp offset Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11898 Bug #: 11898 Summary: bogus DW_FORM_strp offset Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: fischman at chromium.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Building chromium's browser_tests binary with clang & the shared_library build generates a libcontent.so that makes gdb unhappy: Error while reading shared library symbols for /usr/local/google/fischman/src/chromium/src/ninja/Debug/lib/libcontent.so: DW_FORM_strp pointing outside of .debug_str section [in module /usr/local/google/fischman/src/chromium/src/ninja/Debug/lib/libcontent.so] poking at it with readelf -w says: $ readelf -w libcontent.so > /dev/null readelf: Warning: DW_FORM_strp offset too big: 662f706d readelf: Warning: DIE at offset 52f6684 refers to abbreviation number 97 which does not exist readelf: Warning: DIE at offset 52f6684 refers to abbreviation number 97 which does not exist readelf: Warning: Unable to load/parse the .debug_info section, so cannot interpret the .debug_line section. readelf: Warning: Unable to load/parse the .debug_info section, so cannot interpret the .debug_loc section. readelf: Warning: Unable to load/parse the .debug_info section, so cannot interpret the .debug_ranges section. That first warning seems like a problem, since it's an offset of ~1.7e9 in a file that's only 1.6e8 big (!). The particular value also looks like it might be ASCII ("f/mp") but that string doesn't occur in the chromium source tree, so probably just a red herring. The libcontent.so.bz2 in question can be downloaded from: https://docs.google.com/open?id=0B04xnfIubmoUZmY1ODAwYWYtNDU5MS00OTViLTljZjUtODQ1NWQ0ZDg2YjI3 FWIW, links for how to build in this configuration: http://code.google.com/p/chromium/wiki/Clang http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Shared_libraries_(components) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 15:11:22 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 21:11:22 +0000 Subject: [LLVMbugs] [Bug 11899] New: Double-running of global dtors in shared build Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11899 Bug #: 11899 Summary: Double-running of global dtors in shared build Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: fischman at chromium.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified In the clang & the shared_library build of chromium browser_tests (setup described in bug 11898), running the browser_tests binary like: ./out/Debug/browser_tests --gtest_filter=InProcessBrowserTest.Empty runs a test, forks a browser, concludes the test, tears down the browser, and the browser crashes with: [25190:25190:0131/131308:431338029426:ERROR:process_util_posix.cc(142)] Received signal 11 base::debug::StackTrace::StackTrace() [0x7f9666f43ffe] base::(anonymous namespace)::StackDumpSignalHandler() [0x7f9666facfd4] 0x7f965c08caf0 DieFromDoubleFree() [0x7f96699578fe] ValidateAllocatedRegion() [0x7f9669957872] (anonymous namespace)::do_free_with_callback() [0x7f966995760b] (anonymous namespace)::do_free() [0x7f966995588c] operator delete[]() [0x7f9669da25fe] testing::internal::String::~String() [0x51db0d] testing::internal::String::~String() [0x51d755] std::_Destroy<>() [0x1d21505] std::_Destroy_aux<>::__destroy<>() [0x1d214d7] std::_Destroy<>() [0x1d2149d] std::_Destroy<>() [0x1d21331] std::vector<>::~vector() [0x7f96633997fe] std::vector<>::~vector() [0x7f96633994c5] 0x7f965c092630 0x7f966304bc56 This doesn't happen with the gcc/shared_library build, or with clang/static_library build. I'd be happy to provide more info but not sure how to dig into this further. It *feels* like there's a global std::vector that's being destroyed more than once. I suspect this one: http://code.google.com/codesearch#OAMlx_jo-ck/src/testing/gtest/src/gtest-port.cc&exact_package=chromium&q=vector%3C%5Ba-z:%5D*String%20case:yes%20file:gtest&ct=rc&cd=2&sq=&l=631 Any ideas on how to dig further? (gdb-based attempts are likely to be stymied by bug 11898, unless they don't require symbol inspection) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 17:15:35 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 31 Jan 2012 23:15:35 +0000 Subject: [LLVMbugs] [Bug 11794] EarlyCSE stack overflow on long functions. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11794 Lenny Maiorani 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 Jan 31 19:29:49 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Feb 2012 01:29:49 +0000 Subject: [LLVMbugs] [Bug 11900] New: [AVX] cannot select v4i32 = X86ISD::VBROADCAST error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11900 Bug #: 11900 Summary: [AVX] cannot select v4i32 = X86ISD::VBROADCAST error 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: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7978 --> http://llvm.org/bugs/attachment.cgi?id=7978 test case With top-of-tree, if I run the following with the attached test case, I get the following error: % llc -mattr=+avx bugpoint-reduced-simplified.ll LLVM ERROR: Cannot select: 0x7fc00b03c910: v4i32 = X86ISD::VBROADCAST 0x7fc00b03a210 [ID=34] 0x7fc00b03a210: i32,ch = load 0x7fc00b039f10, 0x7fc00b03a010, 0x7fc00b03a010 [ORD=2] [ID=32] 0x7fc00b03a010: i64 = undef [ORD=2] [ID=3] 0x7fc00b03a010: i64 = undef [ORD=2] [ID=3] % -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 23:03:19 2012 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Feb 2012 05:03:19 +0000 Subject: [LLVMbugs] [Bug 11847] Crash on invalid in Microsoft anonymous struct extension In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11847 Jason Haslam 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.