From bugzilla-daemon at llvm.org Tue Mar 1 01:17:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 01:17:34 -0600 (CST) Subject: [LLVMbugs] [Bug 9350] New: possible integer bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9350 Summary: possible integer bug 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 The attached program changes its output depending on the optimization level: regehr at home:~$ clang -O0 overflow.c -o overflow regehr at home:~$ ./overflow 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 regehr at home:~$ clang -O1 overflow.c -o overflow regehr at home:~$ ./overflow 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 regehr at home:~$ clang -v clang version 2.9 (trunk 126534) Target: i386-pc-linux-gnu Thread model: posix I believe this is a bug and that the -O0 output is correct. The C99 standard states that: The expression ++E is equivalent to (E+=1). Thus, x must be promoted to int before the addition takes place and so there is no undefined behavior due to overflow. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 06:24:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 06:24:04 -0600 (CST) Subject: [LLVMbugs] [Bug 9322] clang doesn't DCE dead switch cases (breaks Linux kernel at -O0) In-Reply-To: References: Message-ID: <20110301122404.141422A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9322 PaX Team changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |pageexec at freemail.hu Resolution|FIXED | --- Comment #9 from PaX Team 2011-03-01 06:24:03 CST --- i'm reopening this bug because i believe the problem i see is related to the same underlying cause. in linux/kernel/signal.c:has_pending_signals there's the following construct (linux/include/linux/signal.h has similar): 102 ????????switch (_NSIG_WORDS) { 103 ????????default: 104 ????????????????for (i = _NSIG_WORDS, ready = 0; --i >= 0 ;) 105 ????????????????????????ready |= signal->sig[i] &~ blocked->sig[i]; 106 ????????????????break; 107 108 ????????case 4: ready = signal->sig[3] &~ blocked->sig[3]; 109 ????????????????ready |= signal->sig[2] &~ blocked->sig[2]; 110 ????????????????ready |= signal->sig[1] &~ blocked->sig[1]; 111 ????????????????ready |= signal->sig[0] &~ blocked->sig[0]; 112 ????????????????break; 113 114 ????????case 2: ready = signal->sig[1] &~ blocked->sig[1]; 115 ????????????????ready |= signal->sig[0] &~ blocked->sig[0]; 116 ????????????????break; 117 118 ????????case 1: ready = signal->sig[0] &~ blocked->sig[0]; 119 ????????} on i386 _NSIG_WORDS is #defined to 2 with ->sig[] having 2 elements as well. clang r126742 generates the following warning on this: kernel/signal.c:108:19: warning: array index of '3' indexes past the end of an array (that contains 2 elements) [-Warray-bounds] case 4: ready = signal->sig[3] &~ blocked->sig[3]; and ditto for line 109. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Mar 1 07:30:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 07:30:46 -0600 (CST) Subject: [LLVMbugs] [Bug 9351] New: Cannot have recursive multimap Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9351 Summary: Cannot have recursive multimap 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 This problem effects all the tree-based data structures, but I hit it withe boost::date-time and multimap. The following is not valid in libc++: struct X { std::multimap m; }; I do not believe the standard technically requires it to work, but it is nice if it does. I believe the only thing stopping it from working is the fact that instantiating typedefs in classes also forces instantiating their members. However, I had a quick look and I don't think there is a quick fix to this -- unless there is something clever, it's probably going to involve separating all (or at least many) of the typedefs out into a separate hierarchy, just to avoid instantiating tree_node, and therefore value_type. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Mar 1 08:43:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 08:43:35 -0600 (CST) Subject: [LLVMbugs] [Bug 9352] New: [MC assembler] relocations for weak symbols not generated Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9352 Summary: [MC assembler] relocations for weak symbols not generated Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu Clang's integrated assembler does not always generate external relocations for weak symbols, even when that is required. Test case: .weak foo .equ foo, foo_stub .text foo_stub: ret bar: call foo ret Here, the "call foo" should be resolved at link time, so the assembler should put in a relocation. GNU as assembles this to: 0000000000000000 : 0: c3 retq 0000000000000001 : 1: e8 00 00 00 00 callq 6 6: c3 retq and it creates the following relocation for the call: relocation with addend (.rela.text): entry: 0 r_offset: 0x2 r_info: 2 r_addend: -4 In contrast, clang r126742 integrated-as produces: 0000000000000000 : 0: c3 retq 0000000000000001 : 1: e8 fa ff ff ff callq 0 6: c3 retq so does not create any relocation; it short-circuits the "call foo" directly. On FreeBSD, this breaks our malloc very, very badly. :) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 08:56:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 08:56:16 -0600 (CST) Subject: [LLVMbugs] [Bug 8369] Support mregparm flag In-Reply-To: References: Message-ID: <20110301145616.E88902A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8369 PaX Team changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |pageexec at freemail.hu Resolution|FIXED | -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Mar 1 09:31:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 09:31:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8177] Clang differs from GCC in how it deals with vtables in combination with limited symbol visibility, causing link errors In-Reply-To: References: Message-ID: <20110301153145.C6B282A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8177 Tor Arne Vestb? changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #3 from Tor Arne Vestb? 2011-03-01 09:31:45 CST --- I can reproduce this in LLVM at 126742 + Clang at 126740 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 09:35:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 09:35:16 -0600 (CST) Subject: [LLVMbugs] [Bug 8377] Assertion `Rep && "no type provided!"' on invalid code In-Reply-To: References: Message-ID: <20110301153516.DF16E2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8377 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Christopher Jefferson 2011-03-01 09:35:15 CST --- Has been fixed at some point. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 09:36:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 09:36:54 -0600 (CST) Subject: [LLVMbugs] [Bug 7685] Stack dump without assertion on invalid code In-Reply-To: References: Message-ID: <20110301153654.EB9202A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7685 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Christopher Jefferson 2011-03-01 09:36:53 CST --- Has been fixed at some point. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 09:37:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 09:37:51 -0600 (CST) Subject: [LLVMbugs] [Bug 8177] Clang differs from GCC in how it deals with vtables in combination with limited symbol visibility, causing link errors In-Reply-To: References: Message-ID: <20110301153751.A04F12A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8177 Tor Arne Vestb? changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Tor Arne Vestb? 2011-03-01 09:37:51 CST --- Actually, the testcase exhibits a different failure, exportedMemberFunction() is no longer exported. Sorry about that. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Mar 1 11:05:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 11:05:06 -0600 (CST) Subject: [LLVMbugs] [Bug 9328] Assertion `chunkIndex + 1 < e && "No DeclaratorChunk for the return type?"' failed. In-Reply-To: References: Message-ID: <20110301170506.E1CB72A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9328 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2011-03-01 11:05:06 CST --- Fixed in Clang r126751. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 11:12:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 11:12:22 -0600 (CST) Subject: [LLVMbugs] [Bug 9353] New: Default arguments do not work in template template functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9353 Summary: Default arguments do not work in template template functions Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code does not compile in clang, because there is only one parameter on IntervalMap in the typedef, instead of two. It does compile in g++ and comeau. template class IM; template class IntervalMap> void foo(IntervalMap* m) { typedef IntervalMap type; } Hm void f(IM* m) { foo(m); } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 11:16:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 11:16:31 -0600 (CST) Subject: [LLVMbugs] [Bug 9333] scoped enum values can't be compared In-Reply-To: References: Message-ID: <20110301171631.C41B62A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9333 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-03-01 11:16:31 CST --- Fixed in Clang r126752. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 11:55:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 11:55:34 -0600 (CST) Subject: [LLVMbugs] [Bug 9354] New: Report implicit casts of an enum type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9354 Summary: Report implicit casts of an enum type Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: ranma42 at gmail.com CC: llvmbugs at cs.uiuc.edu I'm sanitizing a C project that (mis)uses enums. I'm looking for a simple way to find out all the occurrence of implicit casts to an enum type and/or from an enum type, in order to have for coding style consistency and to ensure that the code is not misusing the enum values. Example: typedef enum { A1=0, B1, C1 } myenum1; typedef enum { A2, B2, C2 } myenum2; ... myenum1 x; myenum2 y; if (x == 0) {} /* warning */ if (x == A1) {} /* OK */ if (x == y) {} /* warning */ if (x == ((myenum1) y)) {} /* OK */ switch(x) { 0: /* warning */ B2: /* warning */ C1: /* OK */ } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 12:09:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 12:09:45 -0600 (CST) Subject: [LLVMbugs] [Bug 9355] New: missing DCE for certain constant expressions? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9355 Summary: missing DCE for certain constant expressions? Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu cloning comment 10 from bug 9322 per Ted's request: example in linux/include/linux/bitops.h (code's compiled with -O2): static inline unsigned long hweight_long(unsigned long w) { return sizeof(w) == 4 ? hweight32(w) : hweight64(w); } on i386 this should not evaluate hweight64 as that'll result in warnings like this: In file included from lib/halfmd4.c:1: In file included from include/linux/kernel.h:17: include/linux/bitops.h:49:41: warning: shift count >= width of type return sizeof(w) == 4 ? hweight32(w) : hweight64(w); ^~~~~~~~~~~~ as the macro breaks down to this: include/asm-generic/bitops/const_hweight.h:27:49: note: instantiated from: #define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) : __arch_hweight64(w)) ^ include/asm-generic/bitops/const_hweight.h:19:54: note: instantiated from: #define __const_hweight64(w) (__const_hweight32(w) + __const_hweight32((w) >> 32)) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 12:10:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 12:10:10 -0600 (CST) Subject: [LLVMbugs] [Bug 5544] don't emit "shift count is negative" warning in dead arm of conditionals In-Reply-To: References: Message-ID: <20110301181010.2123C2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5544 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #10 from Ted Kremenek 2011-03-01 12:10:09 CST --- Fixed: r126762 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 12:25:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 12:25:06 -0600 (CST) Subject: [LLVMbugs] [Bug 9322] clang doesn't DCE dead switch cases (breaks Linux kernel at -O0) In-Reply-To: References: Message-ID: <20110301182506.EDD9F2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9322 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #14 from Chris Lattner 2011-03-01 12:25:06 CST --- Please file new bugs for 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 Mar 1 12:31:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 12:31:39 -0600 (CST) Subject: [LLVMbugs] [Bug 9356] New: missing warning on inconsistent function section attribute Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9356 Summary: missing warning on inconsistent function section attribute Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu Blocks: 4068 # cat a.c void __attribute__((section(".foo"))) f(void); void __attribute__((section(".bar"))) f(void) {} # gcc -O2 a.c -c -W -Wall # objdump -drw a.o a.o: file format elf32-i386 Disassembly of section .bar: 00000000 : 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 5d pop %ebp 4: c3 ret # ./image/bin/clang -O2 a.c -c -W -Wall # objdump -drw a.o a.o: file format elf32-i386 Disassembly of section .foo: 00000000 : 0: c3 ret there're two issues here. one's that gcc chooses the attribute from the definition whereas clang chooses it from the declaration, so this is an inconsistency (but it's a wrong code case so it's not that important). the second and really important problem is that neither compiler warned about the section mismatch. FYI, the real case is in linux (acpi_status __initdata acpi_os_initialize(void); -> should be __init) and fortunately resulted in code being placed in a non-executable data section, so it was caught at runtime. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 13:14:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 13:14:24 -0600 (CST) Subject: [LLVMbugs] [Bug 9355] missing DCE for certain constant expressions? In-Reply-To: References: Message-ID: <20110301191424.159952A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9355 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |FIXED --- Comment #1 from Ted Kremenek 2011-03-01 13:14:23 CST --- Fixed: r126770 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 13:44:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 13:44:40 -0600 (CST) Subject: [LLVMbugs] [Bug 9357] New: clang doesn't DCE dead switch cases, take 2 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9357 Summary: clang doesn't DCE dead switch cases, take 2 Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu Blocks: 4068 cloning from bug 9322 comment 9 per Ted's request. in linux/kernel/signal.c:has_pending_signals there's the following construct (linux/include/linux/signal.h has similar): 102 ????????switch (_NSIG_WORDS) { 103 ????????default: 104 ????????????????for (i = _NSIG_WORDS, ready = 0; --i >= 0 ;) 105 ????????????????????????ready |= signal->sig[i] &~ blocked->sig[i]; 106 ????????????????break; 107 108 ????????case 4: ready = signal->sig[3] &~ blocked->sig[3]; 109 ????????????????ready |= signal->sig[2] &~ blocked->sig[2]; 110 ????????????????ready |= signal->sig[1] &~ blocked->sig[1]; 111 ????????????????ready |= signal->sig[0] &~ blocked->sig[0]; 112 ????????????????break; 113 114 ????????case 2: ready = signal->sig[1] &~ blocked->sig[1]; 115 ????????????????ready |= signal->sig[0] &~ blocked->sig[0]; 116 ????????????????break; 117 118 ????????case 1: ready = signal->sig[0] &~ blocked->sig[0]; 119 ????????} on i386 _NSIG_WORDS is #defined to 2 with ->sig[] having 2 elements as well. clang r126742 generates the following warning on this: kernel/signal.c:108:19: warning: array index of '3' indexes past the end of an array (that contains 2 elements) [-Warray-bounds] case 4: ready = signal->sig[3] &~ blocked->sig[3]; and ditto for line 109. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Mar 1 13:55:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 13:55:20 -0600 (CST) Subject: [LLVMbugs] [Bug 9358] New: bad -fno-exceptions and -fobjc-exceptions interaction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9358 Summary: bad -fno-exceptions and -fobjc-exceptions interaction Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang will reject #include void* operator new[](size_t size) throw (); if compiled with clang++ -c -fno-exceptions -fobjc-exceptions test.mm but clang++ -c -fno-exceptions test.mm will 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 Mar 1 14:42:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 14:42:46 -0600 (CST) Subject: [LLVMbugs] [Bug 9359] New: Clang thinks unambiguous member lookup is ambiguous (when dependent type is involved) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9359 Summary: Clang thinks unambiguous member lookup is ambiguous (when dependent type is involved) Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: zhanyong.wan at gmail.com CC: llvmbugs at cs.uiuc.edu Build clang using configure + make. $ cat t.cpp namespace PR5820 { struct Base {}; struct D1 : public Base {}; struct D2 : public Base {}; struct Derived : public D1, public D2 { void Inner() { } }; } template struct BaseT { int Member; }; template struct Derived1T : BaseT { }; template struct Derived2T : BaseT { }; template struct DerivedT : public Derived1T, public Derived2T { void Inner(); }; template void Test(DerivedT d) { d.template Derived2T::Member = 17; } template void Test(DerivedT); $ Debug+Asserts/bin/clang -cc1 -fsyntax-only t.cpp t.cpp:27:28: error: non-static member 'Member' found in multiple base-class subobjects of type 'BaseT': struct DerivedT -> Derived1T -> BaseT struct DerivedT -> Derived2T -> BaseT d.template Derived2T::Member = 17; ^ t.cpp:30:15: note: in instantiation of function template specialization 'Test' requested here template void Test(DerivedT); ^ t.cpp:14:7: note: member found by ambiguous name lookup int Member; ^ 1 error generated. Note that this bug is strange in that it's sensitive to the seemingly unrelated code in the input file (e.g. the code in namespace PR5820). I even found that it's sensitive to comments. >From this, I suspect some kind of memory corruption. Unfortunately, running it under valgrind doesn't reveal much: valgrind complains about some conditional jump depending on uninitialized values when comparing a default-initialized SourceLocation (with ID == 0) with another SourceLocation, but I believe the ctor of SourceLocation has properly initialized the ID field in this case, so it looks like a valgrind false positive to me. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Mar 1 16:10:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 16:10:17 -0600 (CST) Subject: [LLVMbugs] [Bug 9360] New: false positive warning with NSFastEnumeration and Obj-C for..in loop Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9360 Summary: false positive warning with NSFastEnumeration and Obj-C for..in loop Product: new-bugs Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sean at rogue-research.com CC: llvmbugs at cs.uiuc.edu In r126782 compiling this: ----------------- #import int main (int argc, char *argv[]) { (void)argc; (void)argv; NSObject* collection = nil; for (id thing in collection) { } return 0; } ----------------- reports: test.m:8:2: warning: collection expression type 'NSObject *' may not respond to 'countByEnumeratingWithState:objects:count:' for (id thing in collection) { } ^ ~~~~~~~~~~ That's gotta be a false positive because that's exactly the only method declared by NSFastEnumeration. gcc does not warn. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 17:13:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 17:13:31 -0600 (CST) Subject: [LLVMbugs] [Bug 9357] flow sensitive (and 'runtime behavior') warnings don't know about switches on constants In-Reply-To: References: Message-ID: <20110301231331.F2A3C2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9357 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Ted Kremenek 2011-03-01 17:13:31 CST --- Fixed: r126797 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 18:51:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 18:51:29 -0600 (CST) Subject: [LLVMbugs] [Bug 9361] New: .skip directive is ignored with integrated-as Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9361 Summary: .skip directive is ignored with integrated-as Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu Blocks: 4068 compiling linux with integrated-as results in this problem: arch/x86/kernel/setup.c:125:1: error: warning: ignoring directive for now RESERVE_BRK(dmi_alloc, 65536); ^ In file included from arch/x86/kernel/setup.c:78: /root/src/linux/linux-2.6.36.4-pax-clang/arch/x86/include/asm/setup.h:88:4: note: instantiated from: ".pushsection .brk_reservation,\"aw\", at nobits;" \ ^ :1:63: note: instantiated into assembly here .pushsection .brk_reservation,"aw", at nobits;.brk.dmi_alloc: 1:.skip 65536; .size .brk.dmi_alloc, . - 1b; .popsection ^ the full macro: 84 #define RESERVE_BRK(name,sz)????????????????????????????????????????????\ 85 ????????static void __section(.discard.text) __used?????????????????????\ 86 ????????__brk_reservation_fn_##name##__(void) {?????????????????????????\ 87 ????????????????asm volatile (??????????????????????????????????????????\ 88 ????????????????????????".pushsection .brk_reservation,\"aw\", at nobits;" \ 89 ????????????????????????".brk." #name ":"???????????????????????????????\ 90 ????????????????????????" 1:.skip %c0;"?????????????????????????????????\ 91 ????????????????????????" .size .brk." #name ", . - 1b;"????????????????\ 92 ????????????????????????" .popsection"??????????????????????????????????\ 93 ????????????????????????: : "i" (sz));??????????????????????????????????\ 94 ????????} -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 19:01:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 19:01:59 -0600 (CST) Subject: [LLVMbugs] [Bug 9362] New: MC doesn't deduce operand size for bt/bts/btc/btr Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9362 Summary: MC doesn't deduce operand size for bt/bts/btc/btr Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu Blocks: 4068 linux/arch/x86/include/asm/bitops.h has several inline functions that use the bt* insns without an explicit operand size suffix, gcc gets this right but llvm doesn't. one example: arch/x86/include/asm/bitops.h:68:19: error: ambiguous instructions require an explicit suffix (could be 'btsw', 'btsl', or 'btsq') asm volatile(LOCK_PREFIX "bts %1,%0" with 59 static __always_inline void 60 set_bit(unsigned int nr, volatile unsigned long *addr) 61 { 62 ????????if (IS_IMMEDIATE(nr)) { 63 ????????????????asm volatile(LOCK_PREFIX "orb %1,%0" 64 ????????????????????????: CONST_MASK_ADDR(nr, addr) 65 ????????????????????????: "iq" ((u8)CONST_MASK(nr)) 66 ????????????????????????: "memory"); 67 ????????} else { 68 ????????????????asm volatile(LOCK_PREFIX "bts %1,%0" 69 ????????????????????????: BITOP_ADDR(addr) : "Ir" (nr) : "memory"); 70 ????????} 71 } since the size of *addr is known, btsl should be deduced on i386 and btsq on amd64. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Mar 1 19:34:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 19:34:46 -0600 (CST) Subject: [LLVMbugs] [Bug 9259] [LSR, linux kernel] llc -O1: Broken module found, compilation aborted! In-Reply-To: References: Message-ID: <20110302013446.2FA192A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9259 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Dan Gohman 2011-03-01 19:34:45 CST --- Fixed in r126812. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 19:49:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 19:49:32 -0600 (CST) Subject: [LLVMbugs] [Bug 9350] possible integer bug In-Reply-To: References: Message-ID: <20110302014932.BCCCA2A6C131@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9350 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #12 from Eli Friedman 2011-03-01 19:49:32 CST --- r126816. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 20:04:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 20:04:52 -0600 (CST) Subject: [LLVMbugs] [Bug 9358] bad -fno-exceptions and -fobjc-exceptions interaction In-Reply-To: References: Message-ID: <20110302020452.629702A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9358 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from John McCall 2011-03-01 20:04:52 CST --- Fixed in r126820. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 22:18:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 22:18:29 -0600 (CST) Subject: [LLVMbugs] [Bug 9363] New: DwarfDebug bounds error when building ARMMCCodeEmitter -O -g Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9363 Summary: DwarfDebug bounds error when building ARMMCCodeEmitter -O -g Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: stoklund at 2pi.dk CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6255) --> (http://llvm.org/bugs/attachment.cgi?id=6255) Reduced from ARMMCCodeEmitter.bc When using clang tot r126826 to build itself with debug symbols, DwarfDebug crashes on ARMMCCodeEmitter.cpp llc ARMMCCodeEmitter.bc Assertion failed: (begin() + idx < end()), function operator[], file /Volumes/Krask/g/llvm/include/llvm/ADT/SmallVector.h, line 150. 0 llc 0x009da338 PrintStackTrace(void*) + 40 1 llc 0x009da93a SignalHandler(int) + 858 2 libSystem.B.dylib 0x94e7b46b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1796754367 4 llc 0x0002048b abort + 27 5 llc 0x00020464 __assert_rtn + 100 6 llc 0x005f8456 llvm::DwarfDebug::addCurrentFnArgument(llvm::MachineFunction const*, llvm::DbgVariable*, llvm::DbgScope*) + 358 7 llc 0x005f8e71 llvm::DwarfDebug::collectVariableInfo(llvm::MachineFunction const*, llvm::SmallPtrSet&) + 1313 8 llc 0x005fbd13 llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) + 323 9 llc 0x005d4dc0 llvm::AsmPrinter::EmitFunctionBody() + 5616 10 llc 0x003475e1 llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 257 11 llc 0x00686297 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 71 12 llc 0x00937c30 llvm::FPPassManager::runOnFunction(llvm::Function&) + 320 13 llc 0x00937f8c llvm::FPPassManager::runOnModule(llvm::Module&) + 76 14 llc 0x009380d4 llvm::MPPassManager::runOnModule(llvm::Module&) + 292 15 llc 0x009386fe llvm::PassManagerImpl::run(llvm::Module&) + 222 16 llc 0x00938ceb llvm::PassManager::run(llvm::Module&) + 27 17 llc 0x00022364 main + 4804 18 llc 0x00021095 start + 53 Stack dump: 0. Program arguments: Release+Asserts/bin/llc ARMMCCodeEmitter.bc 1. Running pass 'Function Pass Manager' on module 'ARMMCCodeEmitter.bc'. 2. Running pass 'X86 AT&T-Style Assembly Printer' on function '@_ZNK12_GLOBAL__N_116ARMMCCodeEmitter25getAddrMode2OffsetOpValueERKN4llvm6MCInstEjRNS1_15SmallVectorImplINS1_7MCFixupEEE' Illegal instruction -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 1 22:27:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 1 Mar 2011 22:27:44 -0600 (CST) Subject: [LLVMbugs] [Bug 9364] New: clang should produce llvm.compiler.used with the symbols needed for inline asm Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9364 Summary: clang should produce llvm.compiler.used with the symbols needed for inline asm Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu libLTO now has an streamer that lets it mark as used symbols needed by inline asm. It would be nice to move that to a more central location so that clang could do the same in a single compilation unit. For example, there should be no need for the user to add __attribute__((used)) to bar in: ---------------------------- asm(".text\n foo: jmp bar"); int foo(void); static int __attribute__((used)) bar(void) { return 42; } int main(void) { return foo(); } --------------------------- -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 00:25:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 00:25:43 -0600 (CST) Subject: [LLVMbugs] [Bug 9365] New: never use integrated-as on gcc output Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9365 Summary: never use integrated-as on gcc output Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Because llvm-mc does not intend to support the same assembly dialect as gcc (see discussion in bug 9164) the driver shouldn't try to use the integrated assembler to assemble gcc-produced outputs. (Using it on raw .s files is still the right thing to do.) This is only going to affect languages clang doesn't support, such as fortran. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 00:57:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 00:57:24 -0600 (CST) Subject: [LLVMbugs] [Bug 9366] New: ARM assertion failed while disassembling rsbs reg/reg form Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9366 Summary: ARM assertion failed while disassembling rsbs reg/reg form Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: crabtw at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6256) --> (http://llvm.org/bugs/attachment.cgi?id=6256) add RSBSrr ================ $ echo '0x08 0x60 0x77 0xe0' | Debug+Asserts/bin/llvm-mc -debug -arch=arm --disassemble Args: Debug+Asserts/bin/llvm-mc -debug -arch=arm --disassemble Opcode=250 Name=RSBSrs Format=ARM_FORMAT_DPSOREGFRM(5) 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ------------------------------------------------------------------------------------------------- | 1: 1: 1: 0| 0: 0: 0: 0| 0: 1: 1: 1| 0: 1: 1: 1| 0: 1: 1: 0| 0: 0: 0: 0| 0: 0: 0: 0| 1: 0: 0: 0| ------------------------------------------------------------------------------------------------- rsbs r6, r7, r8llvm-mc: /home/jyyou/src/llvm-trunk/lib/Target/ARM/InstPrinter/../ARMAddressingModes.h:44: const char* llvm::ARM_AM::getShiftOpcStr(llvm::ARM_AM::ShiftOpc): Assertion `0 && "Unknown shift opc!"' failed. ================ In this example, it should output "rsbs r6, r7, r8". It seems that ARMInstrInfo.td lacks defition of RSBSrr. Attached patch adds the definition. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 01:22:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 01:22:08 -0600 (CST) Subject: [LLVMbugs] [Bug 9367] New: ARM disassembler failed to disassemble conditional blx Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9367 Summary: ARM disassembler failed to disassemble conditional blx Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: crabtw at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6257) --> (http://llvm.org/bugs/attachment.cgi?id=6257) add BLXr9_pred ================ $ echo '0x35 0xff 0x2f 0x01' | Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug Args: Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug Opcode=0 Name=PHI Format=(42) 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ------------------------------------------------------------------------------------------------- | 0: 0: 0: 0| 0: 0: 0: 1| 0: 0: 1: 0| 1: 1: 1: 1| 1: 1: 1: 1| 1: 1: 1: 1| 0: 0: 1: 1| 0: 1: 0: 1| ------------------------------------------------------------------------------------------------- Unknown format :1:1: warning: invalid instruction encoding 0x35 0xff 0x2f 0x01 ^ ================ It should output "blxeq r5". Attached patch adds BLXr9_pred. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 01:36:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 01:36:50 -0600 (CST) Subject: [LLVMbugs] [Bug 9345] Support -Wsign-conversion In-Reply-To: References: Message-ID: <20110302073650.7BADC2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9345 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from John McCall 2011-03-02 01:36:49 CST --- Done in r126836. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 03:17:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 03:17:11 -0600 (CST) Subject: [LLVMbugs] [Bug 9368] New: ARM disassembler failed to disassemble bx Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9368 Summary: ARM disassembler failed to disassemble bx Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: crabtw at gmail.com CC: llvmbugs at cs.uiuc.edu ================ $ echo '0x1c 0xff 0x2f 0xe1' | Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug Args: Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug Opcode=0 Name=PHI Format=(42) 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ------------------------------------------------------------------------------------------------- | 1: 1: 1: 0| 0: 0: 0: 1| 0: 0: 1: 0| 1: 1: 1: 1| 1: 1: 1: 1| 1: 1: 1: 1| 0: 0: 0: 1| 1: 1: 0: 0| ------------------------------------------------------------------------------------------------- Unknown format :1:1: warning: invalid instruction encoding 0x1c 0xff 0x2f 0xe1 ^ ================ It should output "bx r12". ARMInstrInfo.td defined BX, but generated ARMGenDecoderTables.inc doesn't return the opcode of BX. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 05:36:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 05:36:11 -0600 (CST) Subject: [LLVMbugs] [Bug 9369] New: Bad legalization of vector types Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9369 Summary: Bad legalization of vector types Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu The code below fails with assertion in the SelectionDAG. Basically, the first step in the SelectionDAGISel is the legalization. In the DAG there is a chain that looks like this: i33 extract (0, zext(v4i33)) The extract is legalized to i64 while the vector remains v4i33, and soon after we hit an assertion because of the type mismatch. define void @m_387() nounwind { bb.nph18: %tmp658 = zext <4 x i32> undef to <4 x i33> br label %bb.nph11 bb.nph11: br label %bb.nph5 bb.nph5: %tmp8710 = add <4 x i33> %tmp658, undef br label %0 ; :0 br i1 undef, label %._crit_edge6, label %0 ._crit_edge6: br i1 undef, label %._crit_edge12, label %bb.nph5 ._crit_edge12: br i1 undef, label %._crit_edge19, label %bb.nph11 ._crit_edge19: ret void } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 06:38:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 06:38:18 -0600 (CST) Subject: [LLVMbugs] [Bug 9370] New: [arm] unnecessary MOVW not optimized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9370 Summary: [arm] unnecessary MOVW not optimized Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: skoe at directbox.com CC: llvmbugs at cs.uiuc.edu this: volatile store i32 -1, i32* inttoptr (i32 1342210076 to i32*), align 4, !tbaa !0 volatile store i32 -1, i32* inttoptr (i32 1342341148 to i32*), align 4, !tbaa !0 is compiled and optimized to that: movw r0, #32796 mov.w r1, #-1 movt r0, #20480 str r1, [r0] movw r0, #32796 @ <= this MOVW is not needed, value is there already movt r0, #20482 str r1, [r0] the initial C code was: LPC_GPIO0->IC = ~0; LPC_GPIO2->IC = ~0; It was compiled with -march=thumb -mcpu=cortex-m3 -O3 btw: Thanks for the great work, the ARM code looks quite good already! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 06:48:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 06:48:55 -0600 (CST) Subject: [LLVMbugs] [Bug 9371] New: Not possible to export member function of template-class (symbol still hidden) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9371 Summary: Not possible to export member function of template-class (symbol still hidden) Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tor.arne.vestbo at nokia.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In the following testcase: https://gist.github.com/584533 TemplateClass::exportedMemberFunction() is not exported when compiled with Clang, but is when compiled with GCC: libfoo.clang.dylib: 0000000000000f50 t TemplateClass<(Type)0>::exportedMemberFunction() 0000000000000000 t __mh_dylib_header U dyld_stub_binder libfoo.gcc.dylib: 0000000000000f44 T TemplateClass<(Type)0>::exportedMemberFunction() U ___gxx_personality_v0 0000000000000000 t __mh_dylib_header U dyld_stub_binder -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 11:00:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 11:00:43 -0600 (CST) Subject: [LLVMbugs] [Bug 8931] Missing FPU type directives in generated gas assembly for ARM ELF target In-Reply-To: References: Message-ID: <20110302170043.C16A72A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8931 Mans Rullgard changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |mans at mansr.com Resolution|FIXED | -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 11:30:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 11:30:07 -0600 (CST) Subject: [LLVMbugs] [Bug 9349] .svn directories installed by CMake build In-Reply-To: References: Message-ID: <20110302173007.9F9612A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9349 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Howard Hinnant 2011-03-02 11:30:07 CST --- Committed revision 126846. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 12:08:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 12:08:27 -0600 (CST) Subject: [LLVMbugs] [Bug 9370] [arm] unnecessary MOVW not optimized In-Reply-To: References: Message-ID: <20110302180827.C23102A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9370 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |evan.cheng at apple.com Resolution| |INVALID --- Comment #1 from Evan Cheng 2011-03-02 12:08:27 CST --- Hi skoe, there is nothing wrong with the codegen. movw + movt pair must target the same register. We could reuse the value of the first movw, but it requires another copy. movw r0, #32796 mov.w r1, #-1 movt r0, #20480 str r1, [r0] movw r0, #32796 @ <= this MOVW is not needed, value is there already movt r0, #20482 str r1, [r0] => movw r0, #32796 mov r2, r0 @ <= mov.w r1, #-1 movt r0, #20480 str r1, [r0] movt r2, #20482 @ <= str r1, [r2] I don't think it's any better. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 13:05:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 13:05:34 -0600 (CST) Subject: [LLVMbugs] [Bug 9370] [arm] unnecessary MOVW not optimized In-Reply-To: References: Message-ID: <20110302190534.E192B2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9370 skoe changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from skoe 2011-03-02 13:05:34 CST --- Please have a closer look again: movw r0, #32796 @ r0 = 0x0000801c mov.w r1, #-1 movt r0, #20480 @ r0 = 0x5000801c str r1, [r0] movw r0, #32796 @ r0 = 0x0000801c movt r0, #20482 @ r0 = 0x5002801c str r1, [r0] If you remove the second MOVW you have exactly the same result, because the lower 16 bits of r0 were correct already: movw r0, #32796 @ r0 = 0x0000801c mov.w r1, #-1 movt r0, #20480 @ r0 = 0x5000801c str r1, [r0] movt r0, #20482 @ r0 = 0x5002801c str r1, [r0] Remember: MOVW: Rd[15:0] := imm16, Rd[31:16] = 0, imm16 range 0-65535 MOVT: Rd[31:16] := imm16, Rd[15:0] unaffected, imm16 range 0-65535 The optimize could check if the lower 16 bits have the correct value already and replace the upper 16 bits only in this case. I know, it's only one instruction difference. But if it is in an often called interrupt handler it makes a different already :) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 13:25:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 13:25:17 -0600 (CST) Subject: [LLVMbugs] [Bug 9359] Clang thinks unambiguous member lookup is ambiguous (when dependent type is involved) In-Reply-To: References: Message-ID: <20110302192517.7FB8C2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9359 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2011-03-02 13:25:16 CST --- There was a horrible memory error in the nested-name-specifier source-location code yesterday, which was almost certainly causing this. Please try again with r126861 or newer and re-open the bug if you still see a problem. (I can't reproduce the issue) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 13:39:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 13:39:10 -0600 (CST) Subject: [LLVMbugs] [Bug 5791] Track source locations in nested name specifiers In-Reply-To: References: Message-ID: <20110302193910.BC54C2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5791 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2011-03-02 13:39:10 CST --- Implemented in a long series of patches leading up to r126861. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 14:10:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 14:10:56 -0600 (CST) Subject: [LLVMbugs] [Bug 9372] New: Include search path is wrong with -isysroot Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9372 Summary: Include search path is wrong with -isysroot Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu $ g++ -o test.ii -E -isysroot /Developer/SDKs/MacOSX10.5.sdk test.cc -v .... /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1 /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64 /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/backward /Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin10/4.2.1/include /Developer/SDKs/MacOSX10.5.sdk/usr/include /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks (framework directory) /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks (framework directory) $ clang++ -o test.ii -E -isysroot /Developer/SDKs/MacOSX10.5.sdk test.cc -v .... /usr/include/c++/4.2.1 /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64 /usr/include/c++/4.2.1/backward /usr/include/c++/4.0.0 /usr/include/c++/4.0.0/i686-apple-darwin8 /usr/include/c++/4.0.0/backward /Users/espindola/llvm/build-fast/Release/bin/../lib/clang/2.9/include /Developer/SDKs/MacOSX10.5.sdk/usr/include /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks (framework directory) /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks (framework directory) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 14:12:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 14:12:08 -0600 (CST) Subject: [LLVMbugs] [Bug 9373] New: outer array dimension size bug when defined with initializer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9373 Summary: outer array dimension size bug when defined with initializer Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: impulze at impulze.org CC: llvmbugs at cs.uiuc.edu Hey there, I'm facing a bug regarding outer array sizes if it is initialized at the definition. Details below. If more information is required feel free to ask. impulze at istari ~/clang $ gcc -ansi -pedantic -Wall -Wextra -o a.out main.c && ./a.out 28080 0x601220 0x607fd0 28080 tests: teststring array1 teststring array2 tests: teststring array2 impulze at istari ~/clang $ cat main.c #include #include char array1[351][80] = { "teststring array1" }; char array2[][20] = { "teststring array2", }; int main() { printf("%ld\n", sizeof(array1)); printf("%p %p %ld\n", (void *)array1, (void *)array2, (char *)array2 - (char *)array1); printf("tests: %s %s\n", array1[0], array2[0]); memset(array1[0], 0, sizeof array1); printf("tests: %s %s\n", array1[0], array2[0]); return 0; } impulze at istari ~/clang-wchar $ clang -v clang version 2.9 (/var/cache/paludis/distfiles/scm/clang c314aa484524c6a310a51e7b83bc194774e95e90) Target: x86_64-pc-linux-gnu Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 14:20:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 14:20:12 -0600 (CST) Subject: [LLVMbugs] [Bug 9374] New: clang makes a lot of system calls for output files Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9374 Summary: clang makes a lot of system calls for output files Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: gohman at apple.com CC: llvmbugs at cs.uiuc.edu Running clang -c testcase.c gets the following in a system call trace (which I've manually filtered): [pid 17523] stat("testcase.o", {st_mode=S_IFREG|0600, st_size=1120, ...}) = 0 [pid 17523] stat("testcase.o", {st_mode=S_IFREG|0600, st_size=1120, ...}) = 0 [pid 17523] access("testcase.o", W_OK) = 0 [pid 17523] stat("testcase.o", {st_mode=S_IFREG|0600, st_size=1120, ...}) = 0 [pid 17523] open("testcase.o-rM0aoW", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 [pid 17523] close(3) = 0 [pid 17523] open("testcase.o-rM0aoW", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 [pid 17523] close(3) = 0 [pid 17523] open("testcase.o-rM0aoW", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 3 [pid 17523] fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 [pid 17523] close(3) = 0 [pid 17523] rename("testcase.o-rM0aoW", "testcase.o") = 0 This is pretty excessive. A fair amount of it appears to have come from r114187, which was apparently intended for AST/PCH files, but was implemented to apply to all output files. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 14:32:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 14:32:59 -0600 (CST) Subject: [LLVMbugs] [Bug 6884] Clang fails to account for no-return destructors in warnings In-Reply-To: References: Message-ID: <20110302203259.6F1332A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6884 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #14 from Ted Kremenek 2011-03-02 14:32:58 CST --- Fixed in r126875. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 14:55:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 14:55:30 -0600 (CST) Subject: [LLVMbugs] [Bug 9375] New: __private_extern__ should not be recognized on non-Darwin platforms Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9375 Summary: __private_extern__ should not be recognized on non-Darwin platforms Product: clang Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu Currently, libdispatch's configure script tries to detect support for __private_extern__ by simply seeing if a program containing it compiles. Only if that compilation fails, does it attempt to use the other approach of __attribute__((visibility("hidden"))). However, on non-Darwin OSes, __private_extern__ results in a regular extern symbol, and this causes symbols using it to be visible, leading to link problems. Of course, libdispatch's configure script can be fixed to only check for __private_extern__ on Darwin. However, if __private_extern__ is a Darwin-only feature, I think it should simply result in a compile error on non-Darwin platforms. This will prevent problems with any other scripts that try to detect this feature. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 15:29:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 15:29:32 -0600 (CST) Subject: [LLVMbugs] [Bug 9373] outer array dimension size bug when defined with initializer In-Reply-To: References: Message-ID: <20110302212932.567A52A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9373 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |FIXED --- Comment #1 from Benjamin Kramer 2011-03-02 15:29:31 CST --- Fixed in r126883. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110228/039595.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 15:30:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 15:30:36 -0600 (CST) Subject: [LLVMbugs] [Bug 9362] MC doesn't deduce operand size for bt/bts/btc/btr In-Reply-To: References: Message-ID: <20110302213036.6D0702A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9362 PaX Team changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #7 from PaX Team 2011-03-02 15:30:35 CST --- (In reply to comment #6) > Precisely; and since the behavior varies depending on the operand size, and we > can't deduce the operand size, it's an error. (Note that by the time we > actually parse the asm, it's impossible to tell anything about the size of the > memory operand.) ok i see what you mean now (for some reason i kept thinking of the register offset case) and i guess the only way out is to fix the linux side, i'll do that ;). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 15:31:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 15:31:33 -0600 (CST) Subject: [LLVMbugs] [Bug 9372] Include search path is wrong with -isysroot In-Reply-To: References: Message-ID: <20110302213133.E96BF2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9372 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Rafael ?vila de Esp?ndola 2011-03-02 15:31:33 CST --- Fixed in r126884. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 15:35:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 15:35:50 -0600 (CST) Subject: [LLVMbugs] [Bug 8931] Missing FPU type directives in generated gas assembly for ARM ELF target In-Reply-To: References: Message-ID: <20110302213550.7EB0A2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8931 Renato Golin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #5 from Renato Golin 2011-03-02 15:35:50 CST --- Committed on revision 126882 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 16:35:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 16:35:18 -0600 (CST) Subject: [LLVMbugs] [Bug 9376] New: Add line number information for inline assembler Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9376 Summary: Add line number information for inline assembler Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jmuizelaar at mozilla.com CC: llvmbugs at cs.uiuc.edu It would be nice if the debug information included line number information for inline assembler blocks. This would be especially useful for crash reporting software. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 16:39:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 16:39:49 -0600 (CST) Subject: [LLVMbugs] [Bug 9377] New: MC assembler doesn't handle x86 'str' with arbitrary operand Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9377 Summary: MC assembler doesn't handle x86 'str' with arbitrary operand Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu Blocks: 4068 while compiling linux i get this error with integrated-as (gas as usual digests it): In file included from arch/x86/include/asm/elf.h:89: arch/x86/include/asm/desc.h:253:15: error: invalid operand for instruction asm volatile("str %0":"=r" (tr)); ^ :1:2: note: instantiated into assembly here str %eax ^ 1 error generated. (with unsigned long tr;) 'str' can operate on a register operand bigger than 16 bits (it'll zero extend the selector value) so this is a legal form of the insn. i didn't check but 'sldt' may need a similar fix if it doesn't handle this form already. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 16:46:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 16:46:48 -0600 (CST) Subject: [LLVMbugs] [Bug 9378] New: MC assembler doesn't handle fsubp %st, %st(1) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9378 Summary: MC assembler doesn't handle fsubp %st,%st(1) Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu Blocks: 4068 while compiling linux with integrated-as, i get the following error: arch/x86/kernel/cpu/bugs.c:74:13: error: invalid operand for instruction "fldl %1\n\t" ^ :6:12: note: instantiated into assembly here fsubp %st,%st(1) ^ 1 error generated. first note that the error message is printed for the wrong line (the actual problem is in the following line of code), the note is correct however. it seems that MC recognizes only the "fsubp %%st(1)" form. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 16:51:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 16:51:50 -0600 (CST) Subject: [LLVMbugs] [Bug 9379] New: MC assembler doesn't recognize inl (%%dx) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9379 Summary: MC assembler doesn't recognize inl (%%dx) Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu Blocks: 4068 while compiling linux with integrated-as i get the following error: arch/x86/kernel/cpu/vmware.c:48:2: error: invalid operand for instruction VMWARE_PORT(GETVERSION, eax, ebx, ecx, edx); ^ arch/x86/kernel/cpu/vmware.c:38:10: note: instantiated from: __asm__("inl (%%dx)" : \ ^ :1:6: note: instantiated into assembly here inl (%dx) ^ while 'in' doesn't take a memory operand, apparently gas can digest this form as well, so i'll leave it up to you if you want to support this bug/feature as an exception or not. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 16:53:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 16:53:03 -0600 (CST) Subject: [LLVMbugs] [Bug 9380] New: crash on AnalysisBasedWarnings Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9380 Summary: crash on AnalysisBasedWarnings Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The test: ------------ struct nsCString { ~nsCString(); }; struct nsPromiseFlatCString : public nsCString { nsPromiseFlatCString( const nsCString& str ); }; int SetStringProperty(const nsCString& aKey) { const nsCString& flatKey = nsPromiseFlatCString(aKey); } ------------ produces a segmentation fault: $ clang -cc1 -Werror=return-type nsPersistentProperties.ii 0 clang 0x0000000101092ed2 PrintStackTrace(void*) + 34 1 clang 0x0000000101093479 SignalHandler(int) + 857 2 libSystem.B.dylib 0x00007fff81dbd67a _sigtramp + 26 3 clang 0x0000000100595dc3 (anonymous namespace)::CFGBuilder::Visit(clang::Stmt*, (anonymous namespace)::AddStmtChoice) + 14835 4 clang 0x000000010058ccc1 clang::CFGImplicitDtor::getDestructorDecl() const + 113 5 clang 0x000000010058cd59 clang::CFGImplicitDtor::isNoReturn() const + 9 6 clang 0x0000000100279fa4 clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy, clang::sema::FunctionScopeInfo*, clang::Decl const*, clang::BlockExpr const*) + 2548 ... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 17:07:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 17:07:27 -0600 (CST) Subject: [LLVMbugs] [Bug 9381] New: Crash while compiling minimal boost::regex_match program. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9381 Summary: Crash while compiling minimal boost::regex_match program. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: henrik at mysko.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang++ crashes while instantiating the boost::regex_match template for a minimal example. The code is as followed (preprocessed example is attached): ---- #include int main() { return boost::regex_match("lalabc", boost::regex(".*abc")) ? 0 : 1; } ---- clang crashes with the following output: 0 clang 0x00000000018f57af 1 clang 0x00000000018f62ea 2 libpthread.so.0 0x00007f0c15244c80 3 clang 0x0000000000dd291a clang::NestedNameSpecifier::print(llvm::raw_ostream&, clang::PrintingPolicy const&) const + 26 4 clang 0x0000000000e02d41 clang::TemplateName::print(llvm::raw_ostream&, clang::PrintingPolicy const&, bool) const + 705 5 clang 0x0000000000e12f50 6 clang 0x0000000000e1653f 7 clang 0x0000000000e1b50d 8 clang 0x0000000000e16057 9 clang 0x0000000000e15ad1 10 clang 0x0000000000e17d54 clang::QualType::getAsStringInternal(clang::Type const*, clang::Qualifiers, std::string&, clang::PrintingPolicy const&) + 964 11 clang 0x0000000000998636 clang::QualType::getAsStringInternal(std::string&, clang::PrintingPolicy const&) const + 86 12 clang 0x0000000000da9048 clang::PredefinedExpr::ComputeName(clang::PredefinedExpr::IdentType, clang::Decl const*) + 2456 13 clang 0x0000000000b2fe0e 14 clang 0x0000000000b41ab9 15 clang 0x0000000000b448e5 16 clang 0x0000000000b449f1 17 clang 0x0000000000b30ff5 18 clang 0x0000000000b3f008 19 clang 0x0000000000b30135 20 clang 0x0000000000b49032 21 clang 0x0000000000b30d55 22 clang 0x0000000000b3fd7d 23 clang 0x0000000000b418cd 24 clang 0x0000000000b3ffa0 25 clang 0x0000000000b41a2d clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) + 45 26 clang 0x0000000000b55fd0 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 1280 27 clang 0x0000000000b55826 clang::Sema::PerformPendingInstantiations(bool) + 310 28 clang 0x0000000000b562e4 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 2068 29 clang 0x0000000000b55826 clang::Sema::PerformPendingInstantiations(bool) + 310 30 clang 0x0000000000b562e4 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 2068 31 clang 0x0000000000b55826 clang::Sema::PerformPendingInstantiations(bool) + 310 32 clang 0x0000000000b562e4 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 2068 33 clang 0x0000000000b55826 clang::Sema::PerformPendingInstantiations(bool) + 310 34 clang 0x000000000092fac2 clang::Sema::ActOnEndOfTranslationUnit() + 306 35 clang 0x00000000008e44f9 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 217 36 clang 0x00000000008c2cb0 clang::ParseAST(clang::Sema&, bool) + 128 37 clang 0x000000000077f7c4 clang::CodeGenAction::ExecuteAction() + 68 38 clang 0x000000000066b95b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 347 39 clang 0x00000000006473ca clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1130 40 clang 0x000000000063d2e3 cc1_main(char const**, char const**, char const*, void*) + 691 41 clang 0x00000000006463fc main + 5020 42 libc.so.6 0x00007f0c14508efe __libc_start_main + 254 43 clang 0x000000000063ce49 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name regex_test.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.0.20110216 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 238 -fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-R8AAz3.o -x c++ regex_test.cpp 1. parser at end of file 2. /usr/include/boost/regex/v4/regex_match.hpp:85:13: instantiating function definition 'regex_match' 3. /usr/include/boost/regex/v4/regex_match.hpp:44:6: instantiating function definition 'regex_match' 4. /usr/include/boost/regex/v4/perl_matcher.hpp:362:4: instantiating function definition 'perl_matcher' 5. /usr/include/boost/regex/v4/basic_regex.hpp:660:49: instantiating function definition 'get_traits' 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 Wed Mar 2 17:31:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 17:31:22 -0600 (CST) Subject: [LLVMbugs] [Bug 9382] New: Incorrect "'noreturn' should not return" when there's code after a nested call to a noreturn member function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9382 Summary: Incorrect "'noreturn' should not return" when there's code after a nested call to a noreturn member function Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com $ cat test.cc struct Errors { void fatal() __attribute__((noreturn)); }; void gold_fatal(const char* format) __attribute__((noreturn)); void gold_fatal(const char* format) { Errors().fatal(); (void)3; } $ clang++ -Wall -Werror -c test.cc test.cc:14:1: error: function declared 'noreturn' should not return [-Werror,-Winvalid-noreturn] } ^ 1 error generated. -------------- Removing the (void)3; or taking 'fatal' out of Errors causes the warning to go away. Arguably, clang should generate an "unreachable code" warning instead, but the original code after the noreturn call was a va_end() call, which seems nice to keep symmetric. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 18:12:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 18:12:11 -0600 (CST) Subject: [LLVMbugs] [Bug 9383] New: clang does not build for me Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9383 Summary: clang does not build for me Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: felix-llvm at fefe.de CC: llvmbugs at cs.uiuc.edu My LLVM build has stopped compiling through for a while now. Here's the error: [...] make[4]: Leaving directory `/cvs/llvm/tools/clang/lib/AST' make[4]: Entering directory `/cvs/llvm/tools/clang/lib/Sema' llvm[4]: Compiling SemaDeclObjC.cpp for Release+Asserts build SemaDeclObjC.cpp: In member function 'clang::Decl* clang::Sema::ActOnMethodDeclaration(clang::Scope*, clang::SourceLocation, clang::SourceLocation, clang::tok::TokenKind, clang::Decl*, clang::ObjCDeclSpec&, clang::ParsedType, clang::Selector, clang::Sema::ObjCArgInfo*, clang::DeclaratorChunk::ParamInfo*, unsigned int, clang::AttributeList*, clang::tok::ObjCKeywordKind, bool)': SemaDeclObjC.cpp:1793:34: error: 'warn_method_param_redefinition' is not a member of 'clang::diag' rm: /cvs/llvm/tools/clang/lib/Sema/Release+Asserts/SemaDeclObjC.d.tmp: file not found make[4]: *** [/cvs/llvm/tools/clang/lib/Sema/Release+Asserts/SemaDeclObjC.o] Error 1 make[4]: Leaving directory `/cvs/llvm/tools/clang/lib/Sema' make[3]: *** [Sema/.makeall] Error 2 make[3]: Leaving directory `/cvs/llvm/tools/clang/lib' make[2]: *** [all] Error 1 make[2]: Leaving directory `/cvs/llvm/tools/clang' make[1]: *** [clang/.makeall] Error 2 make[1]: Leaving directory `/cvs/llvm/tools' make: *** [all] Error 1 I did "make clean" and also tried manually deleting all the Release+Asserts directories but to no avail. My last theory was that gcc might have some broken old version of a header file in the fixed includes dir but that turned out to be not the case. What now? This is on x86_64-linux btw. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 18:36:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 18:36:42 -0600 (CST) Subject: [LLVMbugs] [Bug 9384] New: Incorrect "ambiguous function" error for extern "C" functions declared and defined in different namespaces Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9384 Summary: Incorrect "ambiguous function" error for extern "C" functions declared and defined in different namespaces Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com [dcl.link]p6 says, "Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function" So I think the call in bar() shouldn't be ambiguous below: $ cat test.cc namespace gold { extern "C" void foo(); } using namespace gold; extern "C" void foo() {} extern "C" void bar() { foo(); } $ clang++ -Wall -Werror -c test.cc test.cc:16:3: error: call to 'foo' is ambiguous foo(); ^~~ test.cc:4:1: note: candidate function foo(); ^ test.cc:10:1: note: candidate function foo() ^ 1 error generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 18:49:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 18:49:33 -0600 (CST) Subject: [LLVMbugs] [Bug 9366] ARM assertion failed while disassembling rsbs reg/reg form In-Reply-To: References: Message-ID: <20110303004933.389A52A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9366 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bob Wilson 2011-03-02 18:49:32 CST --- Kevin Enderby committed the patch in svn r126895. 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 Wed Mar 2 18:54:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 18:54:32 -0600 (CST) Subject: [LLVMbugs] [Bug 9384] Incorrect "ambiguous function" error for extern "C" functions declared and defined in different namespaces In-Reply-To: References: Message-ID: <20110303005432.B59882A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9384 Jeffrey Yasskin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Jeffrey Yasskin 2011-03-02 18:54:32 CST --- *** This bug has been marked as a duplicate of bug 7927 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Mar 2 19:01:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 19:01:26 -0600 (CST) Subject: [LLVMbugs] [Bug 9380] crash on AnalysisBasedWarnings In-Reply-To: References: Message-ID: <20110303010126.2833E2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9380 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Ted Kremenek 2011-03-02 19:01:25 CST --- Fixed: r126909 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 19:29:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 19:29:12 -0600 (CST) Subject: [LLVMbugs] [Bug 9385] New: MC assembler doesn't accept segment override for movs/lods Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9385 Summary: MC assembler doesn't accept segment override for movs/lods Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu Blocks: 4068 while compiling linux with PaX, i get the following error: arch/x86/lib/usercopy_32.c:89:3: error: invalid operand for instruction __do_strncpy_from_user(dst, src, count, res); ^ arch/x86/lib/usercopy_32.c:46:4: note: instantiated from: "0: lodsb " __copyuser_seg" (%%esi)\n" \ ^ :3:10: note: instantiated into assembly here 0: lodsb %gs: (%esi) ^ it appears that there's no form of movs where one could add a segment override to the source operand. gas accepts the following: lodsb %gs:(%esi) movsb %gs:(%esi),(%edi) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 2 19:41:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 19:41:34 -0600 (CST) Subject: [LLVMbugs] [Bug 9367] ARM disassembler failed to disassemble conditional blx In-Reply-To: References: Message-ID: <20110303014134.CF6582A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9367 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bob Wilson 2011-03-02 19:41:34 CST --- I applied the patch, along with a testcase and some minor adjustments, in svn r126915. 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 Wed Mar 2 20:41:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 2 Mar 2011 20:41:33 -0600 (CST) Subject: [LLVMbugs] [Bug 9353] Default arguments of template template parameters are not used In-Reply-To: References: Message-ID: <20110303024134.017F42A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9353 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2011-03-02 20:41:33 CST --- Fixed in Clang r126920. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 00:41:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 00:41:14 -0600 (CST) Subject: [LLVMbugs] [Bug 9370] [arm] unnecessary MOVW not optimized In-Reply-To: References: Message-ID: <20110303064114.2AA912A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9370 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #4 from Bob Wilson 2011-03-03 00:41:13 CST --- This is not a bug, just an opportunity for a potential optimization. I've moved this to a readme entry. svn r126930. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 01:21:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 01:21:53 -0600 (CST) Subject: [LLVMbugs] [Bug 9368] ARM disassembler failed to disassemble bx In-Reply-To: References: Message-ID: <20110303072153.AE2712A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9368 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Bob Wilson 2011-03-03 01:21:53 CST --- Fixed in svn r126931. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 01:49:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 01:49:23 -0600 (CST) Subject: [LLVMbugs] [Bug 9352] [MC assembler] relocations for weak symbols not generated In-Reply-To: References: Message-ID: <20110303074923.345BA2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9352 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Eli Friedman 2011-03-03 01:49:22 CST --- r126933. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 02:44:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 02:44:09 -0600 (CST) Subject: [LLVMbugs] [Bug 9386] New: ARM disassembler failed to disassemble conditional bx Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9386 Summary: ARM disassembler failed to disassemble conditional bx Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: crabtw at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6263) --> (http://llvm.org/bugs/attachment.cgi?id=6263) add pred for BX {{{ $ echo '0x15 0xff 0x2f 0x01' | Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug Args: Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug Opcode=0 Name=PHI Format=(42) 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ------------------------------------------------------------------------------------------------- | 0: 0: 0: 0| 0: 0: 0: 1| 0: 0: 1: 0| 1: 1: 1: 1| 1: 1: 1: 1| 1: 1: 1: 1| 0: 0: 0: 1| 0: 1: 0: 1| ------------------------------------------------------------------------------------------------- Unknown format :1:1: warning: invalid instruction encoding 0x15 0xff 0x2f 0x01 ^ }}} It should output "bxeq r5" Attached patch fixes the problem -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Mar 3 03:44:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 03:44:35 -0600 (CST) Subject: [LLVMbugs] [Bug 9387] New: clang/llvm generates __udivdi3 where gcc doesn't Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9387 Summary: clang/llvm generates __udivdi3 where gcc doesn't Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu Blocks: 4068 given the following code extracted from boot_delay_setup in linux: unsigned long long loops_per_msec; extern unsigned long preset_lpj; void f(void) { loops_per_msec = (unsigned long long)preset_lpj / 1000 * 250; } llvm emits a call to __udivdi3 whereas gcc optimizes it into a mul/shift sequence (compiling an i386 kernel where long is 4 bytes, long long is 8). the problem is that linux doesn't implement __udivdi3 on i386 and relies on the gcc optimization. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Mar 3 06:36:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 06:36:23 -0600 (CST) Subject: [LLVMbugs] [Bug 9388] New: selfhost segfaults in NestedNameSpecifier::getPrefix Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9388 Summary: selfhost segfaults in NestedNameSpecifier::getPrefix Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: release blocker Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: benny.kra at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This looks like a fallout from Doug's recent NestedNameSpecifier work. $ cat t.cc namespace std { template class vector { }; } template static void foo(std::vector &V) { __PRETTY_FUNCTION__; } void bar(std::vector &Blocks) { foo(Blocks); } $ clang++ t.cc clang: error: unable to execute command: Segmentation fault 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 Mar 3 06:58:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 06:58:10 -0600 (CST) Subject: [LLVMbugs] [Bug 9389] New: opt -reassociate produces invalid IR Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9389 Summary: opt -reassociate produces invalid IR Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Keywords: miscompilation Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matti.niemenmaa+llvmbugs at iki.fi CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6264) --> (http://llvm.org/bugs/attachment.cgi?id=6264) Test case With opt from r126934: $ opt -S -reassociate < bugpoint-reduced-simplified.ll Instruction does not dominate all uses! %tmp2 = add i64 undef, undef %m0 = add i64 %tmp2, undef Instruction does not dominate all uses! %m0 = add i64 %tmp2, undef %qs = add i64 %m0, %tmp2 Broken module found, compilation aborted! Stack dump: 0. Program arguments: /home/deewiant/src/llvm/install/bin/opt -reassociate -S 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'Module Verifier' on function '@Main_r_info' 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 Mar 3 08:10:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 08:10:07 -0600 (CST) Subject: [LLVMbugs] [Bug 9390] New: failed assertion "Instantiation of injected-class-name cannot fail." Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9390 Summary: failed assertion "Instantiation of injected-class-name cannot fail." Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ps at kr.tuwien.ac.at CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6266) --> (http://llvm.org/bugs/attachment.cgi?id=6266) bzip2 of preprocessor output that triggers the assertion Dear all, I have a nightly build running with clang trunk and clang release, and very recently (this particular error occured first today) the build started failing: clang: SemaTemplateInstantiateDecl.cpp:2921: clang::NamedDecl* clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, const clang::MultiLevelTemplateArgumentList&): Assertion `!T.isNull() && "Instantiation of injected-class-name cannot fail."' failed. 0 clang 0x000000000162b4ff 1 clang 0x000000000162c04a 2 libpthread.so.0 0x00002b03dd348b40 3 libc.so.6 0x00002b03ddf2eba5 gsignal + 53 4 libc.so.6 0x00002b03ddf326b0 abort + 384 5 libc.so.6 0x00002b03ddf27a71 __assert_fail + 241 6 clang 0x0000000000b0f22a clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&) + 1818 7 clang 0x0000000000b0f2cf clang::Sema::FindInstantiatedContext(clang::SourceLocation, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 63 8 clang 0x0000000000b0eecb clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&) + 955 9 clang 0x0000000000ae66e7 10 clang 0x0000000000af3635 11 clang 0x0000000000afaf82 12 clang 0x0000000000af33f1 13 clang 0x0000000000af9215 clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) + 293 14 clang 0x0000000000b0c5a0 clang::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*, llvm::SmallVectorImpl&) + 96 15 clang 0x0000000000b0f4f6 clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*, clang::TemplateParameterList*) + 422 16 clang 0x0000000000af5c4d clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 1469 17 clang 0x0000000000af6a4b clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1227 18 clang 0x0000000000b2f4c9 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 1177 19 clang 0x0000000000b339b7 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 55 20 clang 0x00000000009ad5bb clang::Sema::CheckBaseSpecifier(clang::CXXRecordDecl*, clang::SourceRange, bool, clang::AccessSpecifier, clang::TypeSourceInfo*, clang::SourceLocation) + 555 21 clang 0x0000000000af5413 clang::Sema::SubstBaseSpecifiers(clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&) + 867 22 clang 0x0000000000af58bd clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 557 23 clang 0x0000000000af6a4b clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1227 24 clang 0x0000000000b2f4c9 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 1177 25 clang 0x0000000000b339b7 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 55 26 clang 0x00000000009161bc clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&, clang::DeclContext*) + 460 27 clang 0x0000000000a84d8d clang::Sema::CheckTypenameType(clang::ElaboratedTypeKeyword, clang::SourceLocation, clang::NestedNameSpecifierLoc, clang::IdentifierInfo const&, clang::SourceLocation) + 173 28 clang 0x0000000000afc49a 29 clang 0x0000000000af2589 30 clang 0x0000000000af49ee 31 clang 0x0000000000aeb70e 32 clang 0x0000000000aed928 33 clang 0x0000000000af278f 34 clang 0x0000000000af49ee 35 clang 0x0000000000af5042 clang::Sema::SubstType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) + 114 36 clang 0x0000000000b0d591 clang::TemplateDeclInstantiator::VisitTypedefDecl(clang::TypedefDecl*) + 321 37 clang 0x0000000000af5c4d clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 1469 38 clang 0x0000000000af6a4b clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1227 39 clang 0x0000000000b2f4c9 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 1177 40 clang 0x0000000000b339b7 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 55 41 clang 0x00000000009161bc clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&, clang::DeclContext*) + 460 42 clang 0x0000000000a84d8d clang::Sema::CheckTypenameType(clang::ElaboratedTypeKeyword, clang::SourceLocation, clang::NestedNameSpecifierLoc, clang::IdentifierInfo const&, clang::SourceLocation) + 173 43 clang 0x0000000000afc49a 44 clang 0x0000000000af2589 45 clang 0x0000000000af49ee 46 clang 0x0000000000af5042 clang::Sema::SubstType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) + 114 47 clang 0x0000000000b0d591 clang::TemplateDeclInstantiator::VisitTypedefDecl(clang::TypedefDecl*) + 321 48 clang 0x0000000000af5c4d clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 1469 49 clang 0x0000000000af6a4b clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1227 50 clang 0x0000000000b2f4c9 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 1177 51 clang 0x0000000000b339b7 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 55 52 clang 0x00000000009161bc clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&, clang::DeclContext*) + 460 53 clang 0x0000000000a84d8d clang::Sema::CheckTypenameType(clang::ElaboratedTypeKeyword, clang::SourceLocation, clang::NestedNameSpecifierLoc, clang::IdentifierInfo const&, clang::SourceLocation) + 173 54 clang 0x0000000000afc49a 55 clang 0x0000000000af2589 56 clang 0x0000000000af49ee 57 clang 0x0000000000af5042 clang::Sema::SubstType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) + 114 58 clang 0x0000000000b0d591 clang::TemplateDeclInstantiator::VisitTypedefDecl(clang::TypedefDecl*) + 321 59 clang 0x0000000000af5c4d clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 1469 60 clang 0x0000000000af6a4b clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1227 61 clang 0x0000000000b2f4c9 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 1177 62 clang 0x0000000000b339b7 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 55 63 clang 0x00000000009ad5bb clang::Sema::CheckBaseSpecifier(clang::CXXRecordDecl*, clang::SourceRange, bool, clang::AccessSpecifier, clang::TypeSourceInfo*, clang::SourceLocation) + 555 64 clang 0x0000000000af5413 clang::Sema::SubstBaseSpecifiers(clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&) + 867 65 clang 0x0000000000af58bd clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 557 66 clang 0x0000000000af6a4b clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1227 67 clang 0x0000000000b2f4c9 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 1177 68 clang 0x0000000000b339b7 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 55 69 clang 0x00000000009ad5bb clang::Sema::CheckBaseSpecifier(clang::CXXRecordDecl*, clang::SourceRange, bool, clang::AccessSpecifier, clang::TypeSourceInfo*, clang::SourceLocation) + 555 70 clang 0x0000000000af5413 clang::Sema::SubstBaseSpecifiers(clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&) + 867 71 clang 0x0000000000af58bd clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 557 72 clang 0x0000000000af6a4b clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1227 73 clang 0x0000000000b2f4c9 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 1177 74 clang 0x0000000000b339b7 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 55 75 clang 0x00000000009161bc clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&, clang::DeclContext*) + 460 76 clang 0x0000000000a84d8d clang::Sema::CheckTypenameType(clang::ElaboratedTypeKeyword, clang::SourceLocation, clang::NestedNameSpecifierLoc, clang::IdentifierInfo const&, clang::SourceLocation) + 173 77 clang 0x0000000000afc49a 78 clang 0x0000000000af2589 79 clang 0x0000000000af7c55 80 clang 0x0000000000af21b2 81 clang 0x0000000000afaf82 82 clang 0x0000000000af33f1 83 clang 0x0000000000af9215 clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) + 293 84 clang 0x0000000000b0c5a0 clang::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*, llvm::SmallVectorImpl&) + 96 85 clang 0x0000000000b12650 clang::TemplateDeclInstantiator::VisitFunctionDecl(clang::FunctionDecl*, clang::TemplateParameterList*) + 384 86 clang 0x0000000000b0eaf0 clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 128 87 clang 0x0000000000ae0e10 clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 2672 88 clang 0x0000000000ae2654 clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo const*, clang::Expr**, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 900 89 clang 0x0000000000a55849 clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::TemplateArgumentListInfo const*, clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool) + 393 90 clang 0x0000000000a6054c clang::Sema::AddArgumentDependentLookupCandidates(clang::DeclarationName, bool, clang::Expr**, unsigned int, clang::TemplateArgumentListInfo const*, clang::OverloadCandidateSet&, bool) + 684 91 clang 0x0000000000a6856b clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int, clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*) + 779 92 clang 0x00000000009e7749 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 217 93 clang 0x00000000009e7924 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 196 94 clang 0x00000000008c2474 clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) + 516 95 clang 0x00000000008c2c50 clang::Parser::ParseAssignmentExpression() + 48 96 clang 0x00000000008c3229 clang::Parser::ParseExpression() + 9 97 clang 0x00000000008c398f clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool, clang::OpaquePtr, clang::OpaquePtr&, clang::SourceLocation&) + 1871 98 clang 0x00000000008c112d clang::Parser::ParseCastExpression(bool, bool, bool&, clang::OpaquePtr) + 5325 99 clang 0x00000000008c223d clang::Parser::ParseCastExpression(bool, bool, clang::OpaquePtr) + 29 100 clang 0x00000000008c2c40 clang::Parser::ParseAssignmentExpression() + 32 101 clang 0x00000000008c3229 clang::Parser::ParseExpression() + 9 102 clang 0x00000000008c398f clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool, clang::OpaquePtr, clang::OpaquePtr&, clang::SourceLocation&) + 1871 103 clang 0x00000000008c112d clang::Parser::ParseCastExpression(bool, bool, bool&, clang::OpaquePtr) + 5325 104 clang 0x00000000008c223d clang::Parser::ParseCastExpression(bool, bool, clang::OpaquePtr) + 29 105 clang 0x00000000008c2c40 clang::Parser::ParseAssignmentExpression() + 32 106 clang 0x00000000008c3229 clang::Parser::ParseExpression() + 9 107 clang 0x00000000008c398f clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool, clang::OpaquePtr, clang::OpaquePtr&, clang::SourceLocation&) + 1871 108 clang 0x00000000008c112d clang::Parser::ParseCastExpression(bool, bool, bool&, clang::OpaquePtr) + 5325 109 clang 0x00000000008c223d clang::Parser::ParseCastExpression(bool, bool, clang::OpaquePtr) + 29 110 clang 0x00000000008c2c40 clang::Parser::ParseAssignmentExpression() + 32 111 clang 0x00000000008a5f61 clang::Parser::ParseDeclarationAfterDeclarator(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&) + 545 112 clang 0x00000000008a8ee2 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 786 113 clang 0x00000000008ad5cf clang::Parser::ParseSimpleDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, bool) + 639 114 clang 0x00000000008ad762 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 98 115 clang 0x0000000000891636 clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 198 116 clang 0x0000000000892790 clang::Parser::ParseCompoundStatementBody(bool) + 1520 117 clang 0x0000000000892ebc clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 140 118 clang 0x00000000008a12c7 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 711 119 clang 0x00000000008d89be clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 2094 120 clang 0x00000000008dba44 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 676 121 clang 0x00000000008ad90a clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 522 122 clang 0x00000000008a1bef clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2031 123 clang 0x00000000008b9633 clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) + 1699 124 clang 0x00000000008ad893 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 403 125 clang 0x00000000008a1bef clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2031 126 clang 0x00000000008a25ed clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 109 127 clang 0x0000000000880b10 clang::ParseAST(clang::Sema&, bool) + 128 128 clang 0x000000000073cde4 clang::CodeGenAction::ExecuteAction() + 68 129 clang 0x000000000062848b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 347 130 clang 0x0000000000603e3a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1130 131 clang 0x00000000005f9dce cc1_main(char const**, char const**, char const*, void*) + 510 132 clang 0x0000000000602e6c main + 5036 133 libc.so.6 0x00002b03ddf19d8e __libc_start_main + 254 134 clang 0x00000000005f99e9 Stack dump: 0. Program arguments: /var/lib/buildbot/instdirs/clang-trunk/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name BoostComponentFinder.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51 -momit-leaf-frame-pointer -g -resource-dir /var/lib/buildbot/instdirs/clang-trunk/bin/../lib/clang/2.9 -dependency-file .deps/BoostComponentFinder.Tpo -sys-header-deps -MP -MT BoostComponentFinder.lo -D HAVE_CONFIG_H -D SYS_PLUGIN_DIR="/var/lib/buildbot/instdirs/dlvhex-trunk-boost-trunk-clang-trunk/lib/dlvhex/plugins" -D USER_PLUGIN_DIR=".dlvhex/plugins" -D PIC -I . -I ../../include -I ../../include -I ../../src -I ../../src -I /var/lib/buildbot/instdirs/boost-trunk/include/boost-1_46 -I ../../libltdl -O2 -W -Wall -ferror-limit 19 -fmessage-length 0 -fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option -o .libs/BoostComponentFinder.o -x c++ BoostComponentFinder.cpp 1. /var/lib/buildbot/instdirs/boost-trunk/include/boost-1_46/boost/graph/graphviz.hpp:65:53: current parser token ')' 2. /var/lib/buildbot/instdirs/boost-trunk/include/boost-1_46/boost/graph/graphviz.hpp:33:1: parsing namespace 'boost' 3. /var/lib/buildbot/instdirs/boost-trunk/include/boost-1_46/boost/graph/graphviz.hpp:63:54: parsing function body 'escape_dot_string' 4. /var/lib/buildbot/instdirs/boost-trunk/include/boost-1_46/boost/graph/graphviz.hpp:63:54: in compound statement ('{}') clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) this is with clang built from trunk [126902] -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 10:46:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 10:46:30 -0600 (CST) Subject: [LLVMbugs] [Bug 9318] New c++ search path needed on Fedora 14 In-Reply-To: References: Message-ID: <20110303164630.995C32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9318 fedorabugmail at yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from fedorabugmail at yahoo.com 2011-03-03 10:46:30 CST --- The latest trunk has fixed this. Clang now compiles successfully on Fedora 14 however it does not link correctly. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 11:05:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 11:05:18 -0600 (CST) Subject: [LLVMbugs] [Bug 9388] selfhost segfaults in NestedNameSpecifier::getPrefix In-Reply-To: References: Message-ID: <20110303170518.4784F2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9388 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2011-03-03 11:05:17 CST --- Fixed in Clang r126946. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 11:15:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 11:15:37 -0600 (CST) Subject: [LLVMbugs] [Bug 9391] New: -Wunused-function complains about unused deleted functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9391 Summary: -Wunused-function complains about unused deleted functions 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 $ echo 'namespace { void f() = delete; }' | clang++ -x c++ -std=c++0x -fsyntax-only -Wunused-function - :1:18: warning: unused function 'f' [-Wunused-function] namespace { void f() = delete; } ^ 1 warning generated. Oops! Deleted functions are /supposed/ to be unused! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 11:50:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 11:50:19 -0600 (CST) Subject: [LLVMbugs] [Bug 9391] -Wunused-function complains about unused deleted functions In-Reply-To: References: Message-ID: <20110303175019.0304C2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9391 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |akyrtzi at gmail.com Resolution| |FIXED --- Comment #2 from Argyrios Kyrtzidis 2011-03-03 11:50:18 CST --- > Oops! Deleted functions are /supposed/ to be unused! Indeed. Fixed at r126950, thanks for the report! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Mar 3 13:56:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 13:56:43 -0600 (CST) Subject: [LLVMbugs] [Bug 9392] New: Feature request: linkonce inline functions in C Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9392 Summary: Feature request: linkonce inline functions in C Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: lennox at cs.columbia.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6268) --> (http://llvm.org/bugs/attachment.cgi?id=6268) Header file for test program that compiles on Microsoft Visual C. Microsoft Visual C++ has the feature that inline (technically, __inline) functions in C are emitted in COMDAT sections, in the same manner as in C++, so they have linkonce semantics. Thus, neither a C99 "extern inline declaration" nor a GNU C "non-inline definition" needs to be provided to handle cases where the function cannot be inlined -- the compiler simply handles it automatically. This significantly simplifies code maintenance. Would it be possible to add this feature as a Clang extension? Looking over the Clang Bugzilla it appears that Clang used to implement inlining this way, but it was fixed to implement the correct C99 semantics instead, so presumably the infrastructure support is there. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 14:02:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 14:02:36 -0600 (CST) Subject: [LLVMbugs] [Bug 9393] New: CodeGen keeps multiple copies of loop induction pointer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9393 Summary: CodeGen keeps multiple copies of loop induction pointer Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: benny.kra at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6271) --> (http://llvm.org/bugs/attachment.cgi?id=6271) bitcode for this piece of C code: int putchar(int); void foo(unsigned u) { char buf[10]; char *s = buf; do *s++ = '0' + u % 10U; while (u /= 10U); while (--s >= buf) putchar(*s); } clang -O2 generates: _foo: ## @foo ## BB#0: ## %entry pushl %ebp movl %esp, %ebp pushl %ebx pushl %edi pushl %esi subl $28, %esp leal -23(%ebp), %ecx movl 8(%ebp), %esi movl %ecx, -32(%ebp) ## 4-byte Spill movl %ecx, %edi movl %ecx, %ebx .align 4, 0x90 LBB0_1: ## %do.body ## =>This Inner Loop Header: Depth=1 movl %esi, %eax movl $-858993459, %edx ## imm = 0xFFFFFFFFCCCCCCCD mull %edx shrl $3, %edx imull $10, %edx, %eax movl %eax, -28(%ebp) ## 4-byte Spill movl %esi, %eax subl -28(%ebp), %eax ## 4-byte Folded Reload orl $48, %eax movb %al, 1(%ecx) incl -32(%ebp) ## 4-byte Folded Spill incl %edi incl %ebx incl %ecx cmpl $9, %esi movl %edx, %esi ja LBB0_1 ## BB#2: ## %while.cond.preheader leal -22(%ebp), %esi cmpl %esi, -32(%ebp) ## 4-byte Folded Reload jb LBB0_4 .align 4, 0x90 LBB0_3: ## %while.body ## =>This Inner Loop Header: Depth=1 movsbl (%edi), %eax movl %eax, (%esp) calll _putchar decl %edi decl %ebx cmpl %esi, %ebx jae LBB0_3 LBB0_4: ## %while.end addl $28, %esp popl %esi popl %edi popl %ebx popl %ebp ret Note the silly looking incl series in the first loop. This is a recent regression, LLVM did produce better code a few months ago. The testcase is reduced from FreeBSD's bootloader, which is very code size sensitive. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 14:13:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 14:13:54 -0600 (CST) Subject: [LLVMbugs] [Bug 9363] DwarfDebug bounds error when building ARMMCCodeEmitter -O -g In-Reply-To: References: Message-ID: <20110303201354.204192A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9363 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Devang Patel 2011-03-03 14:13:53 CST --- I reverted patch from clang, that's why it works now. This should be fixed by r126960. Now, llc won't crash on somewhat invalid debug info. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 14:53:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 14:53:52 -0600 (CST) Subject: [LLVMbugs] [Bug 9394] New: 2 False positives on deref of null ptr Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9394 Summary: 2 False positives on deref of null ptr Product: clang Version: trunk Platform: Other OS/Version: OpenBSD Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: amitkulz at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6273) --> (http://llvm.org/bugs/attachment.cgi?id=6273) false positive OpenBSD 4.9 current on AMD64 with clang trunk r126955 Two cases where the wrong condition being taken by the static analyzer is causing false positives. In both attachments the important lines are Line 1087 ==> EM_KASSERT(map->dm_nsegs!= 0, ("em_encap: empty packet")); Line 1105 ==> for (j = 0; j < map->dm_nsegs; j++) { Analyzer warns that current_tx_desc is null, but it is impossible for current_tx_desc to be null because current_tx_desc is initialized in the loop starting on 1105 like so. for (j = 0; j < map->dm_nsegs; j++) { ... skipping the more complex 82544 handling ... } else { tx_buffer = &sc->tx_buffer_area[i]; current_tx_desc = &sc->tx_desc_base[i]; ... } } Now this block can only be skipped if map->dm_nsegs == 0 but on line 1087 we have: EM_KASSERT(map->dm_nsegs!= 0, ("em_encap: empty packet")); and additionally bus_dmamap_load_mbuf() will always return a dm_nseg > 1 if there is no error. This message is mainly composed of feedback from Claudio Jeker of OpenBSD. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 15:24:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 15:24:59 -0600 (CST) Subject: [LLVMbugs] [Bug 9395] New: open source project ITK, when built with clang, has many failing unit tests Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9395 Summary: open source project ITK, when built with clang, has many failing unit tests Product: new-bugs Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sean at rogue-research.com CC: llvmbugs at cs.uiuc.edu The cross platform open source C++ project ITK is now buildable by clang-- after recent changes to both clang and ITK. Everything now builds and links. But about half of the unit tests crash when run. I suspect a clang bug because ITK has very rigorous testing and this problem occurs nowhere else (gcc, icc, Visual Studio, etc.) It is compiled nightly by many OS/compiler combinations, and results are gathered on a dashboard: http://www.cdash.org/CDash/index.php?project=Insight The backtrace always shows one or more threads in _Unwind_Resume_or_Rethrow, and one of those threads is the one that's crashed. ex: Thread 3 Crashed: 0 libSystem.B.dylib 0x00007fff84fab35a unwind_phase2_forced + 122 1 libSystem.B.dylib 0x00007fff84edec4d _Unwind_Resume + 61 2 libSystem.B.dylib 0x00007fff84ee2aab _Unwind_Resume_or_Rethrow + 27 3 IOCxxTests 0x000000010015ae59 itk::ImageSource >::ThreaderCallback(void*) + 345 (itkImageSource.txx:312) 4 IOCxxTests 0x0000000100f5ed14 itk::MultiThreader::SingleMethodProxy(void*) + 36 5 libSystem.B.dylib 0x00007fff84ea94f6 _pthread_start + 331 6 libSystem.B.dylib 0x00007fff84ea93a9 thread_start + 13 I brought this up on cfe-dev, and John McCall says 'it is probably at least related to PR8098, if not necessarily a dupe.' To repro, you need to build ITK. For which you need git and CMake. Basically: git clone git://itk.org/ITK.git cd ITK git submodule update --init cd .. mkdir ITK-bin cd ITK-bin cmake ../ITK make ctest -R . Then it will start running tests and soon enough one will crash. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 15:49:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 15:49:23 -0600 (CST) Subject: [LLVMbugs] [Bug 9390] failed assertion "Instantiation of injected-class-name cannot fail." In-Reply-To: References: Message-ID: <20110303214923.9D8BE2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9390 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Resolution| |FIXED --- Comment #3 from Douglas Gregor 2011-03-03 15:49:22 CST --- Fixed in Clang r126961. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 16:04:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 16:04:41 -0600 (CST) Subject: [LLVMbugs] [Bug 9168] Wrong source location for CXXMemberCallExpr In-Reply-To: References: Message-ID: <20110303220441.D80812A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9168 Alex changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Alex 2011-03-03 16:04:41 CST --- I am using r126480. The issue does not seem to be fixed. The static type I am using is clang::Stmt. BTW, here is my current workaround: clang::SourceLocation GetStmtBeginLocation(clang::Stmt* stmt) { clang::SourceLocation loc = stmt->getLocStart(); if (clang::CXXMemberCallExpr* expr = dyn_cast(stmt)) { if (clang::MemberExpr* member_expr = dyn_cast(expr->getCallee())) { if (member_expr->hasQualifier()) { loc = member_expr->getQualifierRange().getBegin(); } } } return loc; } P.S. Sorry it took me so long to reply. Was out of office for two weeks. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 16:07:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 16:07:26 -0600 (CST) Subject: [LLVMbugs] [Bug 9396] New: -Woverloaded-virtual shouldn't warn for static functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9396 Summary: -Woverloaded-virtual shouldn't warn for static functions Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu $ cat test.cc class A { public: virtual void f(int) {} }; class B : public A { public: static void f() {} }; $ clang -c test.cc -Woverloaded-virtual test.cc:8:15: warning: 'B::f' hides overloaded virtual function [-Woverloaded-virtual] static void f() {} ^ test.cc:3:16: note: hidden overloaded virtual function 'A::f' declared here virtual void f(int) {} ^ 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 Mar 3 16:32:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 16:32:56 -0600 (CST) Subject: [LLVMbugs] [Bug 9033] [elf] AsmPrinter doesn't quote section name when necessary In-Reply-To: References: Message-ID: <20110303223256.872B82A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9033 J?rg Sonnenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from J?rg Sonnenberger 2011-03-03 16:32:56 CST --- With a small test for the quote handling committed. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 16:45:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 16:45:09 -0600 (CST) Subject: [LLVMbugs] [Bug 9168] Wrong source location for CXXMemberCallExpr In-Reply-To: References: Message-ID: <20110303224509.345F32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9168 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #5 from Douglas Gregor 2011-03-03 16:45:08 CST --- I just fixed MemberExpr's source-range information to cover the qualifier in r126880. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 16:59:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 16:59:51 -0600 (CST) Subject: [LLVMbugs] [Bug 9396] -Woverloaded-virtual shouldn't warn for static functions In-Reply-To: References: Message-ID: <20110303225951.F2EDB2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9396 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Argyrios Kyrtzidis 2011-03-03 16:59:51 CST --- Fixed at r126966, thanks for the report! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Mar 3 17:07:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 17:07:46 -0600 (CST) Subject: [LLVMbugs] [Bug 8053] LLVM JIT code emitter fails to encode the S bit in some instructions In-Reply-To: References: Message-ID: <20110303230746.0D5B92A6C131@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8053 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Bob Wilson 2011-03-03 17:07:45 CST --- Patch applied in svn r126967. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 18:13:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 18:13:15 -0600 (CST) Subject: [LLVMbugs] [Bug 9377] MC assembler doesn't handle x86 'str' with arbitrary operand In-Reply-To: References: Message-ID: <20110304001315.1B1B52A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9377 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-03-03 18:13:14 CST --- r126970. (I don't think sldt needs any fixes, but please file if you run into 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 Thu Mar 3 18:21:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 18:21:41 -0600 (CST) Subject: [LLVMbugs] [Bug 9397] New: wrong source location for inline asm from macro Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9397 Summary: wrong source location for inline asm from macro Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu ffmpeg is a rich vein of wonder. The problem boils down to this testcase: #define asm_code_block\ "add $8*1, -88(%rsp)\n\t" void test() { __asm__ ("mov %eax, %ebx\n\t" asm_code_block ); } on which clang delivers the right error in the wrong place: inlineasm.c:5:29: error: ambiguous instructions require an explicit suffix (could be 'addb', 'addw', 'addl', or 'addq') __asm__ ("mov %eax, %ebx\n\t" ^ :2:2: note: instantiated into assembly here add $8*1, -88(%rsp) ^ 1 error generated. Yes, I really wanted it to point at the text from the macro expansion. A macro backtrace would be okay 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 Mar 3 19:30:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 19:30:16 -0600 (CST) Subject: [LLVMbugs] [Bug 8633] [MC] Clang integrated-as doesn't support .pushsection .popsection ASM directives In-Reply-To: References: Message-ID: <20110304013016.6C7E92A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8633 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Nick Lewycky 2011-03-03 19:30:15 CST --- This was fixed back in r126099 by Joerg Sonnenberger. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 3 20:08:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 3 Mar 2011 20:08:39 -0600 (CST) Subject: [LLVMbugs] [Bug 9398] New: 10% of llc compile time is spent in Value::getNumUses Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9398 Summary: 10% of llc compile time is spent in Value::getNumUses Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: stoklund at 2pi.dk CC: llvmbugs at cs.uiuc.edu When running llc on 403.gcc, 10% of total code generation time is spent in Value::getNumUses(). It is being called from CodeGenPrepare::OptimizeMemoryInst(). I think we need to tweak that algorithm. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 4 00:00:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 4 Mar 2011 00:00:05 -0600 (CST) Subject: [LLVMbugs] [Bug 9399] New: libc++.so: undefined reference to `clock_gettime' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9399 Summary: libc++.so: undefined reference to `clock_gettime' Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, When I tried to compile a piece of c++ code clang++ -std=c++0x -I/usr/include/c++/v1/ ./variadic_print.cpp -lc++ the linker was unable to resolve the symbol clock_gettime. Of course, it's in librt.so, so simply appending -lrt fixes the problem. Does libc++ itself depend on librt? I built libc++ by CMake using clang compiler instead of gcc. Thanks, Ryuta -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Mar 4 03:09:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 4 Mar 2011 03:09:25 -0600 (CST) Subject: [LLVMbugs] [Bug 9400] New: Regression concerning template default argument Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9400 Summary: Regression concerning template default argument Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: abramobagnara at tin.it CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com While the following source compiles ok with r125832, it crashes r126952. $ cat t.cc template