End of assembler dump. Here is LLVM IR: $ clang -S -emit-llvm test.c; cat test.s ; ModuleID = 'test.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" target triple = "x86_64-pc-linux-gnu" define i32 @main() nounwind { %1 = alloca i32, align 4 store i32 0, i32* %1 %2 = call i32 @btowc(i32 0) nounwind ret i32 %2 } declare i32 @btowc(i32) nounwind $ clang -O -S -emit-llvm test.c; cat test.s ; ModuleID = 'test.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" target triple = "x86_64-pc-linux-gnu" define i32 @main() nounwind readnone { br label %tailrecurse.i tailrecurse.i: ; preds = %tailrecurse.i, %0 br label %tailrecurse.i } I've attached wchar.h just in 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 Sat Apr 2 21:39:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Apr 2011 21:39:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 9615] New: Missing destructor call on objects returned from operator-> Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9615 Summary: Missing destructor call on objects returned from operator-> Product: clang Version: 2.9 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ejtttje at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6392) --> (http://llvm.org/bugs/attachment.cgi?id=6392) Demonstrates the bug. I am using Xcode 4 with Mac OS X 10.6.7. I have a piece of code which attempts to use RAII for wrapping a mutex around calls to a resource class. There is an Accessor class which overloads operator->(). This returns an instance of the Lock class, which handles mutex operations in its constructor and destructor. The Lock also overrides operator->() to return a pointer to the resource in question. (Sample code attached) This works with g++ across a variety of versions (e.g. 4.2.1 on OS X or 4.4.3 on Ubuntu), as well as llvm-g++ on OS X. The expected output is: TEST 1 Lock Acquired 0x7fff5fbff738 Hello World! Lock Released 0x7fff5fbff738 TEST 2 Lock Acquired 0x7fff5fbff740 Hello World! Lock Released 0x7fff5fbff740 However, when compiled by clang (Apple clang version 2.0 (tags/Apple/clang-137)) TEST 1 Lock Acquired 0x7fff5fbff760 Hello World! TEST 2 Lock Acquired 0x7fff5fbff758 Hello World! Lock Released 0x7fff5fbff758 Notice the Lock in the first test is never destructed/released. The difference with the second test is that a 'normal' function is called on the Accessor, which returns the Lock, and then operator-> is called on that directly. In this case, destruction appears to work correctly. It is the 'implicit' operator-> call in the first case which seems to screw up the destruction call. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 2 23:10:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Apr 2011 23:10:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 9522] Assignment to nested structs not marking fields as initialized In-Reply-To: References: Message-ID: <20110403041009.81D6C2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9522 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Ted Kremenek 2011-04-02 23:10:08 CDT --- Fixed: r128783 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 3 02:47:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Apr 2011 02:47:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 9616] New: Assertion in LiveIntervals pass Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9616 Summary: Assertion in LiveIntervals pass Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Register Allocator AssignedTo: unassignedbugs at nondot.org ReportedBy: css20 at mail.ru CC: llvmbugs at cs.uiuc.edu Platform - Linux x86_64 (may be any other), bug exists in trunk and llvm 2.9. For reproduce, run llc with bitcode file from attachment and see this: llc: /HDD/E/build/llvm-tot/src/lib/CodeGen/LiveIntervalAnalysis.cpp:825: bool llvm::LiveIntervals::shrinkToUses(llvm::LiveInterval*, llvm::SmallVectorImpl*): Assertion `PVNI->hasPHIKill() && "Missing hasPHIKill flag"' failed. 0 llc 0x0000000000e609df 1 llc 0x0000000000e62c52 2 libpthread.so.0 0x00007fdfe380a0e0 3 libc.so.6 0x00007fdfe2b25065 gsignal + 53 4 libc.so.6 0x00007fdfe2b262ff abort + 383 5 libc.so.6 0x00007fdfe2b1e1e1 __assert_fail + 241 6 llc 0x0000000000bda372 llvm::LiveIntervals::shrinkToUses(llvm::LiveInterval*, llvm::SmallVectorImpl*) + 5122 7 llc 0x0000000000b3f7a9 llvm::SimpleRegisterCoalescing::ReMaterializeTrivialDef(llvm::LiveInterval&, bool, unsigned int, unsigned int, llvm::MachineInstr*) + 937 8 llc 0x0000000000b440bc llvm::SimpleRegisterCoalescing::JoinCopy(llvm::CopyRec&, bool&) + 2252 9 llc 0x0000000000b449cc llvm::SimpleRegisterCoalescing::CopyCoalesceInMBB(llvm::MachineBasicBlock*, std::vector >&) + 1100 10 llc 0x0000000000b45146 llvm::SimpleRegisterCoalescing::joinIntervals() + 870 11 llc 0x0000000000b46698 llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&) + 5096 12 llc 0x0000000000db35eb llvm::FPPassManager::runOnFunction(llvm::Function&) + 587 13 llc 0x0000000000db36eb llvm::FPPassManager::runOnModule(llvm::Module&) + 75 14 llc 0x0000000000db4cb7 llvm::MPPassManager::runOnModule(llvm::Module&) + 503 15 llc 0x0000000000db4e4b llvm::PassManagerImpl::run(llvm::Module&) + 187 16 llc 0x000000000055935d main + 4781 17 libc.so.6 0x00007fdfe2b11bbd __libc_start_main + 253 18 llc 0x0000000000557499 Stack dump: 0. Program arguments: /HDD/E/build/llvm-tot/x86_64-Linux/Release+Asserts/bin/llc bugpoint-reduced-blocks.bc 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-blocks.bc'. 2. Running pass 'Simple Register Coalescing' on function '@_Z7paqmainiPPc' -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 3 03:36:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Apr 2011 03:36:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 9512] 32bit value not sign-extended to 64bit on X86_64 In-Reply-To: References: Message-ID: <20110403083657.B54542A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9512 Csaba R?duly 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 Sun Apr 3 12:52:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Apr 2011 12:52:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 9617] New: warn on semi-colon after function definition Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9617 Summary: warn on semi-colon after function definition Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu I'd like a warning on this code: void foo() { }; with fixit to remove the trailing semi-colon. Comeau says "error: extra ";" ignored", gcc and clang accept the code with no comment. (This code is valid, 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 Sun Apr 3 14:05:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Apr 2011 14:05:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 9618] New: Clang errors out reading cstddef Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9618 Summary: Clang errors out reading cstddef Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: gagang at cs.wisc.edu CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6394) --> (http://llvm.org/bugs/attachment.cgi?id=6394) Driver source code I have written a Clang-based driver and implemented my own ASTconsumer. When Clang parses the C++ input, it complains about cstddef, and generates the following error message: == In file included from /usr/include/c++/4.4.4/cstdlib:43: /usr/include/c++/4.4.4/cstddef:48:1: error: C++ requires a type specifier for all declarations bug_test: /afs/cs.wisc.edu/p/prometheus/private/gagan1/tools/llvm/llvm-src/tools/clang/lib/Frontend/TextDiagnosticPrinter.cpp:306: void clang::TextDiagnosticPrinter::EmitCaretDiagnostic(clang::Diagnostic::Level, clang::SourceLocation, clang::CharSourceRange*, unsigned int, const clang::SourceManager&, const clang::FixItHint*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int): Assertion `LangOpts && "Unexpected diagnostic outside source file processing"' failed. Stack dump: 0. /usr/include/c++/4.4.4/cstddef:48:25: current parser token '(' Aborted === The error is also generated for older versions of cstddef (4.3.2, etc.). I am using the latest Clang, LLVm from the trunk. Included is the driver code and the C++ test input. Clang and LLVm were installed using gcc-4.2.1. Driver code was compiled using gcc-4.5.2, with the following options: g++ -I/p/prometheus/private/gagan1/tools/llvm/llvm-src/tools/clang/include `/p/prometheus/private/gagan1/tools/llvm/install/bin/llvm-config --cxxflags` -fno-rtti -c bug_test.cpp -O0 -g Driver code was linked as follows: g++ bug_test.o -o bug_test -lclang -lclangFrontendTool -lclangFrontend -lclangIndex -lclangCodeGen -lclangDriver -lclangBasic -lclangLex -lclangParse -lclangSema -lclangAnalysis -lclangAST -lclangRewrite -lclangSerialization -lclangBasic `/p/prometheus/private/gagan1/tools/llvm/install/bin/llvm-config --cxxflags --ldflags --libs` -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 Sun Apr 3 14:50:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Apr 2011 14:50:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 9619] New: clang c++ "infinite" loop with template class and operator-> Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9619 Summary: clang c++ "infinite" loop with template class and operator-> Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Testcase: template struct A { A operator->() { return A(); } }; void f() { A<0> x; x->foo(); } There isn't any limit on the number of operator->'s that clang will try to use. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 3 15:07:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Apr 2011 15:07:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 9351] Cannot have recursive multimap In-Reply-To: References: Message-ID: <20110403200730.B76012A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9351 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Howard Hinnant 2011-04-03 15:07:29 CDT --- This looks great Chris! I would never have guessed that it was so easy to accomplish incomplete support. Thanks much. Committed revision 128797. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 3 20:37:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Apr 2011 20:37:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 9615] Missing destructor call on objects returned from operator-> In-Reply-To: References: Message-ID: <20110404013726.F06432A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9615 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Eli Friedman 2011-04-03 20:37:26 CDT --- r128806. Basically, the bug is exactly as you stated in the summary: clang wasn't destroying temporaries returned by operator->, period. In terms of a workaround, you could hack up Accessor with a doit() method, I guess... it depends on what your original code looks like. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 02:20:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 02:20:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 9585] Support __decltype() as a synonym for decltype() for gcc compatibility In-Reply-To: References: Message-ID: <20110404072044.CDBE02A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9585 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #2 from Eli Friedman 2011-04-04 02:20:44 CDT --- It's a one-line change; not worth trying to get libstdc++ changed over it. r128809. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 02:51:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 02:51:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 9620] New: Macro arguments fail with variadic Objective-C message Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9620 Summary: Macro arguments fail with variadic Objective-C message Product: clang Version: 2.9 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: me at jonathonmah.com CC: llvmbugs at cs.uiuc.edu The following should make it through the preprocessor: void *something; #define vararg_msg(x) something = (x) vararg_msg([nil msg:1, 2, 3]); Instead there are errors: % clang objc-pp.m -fsyntax-only -pedantic -ffreestanding objc-pp.m:3:24: error: too many arguments provided to function-like macro invocation vararg_msg([nil msg:1, 2, 3]); ^ objc-pp.m:3:1: error: unknown type name 'vararg_msg' vararg_msg([nil msg:1, 2, 3]); ^ objc-pp.m:3:27: error: expected identifier or '(' vararg_msg([nil msg:1, 2, 3]); ^ 3 errors generated. I am running Mac OS X 10.7 developer preview 2 (11A419). % clang --version Apple clang version 2.0 (tags/Apple/clang-138) (based on LLVM 2.9svn) Target: x86_64-apple-darwin11 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 Apr 4 03:22:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 03:22:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 9621] New: Add "-fplugin" and "-fplugin-arg-" parameters to GCC-compatible driver Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9621 Summary: Add "-fplugin" and "-fplugin-arg-" parameters to GCC-compatible driver Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: annulen at yandex.ru CC: llvmbugs at cs.uiuc.edu Currently plugin may only be loaded when clang is run in "-cc1" mode. It would be useful to have a possibility to load them in GCC-compatible mode too (using GCC-compatible syntax) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 06:54:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 06:54:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 9622] New: [Cygming] Emission of linkonce_odr {llvm_unreachable} crashes GNU binutils Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9622 Summary: [Cygming] Emission of linkonce_odr {llvm_unreachable} crashes GNU binutils 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: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu Blocks: 8390 ; foo.ll ; W/O linkonce_odr, no one crashes. define linkonce_odr void @foo() noreturn nounwind { unreachable } # foo.s .def _foo; .scl 2; .type 32; .endef .section .text$foo,"xr" .linkonce discard .globl _foo .align 16, 0x90 _foo: # @foo Lllvm$workaround$fake$stub$_foo: # BB#0: #[EOF] $ llc foo.ll $ as foo.s -o foo.o $ objdump -x foo.o foo.o crashes Cygwin-17's {objdump|ld|ar}-2.20.51.20100410, msysgit's BFD-2.19.1. BFD: BFD (GNU Binutils) 2.20.51.20100410 internal error, aborting at /netrel/src/binutils-2.20.51-2/bfd/coffcode.h line 954 in handle_COMDAT BFD: Please report this bug. (mingw-w64's 2.21.51.20101129 does not crash) 3 .text$foo 00000000 00000000 00000000 00000000 2**4 ALLOC, LOAD, READONLY, CODE, LINK_ONCE_DISCARD Shall we make workaround for zero-size section? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 07:22:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 07:22:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 9623] New: x86: inefficient code generated for i8 vector types Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9623 Summary: x86: inefficient code generated for i8 vector types 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 Given this input: define <4 x i8> @foo(<4 x i8> %x, <4 x i8> %y, <4 x i8> %__mask) nounwind readnone alwaysinline { entry: %binop = mul <4 x i8> %x, %y %binop6 = add <4 x i8> %binop, %x ret <4 x i8> %binop6 } The following quite lengthy code is generated by llc. It would be nice to get the appropriate MMX instructions instead. (This is probably not a high priority fix in the grand scheme of things, though.) _foo: ## @foo ## BB#0: ## %entry pushq %rbp pushq %r15 pushq %r14 pushq %r13 pushq %r12 pushq %rbx movdqa %xmm0, %xmm2 pextrb $1, %xmm2, %eax pextrb $1, %xmm1, %ecx mulb %cl pextrb $0, %xmm2, %ecx pextrb $0, %xmm1, %edx movzbl %al, %esi movb %cl, %al mulb %dl movzbl %al, %eax movd %eax, %xmm0 pextrb $2, %xmm2, %eax pextrb $2, %xmm1, %ecx pinsrb $1, %esi, %xmm0 mulb %cl movb %al, %cl pextrb $3, %xmm2, %eax pextrb $3, %xmm1, %edx mulb %dl movb %al, %dl movzbl %cl, %ecx pextrb $4, %xmm2, %eax pextrb $4, %xmm1, %esi pinsrb $2, %ecx, %xmm0 mulb %sil movzbl %dl, %ecx pextrb $11, %xmm2, %edx pextrb $12, %xmm2, %esi pextrb $13, %xmm2, %edi pextrb $14, %xmm2, %r8d movl %r8d, -4(%rsp) ## 4-byte Spill pextrb $5, %xmm1, %r9d pextrb $5, %xmm2, %r10d pextrb $8, %xmm1, %r11d pinsrb $3, %ecx, %xmm0 movzbl %al, %ecx pextrb $15, %xmm2, %ebx pextrb $8, %xmm2, %r14d pextrb $12, %xmm1, %r15d movb %r10b, %al pextrb $13, %xmm1, %r10d pinsrb $4, %ecx, %xmm0 pextrb $14, %xmm1, %ecx pextrb $15, %xmm1, %r12d mulb %r9b movb %al, %r9b pextrb $11, %xmm1, %r13d pextrb $10, %xmm2, %ebp movb %r14b, %al mulb %r11b movb %al, %r11b pextrb $9, %xmm2, %eax pextrb $9, %xmm1, %r14d mulb %r14b movb %al, %r14b pextrb $10, %xmm1, %r8d movb %bpl, %al mulb %r8b movb %al, %r8b movb %dl, %al mulb %r13b movb %al, %dl movb %sil, %al mulb %r15b movb %al, %sil movb %dil, %al mulb %r10b movb %al, %dil movl -4(%rsp), %eax ## 4-byte Reload mulb %cl movb %al, %cl movb %bl, %al mulb %r12b movb %al, %r10b movzbl %r9b, %r9d pextrb $7, %xmm2, %eax pextrb $7, %xmm1, %ebx mulb %bl pinsrb $5, %r9d, %xmm0 movzbl %r10b, %r9d movzbl %cl, %ecx movzbl %dil, %edi movzbl %sil, %esi movzbl %dl, %edx movzbl %r8b, %r8d movzbl %r14b, %r10d movzbl %r11b, %r11d movzbl %al, %ebx pextrb $6, %xmm2, %eax pextrb $6, %xmm1, %r14d mulb %r14b movzbl %al, %eax pinsrb $6, %eax, %xmm0 pinsrb $7, %ebx, %xmm0 pinsrb $8, %r11d, %xmm0 pinsrb $9, %r10d, %xmm0 pinsrb $10, %r8d, %xmm0 pinsrb $11, %edx, %xmm0 pinsrb $12, %esi, %xmm0 pinsrb $13, %edi, %xmm0 pinsrb $14, %ecx, %xmm0 pinsrb $15, %r9d, %xmm0 paddb %xmm2, %xmm0 popq %rbx popq %r12 popq %r13 popq %r14 popq %r15 popq %rbp ret If I explicitly extract the values from the vector, do the math, and repack, like this: define <4 x i8> @bar(<4 x i8> %x, <4 x i8> %y, <4 x i8> %__mask) nounwind readnone alwaysinline { entry: %x0 = extractelement <4 x i8> %x, i32 0 %x1 = extractelement <4 x i8> %x, i32 1 %x2 = extractelement <4 x i8> %x, i32 2 %x3 = extractelement <4 x i8> %x, i32 3 %y0 = extractelement <4 x i8> %y, i32 0 %y1 = extractelement <4 x i8> %y, i32 1 %y2 = extractelement <4 x i8> %y, i32 2 %y3 = extractelement <4 x i8> %y, i32 3 %m0 = mul i8 %x0, %y0 %m1 = mul i8 %x1, %y1 %m2 = mul i8 %x2, %y2 %m3 = mul i8 %x3, %y3 %a0 = add i8 %m0, %x0 %a1 = add i8 %m1, %x1 %a2 = add i8 %m2, %x2 %a3 = add i8 %m3, %x3 %r0 = insertelement <4 x i8> undef, i8 %a0, i32 0 %r1 = insertelement <4 x i8> %r0, i8 %a1, i32 1 %r2 = insertelement <4 x i8> %r1, i8 %a2, i32 2 %r3 = insertelement <4 x i8> %r2, i8 %a3, i32 3 ret <4 x i8> %r3 } The code is better: _bar: ## @bar ## BB#0: ## %entry pextrb $2, %xmm0, %ecx pextrb $2, %xmm1, %edx movb %cl, %al mulb %dl movb %al, %dl addb %cl, %dl pextrb $0, %xmm0, %ecx pextrb $0, %xmm1, %esi movb %cl, %al mulb %sil pextrb $3, %xmm0, %esi movb %al, %dil addb %cl, %dil movzbl %dl, %ecx pextrb $3, %xmm1, %edx movb %sil, %al mulb %dl addb %sil, %al movzbl %al, %edx shll $8, %edx pextrb $1, %xmm0, %esi orl %ecx, %edx movzbl %dil, %ecx pextrb $1, %xmm1, %edi movb %sil, %al mulb %dil addb %sil, %al movzbl %al, %eax shll $8, %eax orl %ecx, %eax pinsrw $0, %eax, %xmm0 pinsrw $1, %edx, %xmm0 ret -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 11:31:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 11:31:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 9620] Macro arguments fail with variadic Objective-C message In-Reply-To: References: Message-ID: <20110404163107.68ACB2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9620 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |INVALID --- Comment #1 from Ted Kremenek 2011-04-04 11:31:06 CDT --- This is correct behavior. Both GCC and Clang reject this code with essentially the same error. Preprocessing occurs before parsing, so the preprocessor sees the commas first. This isn't a bug in the compiler; it's a consequence of how the C language 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 Mon Apr 4 14:02:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 14:02:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 9624] New: False positive with -Wuninitialized with explicit self-initialization Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9624 Summary: False positive with -Wuninitialized with explicit self-initialization Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu A lot of code uses the construct of direct explicit initialization to mark it as intentional. The static analysis based -Wuninitialized should avoid warning on this code. % cat x.cc void test() { int x = x; (void)x; } % ./bin/clang -fsyntax-only -Wuninitialized x.cc x.cc:2:11: warning: variable 'x' is possibly uninitialized when used here [-Wuninitialized] int x = x; ^ x.cc:2:3: note: variable 'x' is declared here int x = x; ^ x.cc:2:12: note: add initialization to silence this warning int x = x; ^ = 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 Apr 4 14:04:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 14:04:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 9625] New: False positive with -Wuninitialized in trivially dead code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9625 Summary: False positive with -Wuninitialized in trivially dead code Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu I thought we were able to prune trivially dead code: % cat x.cc void test() { if (false) { int x; (void)static_cast(x); } } % ./bin/clang -fsyntax-only -Wuninitialized x.cc x.cc:4:30: warning: variable 'x' is possibly uninitialized when used here [-Wuninitialized] (void)static_cast(x); ^ x.cc:3:5: note: variable 'x' is declared here int x; ^ x.cc:3:10: note: add initialization to silence this warning int x; ^ = 0 1 warning generated. (the original code is doing casts to check if pointers are convertible, but same difference) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 14:07:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 14:07:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 9626] New: Duplicate and confusing warnings from -Wuninitialized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9626 Summary: Duplicate and confusing warnings from -Wuninitialized Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu This is partially my fault. =[ But I'm not sure what exactly to do here. I added a special check for -Wuninitialized with self-initialization cases. The recent changes to the CFG-based uninitialized checker now warn for the same construct, resulting in this: % cat x.cc void test() { int x = x + 42; (void)x; } % ./bin/clang -fsyntax-only -Wuninitialized x.cc x.cc:2:11: warning: variable 'x' is uninitialized when used within its own initialization [-Wuninitialized] int x = x + 42; ~ ^ x.cc:2:11: warning: variable 'x' is possibly uninitialized when used here [-Wuninitialized] int x = x + 42; ^ x.cc:2:3: note: variable 'x' is declared here int x = x + 42; ^ x.cc:2:17: note: add initialization to silence this warning int x = x + 42; ^ = 0 2 warnings generated. At the very least we shouldn't generate two warnings here, but more-over: - The first is much more concise - The declaration note is general unhelpful when warning on the initializer - The fixit hint is just nuts here. =/ I wonder if we should stick to the custom logic for the initializer case for now? Or is there an easy way to fix these in the CFG? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 15:31:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 15:31:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 9625] False positive with -Wuninitialized in trivially dead code In-Reply-To: References: Message-ID: <20110404203125.0FB162A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9625 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Ted Kremenek 2011-04-04 15:31:24 CDT --- Fixed: r128840 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 17:36:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 17:36:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 9627] New: potentially bogus constructor errors Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9627 Summary: potentially bogus constructor errors Product: clang Version: 2.9 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: howarth at nitro.med.uc.edu CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The modules/cealign/src/ccealignmodule.cpp c++ source file from pymol 1.3 fails to compile due to potentially bogus constructor errors... clang++ -c ccealignmodule.ii -o ccealignmodule.o In file included from ccealignmodule.cpp:1: In file included from ccealignmodule.cpp:32: In file included from ./ccealignmodule.H:36: In file included from ./tnt/tnt.h:55: tnt/tnt_sparse_matrix_csr.h:97:3: error: no matching constructor for initialization of 'Array1D' rowptr_(M, r), colind_(nz, c), dim1_(M), dim2_(N) {} ^ ~~~~ In file included from ccealignmodule.cpp:1: In file included from ccealignmodule.cpp:32: In file included from ./ccealignmodule.H:36: In file included from ./tnt/tnt.h:41: tnt/tnt_array1d.h:63:17: note: candidate constructor not viable: no known conversion from 'const int *' to 'int const' for 2nd argument explicit Array1D(int n, const T &a); ^ tnt/tnt_array1d.h:64:11: note: candidate constructor not viable: 2nd argument ('const int *') would lose const qualifier Array1D(int n, T *a); ^ tnt/tnt_array1d.h:61:11: note: candidate constructor not viable: requires 0 arguments, but 2 were provided Array1D(); ^ tnt/tnt_array1d.h:62:17: note: candidate constructor not viable: requires 1 argument, but 2 were provided explicit Array1D(int n); ^ tnt/tnt_array1d.h:65:12: note: candidate constructor not viable: requires 1 argument, but 2 were provided inline Array1D(const Array1D &A); ^ In file included from ccealignmodule.cpp:1: In file included from ccealignmodule.cpp:32: In file included from ./ccealignmodule.H:36: In file included from ./tnt/tnt.h:55: tnt/tnt_sparse_matrix_csr.h:97:18: error: no matching constructor for initialization of 'Array1D' rowptr_(M, r), colind_(nz, c), dim1_(M), dim2_(N) {} ^ ~~~~~ In file included from ccealignmodule.cpp:1: In file included from ccealignmodule.cpp:32: In file included from ./ccealignmodule.H:36: In file included from ./tnt/tnt.h:41: tnt/tnt_array1d.h:63:17: note: candidate constructor not viable: no known conversion from 'const int *' to 'int const' for 2nd argument explicit Array1D(int n, const T &a); ^ tnt/tnt_array1d.h:64:11: note: candidate constructor not viable: 2nd argument ('const int *') would lose const qualifier Array1D(int n, T *a); ^ tnt/tnt_array1d.h:61:11: note: candidate constructor not viable: requires 0 arguments, but 2 were provided Array1D(); ^ tnt/tnt_array1d.h:62:17: note: candidate constructor not viable: requires 1 argument, but 2 were provided explicit Array1D(int n); ^ tnt/tnt_array1d.h:65:12: note: candidate constructor not viable: requires 1 argument, but 2 were provided inline Array1D(const Array1D &A); ^ 2 errors generated. The same preprocessed source file is compiled by Apple llvm-gcc 4.2.1 from Xcode 4 and FSF gcc 4.6.0 without errors or warnings. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Apr 4 17:54:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 17:54:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 9628] New: Bogus warning with semi-initialised struct variables and static inline functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9628 Summary: Bogus warning with semi-initialised struct variables and static inline functions Product: clang Version: 2.9 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: macbavarious at gmail.com CC: llvmbugs at cs.uiuc.edu Consider the following program: #include struct Foo { int x; int y; }; static __inline__ int foogetx(struct Foo foo) { return foo.x; } int main() { struct Foo bar; bar.x = 5; printf("%d\n", foogetx(bar)); return 0; } $ clang --version Apple clang version 2.0 (tags/Apple/clang-137) (based on LLVM 2.9svn) Target: x86_64-apple-darwin10 Thread model: posix $ clang --analyze a.c a.c:10:20: warning: Passed-by-value struct argument contains uninitialized data (e.g., field: 'y') printf("%d\n", foogetx(bar)); ^ ~~~ 1 warning generated. This is not an actual issue since that particular member (.x) has been initialised. It seems that this should be fixed with full interprocedural analysis, but that might not be necessary considering that foogetx() is a static inline function. At any rate, using bar.x instead of foogetx(bar) is a simple enough workaround. This situation happens with some functions in Apple's Foundation library, too: NSRect frame; frame.size = NSZeroSize; NSHeight(frame) // static analyser warning frame.size.height // no static analyser 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 Mon Apr 4 18:19:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 18:19:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 9608] crash generating debug with templates and partially virtual MI In-Reply-To: References: Message-ID: <20110404231916.1C14D2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9608 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Devang Patel 2011-04-04 18:19:14 CDT --- Fixed r128855. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 18:29:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 18:29:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 9626] Duplicate and confusing warnings from -Wuninitialized In-Reply-To: References: Message-ID: <20110404232951.CBCDF2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9626 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #9 from Ted Kremenek 2011-04-04 18:29:51 CDT --- Fixed: r128858 Now the SelfReferenceChecker only handles global variables; the dataflow analysis handles other cases. We can continue to further evolve this design. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 18:37:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 18:37:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 9629] New: FileCheck substitutes variables too late. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9629 Summary: FileCheck substitutes variables too late. 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: stoklund at 2pi.dk CC: llvmbugs at cs.uiuc.edu -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Apr 4 19:26:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 19:26:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 1795] Missed optimization: eliminating loads around ptrtoint/inttoptr In-Reply-To: References: Message-ID: <20110405002607.89A282A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=1795 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #9 from Eli Friedman 2011-04-04 19:26:06 CDT --- This doesn't matter. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 4 22:22:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 22:22:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 9630] New: Assertion `*PrevPtr == this && "List invariant broken"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9630 Summary: Assertion `*PrevPtr == this && "List invariant broken"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu Another beautiful testcase, enjoy. regehr at home:~/volatile/bugs/tmp010$ clang -O1 small.c -c -w clang: Value.cpp:499: void llvm::ValueHandleBase::RemoveFromUseList(): Assertion `*PrevPtr == this && "List invariant broken"' failed. 0 clang 0x0958e8c8 Stack dump: 0. Program arguments: /mnt/z/z/compiler-install/llvm-gcc-r128807-install/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.20.51 -momit-leaf-frame-pointer -resource-dir /mnt/z/z/compiler-install/llvm-gcc-r128807-install/bin/../lib/clang/3.0 -O1 -w -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -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' 5. Running pass 'Loop Invariant Code Motion' on basic block '%for.cond1.preheader' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) regehr at home:~/volatile/bugs/tmp010$ clang -v clang version 3.0 (trunk 128807) Target: i386-pc-linux-gnu Thread model: posix regehr at home:~/volatile/bugs/tmp010$ cat small.c static unsigned char foo (unsigned long long ui1, unsigned long long ui2) { return ui2 ? : ui1 + ui2; } int g_22; short g_38; volatile short g_39; int g_40; const int *g = &g_22; int *g_104[5][5] = { }; int *g_212[3][9][1] = { }; int **g_461 = &g_212[0][5][0]; int *func_84 (int **p_87, int *p_88, unsigned long long p_89) { return *p_87; } int **func_108 (unsigned char p_110, int ***p_113) { return *p_113; } short *func (unsigned char p_61) { int *l_612 = &g_40; int **l_625 = &g_212[2][8][0]; unsigned char l_608; for (0; g; g += 0) for (l_608 = 0; l_608 < 1; l_608 += 1) { unsigned char l_749; int **l_752 = &l_612; *l_752 = func_84 (func_108 (g_39, &l_625), (foo (0, **l_752 && p_61)), 0); } 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 Mon Apr 4 23:19:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Apr 2011 23:19:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 9627] potentially bogus constructor errors In-Reply-To: References: Message-ID: <20110405041920.913232A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9627 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #2 from Eli Friedman 2011-04-04 23:19:20 CDT --- This essentially reduces to the following: template class Array1D { Array1D(int n, T *a); }; template struct A { Array1D x; A() : x(1, (const int*)0) {} }; The code is invalid, but no diagnostic is required if the class isn't instantiated. clang is being more aggressive about diagnosing the issue than 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 Tue Apr 5 02:55:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Apr 2011 02:55:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 9426] change __builtin_object_size prototype In-Reply-To: References: Message-ID: <20110405075513.2C6F32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9426 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Eric Christopher 2011-04-05 02:55:12 CDT --- Fixed thusly: [yendi:llvm/tools/clang] echristo% svn ci Sending include/clang/Basic/Builtins.def Transmitting file data . Committed revision 128880. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 5 08:00:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Apr 2011 08:00:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 9631] New: clang misses "-fpack-struct" GCC command line option Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9631 Summary: clang misses "-fpack-struct" GCC command line option Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: gmarkhor at gmail.com CC: llvmbugs at cs.uiuc.edu GCC supports -fpack-struct option, which is described at http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options It globally sets the maximum alignment for struct members. However, clang does not know about it. Please implement that :) Since #pragma pack is already inside, it will not take much 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 Apr 5 09:42:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Apr 2011 09:42:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 9632] New: bitset does not define operator>> and operator<< for streams Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9632 Summary: bitset does not define operator>> and operator<< for streams Product: libc++ Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu I believe, based on the standard, that should define both of: template basic_istream& operator>>(basic_istream& is, bitset& x); template basic_ostream& operator<<(basic_ostream& os, const bitset& x); But these are instead in and . 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 Apr 5 14:43:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Apr 2011 14:43:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 6150] Dereference of null pointer false positive In-Reply-To: References: Message-ID: <20110405194327.20AB42A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6150 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Ted Kremenek 2011-04-05 14:43:26 CDT --- The analyzer no longer produces a null pointer dereference for this 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 Apr 5 14:58:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Apr 2011 14:58:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 6150] Dereference of null pointer false positive In-Reply-To: References: Message-ID: <20110405195810.7AE4F2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6150 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Ted Kremenek 2011-04-05 14:58:09 CDT --- (In reply to comment #3) > The analyzer no longer produces a null pointer dereference for this case. Scratch that. I am able to reproduce 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 Tue Apr 5 15:14:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Apr 2011 15:14:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 6150] Dereference of null pointer false positive In-Reply-To: References: Message-ID: <20110405201456.322FB2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6150 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |DUPLICATE --- Comment #8 from Ted Kremenek 2011-04-05 15:14:55 CDT --- This is the same as PR 3098. *** This bug has been marked as a duplicate of bug 3098 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 5 16:37:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Apr 2011 16:37:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 9624] False positive with -Wuninitialized with explicit self-initialization In-Reply-To: References: Message-ID: <20110405213719.3010C2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9624 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Chandler Carruth 2011-04-05 16:37:18 CDT --- I think the last problem Ted pointed out is fixed in r128932. We should use separate bugs for any new 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 Tue Apr 5 22:35:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Apr 2011 22:35:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 9633] New: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9633 Summary: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu [regehr at gamow tmp010]$ clang -c -w -O2 small.c clang: /uusoc/exports/scratch/regehr/z/compiler-build/llvm-r128982/include/llvm/Support/Casting.h:202: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = llvm::SCEVAddRecExpr, Y = const llvm::SCEV*]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. 0 clang 0x000000000189895f 1 clang 0x000000000189abd2 2 libpthread.so.0 0x00007f03b2029190 3 libc.so.6 0x00007f03b132e4b5 gsignal + 53 4 libc.so.6 0x00007f03b1331f50 abort + 384 5 libc.so.6 0x00007f03b1327481 __assert_fail + 241 6 clang 0x00000000015709d2 7 clang 0x00000000016fa70c llvm::ScalarEvolution::computeSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 412 8 clang 0x00000000016fb414 llvm::ScalarEvolution::getSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 644 9 clang 0x00000000016fa993 llvm::ScalarEvolution::computeSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 1059 10 clang 0x00000000016fb414 llvm::ScalarEvolution::getSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 644 11 clang 0x00000000016fa993 llvm::ScalarEvolution::computeSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 1059 12 clang 0x00000000016fb414 llvm::ScalarEvolution::getSCEVAtScope(llvm::SCEV const*, llvm::Loop const*) + 644 13 clang 0x00000000016e9bc1 llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExitCondICmp(llvm::Loop const*, llvm::ICmpInst*, llvm::BasicBlock*, llvm::BasicBlock*) + 321 14 clang 0x00000000016ea2e4 llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExitCond(llvm::Loop const*, llvm::Value*, llvm::BasicBlock*, llvm::BasicBlock*) + 500 15 clang 0x00000000016ea811 llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExit(llvm::Loop const*, llvm::BasicBlock*) + 657 16 clang 0x00000000016eab54 llvm::ScalarEvolution::ComputeBackedgeTakenCount(llvm::Loop const*) + 740 17 clang 0x00000000016eaf14 llvm::ScalarEvolution::getBackedgeTakenInfo(llvm::Loop const*) + 260 18 clang 0x00000000016eb419 llvm::ScalarEvolution::getMaxBackedgeTakenCount(llvm::Loop const*) + 9 19 clang 0x00000000016f1910 llvm::ScalarEvolution::getZeroExtendExpr(llvm::SCEV const*, llvm::Type const*) + 1168 20 clang 0x00000000016f715e llvm::ScalarEvolution::getUDivExpr(llvm::SCEV const*, llvm::SCEV const*) + 814 21 clang 0x00000000016ef69b llvm::ScalarEvolution::createSCEV(llvm::Value*) + 2283 22 clang 0x00000000016f084b llvm::ScalarEvolution::getSCEV(llvm::Value*) + 555 23 clang 0x00000000016efd23 llvm::ScalarEvolution::createSCEV(llvm::Value*) + 3955 24 clang 0x00000000016f084b llvm::ScalarEvolution::getSCEV(llvm::Value*) + 555 25 clang 0x000000000169e507 llvm::IVUsers::AddUsersIfInteresting(llvm::Instruction*) + 551 26 clang 0x000000000169e975 llvm::IVUsers::AddUsersIfInteresting(llvm::Instruction*) + 1685 27 clang 0x000000000169e975 llvm::IVUsers::AddUsersIfInteresting(llvm::Instruction*) + 1685 28 clang 0x000000000169e975 llvm::IVUsers::AddUsersIfInteresting(llvm::Instruction*) + 1685 29 clang 0x000000000169ea6b llvm::IVUsers::runOnLoop(llvm::Loop*, llvm::LPPassManager&) + 171 30 clang 0x00000000016bc1c4 llvm::LPPassManager::runOnFunction(llvm::Function&) + 1140 31 clang 0x00000000017dda7b llvm::FPPassManager::runOnFunction(llvm::Function&) + 587 32 clang 0x000000000167daeb 33 clang 0x000000000167e785 34 clang 0x00000000017df084 llvm::MPPassManager::runOnModule(llvm::Module&) + 500 35 clang 0x00000000017df20b llvm::PassManagerImpl::run(llvm::Module&) + 187 36 clang 0x000000000081e2e9 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1625 37 clang 0x000000000081b0bb clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251 38 clang 0x0000000000942c1f clang::ParseAST(clang::Sema&, bool) + 431 39 clang 0x000000000081a854 clang::CodeGenAction::ExecuteAction() + 68 40 clang 0x000000000070d783 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371 41 clang 0x00000000006e8282 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1298 42 clang 0x00000000006df1fc cc1_main(char const**, char const**, char const*, void*) + 524 43 clang 0x00000000006e736d main + 4445 44 libc.so.6 0x00007f03b1319abd __libc_start_main + 253 45 clang 0x00000000006dd949 Stack dump: 0. Program arguments: /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r128982-install/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20 -momit-leaf-frame-pointer -resource-dir /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r128982-install/bin/../lib/clang/3.0 -O2 -w -ferror-limit 19 -fmessage-length 97 -fgnu-runtime -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_14' 5. Running pass 'Induction Variable Users' on basic block '%for.inc9' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) [regehr at gamow tmp010]$ clang -v clang version 3.0 (trunk 128982) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp010]$ cat small.c typedef char int8_t; typedef int int16_t; typedef char uint8_t; typedef int uint16_t; typedef int uint64_t; uint8_t foo (int8_t si1, uint8_t si2) { return si1 * si2; } uint8_t bar (int16_t left, int right) { return left < right || right ? : left >> right; } uint8_t baz (uint8_t ui1, uint8_t ui2) { return ui1 * ui2; } uint8_t buz (uint16_t left, int right) { return right >= 32 || left >> right ? left : left << right; } uint8_t func_14 (uint16_t p_17, uint8_t p_18) { for (p_17 = 0; p_17 < 1; p_17 += 1) { } for (0; 1; p_18 += 1) if (bar (foo (baz (p_18, 1), buz (p_17, 13)), 0)) 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 Apr 6 01:48:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Apr 2011 01:48:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 9634] New: likely improper segfault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9634 Summary: likely improper segfault Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu This program, as far as I can tell, should not crash. regehr at home:~/volatile/bugs/tmp011$ clang -Os small.c -o small regehr at home:~/volatile/bugs/tmp011$ ./small Segmentation fault regehr at home:~/volatile/bugs/tmp011$ clang -v clang version 3.0 (trunk 128982) Target: i386-pc-linux-gnu Thread model: posix regehr at home:~/volatile/bugs/tmp011$ cat small.c extern int printf (const char *, ...); int g_58; int *g_116; short func_82 (void); short func_82 (void) { short l_87[9]; int i; for (i = 0; i < 9; i++) l_87[i] = 0xDCDEL; return l_87[6]; } int main (void) { int p_45; for (p_45 = 0; p_45 < 4; p_45++) { g_116 = &g_58; *g_116 |= func_82 (); } printf ("checksum = 0\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 Wed Apr 6 02:09:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Apr 2011 02:09:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 8805] No indication of what's changed in new releases of the clang analyzer In-Reply-To: References: Message-ID: <20110406070955.40C692A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8805 Peter Gutmann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Peter Gutmann 2011-04-06 02:09:54 CDT --- Since there's now a link to release notes on the clang analyzer page, I've closed this bug. Thanks for the fix! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Apr 6 05:36:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Apr 2011 05:36:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 9635] New: C++0x bug in clang (possibly) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9635 Summary: C++0x bug in clang (possibly) Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I'm not sure if the following is a bug in clang, or a change in the C++ standard for C++0x (although if it is a change, it's not one I've heard of). The following code fails to compile in clang c++03 and g++. g++ 4.5 continues to reject the code in c++0x mode, but clang accepts it with -std=c++0x. Some libraries rely on code like this NOT compiling, to check templates are only instantiated in certain ways. template struct foo { friend int f(int) { return 0; } }; int main(void) { foo<1> f; foo<2> 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 Wed Apr 6 13:20:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Apr 2011 13:20:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 9441] Umbrella Bug for 2.9 Release In-Reply-To: References: Message-ID: <20110406182019.6B4982A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9441 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #16 from Bill Wendling 2011-04-06 13:20:18 CDT --- The 2.9 release is finished. The announcement will be soon. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Apr 6 15:02:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Apr 2011 15:02:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 9283] [C++] False positive: uninitialized but passed as ref arg to a member function. In-Reply-To: References: Message-ID: <20110406200216.89A022A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9283 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |FIXED --- Comment #1 from Ted Kremenek 2011-04-06 15:02:16 CDT --- I fixed this last week: http://llvm.org/viewvc/llvm-project?view=rev&revision=128557 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 6 16:06:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Apr 2011 16:06:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 9636] New: __push_heap_front does two comparisons per step, only one is needed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9636 Summary: __push_heap_front does two comparisons per step, only one is needed Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu __push_heap_front is normally used to put in the correct position an element that was previously a leaf of a heap (as in the pop_heap implementation). Since that element was a leaf, it is likely that it will move down when placed in the root. An optimization is to move down the empty space at the root by swapping it with the largest children. When the empty space becomes a leaf, the last element is moved to its place and moved up if necessary (push_heap). The advantage is that only one comparison per step is needed to move the empty space down. Wikipedia attributes the improvement to R. W. Floyd (http://en.wikipedia.org/wiki/Heapsort), but I could not find the original paper. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 6 19:45:58 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Apr 2011 19:45:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 9543] linux ppc: clang linking invokes ld for x86_64 rather than ppc In-Reply-To: References: Message-ID: <20110407004558.A1E3C2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9543 Jeremy Huddleston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Jeremy Huddleston 2011-04-06 19:45:57 CDT --- r128944 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 6 20:35:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Apr 2011 20:35:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 9634] likely improper segfault In-Reply-To: References: Message-ID: <20110407013554.4C19C2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9634 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #2 from Eli Friedman 2011-04-06 20:35:53 CDT --- r129049. (This turned out to be mostly unrelated to the other two LICM 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 Wed Apr 6 21:07:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Apr 2011 21:07:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 9638] New: llvm-gcc fails to build with gcc-4.3.2 on x86_64 linux Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9638 Summary: llvm-gcc fails to build with gcc-4.3.2 on x86_64 linux Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: etherzhhb at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6401) --> (http://llvm.org/bugs/attachment.cgi?id=6401) The header 'stl_iterator_base_types.h' When i building llvm-gcc with gcc-4.3.2 on x86_64 linux, i got: make[4]: Entering directory `/home/ether/build/llvm-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src' ... /home/ether/build/llvm-gcc/./gcc/xgcc -shared-libgcc -B/home/ether/build/llvm-gcc/./gcc -nostdinc++ -L/home/ether/build/llvm-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/ether/build/llvm-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/ether/local/llvm-gcc//x86_64-unknown-linux-gnu/bin/ -B/home/ether/local/llvm-gcc//x86_64-unknown-linux-gnu/lib/ -isystem /home/ether/local/llvm-gcc//x86_64-unknown-linux-gnu/include -isystem /home/ether/local/llvm-gcc//x86_64-unknown-linux-gnu/sys-include -I/home/ether/build/llvm-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/ether/build/llvm-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/ether/sources/llvm-gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c /home/ether/sources/llvm-gcc/libstdc++-v3/src/string-inst.cc -fPIC -DPIC -o .libs/string-inst.o Function return type does not match operand type of return inst! ret void, !dbg !940 {}Broken module found, compilation aborted! /home/ether/build/llvm-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_iterator_base_types.h: In function 'typename std::iterator_traits<_Iterator>::iterator_category std::__iterator_category(const _Iter&) [with _Iter = __gnu_cxx::__normal_iterator, std::allocator > >]': /home/ether/build/llvm-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_iterator_base_types.h:164: internal compiler error: Aborted Please submit a full bug report, I am configure llvm-gcc with: $HOME/sources/llvm-gcc/configure --prefix=$HOME/local/llvm-gcc/ --enable-languages=c,c++ --enable-checking --enable-llvm=$HOME/build/llvm-ts --disable-bootstrap --disable-multilib The result of gcc -v is: Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) And uname -a get: Linux gcc16 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64 GNU/Linux The revision of llvm-gcc is 129047, The revision of llvm is 129002 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 02:38:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 02:38:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 9635] C++0x bug in clang (possibly) In-Reply-To: References: Message-ID: <20110407073830.62EE22A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9635 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #8 from Christopher Jefferson 2011-04-07 02:38:29 CDT --- Yes, changing the return value works. Strange, I thought I tried that. Anyway, this is certainly not a bug in clang. Thanks all. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Apr 7 03:15:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 03:15:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 9638] llvm-gcc fails to build with gcc-4.3.2 on x86_64 linux In-Reply-To: References: Message-ID: <20110407081512.E1C552A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9638 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |baldrick at free.fr Resolution| |WONTFIX --- Comment #2 from Duncan Sands 2011-04-07 03:15:12 CDT --- I already fixed this in dragonegg. As llvm-gcc is now dead I don't plan to fix it in llvm-gcc. The cause of this is the recent (post 2.9) removal of support for "old style" multiple return values: it used to be possible to use "return void" with a function that returned an empty struct, but no longer. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 05:14:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 05:14:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 9639] New: Crash during llvm-ld Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9639 Summary: Crash during llvm-ld Product: new-bugs Version: 2.8 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: garrofi at hotmail.com CC: llvmbugs at cs.uiuc.edu AliasSetTracker.h void removeCallSite(CallSite CS) { for (size_t i = 0, e = CallSites.size(); i != e; ++i) if (CallSites[i] == CS.getInstruction()) { CallSites[i] = CallSites.back(); CallSites.pop_back(); } } this code is wrong, it caches the size of the vector but it doesn't update the size after removing an element from the vector this piece of code fixes it void removeCallSite(CallSite CS) { for (size_t i = 0; i != CallSites.size(); ++i) if (CallSites[i] == CS.getInstruction()) { CallSites[i] = CallSites.back(); CallSites.pop_back(); } } Thanks, Miguel -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 07:09:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 07:09:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 9640] New: clang++ optimizer causes std::bad_alloc in boost::unordered_set<>::insert Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9640 Summary: clang++ optimizer causes std::bad_alloc in boost::unordered_set<>::insert Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matthias.andree at gmx.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6402) --> (http://llvm.org/bugs/attachment.cgi?id=6402) C++ code to show misoptimization causing std::bad_alloc clang version 2.8 (branches/release_28) Target: i386-pc-linux-gnu Thread model: posix LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-ia32:core-3.2-ia32:core-4.0-ia32:desktop-4.0-ia32:desktop-4.0-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.2-ia32:graphics-3.2-noarch:graphics-4.0-ia32:graphics-4.0-noarch Distributor ID: SUSE LINUX Description: openSUSE 11.4 (i586) Release: 11.4 Codename: Celadon boost-devel-1.44.0-5.1.i586 Greetings, the attached program works OK when compiled with g++ 4.5: copying tokens to capabilities token FOO token BAR token BAZ IMAPCapa::IMAPCapa(const std::string &) completed but barfs when compiled with clang++ 2.8: $ clang++ -Wall -pedantic-errors -Wextra -g -O -fexceptions -march=athlon-xp -o break break.cpp $ ./break copying tokens to capabilities token FOO caught std::bad_alloc Apparently clang version 2.9 (trunk 116146) Target: x86_64-unknown-linux-gnu and libboost1.40-dev (Ubuntu 10.10) fares better (and succeeds like g++ 4.5 does). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 10:07:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 10:07:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 9641] New: Missing optimization for dynamic_cast to/from final class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9641 Summary: Missing optimization for dynamic_cast to/from final class Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Consider this: class A { virtual ~A(); }; class B final : public A {}; extern struct A *p; int main() { return dynamic_cast(p) != 0; } This produces the following IR: ; ModuleID = '-' 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" target triple = "x86_64-unknown-linux-gnu" %0 = type { i8*, i8*, i8* } %class.A = type { i32 (...)** } %class.B = type { [8 x i8] } @p = external global %class.A* @_ZTI1A = external constant i8* @_ZTVN10__cxxabiv120__si_class_type_infoE = external global i8* @_ZTS1B = linkonce_odr constant [3 x i8] c"1B\00" @_ZTI1B = linkonce_odr unnamed_addr constant %0 { i8* bitcast (i8** getelementptr inbounds (i8** @_ZTVN10__cxxabiv120__si_class_type_infoE, i64 2) to i8*), i8* getelementptr inbounds ([3 x i8]* @_ZTS1B, i32 0, i32 0), i8* bitcast (i8** @_ZTI1A to i8*) } define i32 @main() nounwind { entry: %retval = alloca i32, align 4 store i32 0, i32* %retval %tmp = load %class.A** @p, align 8 %0 = icmp ne %class.A* %tmp, null br i1 %0, label %1, label %5 ; :1 ; preds = %entry %2 = bitcast %class.A* %tmp to i8* %3 = call i8* @__dynamic_cast(i8* %2, i8* bitcast (i8** @_ZTI1A to i8*), i8* bitcast (%0* @_ZTI1B to i8*), i64 -1) %4 = bitcast i8* %3 to %class.B* br label %6 ; :5 ; preds = %entry br label %6 ; :6 ; preds = %5, %1 %7 = phi %class.B* [ %4, %1 ], [ null, %5 ] %cmp = icmp ne %class.B* %7, null %conv = zext i1 %cmp to i32 ret i32 %conv } declare i8* @__dynamic_cast(i8*, i8*, i8*, i64) Since 'B' is final, the call to __dynamic_cast is unnecessary: we can just directly compare p's vptr against B's vptr. When dynamic_cast<>ing /from/ a final type, the situation is even better: all dynamic_cast<>s can be directly resolved at compile time. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 11:45:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 11:45:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 9642] New: doxygen build fails Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9642 Summary: doxygen build fails Product: Build scripts Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: autoconf AssignedTo: unassignedbugs at nondot.org ReportedBy: krvladislav at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6403) --> (http://llvm.org/bugs/attachment.cgi?id=6403) fix doxygen.cfg generation [files: configure.ac, configure] Hi I've tried to get doxygen documentation by configuring with --enable-doxygen. Then 'make install' has been interrupted with message "error: configuration file /media/data/virtual/share/gsoc/build/docs/doxygen.cfg not found!". mikem, why did you remove a line "AC_CONFIG_FILES([docs/doxygen.cfg])" in autoconf/configure.ac [1] ? I've restored this line. Now 'make install' is ok and doxygen is generated. I've done pat?h by 'git diff'. If it's not acceptable, please inform me. [1] https://llvm.org/viewvc/llvm-project/llvm/trunk/autoconf/configure.ac?r1=102719&r2=103213&sortby=log -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 13:12:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 13:12:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 9643] New: clang crash on template template argument Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9643 Summary: clang crash on template template argument Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mitza at ociweb.com CC: llvmbugs at cs.uiuc.edu #include template > class container, typename DT> container

initializer(const DT& d) { container

t; t.insert(t.end(), d); return t; } int main(int, char *[]) { std::vector v = initializer(5); v.clear(); return 0; } 0 libLLVM-2.9.so 0x00007fb0dcc5d12f 1 libLLVM-2.9.so 0x00007fb0dcc5ee7a 2 libpthread.so.0 0x00007fb0dbe168f0 3 clang 0x0000000000b6a369 clang::ASTContext::getSubstTemplateTypeParmType(clang::TemplateTypeParmType const*, clang::QualType) const + 265 4 clang 0x00000000009ad280 5 clang 0x00000000009ae3e7 6 clang 0x00000000009a9bf5 7 clang 0x00000000009abef0 8 clang 0x00000000009ad0c2 9 clang 0x00000000009b4ba1 10 clang 0x00000000009ad382 11 clang 0x00000000009ae3e7 12 clang 0x00000000009a9bf5 13 clang 0x00000000009abef0 14 clang 0x00000000009ad0c2 15 clang 0x00000000009b6aed 16 clang 0x00000000009ad8aa 17 clang 0x00000000009b703d clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) + 445 18 clang 0x00000000009c13df clang::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*, llvm::SmallVectorImpl&) + 79 19 clang 0x00000000009c7213 clang::TemplateDeclInstantiator::VisitFunctionDecl(clang::FunctionDecl*, clang::TemplateParameterList*) + 435 20 clang 0x00000000009c3d7d clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 125 21 clang 0x000000000099508a clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 2634 22 clang 0x00000000009968e1 clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, clang::Expr**, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 1281 23 clang 0x0000000000909f11 clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::TemplateArgumentListInfo*, clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool) + 337 24 clang 0x0000000000914f91 clang::Sema::AddOverloadedCallCandidates(clang::UnresolvedLookupExpr*, clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool) + 481 25 clang 0x00000000009194c7 clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation, clang::Expr*) + 199 26 clang 0x00000000008aba42 clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, clang::ASTMultiPtr, clang::SourceLocation, clang::Expr*) + 1490 27 clang 0x0000000000769531 clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) + 2481 28 clang 0x000000000076a718 clang::Parser::ParseCastExpression(bool, bool, bool&, clang::OpaquePtr) + 200 29 clang 0x000000000076b55a clang::Parser::ParseCastExpression(bool, bool, clang::OpaquePtr) + 42 30 clang 0x000000000076ade3 clang::Parser::ParseCastExpression(bool, bool, bool&, clang::OpaquePtr) + 1939 31 clang 0x000000000076b55a clang::Parser::ParseCastExpression(bool, bool, clang::OpaquePtr) + 42 32 clang 0x000000000076c1ee clang::Parser::ParseAssignmentExpression() + 30 33 clang 0x0000000000753730 clang::Parser::ParseDeclarationAfterDeclarator(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&) + 544 34 clang 0x00000000007556c2 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 786 35 clang 0x000000000075e6ab clang::Parser::ParseSimpleDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, bool) + 635 36 clang 0x000000000075e822 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 98 37 clang 0x0000000000742f12 clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 194 38 clang 0x0000000000743eef clang::Parser::ParseCompoundStatementBody(bool) + 1551 39 clang 0x00000000007445ed clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 157 40 clang 0x000000000074ea9a clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 474 41 clang 0x0000000000755e40 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 2704 42 clang 0x000000000074d6a2 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 146 43 clang 0x000000000074dad0 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 448 44 clang 0x000000000074fc8a clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1578 45 clang 0x000000000074fd5d clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 109 46 clang 0x0000000000737d6b clang::ParseAST(clang::Sema&, bool) + 139 47 clang 0x0000000000621273 clang::CodeGenAction::ExecuteAction() + 51 48 clang 0x000000000052e7ab clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 283 49 clang 0x000000000050d57c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1196 50 clang 0x00000000005053b5 cc1_main(char const**, char const**, char const*, void*) + 709 51 clang 0x000000000050c6d4 main + 4724 52 libc.so.6 0x00007fb0db0f0c4d __libc_start_main + 253 53 clang 0x0000000000503a29 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name 3709_noace.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -momit-leaf-frame-pointer -g -resource-dir /usr/local/bin/../lib/clang/2.9 -O0 -ferror-limit 19 -fmessage-length 80 -fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-BiYr15.o -x c++ 3709_noace.cpp 1. 3709_noace.cpp:14:50: current parser token ')' 2. 3709_noace.cpp:13:1: parsing function body 'main' 3. 3709_noace.cpp:13:1: in compound statement ('{}') clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Apr 7 13:12:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 13:12:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 9644] New: Adding dummy argument to Fortran external routines call breaks interop with other languages Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9644 Summary: Adding dummy argument to Fortran external routines call breaks interop with other languages 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: maemarcus at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6407) --> (http://llvm.org/bugs/attachment.cgi?id=6407) test case source code There is an openmpi configure test that writes a Fortran program sending two sequential pointers of logical type to external function in C. The test is expected to compute the size of type by difference between two addresses. But instead of 2 args Fortran part sends 3, starting with 0. Please see a test case in attachment. 1) Compile: [dmikushin at tesla-cmc szlogical]$ make ./cgen-gfortran -g -c main.f90 ./cgen-gcc -g -c size.c dragonegg-gfortran main.o size.o -o szlogical Note cgen-* scripts are implementing the compilation pipeline, looping the llvm C backend: Source -> emit IR -> llc -> gcc 2) Run debugger: [dmikushin at tesla-cmc szlogical]$ gdb ./szlogical (gdb) b size_ Breakpoint 1 at 0x400724: file size.c.bc.c, line 167. (gdb) r Starting program: /home/dmikushin/Programming/kernelgen/tests/public/szlogical/szlogical Breakpoint 1, size_ (llvm_cbe_a=0x0, llvm_cbe_b=0x7fffffffdf50 "x\v`") at size.c.bc.c:167 167 llvm_cbe_alloca_20_point = ((unsigned int )0u); Missing separate debuginfos, use: debuginfo-install glibc-2.13-1.x86_64 libgcc-4.5.1-4.fc14.x86_64 libgfortran-4.5.1-4.fc14.x86_64 (gdb) f 0 #0 size_ (llvm_cbe_a=0x0, llvm_cbe_b=0x7fffffffdf50 "x\v`") at size.c.bc.c:167 167 llvm_cbe_alloca_20_point = ((unsigned int )0u); (gdb) list 162 unsigned char *llvm_cbe_tmp__1; 163 unsigned char *llvm_cbe_tmp__2; 164 unsigned int llvm_cbe_ssa_20_point; 165 unsigned int llvm_cbe_tmp__3; 166 167 llvm_cbe_alloca_20_point = ((unsigned int )0u); 168 *(&llvm_cbe_a_addr) = llvm_cbe_a; 169 *(&llvm_cbe_b_addr) = llvm_cbe_b; 170 llvm_cbe_tmp__1 = *(&llvm_cbe_b_addr); 171 llvm_cbe_tmp__2 = *(&llvm_cbe_a_addr); (gdb) f 1 #1 0x0000000000400689 in MAIN__ (vararg_dummy_arg=0) at main.f90.bc.c:172 172 size_(0 /*dummy arg*/, ((&(*(((unsigned int *)(&llvm_cbe_memtmp)))))), ((&(((unsigned int *)(&llvm_cbe_memtmp)))[((signed long long )1ull)]))); (gdb) list 167 unsigned int llvm_cbe_alloca_20_point; 168 unsigned int llvm_cbe_ssa_20_point; 169 170 llvm_cbe_alloca_20_point = ((unsigned int )0u); 171 llvm_cbe_ssa_20_point = ((unsigned int )0u); 172 size_(0 /*dummy arg*/, ((&(*(((unsigned int *)(&llvm_cbe_memtmp)))))), ((&(((unsigned int *)(&llvm_cbe_memtmp)))[((signed long long )1ull)]))); 173 return; 174 } 3) The unexpected result: size_ function is called with 3 arguments, while it actually accepts only 2, and everything gets corrupted. 4) Even simpler single language test has the same problem: program fsize external size logical x(2) call size(x(1),x(2)) end subroutine size(X,Y) end -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Apr 7 13:45:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 13:45:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 9616] Assertion in LiveIntervals pass In-Reply-To: References: Message-ID: <20110407184519.869F12A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9616 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Jakob Stoklund Olesen 2011-04-07 13:45:18 CDT --- Fixed in r129092. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 14:20:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 14:20:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 9645] New: Uninitialized value false positive when pointer captured by ctor/method Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9645 Summary: Uninitialized value false positive when pointer captured by ctor/method Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: nherring at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6408) --> (http://llvm.org/bugs/attachment.cgi?id=6408) small reproduction case A C++ object method taking a pointer argument has the opportunity to capture said pointer in its own or associated state s.t., later a side effect of another method call would be to initialize the value pointed to by the method. This is really no different than a C function taking an argument and storing it in global state, and having another C function mutate it. In the attached reproduction, the value of main's local int i is initialized by the time that UseMe is called, but clang warns anyway: test.cc:19:3: warning: Function call argument is an uninitialized value exit(i); ^ ~ 1 warning generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Apr 7 15:27:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 15:27:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 9361] .skip directive is ignored with integrated-as In-Reply-To: References: Message-ID: <20110407202753.4CB262A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9361 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Rafael ?vila de Esp?ndola 2011-04-07 15:27:52 CDT --- fixed in 129106. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 15:28:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 15:28:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 9646] New: fallback to -no-canonical-prefixes if canonicalization fails Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9646 Summary: fallback to -no-canonical-prefixes if canonicalization fails Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nobled at dreamwidth.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6410) --> (http://llvm.org/bugs/attachment.cgi?id=6410) add fall back to -no-canonical-prefixes GetMainExecutable() may fail, but the driver never checks its return value - so even if it gets an empty path, the driver invocation goes ahead anyway and it ends up like this: "" -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name test.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.20.51 -momit-leaf-frame-pointer -v -resource-dir ../lib/clang/3.0 -ferror-limit 19 -fmessage-length 80 -fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++ test.cpp clang++: error: clang frontend command failed due to signal 127 (use -v to see invocation) which obviously doesn't work. The attached patch adds a fallback that acts as if -no-canonical-prefixes was passed. To reproduce this: it fails on Linux if it can't read /proc/self/exe; e.g. if it's run in a chroot and /proc isn't mounted. This isn't a complete fix, since -no-canonical-prefixes is still completely broken when running an installed clang; see PR9576. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 17:42:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 17:42:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 9647] New: extent of MacroDefinition cursor is wrong Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9647 Summary: extent of MacroDefinition cursor is wrong Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: stefan at seefeld.name CC: llvmbugs at cs.uiuc.edu There are actually two issues: 1) For normal (C, C++) declarators it has been decided to report the extent start as the first token of the declaration specifier. I would argue that for macro definitions, the extent start should fall on the '#' token / character. 2) For a macro definition "#define FOO() ", the range end is reported to not include the parens. When I change it to "#define FOO () " (i.e. insert a whitespace), the parens are included, 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 Apr 7 17:48:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 17:48:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 9648] New: ARM disassembler: UNREACHABLE executed at [...]/llvm-trunk/lib/Target/ARM/InstPrinter/../ARMBaseInfo.h:146! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9648 Summary: ARM disassembler: UNREACHABLE executed at [...]/llvm-trunk/lib/Target/ARM/InstPrinter/../ARMBase Info.h:146! 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: sliedes at cc.hut.fi CC: llvmbugs at cs.uiuc.edu This is trunk r129111 running on Debian x86-64. I get $ echo '0x40 0xf0 0x7f 0xf5' |llvm-mc --disassemble --triple=arm dsb Unknown memory operation UNREACHABLE executed at /home/sliedes/projects/llvm-trunk/lib/Target/ARM/InstPrinter/../ARMBaseInfo.h:146! 0 llvm-mc 0x0000000000d9838f 1 llvm-mc 0x0000000000d98eca 2 libpthread.so.0 0x00007f1e41523f60 3 libc.so.6 0x00007f1e40840165 gsignal + 53 4 libc.so.6 0x00007f1e40842f70 abort + 384 5 llvm-mc 0x0000000000d82684 6 llvm-mc 0x000000000064e957 7 llvm-mc 0x0000000000408871 8 llvm-mc 0x0000000000409c1f 9 llvm-mc 0x000000000040c762 10 libc.so.6 0x00007f1e4082cc4d __libc_start_main + 253 11 llvm-mc 0x0000000000406e29 Stack dump: 0. Program arguments: llvm-mc --disassemble --triple=arm 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 Thu Apr 7 18:08:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 18:08:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 9649] New: empty.o breaks dwarfdump Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9649 Summary: empty.o breaks dwarfdump 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: nlewycky at google.com CC: dpatel at apple.com, llvmbugs at cs.uiuc.edu This program: int main(void) { return 0; } when built by "clang -g -c" produces a .o file that dwarfdump isn't happy with: .debug_info COMPILE_UNIT

: <0>< 11> DW_TAG_compile_unit DW_AT_producer clang version 3.0 (trunk 129027) DW_AT_language DW_LANG_C99 DW_AT_name empty.c DW_AT_entry_pc 0x0 DW_AT_stmt_list 0x0 DW_AT_comp_dir /home/nlewycky LOCAL_SYMBOLS: <1>< 86> DW_TAG_base_type DW_AT_encoding DW_ATE_signed DW_AT_name int DW_AT_byte_size 4 <1>< 93> DW_TAG_subprogram DW_AT_name main DW_AT_decl_file 1 DW_AT_decl_line 1 DW_AT_prototyped yes(1) DW_AT_type <86> DW_AT_external yes(1) DW_AT_low_pc 0x0 DW_AT_high_pc 0xe DW_AT_frame_base DW_OP_reg7 AT of 16359 (0x3fe7) is unknown to dwarfdump. Continuing. yes(1) .debug_line: line number info for a single cu dwarfdump ERROR: dwarf_srclines: DW_DLE_ATTR_FORM_BAD (114) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 18:17:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 18:17:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 9650] New: ARM disassembler: Assertion `0 && "Unexpected opcode!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9650 Summary: ARM disassembler: Assertion `0 && "Unexpected opcode!"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sliedes at cc.hut.fi CC: llvmbugs at cs.uiuc.edu This is trunk r129111 running on Debian x86-64. I get $ echo '0x30 0x00 0x50 0x07' |llvm-mc --disassemble --triple=arm llvm-mc: ARMDisassemblerCore.cpp:535: bool BadRegsMulFrm(unsigned int, uint32_t): Assertion `0 && "Unexpected opcode!"' failed. 0 llvm-mc 0x0000000000d9838f 1 llvm-mc 0x0000000000d98eca 2 libpthread.so.0 0x00007f464fe3cf60 3 libc.so.6 0x00007f464f159165 gsignal + 53 4 libc.so.6 0x00007f464f15bf70 abort + 384 5 libc.so.6 0x00007f464f1522b1 __assert_fail + 241 6 llvm-mc 0x000000000054b1bd 7 llvm-mc 0x000000000054bac6 8 llvm-mc 0x0000000000550b42 9 llvm-mc 0x000000000053c6ab 10 llvm-mc 0x0000000000408903 11 llvm-mc 0x0000000000409c1f 12 llvm-mc 0x000000000040c762 13 libc.so.6 0x00007f464f145c4d __libc_start_main + 253 14 llvm-mc 0x0000000000406e29 Stack dump: 0. Program arguments: llvm-mc --disassemble --triple=arm 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 Thu Apr 7 18:18:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 18:18:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 9651] New: -Wshift-overflow should show the shift result in hex Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9651 Summary: -Wshift-overflow should show the shift result in hex Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: zhanyong.wan at gmail.com CC: llvmbugs at cs.uiuc.edu -Wshift-overflow is awesome. There's room for improving its message though. Example: foo.cc:2908:58: error: shift result (36893488143124135936) requires 66 bits to represent, but 'long long' only has 64 bits [-Werror,-Wshift-overflow] Knowing the value in decimal isn't very helpful here. Since 'shift' means 'multiply/divide by power of 2', we should print the shift result in hex such that the user can easily see what the bits are. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 18:24:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 18:24:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 9652] New: Regression between r129003 and r129068 - internal compiler error: Segmentation fault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9652 Summary: Regression between r129003 and r129068 - internal compiler error: Segmentation fault Product: dragonegg Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: New Bugs AssignedTo: baldrick at free.fr ReportedBy: maemarcus at gmail.com CC: llvmbugs at cs.uiuc.edu Tracked down a DragonEgg failure with the following simplified test case: SUBROUTINE FOO() DIMENSION IBUFR(4) CHARACTER*4 VALUE VALUE=CHAR(IBUFR(1))//CHAR(IBUFR(2))// 1 CHAR(IBUFR(3))//CHAR(IBUFR(4)) END r129003 ======= dragonegg-gfortran-orig -fplugin=/home/dmikushin/opt/llvm/dragonegg/lib64/dragonegg.so -c foo.F (OK, created object) r129068 ======= dragonegg-gfortran-orig -fplugin=/home/dmikushin/opt/llvm/dragonegg/lib64/dragonegg.so -c foo.F *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event | Plugins PLUGIN_FINISH_UNIT | dragonegg PLUGIN_FINISH | dragonegg PLUGIN_START_UNIT | dragonegg buexs0.F: In function ?foo_?: buexs0.F:10:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [all] Error 1 Interestingly, if we change name of the variable IBUFR to some other, for example BUFFER, a different compile time error occurs. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 7 18:47:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 18:47:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 9653] New: MBlaze disassembler: UNREACHABLE executed at MBlazeRegisterInfo.cpp:179 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9653 Summary: MBlaze disassembler: UNREACHABLE executed at MBlazeRegisterInfo.cpp:179 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: sliedes at cc.hut.fi CC: llvmbugs at cs.uiuc.edu This is trunk r129111 running on Debian x86-64. I get $ echo '0x95 0x80 0x96' |llvm-mc --disassemble --triple=mblaze Unknown register number! UNREACHABLE executed at MBlazeRegisterInfo.cpp:179! 0 llvm-mc 0x0000000000d9838f 1 llvm-mc 0x0000000000d98eca 2 libpthread.so.0 0x00007fb4a62a3f60 3 libc.so.6 0x00007fb4a55c0165 gsignal + 53 4 libc.so.6 0x00007fb4a55c2f70 abort + 384 5 llvm-mc 0x0000000000d82684 6 llvm-mc 0x00000000004378f0 7 llvm-mc 0x000000000042ae04 8 llvm-mc 0x0000000000408903 9 llvm-mc 0x0000000000409c1f 10 llvm-mc 0x000000000040c762 11 libc.so.6 0x00007fb4a55acc4d __libc_start_main + 253 12 llvm-mc 0x0000000000406e29 Stack dump: 0. Program arguments: llvm-mc --disassemble --triple=mblaze 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 Thu Apr 7 23:01:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Apr 2011 23:01:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 9654] New: Crash on call to function template declared without function declarator Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9654 Summary: Crash on call to function template declared without function declarator Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang crashes on this code: typedef void ftype(int); template ftype f; int main() { f(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 Apr 8 07:51:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 07:51:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 9655] New: Error path combined from 2 opposite values Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9655 Summary: Error path combined from 2 opposite values Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: zdenek.kabelac at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6412) --> (http://llvm.org/bugs/attachment.cgi?id=6412) scan-build problem Hi I've noticed that this scan-build error looks strange: -- Access to field 'le_count' results in a dereference of a null pointer (loaded from variable 'org') -- It first goes with (lp->snapshot) taking false branch (line 3571) and then taking a true branch (line 3849) - obviously it will combine impossible result that 'org' could be uninitialized. I've checked referenced usage of 'lp': int vg_prearrange_replicator(struct volume_group *vg, const struct lvcreate_params *lp) seg_is_virtual(lp) is just access macro. So there is no way the clang compiler might think the value could change between those two tests for lp->snapshot. Unless I missed something it looks like bug in analyser. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 8 07:55:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 07:55:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 9656] New: dragonegg 2.9 fails to compile against FSF gcc 4.5.2/4.5.3svn and llvm 2.9 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9656 Summary: dragonegg 2.9 fails to compile against FSF gcc 4.5.2/4.5.3svn and llvm 2.9 Product: dragonegg Version: 2.9 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: New Bugs AssignedTo: baldrick at free.fr ReportedBy: howarth at nitro.med.uc.edu CC: llvmbugs at cs.uiuc.edu The build of dragonegg 2.9 against either FSF gcc 4.5.2 or 4.5.3svn and llvm 2.9 fails as follows with CC set to /sw/lib/gcc4.5/bin/gcc-4 and CXX set to /sw/lib/gcc4.5/bin/g++-4... GCC=/sw/lib/gcc4.5/bin/gcc-4 LLVM_CONFIG=/sw/bin/llvm-config make VERBOSE=1 CPPFLAGS="-DENABLE_LTO -I/sw/include" ... Compiling Backend.cpp /sw/lib/gcc4.5/bin/g++-4 -c -DENABLE_LTO -I/sw/include -I/sw/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD -MP -DIN_GCC -DREVISION=\"exported\" -DGCC_MAJOR=4 -DGCC_MINOR=5 -I/sw/src/fink.build/dragonegg-gcc45-2.9-1/dragonegg-2.9 -I/sw/src/fink.build/dragonegg-gcc45-2.9-1/dragonegg-2.9/ADT -I/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.7.0/4.5.3/plugin/include -DTARGET_NAME=\"x86_64-apple-darwin10.7.0\" -I/sw/src/fink.build/dragonegg-gcc45-2.9-1/dragonegg-2.9/x86 -I/sw/src/fink.build/dragonegg-gcc45-2.9-1/dragonegg-2.9/darwin -Wall -Wextra -fvisibility=hidden -I/sw/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual /sw/src/fink.build/dragonegg-gcc45-2.9-1/dragonegg-2.9/Backend.cpp In file included from /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.7.0/4.5.3/plugin/include/config.h:6:0, from /sw/src/fink.build/dragonegg-gcc45-2.9-1/dragonegg-2.9/Backend.cpp:55: /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.7.0/4.5.3/plugin/include/auto-host.h:39:0: warning: "DEFAULT_USE_CXA_ATEXIT" redefined /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.7.0/4.5.3/plugin/include/defaults.h:921:0: note: this is the location of the previous definition /sw/src/fink.build/dragonegg-gcc45-2.9-1/dragonegg-2.9/Backend.cpp:310:2: error: #error LLVM_TARGET_NAME macro not specified In file included from /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.7.0/4.5.3/plugin/include/tm.h:4:0, from /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.7.0/4.5.3/plugin/include/Target.h:52, from /sw/src/fink.build/dragonegg-gcc45-2.9-1/dragonegg-2.9/Backend.cpp:31: /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.7.0/4.5.3/plugin/include/options.h:414:13: error: expected unqualified-id before ')' token /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.7.0/4.5.3/plugin/include/options.h:582:13: error: expected unqualified-id before ')' token .... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 8 08:13:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 08:13:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 9657] New: Submitting self report from scan-build Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9657 Summary: Submitting self report from scan-build Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: zdenek.kabelac at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6413) --> (http://llvm.org/bugs/attachment.cgi?id=6413) clang_crash1 scan-build: The analyzer encountered problems on some source files. scan-build: Preprocessed versions of these sources were deposited in '/tmp/scan-build-2011-04-08-1/failures'. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Apr 8 08:14:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 08:14:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 9658] New: Probably inefficient code generation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9658 Summary: Probably inefficient code generation 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: eugeny.grishul at gmail.com CC: llvmbugs at cs.uiuc.edu Working on my compiler(http://code.google.com/p/bamelg/) I found that sometimes LLVM generates TOO many movb's ... movb $0, 209(%esp) movb $0, 208(%esp) movb $0, 207(%esp) movb $0, 206(%esp) movb $0, 205(%esp) movb $0, 204(%esp) movb $0, 203(%esp) ... following each other. ( total of ~500Kb of compiled movbs! ) Tested with rev 129071. 1. `llc -O=3 -march=x86 test.bc -O=3 -o test.s` 2. see test.s line 287-4403 ( also 47497-84488 ) PS. Code from real app and I have no idea how to reduce bytecode file to repro 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 Fri Apr 8 10:28:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 10:28:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 9659] New: Please support __int128_t and _uint128_t on 64-bit platforms! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9659 Summary: Please support __int128_t and _uint128_t on 64-bit platforms! Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: felix-llvm at fefe.de CC: llvmbugs at cs.uiuc.edu gcc supports __int128_t and __uint128_t on 64-bit platforms, so it is possible to make use of the 64*64->128 bit multiply instructions directly. In particular, a 128-bit integer type is needed to take advantage of 64-bit integers when implementing a bignum library in C on 64-bit platforms. Most bignum libraries are implemented in assembly language because compilers historically produced much worse code than hand-crafted assembly trickery could, but nowadays compilers ought to be able to do well with C code, too. In fact, it would be a great opportunity for perfecting the register 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 Fri Apr 8 12:56:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 12:56:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 9657] Submitting self report from scan-build In-Reply-To: References: Message-ID: <20110408175617.4EEFF2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9657 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Ted Kremenek 2011-04-08 12:56:17 CDT --- (In reply to comment #4) > clang -v > clang version 2.9 (tags/RELEASE_29/rc1) > Target: x86_64-redhat-linux-gnu > Thread model: posix > > > clang-doc-2.9-0.2.rc1.fc16.noarch > clang-analyzer-2.9-0.2.rc1.fc16.x86_64 > clang-2.9-0.2.rc1.fc16.x86_64 Okay, thanks. This has since been fixed in mainline since 2.9 branched. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 8 13:12:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:12:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 783] llvm-gcc[34] i386 ELF ABI struct return incompatibility In-Reply-To: References: Message-ID: <20110408181241.7352E2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=783 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2011-04-08 13:12:40 CDT --- llvm-gcc is end of life. Please use Clang or DragonEgg instead. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 8 13:16:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:16:41 -0500 (CDT) Subject: [LLVMbugs] =?utf-8?q?=5BBug_9660=5D_New=3A__Polymorphic_return_ty?= =?utf-8?q?pes_conflict_with_virtual_base_class_=E2=86=92_executable_segfa?= =?utf-8?q?ults?= Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9660 Summary: Polymorphic return types conflict with virtual base class ? executable segfaults Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ejtttje at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6422) --> (http://llvm.org/bugs/attachment.cgi?id=6422) sample code In the attached sample code, there is a 'Cloneable' interface to provide 'clone()'. Another class 'Base' inherits virtually from Cloneable, providing a Base* clone(), and a third class 'Derived' inherits from Base, providing its own Derived* clone(). When Derived::clone() is called, the code generated by clang will crash, as shown in this log from gdb running the attached sample code (gdb) run Starting program: /Users/ejt/test Reading symbols for shared libraries ++. done Base clone works! Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff70ec2990 0x00007fff70ec2990 in vtable for __cxxabiv1::__class_type_info () (gdb) bt #0 0x00007fff70ec2990 in vtable for __cxxabiv1::__class_type_info () #1 0x00000001000016fb in main (argc=1, argv=0x7fff5fbff730) at test.cc:26 All of the elements described above are necessary to reproduce this bug. Cloneable must provide the function prototype, Base must use virtual inheritance, and Base must update the return type. If any one of these items is removed, then the crash does not occur. Also, as noted in the above output, Base::clone() can be called successfully, it is only the Derived::clone() which crashes. g++ and llvm-g++ will compile this code for successful execution. This issue occurs identically with both the Apple clang (Apple clang version 2.0 (tags/Apple/clang-137) (based on LLVM 2.9svn)) as well as the latest svn (revision 129132) 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 Apr 8 13:16:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:16:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 2490] clang does not support __attribute__((annotate)) on functions In-Reply-To: References: Message-ID: <20110408181655.D25F52A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2490 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2011-04-08 13:16:55 CDT --- I'm pretty sure that this is implemented. We have tests for 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 Apr 8 13:17:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:17:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 2547] Implement support for Type Based Alias Analysis In-Reply-To: References: Message-ID: <20110408181722.2790D2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2547 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #12 from Chris Lattner 2011-04-08 13:17:20 CDT --- Dan implemented 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 Fri Apr 8 13:19:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:19:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 3771] [PATCH] EXEEXT missing in tool install, causes llvm-gcc configure error in cygwin In-Reply-To: References: Message-ID: <20110408181932.9A6DB2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3771 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-04-08 13:19:32 CDT --- Per anton's comment, this is already done. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Apr 8 13:24:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:24:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 9661] New: Missed optimization: unnecessary branching Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9661 Summary: Missed optimization: unnecessary branching Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: jmuizelaar at mozilla.com CC: llvmbugs at cs.uiuc.edu This code: float clamp_float(float a) { if (a > 1.0f) return 1.0f; else if (a < 0.0f) return 0.0f; else return a; } compiles to: clamp_float: # @clamp_float movss .LCPI0_0(%rip), %xmm1 ucomiss %xmm1, %xmm0 ja .LBB0_2 pxor %xmm1, %xmm1 maxss %xmm0, %xmm1 .LBB0_2: # %return movaps %xmm1, %xmm0 ret It should be able to be something like: clamp_float: # @clamp_float movss .LCPI0_0(%rip), %xmm1 minss %xmm1, %xmm0 pxor %xmm1, %xmm1 maxss %xmm1, %xmm0 ret -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Apr 8 13:28:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 6493] LLVM-GCC fails on simple case In-Reply-To: References: Message-ID: <20110408182805.DA6C92A6C133@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6493 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #4 from Chris Lattner 2011-04-08 13:28:04 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 2040] Docs for building llvm-gcc-4.2 incorrectly explain bootstrap option. In-Reply-To: References: Message-ID: <20110408182806.92CEB2A6C139@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2040 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:06 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 8153] llvm-gcc fails to build with gcc-4.2 on x86-32 linux In-Reply-To: References: Message-ID: <20110408182808.907F72A6C13B@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8153 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #8 from Chris Lattner 2011-04-08 13:28:06 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 5234] llvm-gcc doesn't honor -fno-inline? In-Reply-To: References: Message-ID: <20110408182810.4D8892A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5234 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Comment #10 from Chris Lattner 2011-04-08 13:28:08 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 2823] llvm-gcc does not respect ABI alignment for structs-with-vectors In-Reply-To: References: Message-ID: <20110408182812.114BB2A6C136@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2823 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-04-08 13:28:10 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 4719] llvm-gcc should not use duplicate definitions of the same inline function In-Reply-To: References: Message-ID: <20110408182812.EF9342A6C142@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4719 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #7 from Chris Lattner 2011-04-08 13:28:12 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 3548] Bus error with -O4 on memory deallocation In-Reply-To: References: Message-ID: <20110408182820.303A82A6C13B@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3548 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2011-04-08 13:28:19 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 9097] FreeBSD updates and enhancements In-Reply-To: References: Message-ID: <20110408182814.8F60E2A6C133@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9097 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #19 from Chris Lattner 2011-04-08 13:28:13 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 4193] llvm-gcc segfault on broken code In-Reply-To: References: Message-ID: <20110408182821.73FA82A6C147@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4193 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:20 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 3414] missing x86-64 ABI alignment for arrays In-Reply-To: References: Message-ID: <20110408182822.179A62A6C14A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3414 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #9 from Chris Lattner 2011-04-08 13:28:21 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8208] llvm-gcc-4.2 compilation failure of darwin-crt3.c (2.8 RC2) In-Reply-To: References: Message-ID: <20110408182816.544E82A6C140@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8208 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #14 from Chris Lattner 2011-04-08 13:28:14 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 4430] Too weak memory operation alignment from llvm-gcc with -O0 In-Reply-To: References: Message-ID: <20110408182822.D88312A6C133@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4430 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2011-04-08 13:28:22 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 5229] llvm-gcc generates ton of duplicate landing pads In-Reply-To: References: Message-ID: <20110408182823.8BF462A6C133@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5229 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-04-08 13:28:23 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 5013] Can't build llvm-gcc from CMake build In-Reply-To: References: Message-ID: <20110408182818.18AB92A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5013 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #7 from Chris Lattner 2011-04-08 13:28:16 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 3121] __cxa_atexit multiply defined on Mac OS X 10.4 In-Reply-To: References: Message-ID: <20110408182824.A26EE2A6C133@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3121 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #9 from Chris Lattner 2011-04-08 13:28:23 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 5852] llvm-gcc doesn't generate proper attributes in IR with -mrtd option In-Reply-To: References: Message-ID: <20110408182818.AD0472A6C13E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5852 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-04-08 13:28:18 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 1436] make llvm-gcc configure options make sense In-Reply-To: References: Message-ID: <20110408182825.DAB2B2A6C133@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=1436 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #15 from Chris Lattner 2011-04-08 13:28:24 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 5288] llvmc ignores --with-llvmgccdir flag to configure In-Reply-To: References: Message-ID: <20110408182820.AF0B32A6C142@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5288 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2011-04-08 13:28:20 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 4947] LLVM-GCC generates suboptimal type for GV zeroinitializer In-Reply-To: References: Message-ID: <20110408182819.6F9F72A6C138@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4947 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2011-04-08 13:28:18 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 9274] Add opteron-sse3, athlon64-sse3 and k8-sse3 cpu-types for -march=/-mtune= gcc options. In-Reply-To: References: Message-ID: <20110408182826.89C0E2A6C140@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9274 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-04-08 13:28:26 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 3576] llvm-gcc ignores local attribute used without -funit-at-a-time In-Reply-To: References: Message-ID: <20110408182827.33DD32A6C138@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3576 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:26 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 8378] Cannot Build llvm-gcc-4.2-2.8 on Solaris/x86 In-Reply-To: References: Message-ID: <20110408182828.E5C342A6C13E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8378 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #8 from Chris Lattner 2011-04-08 13:28:27 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 6666] llvm-gcc fails to emit volatile for volatile array struct argument? In-Reply-To: References: Message-ID: <20110408182829.68BE72A6C147@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6666 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:29 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 6406] [GNU Extension] LLVM-GCC does not fully support __force_align_arg_pointer__ In-Reply-To: References: Message-ID: <20110408182830.52AC12A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6406 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2011-04-08 13:28:29 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 4712] internal compiler error when compiling ObjC 2.0 code with fast enumeration In-Reply-To: References: Message-ID: <20110408182831.3152F2A6C14B@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4712 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #7 from Chris Lattner 2011-04-08 13:28:30 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 8332] llvm-gcc inline asm regression wrt 2.7 In-Reply-To: References: Message-ID: <20110408182831.DD1B52A6C13F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8332 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-04-08 13:28:31 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7422] llvm-gcc: TreeToLLVM::Emit @ llvm-convert.cpp asserts In-Reply-To: References: Message-ID: <20110408182833.05FC02A6C14C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7422 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2011-04-08 13:28:31 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 3360] g++.dg/abi/local1.C fails In-Reply-To: References: Message-ID: <20110408182833.9A35B2A6C155@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3360 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:33 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 4523] llvm-gcc generates symbol for weakref In-Reply-To: References: Message-ID: <20110408182834.2505F2A6C154@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4523 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:33 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 2431] llvm-gfortran 4.2 fails a bunch of its regression tests In-Reply-To: References: Message-ID: <20110408182841.B437F2A6C159@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2431 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #19 from Chris Lattner 2011-04-08 13:28:41 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7478] Assertion `(NumParams == FTy->getNumParams() || (FTy->isVarArg() && NumParams > FTy->getNumParams())) && "Calling a function with bad signature!"' In-Reply-To: References: Message-ID: <20110408182842.96B0B2A6C14C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7478 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #4 from Chris Lattner 2011-04-08 13:28:41 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 2548] wide strings versus endianness In-Reply-To: References: Message-ID: <20110408182834.EAB2D2A6C144@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2548 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-04-08 13:28:34 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 4693] arm llvm-gcc build missing symbol ___aeabi_cdcmple but __aeabi_cdcmple is present In-Reply-To: References: Message-ID: <20110408182836.E91812A6C151@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4693 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:36 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 2909] testsuite should compile Fortran using llvm-gfortran if available In-Reply-To: References: Message-ID: <20110408182844.27D4F2A6C160@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2909 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:43 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 896] llvm-gcc's xgcc links with system libstdc++ In-Reply-To: References: Message-ID: <20110408182845.68E872A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=896 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Comment #11 from Chris Lattner 2011-04-08 13:28:44 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 2432] llvm-g++ can't cope with lots of cleanups In-Reply-To: References: Message-ID: <20110408182839.DE9502A6C153@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2432 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Comment #4 from Chris Lattner 2011-04-08 13:28:39 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 4765] Dllexport function declaration, llvm-gcc aborted In-Reply-To: References: Message-ID: <20110408182838.1054C2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4765 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #10 from Chris Lattner 2011-04-08 13:28:37 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 2951] [array_ref hack] llvm-gcc error on static initializer In-Reply-To: References: Message-ID: <20110408182847.E4DDF2A6C144@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2951 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2011-04-08 13:28:47 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 3163] llvm-gcc generates incorrect LLVM IR for weakref In-Reply-To: References: Message-ID: <20110408182836.0E2ED2A6C13E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3163 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #4 from Chris Lattner 2011-04-08 13:28:35 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 1106] [llvm-gcc] "--enable-llvm" only works with a build-location, not an installed version. In-Reply-To: References: Message-ID: <20110408182843.8C93E2A6C14B@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=1106 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-04-08 13:28:42 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 5008] linking with llvm-gcc results in "/usr/bin/ld: error: gcc: malformed archive header name at 1046" In-Reply-To: References: Message-ID: <20110408182846.7B51D2A6C14B@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5008 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Comment #10 from Chris Lattner 2011-04-08 13:28:45 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 5175] llvm-gcc cannot export symbols with __declspec(dllexport) In-Reply-To: References: Message-ID: <20110408182847.06A4C2A6C144@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5175 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:46 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 8540] "llvm-gcc -m96bit-long-double" addresses memory incorrectly In-Reply-To: References: Message-ID: <20110408182838.CDC8A2A6C147@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8540 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-04-08 13:28:38 CDT --- LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -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 Fri Apr 8 13:28:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Apr 2011 13:28:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 4529] llvm-gcc 4.2 on Solaris gives internal compiler error In-Reply-To: