From bugzilla-daemon at llvm.org Sat May 1 00:46:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 00:46:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 5009] inliner missing opportunity with CPS style code In-Reply-To: References: Message-ID: <20100501054629.57BD83128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5009 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE | --- Comment #4 from Chris Lattner 2010-05-01 00:46:28 CDT --- This is now a lot better than it was before, but we're still missing inlining "quit" into main. All the indirection is gone though. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 01:39:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 01:39:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 5009] inliner missing opportunity with CPS style code In-Reply-To: References: Message-ID: <20100501063957.3E45D3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5009 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2010-05-01 01:39:56 CDT --- Fixed in r102830, we now compile this to: define i32 @main() nounwind ssp { entry: tail call void @exit(i32 38) noreturn nounwind unreachable } at -O2, -Os, and -O3. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 04:37:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 04:37:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 7002] New: Cmake build of clang broken on FreeBSD Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7002 Summary: Cmake build of clang broken on FreeBSD Product: Build scripts Version: trunk Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: cmake AssignedTo: unassignedbugs at nondot.org ReportedBy: 6yearold at gmail.com CC: llvmbugs at cs.uiuc.edu Both Debug and Release configurations gives this error on make: http://pastebin.com/zjVuR8EJ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 07:29:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 07:29:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 6603] msp430 backend: wrong addressing mode for 'br' instruction In-Reply-To: References: Message-ID: <20100501122901.A09153128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6603 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Anton Korobeynikov 2010-05-01 07:29:01 CDT --- I cannot reproduce the problem with the attached testcases anymore, but I believe r102834 fixed it. Please verify. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 07:52:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 07:52:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 7001] DAG Combiner assertion: "Invalid truncate node" on a simple loop In-Reply-To: References: Message-ID: <20100501125253.569CA3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7001 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Anton Korobeynikov 2010-05-01 07:52:52 CDT --- Fixed in r102838 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 08:50:39 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 08:50:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 6861] invalid x86-64 instructions generated In-Reply-To: References: Message-ID: <20100501135039.877ED3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6861 Jakub Staszak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Jakub Staszak 2010-05-01 08:50:39 CDT --- Bug was fixed in r102672. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 08:57:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 08:57:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 7003] New: Class DeltaTreeNode needs virtual destructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7003 Summary: Class DeltaTreeNode needs virtual destructor Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: begert at gmail.com CC: llvmbugs at cs.uiuc.edu running cppcheck yields: [./Rewrite/DeltaTree.cpp:55]: (error) Class DeltaTreeNode which is inherited by class DeltaTreeInteriorNode does not have a virtual destructor -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 10:00:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 10:00:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 7004] New: Failed to build project with Boost.PropertyTree Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7004 Summary: Failed to build project with Boost.PropertyTree Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: osmano807 at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Hello Today I decided to test clang++ with a project of mine, as it uses Boost.PropertyTree parser for your configuration file. Except that when I compile, gave this error: In file included from /usr/include/boost/property_tree/ptree.hpp:515: /usr/include/boost/property_tree/detail/ptree_implementation.hpp:749:51: error: 'Type' does not refer to a value return child.get().get_value_optional(tr); ^ /usr/include/boost/property_tree/detail/ptree_implementation.hpp:744:20: note: declared at template ^ 2 diagnostics generated. With g++ compiles normal. I'm using Arch Linux, clang with version 2.7-2 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 10:01:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 10:01:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 6794] Assertion failed: ((Result || D->isInvalidDecl()) && "declaration was not instantiated in this scope!") In-Reply-To: References: Message-ID: <20100501150132.8B86D3128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6794 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #14 from Douglas Gregor 2010-05-01 10:01:31 CDT --- Great! Closing again. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 10:02:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 10:02:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 7004] Failed to build project with Boost.PropertyTree In-Reply-To: References: Message-ID: <20100501150252.849EE3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7004 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Douglas Gregor 2010-05-01 10:02:52 CDT --- Clang is correct, and GCC is wrong to compile this code. There is a missing "template" keyword in that line, which should look like this: return child.get().template get_value_optional(tr); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 10:05:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 10:05:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 6979] error: no type named ... In-Reply-To: References: Message-ID: <20100501150516.F15C13128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6979 Albert Zeyer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Albert Zeyer 2010-05-01 10:05:16 CDT --- Doesn't happen anymore with r102825. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 10:53:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 10:53:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7006] New: Missed struct allocation escape analysis Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7006 Summary: Missed struct allocation escape analysis Product: new-bugs Version: 2.7 Platform: Other OS/Version: other Status: NEW Keywords: code-quality Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: bearophile at mailas.com CC: llvmbugs at cs.uiuc.edu This little C program shows something I have found in a larger program: #include "stdio.h" #include "stdlib.h" #define WITH_Y typedef struct { int x; #ifdef WITH_Y int y; #endif double z; } Foo; Foo *new_Foo(int n) { Foo *f = (Foo *)malloc(sizeof(Foo)); f->x = n * 1; #ifdef WITH_Y f->y = n * 2; #endif f->z = n * 3; return f; } int main() { int n = atoi("20"); Foo *f = new_Foo(n); printf("%f\n", f->z); free(f); return 0; } With the online llvm 2.7 demo, Optimization level: LTO If WITH_Y is defined there is a malloc: define i32 @main() nounwind { entry: %0 = tail call i32 @atoi(i8* getelementptr inbounds ([3 x i8]* @.str, i64 0, i64 0)) nounwind readonly ; [#uses=2] %1 = tail call noalias i8* @malloc(i64 16) nounwind ; [#uses=2] %2 = bitcast i8* %1 to i32* ; [#uses=1] store i32 %0, i32* %2, align 8 %3 = mul nsw i32 %0, 3 ; [#uses=1] %4 = sitofp i32 %3 to double ; [#uses=1] %5 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr inbounds ([4 x i8]* @.str1, i64 0, i64 0), double %4) nounwind ; [#uses=0] tail call void @free(i8* %1) nounwind ret i32 0 } If WITH_Y is not defined there isn't a malloc: define i32 @main() nounwind { entry: %0 = tail call i32 @atoi(i8* getelementptr inbounds ([3 x i8]* @.str, i64 0, i64 0)) nounwind readonly ; [#uses=1] %1 = mul nsw i32 %0, 3 ; [#uses=1] %2 = sitofp i32 %1 to double ; [#uses=1] %3 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr inbounds ([4 x i8]* @.str1, i64 0, i64 0), double %2) nounwind ; [#uses=0] ret i32 0 } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 11:01:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 11:01:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 7007] New: fix suggestion for -Wreorder Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7007 Summary: fix suggestion for -Wreorder Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ich at az2000.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In the case that clang gives some -Wreorder warning like this: In file included from /Users/az/Programmierung/openlierox/src/gusanos/gui/detail/gss.cpp:12: GUI/detail/gss-grammar.h.re:249:23: warning: field 'begin' will be initialized after field 'marker' [-Wreorder] TGrammar() : cur(-1), begin(0), marker(0), buffer(0), curp(0), limit(0), line(1), syncTokens(false), ... ^ It would be nice if it also automatically outputs the code which would fix this. In case you have several such warnings for a single constructor (because the order is completely wrong), it's annoying to fix it by hand. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 11:34:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 11:34:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 7009] New: error: empty parameter list defined with a typedef of 'void' not allowed in C++ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7009 Summary: error: empty parameter list defined with a typedef of 'void' not allowed in C++ Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ich at az2000.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In file included from /Users/az/Programmierung/openlierox/./build/Xcode/freealut/include/AL/alut.h:8: /System/Library/Frameworks/OpenAL.framework/Headers/alc.h:182:68: error: empty parameter list defined with a typedef of 'void' not allowed in C++ ALC_API ALCcontext * ALC_APIENTRY alcGetCurrentContext( ALCvoid ); Testcase: typedef void V; void foo(V); The error says that this violates C++. GCC compiles it though. Should the OpenAL headers be fixed? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 12:33:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 12:33:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 7003] Class DeltaTreeNode needs virtual destructor In-Reply-To: References: Message-ID: <20100501173303.79FDF3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7003 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2010-05-01 12:33:03 CDT --- This is a false positive. We don't want delta tree to have a vtable, the destruction path is handled by DeltaTreeNode::Destroy() -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 12:50:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 12:50:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7009] error: empty parameter list defined with a typedef of 'void' not allowed in C++ In-Reply-To: References: Message-ID: <20100501175012.6DDD13128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7009 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |INVALID --- Comment #1 from John McCall 2010-05-01 12:50:12 CDT --- Clang is correct, this is forbidden in C++; only "(void)" is allowed. Also, both clang and gcc accept this in C mode, and both clang and gcc reject this in C++ mode, so I really see no incentive to change it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 12:59:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 12:59:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 4919] llvm-gcc doesn't optimize simple factorial into a loop In-Reply-To: References: Message-ID: <20100501175919.3516B3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4919 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2010-05-01 12:59:18 CDT --- This got fixed a long time ago. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 1 13:03:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 May 2010 13:03:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7002] Cmake build of clang broken on FreeBSD In-Reply-To: References: Message-ID: <20100501180306.4C0BD3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7002 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2010-05-01 13:03:05 CDT --- pastebins are not stable. Here is the issue: [ 81%] Building CXX object tools/clang/lib/Lex/CMakeFiles/clangLex.dir/Lexer.cpp.o In file included from /usr/include/xmmintrin.h:42, from /usr/include/emmintrin.h:34, from /home/arr/projects/llvm/llvm/tools/clang/lib/Lex/Lexer.cpp:1116: /usr/include/mm_malloc.h:37: error: declaration of 'int posix_memalign(void**, size_t, size_t) throw ()' throws different exceptions /usr/include/stdlib.h:160: error: from previous declaration 'int posix_memalign(void**, size_t, size_t)' gmake[2]: *** [tools/clang/lib/Lex/CMakeFiles/clangLex.dir/Lexer.cpp.o] Error 1 gmake[1]: *** [tools/clang/lib/Lex/CMakeFiles/clangLex.dir/all] Error 2 gmake: *** [all] Error 2 It looks to me that your system headers are incompatible. mm_malloc.h and stdlib.h need to agree, this seems to be a likely bug in your system headers. This probably doesn't work: $ cat > t.cc #include #include ^D $ gcc t.cc -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 02:06:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 02:06:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 7010] New: template instantiation of function can't find this function in the namespace Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7010 Summary: template instantiation of function can't find this function in the namespace Product: clang Version: 2.7 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: yuri at tsoft.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com --- testcase --- template class Container { }; namespace Z { template class Container> int x(const Container &s); }; template class Container> int Z::x(const Container &s) { return 0; } --- output --- pr.C:8:53: error: out-of-line definition of 'x' does not match any declaration in namespace 'Z' template class Container> int Z::x(const Container &s) { ~~~^ 1 diagnostic generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 02:12:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 02:12:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 7011] New: variable length arrays error on constant length array Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7011 Summary: variable length arrays error on constant length array Product: clang Version: 2.7 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: yuri at tsoft.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com --- testcase --- void f(int sz) { const int sz_c = sz; int i[sz_c]; } --- output --- pr.C:2:8: error: variable length arrays are not permitted in C++ int i[sz]; ^ 1 diagnostic generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 02:19:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 02:19:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 7012] New: EBO issue when explicitly calling the empty base's implicit constructor. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7012 Summary: EBO issue when explicitly calling the empty base's implicit constructor. Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dnljms at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In the attached code, calling empty's constructor seems to zero the last byte in the previous base class. It only seems to happen when 'empty' has an implicit constructor that is explicitly called. I found this testing quickbook from boost, it happens when running any of the template tests at 'tools/quickbook/test'. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 04:05:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 04:05:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 7013] New: Error-on-valid and assert on templated friend function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7013 Summary: Error-on-valid and assert on templated friend function 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 Created an attachment (id=4795) --> (http://llvm.org/bugs/attachment.cgi?id=4795) Code which causes error I attach two closely related testcases, reduced from the same boost file. I suspect they are both showing the same underlying error. templates_with_int causes an error-on-valid. templates_without_int causes an assert-on-valid. The error produced by templates_with_int suggests to me that somehow the template arguments are getting rearranged. The backtrace produced by templates_without_int is: clang: Type.cpp:611: bool clang::Type::isConstantSizeType() const: Assertion `!isDependentType() && "This doesn't make sense for dependent types"' failed. 0 clang 0x000000000149a582 1 clang 0x000000000149a469 2 libpthread.so.0 0x00007f1d86df08f0 3 libc.so.6 0x00007f1d860e0a75 gsignal + 53 4 libc.so.6 0x00007f1d860e45c0 abort + 384 5 libc.so.6 0x00007f1d860d9941 __assert_fail + 241 6 clang 0x0000000000a29beb 7 clang 0x00000000005ba8ce 8 clang 0x00000000005b968b 9 clang 0x00000000005b9586 10 clang 0x0000000000642cb5 11 clang 0x00000000006412c6 12 clang 0x0000000000640e74 13 clang 0x00000000006414e6 14 clang 0x00000000006412a3 15 clang 0x0000000000640e74 16 clang 0x000000000066c99f 17 clang 0x000000000066d011 18 clang 0x000000000056e005 19 clang 0x000000000056bfa8 20 clang 0x000000000056b26c 21 clang 0x0000000000569884 22 clang 0x0000000000568601 23 clang 0x000000000041aad1 24 clang 0x000000000068ffbe 25 clang 0x0000000000437014 26 clang 0x0000000000436c7f 27 clang 0x00000000004212ff 28 clang 0x0000000000409172 29 clang 0x000000000040dce2 main + 259 30 libc.so.6 0x00007f1d860cbc4d __libc_start_main + 253 31 clang 0x0000000000407b49 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 140 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-E5zX5R.s -x c++ t.cc 1. parser at end of file 2. Per-file LLVM IR generation 3. t.cc:16:72: Generating code for declaration 'boost::op' 4. t.cc:19:3: LLVM IR generation of compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 07:02:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 07:02:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 7014] New: "Using namespace" problem Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7014 Summary: "Using namespace" problem 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, reduced from a boost test case, is accepted by g++ and Comeau, but rejected by clang. I can't find wording which would allow of forbid it in the standard. namespace X { namespace Y {} } using namespace X; namespace Y = X::Y; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 08:16:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 08:16:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 7015] New: Assertion: Uses remain when a value is destroyed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7015 Summary: Assertion: Uses remain when a value is destroyed 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 Created an attachment (id=4797) --> (http://llvm.org/bugs/attachment.cgi?id=4797) Asserting test case The attached file, reduced from boost, causes an assertion. This file is, I believe, fairly minimal. There are other bugs with this error reported, but this test case is smaller. It may fix the other problems at the same time. t.cc:27:1: warning: control may reach end of non-void function [-Wreturn-type] } ^ While deleting: label %init.check Use still stuck around after Def is destroyed: br i1 %tobool, label %init.check, label %init.end clang: Value.cpp:75: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed. 0 clang 0x000000000149c282 1 clang 0x000000000149c169 2 libpthread.so.0 0x00007fd05bc3e8f0 3 libc.so.6 0x00007fd05af2ea75 gsignal + 53 4 libc.so.6 0x00007fd05af325c0 abort + 384 5 libc.so.6 0x00007fd05af27941 __assert_fail + 241 6 clang 0x000000000142954e 7 clang 0x0000000001367c5d 8 clang 0x00000000011db740 9 clang 0x00000000011dae2b 10 clang 0x0000000001367d92 11 clang 0x00000000010f7222 12 clang 0x000000000140479f 13 clang 0x0000000001404469 14 clang 0x0000000001404119 15 clang 0x000000000041bdb0 16 clang 0x000000000041ab09 17 clang 0x000000000068f722 18 clang 0x0000000000437014 19 clang 0x0000000000436c7f 20 clang 0x00000000004212ff 21 clang 0x0000000000409172 22 clang 0x000000000040dce2 main + 259 23 libc.so.6 0x00007fd05af19c4d __libc_start_main + 253 24 clang 0x0000000000407b49 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 120 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-V3NHHe.s -x c++ t.cc 1. parser at end of file 2. Code generation 3. Running pass 'Remove unreachable blocks from the CFG' on function '@_ZN5arrayI12basic_stringE2atEv' clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 08:18:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 08:18:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 7015] Assertion: Uses remain when a value is destroyed In-Reply-To: References: Message-ID: <20100502131852.33F603128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7015 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Christopher Jefferson 2010-05-02 08:18:51 CDT --- Many apologies. This is a dup of one of my own bugs! *** This bug has been marked as a duplicate of bug 6980 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 09:20:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 09:20:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7011] 'variable length arrays are not permitted' error on run-time computed length array In-Reply-To: References: Message-ID: <20100502142000.369143128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7011 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #4 from Chris Lattner 2010-05-02 09:19:59 CDT --- *** This bug has been marked as a duplicate of bug 5678 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 16:34:18 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 16:34:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 7016] New: Assertion: 'declaration was not instantiated in this scope' in boost code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7016 Summary: Assertion: 'declaration was not instantiated in this scope' in boost code 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 Created an attachment (id=4800) --> (http://llvm.org/bugs/attachment.cgi?id=4800) Testcase The attached test case (apologises for the size, if it very hard to debug, report back, and I shall try my best to reduce it further) comes from a boost::proto testcase and compiles fine in g++. It produces the following backtrace. ~/Dropbox$ clang++ declaration_not_instantiated.cc -c -w Assertion failed: (D->isInvalidDecl() && "declaration was not instantiated in this scope!"), function getInstantiationOf, file SemaTemplateInstantiate.cpp, line 1603. 0 clang 0x00f54489 PrintStackTrace(void*) + 45 1 clang 0x00f549d3 SignalHandler(int) + 374 2 libSystem.B.dylib 0x91cc842b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1848867839 4 libSystem.B.dylib 0x91d558e5 raise + 26 5 libSystem.B.dylib 0x91d6b99c abort + 93 6 libSystem.B.dylib 0x91d58544 __pthread_markcancel + 0 7 clang 0x0039f82f clang::Sema::LocalInstantiationScope::getInstantiationOf(clang::Decl const*) + 249 8 clang 0x003cfd4b clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&) + 147 9 clang 0x003a66ea (anonymous namespace)::TemplateInstantiator::TransformDecl(clang::SourceLocation, clang::Decl*) + 390 10 clang 0x003bea7a clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDeclRefExpr(clang::DeclRefExpr*) + 342 11 clang 0x003bef02 (anonymous namespace)::TemplateInstantiator::TransformDeclRefExpr(clang::DeclRefExpr*) + 188 12 clang 0x003a8cb2 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 706 13 clang 0x003ae839 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) + 297 14 clang 0x003a90fe clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 1806 15 clang 0x003bf039 clang::Sema::SubstExpr(clang::Expr*, clang::MultiLevelTemplateArgumentList const&) + 165 16 clang 0x003d4212 InstantiateInitializer(clang::Sema&, clang::Expr*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation&, llvm::SmallVector&, clang::ASTOwningVector<&(clang::ActionBase::DeleteExpr(void*)), 8u>&, clang::SourceLocation&) + 579 17 clang 0x003d4b54 (anonymous namespace)::TemplateDeclInstantiator::VisitVarDecl(clang::VarDecl*) + 1124 18 clang 0x003d590c clang::DeclVisitor<(anonymous namespace)::TemplateDeclInstantiator, clang::Decl*>::Visit(clang::Decl*) + 870 19 clang 0x003d6f37 clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 71 20 clang 0x003a5f56 (anonymous namespace)::TemplateInstantiator::TransformDefinition(clang::SourceLocation, clang::Decl*) + 58 21 clang 0x003a6000 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDeclStmt(clang::DeclStmt*) + 100 22 clang 0x003a7ea2 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2108 23 clang 0x003a8533 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*, bool) + 115 24 clang 0x003bf0a3 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*) + 53 25 clang 0x003a792a clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 708 26 clang 0x003c2ad9 clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) + 165 27 clang 0x003d7b49 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 1213 28 clang 0x003d74ba clang::Sema::PerformPendingImplicitInstantiations(bool) + 328 29 clang 0x003d7cc4 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 1592 30 clang 0x003d74ba clang::Sema::PerformPendingImplicitInstantiations(bool) + 328 31 clang 0x003d7cc4 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 1592 32 clang 0x003d74ba clang::Sema::PerformPendingImplicitInstantiations(bool) + 328 33 clang 0x003d7cc4 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 1592 34 clang 0x003d74ba clang::Sema::PerformPendingImplicitInstantiations(bool) + 328 35 clang 0x00240b89 clang::Sema::ActOnEndOfTranslationUnit() + 37 36 clang 0x0061322b clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 77 37 clang 0x0023ff35 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 426 38 clang 0x00063d6f clang::ASTFrontendAction::ExecuteAction() + 269 39 clang 0x00063e8c clang::FrontendAction::Execute() + 278 40 clang 0x00047ea3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 41 clang 0x0002ab7f cc1_main(char const**, char const**, char const*, void*) + 1979 42 clang 0x0002eaa5 main + 272 43 clang 0x000298bd start + 53 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name declaration_not_instantiated.cc -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -w -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 129 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-QWMM6y.s -x c++ declaration_not_instantiated.cc 1. parser at end of file 2. declaration_not_instantiated.cc:218:14: instantiating function definition 'boost::xpressive::detail::xpression_adaptor, boost::xpressive::detail::static_xpression, int> >, boost::xpressive::detail::matchable_ex >::match' 3. declaration_not_instantiated.cc:315:34: instantiating function definition 'boost::xpressive::detail::static_xpression, boost::xpressive::detail::static_xpression, int> >::match' 4. declaration_not_instantiated.cc:231:30: instantiating function definition 'boost::xpressive::detail::regex_byref_matcher::match' 5. declaration_not_instantiated.cc:208:39: instantiating function definition 'boost::xpressive::detail::push_context_match' clang: error: compiler command failed due to signal 6 (use -v to see invocation) ~/Dropbox$ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 18:18:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 18:18:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 7017] New: Assertion failed : point of instantiation must be valid! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7017 Summary: Assertion failed : point of instantiation must be valid! 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 Created an attachment (id=4801) --> (http://llvm.org/bugs/attachment.cgi?id=4801) Testcase The following test case, reduced from a boost instance, compiles in g++ and asserts clang. Backtrace: ~/Dropbox$ clang++ -c point_of.cc Assertion failed: (Loc.isValid() && "point of instantiation must be valid!"), function setPointOfInstantiation, file /Users/caj/clang/llvm/tools/clang/lib/Sema/../../include/clang/AST/DeclTemplate.h, line 909. 0 clang 0x00f54489 PrintStackTrace(void*) + 45 1 clang 0x00f549d3 SignalHandler(int) + 374 2 libSystem.B.dylib 0x91cc842b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1848867839 4 libSystem.B.dylib 0x91d558e5 raise + 26 5 libSystem.B.dylib 0x91d6b99c abort + 93 6 libSystem.B.dylib 0x91d58544 __pthread_markcancel + 0 7 clang 0x003cc6fb clang::ClassTemplateSpecializationDecl::setPointOfInstantiation(clang::SourceLocation) + 91 8 clang 0x003bd245 clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 585 9 clang 0x003c44d7 clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1609 10 clang 0x003da635 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 259 11 clang 0x003daabc clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 114 12 clang 0x00345b48 clang::Sema::CompareReferenceRelationship(clang::SourceLocation, clang::QualType, clang::QualType, bool&) + 442 13 clang 0x0034eabe clang::TryReferenceInit(clang::Sema&, clang::Expr*&, clang::QualType, clang::SourceLocation, bool, bool) + 556 14 clang 0x0034f581 clang::TryCopyInitialization(clang::Sema&, clang::Expr*, clang::QualType, bool, bool) + 106 15 clang 0x0034d02f clang::Sema::AddOverloadCandidate(clang::FunctionDecl*, clang::DeclAccessPair, clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool, bool) + 1171 16 clang 0x0031fbe5 TryConstructorInitialization(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, clang::Expr**, unsigned int, clang::QualType, clang::InitializationSequence&) + 792 17 clang 0x003238d1 clang::InitializationSequence::InitializationSequence(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, clang::Expr**, unsigned int) + 1009 18 clang 0x002bdcfb BuildImplicitBaseInitializer(clang::Sema&, clang::CXXConstructorDecl*, ImplicitInitializerKind, clang::CXXBaseSpecifier*, bool, clang::CXXBaseOrMemberInitializer*&) + 844 19 clang 0x002be3d0 clang::Sema::SetBaseOrMemberInitializers(clang::CXXConstructorDecl*, clang::CXXBaseOrMemberInitializer**, unsigned int, bool) + 1022 20 clang 0x002be82e clang::Sema::DefineImplicitCopyConstructor(clang::SourceLocation, clang::CXXConstructorDecl*, unsigned int) + 262 21 clang 0x002da851 clang::Sema::MarkDeclarationReferenced(clang::SourceLocation, clang::Decl*) + 635 22 clang 0x002bea62 clang::Sema::DefineImplicitCopyConstructor(clang::SourceLocation, clang::CXXConstructorDecl*, unsigned int) + 826 23 clang 0x002da851 clang::Sema::MarkDeclarationReferenced(clang::SourceLocation, clang::Decl*) + 635 24 clang 0x0034a3c5 clang::Sema::BestViableFunction(clang::OverloadCandidateSet&, clang::SourceLocation, clang::OverloadCandidate*&) + 487 25 clang 0x0031ef6c CopyObject(clang::Sema&, clang::QualType, clang::InitializedEntity const&, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>, bool) + 1055 26 clang 0x003255f7 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, clang::ASTMultiPtr<&(clang::ActionBase::DeleteExpr(void*))>, clang::QualType*) + 3937 27 clang 0x00326fe5 clang::Sema::PerformCopyInitialization(clang::InitializedEntity const&, clang::SourceLocation, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>) + 425 28 clang 0x00358ea4 clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int, clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*) + 2170 29 clang 0x002f3a99 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperator::Opcode, clang::Expr*, clang::Expr*) + 295 30 clang 0x002f3c41 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>) + 263 31 clang 0x005eade5 clang::Parser::ParseRHSOfBinaryExpression(clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>, clang::prec::Level) + 2501 32 clang 0x005e339e clang::Parser::ParseAssignmentExpression() + 444 33 clang 0x005e37db clang::Parser::ParseExpression() + 25 34 clang 0x00603fc3 clang::Parser::ParseStatementOrDeclaration(bool) + 1679 35 clang 0x006086cb clang::Parser::ParseCompoundStatementBody(bool) + 215 36 clang 0x00608d2f clang::Parser::ParseFunctionStatementBody(clang::OpaquePtr<0>) + 199 37 clang 0x00612362 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1196 38 clang 0x005d5f15 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 483 39 clang 0x006113df clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 1001 40 clang 0x0061142c clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 66 41 clang 0x006131a4 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2222 42 clang 0x006132ea clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 268 43 clang 0x0023ff35 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 426 44 clang 0x00063d6f clang::ASTFrontendAction::ExecuteAction() + 269 45 clang 0x00063e8c clang::FrontendAction::Execute() + 278 46 clang 0x00047ea3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 47 clang 0x0002ab7f cc1_main(char const**, char const**, char const*, void*) + 1979 48 clang 0x0002eaa5 main + 272 49 clang 0x000298bd start + 53 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name point_of.cc -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 129 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-nM1uAs.s -x c++ point_of.cc 1. point_of.cc:32:23: current parser token ';' 2. point_of.cc:29:1: parsing function body 'test_main' 3. point_of.cc:29:1: in compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) ~/Dropbox$ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 2 21:39:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 May 2010 21:39:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 7018] New: UNREACHABLE executed at SelectionDAG.cpp:653! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7018 Summary: UNREACHABLE executed at SelectionDAG.cpp:653! Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu Seen on x64. I cannot repro with opt (which doesn't have -Os?). regehr at gamow tmp410]$ clang -v clang version 2.0 (trunk 102880) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp410]$ clang -Os small.c 0x2cc1db0: i16,ch = <> 0x0, 0x0, 0x0 [ID=10] Node is not in map! UNREACHABLE executed at SelectionDAG.cpp:653! 0 clang 0x00000000012675ef 1 clang 0x00000000012694f2 2 libpthread.so.0 0x00007fdecbf83190 3 libc.so.6 0x00007fdecb2894b5 gsignal + 53 4 libc.so.6 0x00007fdecb28cf50 abort + 384 5 clang 0x000000000123cc24 6 clang 0x0000000000d36251 7 clang 0x0000000000d37639 8 clang 0x0000000000d030e8 9 clang 0x0000000000d03fbb 10 clang 0x0000000000d1bf56 11 clang 0x0000000000d1d4fb 12 clang 0x0000000000d1e00f 13 clang 0x0000000000d9754d 14 clang 0x0000000000d99570 15 clang 0x0000000000d99ca4 16 clang 0x0000000000d9a54e 17 clang 0x00000000011eabbd 18 clang 0x00000000011ead9b 19 clang 0x00000000011eb05f 20 clang 0x00000000004154f7 21 clang 0x0000000000415d75 22 clang 0x000000000060e15f 23 clang 0x0000000000419841 24 clang 0x0000000000409c2b 25 clang 0x000000000040cf33 main + 2499 26 libc.so.6 0x00007fdecb274abd __libc_start_main + 253 27 clang 0x0000000000407479 Stack dump: 0. Program arguments: /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r102880-install/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r102880-install/lib/clang/2.0 -Os -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 79 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-VazXB9.s -x c small.c 1. parser at end of file 2. Code generation 3. Running pass 'X86 DAG->DAG Instruction Selection' on function '@uint161' clang: error: compiler command failed due to signal 6 (use -v to see invocation) [regehr at gamow tmp410]$ cat small.c typedef short int int16_t; typedef unsigned char uint8_t; typedef unsigned short int uint16_t; static uint8_t safe_mul_func_int16_t_s_s (int16_t si1, int16_t si2) { return si1 && si2 && si1 > +si2 || si1 && si2 && si2 < +si1 || si1 && si2 && si1 < +si2 || si1 && si2 && si1 && si2 < +si1 ? : si1 * si2; } static uint8_t safe_mul_func_uint8_t_u_u (uint8_t ui1, uint8_t ui2) { return ui1 * ui2; } int safe (int); int uint161 (void) { uint8_t l_305[3]; int i, j, k; uint16_t l_308[8]; for (i = 0; i < 8; i++) l_308[i] = 0; if (safe (safe_mul_func_int16_t_s_s (l_305[1] <= 0, safe_mul_func_uint8_t_u_u (l_308[4], l_308[4]))), 0) { } return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 01:10:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 01:10:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 7012] EBO issue when explicitly calling the empty base's implicit constructor. In-Reply-To: References: Message-ID: <20100503061015.9018F3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7012 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Anders Carlsson 2010-05-03 01:10:15 CDT --- Yup! Fixed in r102891. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 03:32:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 03:32:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 7019] New: Definition and Declaration if LLVMUnionType do not match Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7019 Summary: Definition and Declaration if LLVMUnionType do not match Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: jos.decoster at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, The definition of the LLVMUnionType function in Core.cpp: LLVMTypeRef LLVMUnionType(LLVMTypeRef *ElementTypes, unsigned ElementCount, int Packed) is different from the declaration in Core.h: LLVMTypeRef LLVMUnionType(LLVMTypeRef *ElementTypes, unsigned ElementCount); Kind regards, Jos. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 04:20:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 04:20:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 7021] New: Not copying anonymous unions by default Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7021 Summary: Not copying anonymous unions by default Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dnljms at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4803) --> (http://llvm.org/bugs/attachment.cgi?id=4803) Test copying anonymous unions. In the attached test the anonymous union doesn't get copied correctly. In boost, this causes 'libs/spirit/classic/test/ast_calc_tests.cpp' to fail (which isn't included in the regression tests, as it's from the old version of spirit). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 05:24:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 05:24:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7022] New: Assert `isa(Val) && "cast() argument of incompatible type!"' on valid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7022 Summary: Assert `isa(Val) && "cast() argument of incompatible type!"' on valid code 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 Created an attachment (id=4805) --> (http://llvm.org/bugs/attachment.cgi?id=4805) Asserting test case derived from boost The following testcase, derived from boost, is I believe valid code and causes an assertion on clang++. This bug may be related to #6310 as it is the same assertion. Assertion failed: (isa(Val) && "cast() argument of incompatible type!"), function cast, file /Users/caj/clang/llvm/include/llvm/Support/Casting.h, line 202. 0 clang 0x00f54489 PrintStackTrace(void*) + 45 1 clang 0x00f549d3 SignalHandler(int) + 374 2 libSystem.B.dylib 0x91cc842b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1848867839 4 libSystem.B.dylib 0x91d558e5 raise + 26 5 libSystem.B.dylib 0x91d6b99c abort + 93 6 libSystem.B.dylib 0x91d58544 __pthread_markcancel + 0 7 clang 0x003d87a5 llvm::cast_retty::ret_type llvm::cast(clang::TypeLoc* const&) + 91 8 clang 0x003d19aa (anonymous namespace)::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*, llvm::SmallVectorImpl&) + 572 9 clang 0x003d1c9f (anonymous namespace)::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*, clang::TemplateParameterList*) + 471 10 clang 0x003d5864 clang::DeclVisitor<(anonymous namespace)::TemplateDeclInstantiator, clang::Decl*>::Visit(clang::Decl*) + 702 11 clang 0x003d6f37 clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 71 12 clang 0x003bd3bb clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 959 13 clang 0x003c44d7 clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1609 14 clang 0x003da635 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 259 15 clang 0x003daabc clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 114 16 clang 0x003131ae clang::Sema::ActOnCXXTypeConstructExpr(clang::SourceRange, void*, clang::SourceLocation, clang::ASTMultiPtr<&(clang::ActionBase::DeleteExpr(void*))>, clang::SourceLocation*, clang::SourceLocation) + 754 17 clang 0x0039c60f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::RebuildCXXUnresolvedConstructExpr(clang::SourceLocation, clang::QualType, clang::SourceLocation, clang::ASTMultiPtr<&(clang::ActionBase::DeleteExpr(void*))>, clang::SourceLocation*, clang::SourceLocation) + 201 18 clang 0x003b5d25 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCXXUnresolvedConstructExpr(clang::CXXUnresolvedConstructExpr*) + 1053 19 clang 0x003aa2e8 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 6392 20 clang 0x003bf039 clang::Sema::SubstExpr(clang::Expr*, clang::MultiLevelTemplateArgumentList const&) + 165 21 clang 0x002e8a0c clang::Sema::BuildCXXDefaultArgExpr(clang::SourceLocation, clang::FunctionDecl*, clang::ParmVarDecl*) + 466 22 clang 0x002f5879 clang::Sema::GatherArgumentsForCall(clang::SourceLocation, clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int, clang::Expr**, unsigned int, llvm::SmallVector&, clang::Sema::VariadicCallType) + 759 23 clang 0x002b0f13 clang::Sema::CompleteConstructorCall(clang::CXXConstructorDecl*, clang::ASTMultiPtr<&(clang::ActionBase::DeleteExpr(void*))>, clang::SourceLocation, clang::ASTOwningVector<&(clang::ActionBase::DeleteExpr(void*)), 8u>&) + 313 24 clang 0x00326485 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, clang::ASTMultiPtr<&(clang::ActionBase::DeleteExpr(void*))>, clang::QualType*) + 7663 25 clang 0x002823ce clang::Sema::ActOnUninitializedDecl(clang::OpaquePtr<0>, bool) + 1906 26 clang 0x005d5d1b clang::Parser::ParseDeclarationAfterDeclarator(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&) + 2513 27 clang 0x005d5fe5 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 691 28 clang 0x005d63f6 clang::Parser::ParseSimpleDeclaration(unsigned int, clang::SourceLocation&, clang::AttributeList*, bool) + 340 29 clang 0x005d66b7 clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::CXX0XAttributeList) + 669 30 clang 0x00603e95 clang::Parser::ParseStatementOrDeclaration(bool) + 1377 31 clang 0x006086cb clang::Parser::ParseCompoundStatementBody(bool) + 215 32 clang 0x00608d2f clang::Parser::ParseFunctionStatementBody(clang::OpaquePtr<0>) + 199 33 clang 0x00612362 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1196 34 clang 0x005d5f15 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 483 35 clang 0x006113df clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 1001 36 clang 0x0061142c clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 66 37 clang 0x006131a4 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2222 38 clang 0x006132ea clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 268 39 clang 0x0023ff35 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 426 40 clang 0x00063d6f clang::ASTFrontendAction::ExecuteAction() + 269 41 clang 0x00063e8c clang::FrontendAction::Execute() + 278 42 clang 0x00047ea3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 43 clang 0x0002ab7f cc1_main(char const**, char const**, char const*, void*) + 1979 44 clang 0x0002eaa5 main + 272 45 clang 0x000298bd start + 53 46 clang 0x00000020 start + 4294797208 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name incompatible_type.cc -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 107 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-3Ha7WB.s -x c++ incompatible_type.cc 1. incompatible_type.cc:18:17: current parser token ';' 2. incompatible_type.cc:16:1: parsing function body 'm' 3. incompatible_type.cc:16:1: in compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 07:25:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 07:25:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 6310] clang codegen fails with clang: /home/corni/clang/llvm/include/llvm/Support/Casting.h:200: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = clang::VarDecl, Y = const clang::NamedDecl*]: Assertion `isa(Val) && "cast() arg In-Reply-To: References: Message-ID: <20100503122500.5A1013128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6310 Cornelius changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #5 from Cornelius 2010-05-03 07:24:59 CDT --- yes, this was fixed some time ago. *** This bug has been marked as a duplicate of bug 6460 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 09:19:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 09:19:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 7023] New: GVN slow on large function with lots of instructions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7023 Summary: GVN slow on large function with lots of instructions Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4806) --> (http://llvm.org/bugs/attachment.cgi?id=4806) l2.bc LLVM 2.7 Release-Asserts build, GVN takes 0.7s on the attached bitcode (and even more on some even larger bitcodes). This is important in mesa's llvmpipe, where GVN takes up most of the optimization time (and thus optimization time is higher than actual codegen time) ;opt 650 ms (shader39) ;codegen 340 ms (shader39) ... ;opt 910 ms (shader76) ;codegen 430 ms (shader76) ;opt 930 ms (shader77) ;codegen 430 ms (shader77) $ opt -gvn l2.bc -time-passes Total Execution Time: 0.7320 seconds (0.7351 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.7200 ( 99.4%) 0.0080 (100.0%) 0.7280 ( 99.5%) 0.7311 ( 99.5%) Global Value Numbering 0.0040 ( 0.6%) 0.0000 ( 0.0%) 0.0040 ( 0.5%) 0.0038 ( 0.5%) Module Verifier 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0001 ( 0.0%) Memory Dependence Analysis 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0001 ( 0.0%) Dominator Tree Construction 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) Preliminary module verification 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) Basic Alias Analysis (default AA impl) 0.7240 (100.0%) 0.0080 (100.0%) 0.7320 (100.0%) 0.7351 (100.0%) TOTAL -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 09:31:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 09:31:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7024] New: Private access error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7024 Summary: Private access error Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu template class A { int foo; int getFoo(A &a) { return a.foo; } }; C:\Sony\Clang\exp>clang -cc1 templ1.cpp templ1.cpp:4:13: error: 'foo' is a private member of 'A' return a.foo; ^ templ1.cpp:2:6: note: declared private here int 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 Mon May 3 09:50:18 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 09:50:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 3328] analyze <= and >= loops In-Reply-To: References: Message-ID: <20100503145018.872CF312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3328 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Dan Gohman 2010-05-03 09:50:18 CDT --- This is now fixed on trunk. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 10:18:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 10:18:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 7021] Not copying anonymous unions by default In-Reply-To: References: Message-ID: <20100503151837.508663128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7021 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-03 10:18:37 CDT --- Fixed in r102913 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 10:32:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 10:32:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 7022] Assertion instantiating member function declared via typedef In-Reply-To: References: Message-ID: <20100503153229.6CF973128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7022 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-03 10:32:28 CDT --- Fixed in r102914. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 10:37:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 10:37:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 7014] "Using namespace" problem In-Reply-To: References: Message-ID: <20100503153743.8E8CC3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7014 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-03 10:37:43 CDT --- Fixed in r102915. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 10:44:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 10:44:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7017] Assertion failed : point of instantiation must be valid! In-Reply-To: References: Message-ID: <20100503154406.A81713128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7017 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-03 10:44:06 CDT --- Fixed in r102916. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 11:17:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 11:17:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 7025] New: __attribute__((regparm(3))) breaks declaratio <-> definition mapping Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7025 Summary: __attribute__((regparm(3))) breaks declaratio <-> definition mapping Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: syntheticpp at gmx.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com When compiling Qt 4.7, building qmake stops due to this error, (QT_FASTCALL is defined to __attribute__((regparm(3))) ): src/corelib/tools/qchar.cpp:707:12: error: conflicting types for 'digitValue' int QChar::digitValue(ushort ucs2) ^ ... In file included from include/QtCore/qchar.h:1: src/corelib/tools/qchar.h:315:28: note: previous declaration is here static int QT_FASTCALL digitValue(ushort ucs2); ^ ... src/corelib/tools/qchar.cpp:717:12: error: conflicting types for 'digitValue' int QChar::digitValue(uint ucs4) ... In file included from include/QtCore/qchar.h:1: src/corelib/tools/qchar.h:314:28: note: previous declaration is here static int QT_FASTCALL digitValue(uint ucs4); ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 11:50:22 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 11:50:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 6218] Broken debug info for almost every c++ app In-Reply-To: References: Message-ID: <20100503165022.2A5253128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6218 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #3 from Anton Korobeynikov 2010-05-03 11:50:21 CDT --- (In reply to comment #2) > I'm experiencing the same problem. Could you explain what kind of problems > binutils had? I verified twice and it seems to be the problem with clang's debug info generation -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 12:15:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 12:15:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 7026] New: Loop unroll thinks inline assembly blocks are function calls and does not unroll loops having them Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7026 Summary: Loop unroll thinks inline assembly blocks are function calls and does not unroll loops having them 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: pekka.jaaskelainen at tut.fi CC: llvmbugs at cs.uiuc.edu LLVM 2.7 does not unroll loops with inline assembly in the body. This is caused by the following new code in LoopUnrollPass.cpp: + unsigned NumCalls; + unsigned LoopSize = ApproximateLoopSize(L, NumCalls); + DEBUG(dbgs() << " Loop Size = " << LoopSize << "\n"); + if (NumCalls != 0) { + DEBUG(dbgs() << " Not unrolling loop with function calls.\n"); + return false; + } The NumCalls should not include the inline assembly calls, I think. This code is in the current trunk also. This is quite a bad performance regression to us in the TCE project as we heavily use custom operations available in the designed target processor by means of inline assembly, and loop unroll is quite important optimization for a static VLIW-style architecture like ours for extracting static instruction level parallelism from the loops. Should be an issue also for other targets with special instructions as quite often performance critical loops are optimized with inline assembly access to special instructions which also benefit from unrolling. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 12:17:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 12:17:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7027] New: crash without assert in boost code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7027 Summary: crash without assert in boost code 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 Created an attachment (id=4807) --> (http://llvm.org/bugs/attachment.cgi?id=4807) Crashing testcase The attached testsuite crashes, without an assert. It is (I believe) valid code, reduced from a boost test case. ~/Dropbox$ clang++ crash_without_assert.cpp -c -w 0 clang 0x00f54489 PrintStackTrace(void*) + 45 1 clang 0x00f549d3 SignalHandler(int) + 374 2 libSystem.B.dylib 0x91cc842b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1848867839 4 clang 0x00c3f559 llvm::isa_impl::doit(llvm::Value const&) + 17 5 clang 0x00706c99 llvm::isa_impl_wrap::doit(llvm::Value const&) + 17 6 clang 0x009c7d85 bool llvm::isa_impl_cl::isa(llvm::Value const&) + 17 7 clang 0x00706caf bool llvm::isa_impl_cl::isa(llvm::Value*) + 17 8 clang 0x00de9467 bool llvm::isa(llvm::Value* const&) + 19 9 clang 0x006df3b5 llvm::cast_retty::ret_type llvm::dyn_cast(llvm::Value* const&) + 17 10 clang 0x001b2bee llvm::IRBuilder >::CreateConstInBoundsGEP2_32(llvm::Value*, unsigned int, unsigned int, llvm::Twine const&) + 138 11 clang 0x001b2cb4 llvm::IRBuilder >::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 46 12 clang 0x0018d04a (anonymous namespace)::AggExprEmitter::VisitUnaryAddrOf(clang::UnaryOperator const*) + 336 13 clang 0x0018eb2c clang::StmtVisitor<(anonymous namespace)::AggExprEmitter, void>::Visit(clang::Stmt*) + 1088 14 clang 0x0018f5f7 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, llvm::Value*, bool, bool, bool, bool) + 293 15 clang 0x001866bc clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, llvm::Value*, bool, bool, bool) + 264 16 clang 0x001eb5b8 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 488 17 clang 0x001ecea9 clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, llvm::Value*, bool) + 253 18 clang 0x001ed092 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 182 19 clang 0x001eb428 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 88 20 clang 0x00167f26 clang::CodeGen::CodeGenFunction::EmitConstructorBody(llvm::SmallVector, 16u>&) + 382 21 clang 0x00210433 clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl, llvm::Function*) + 1211 22 clang 0x0015cff0 clang::CodeGen::CodeGenModule::EmitCXXConstructor(clang::CXXConstructorDecl const*, clang::CXXCtorType) + 272 23 clang 0x0021934b clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl) + 205 24 clang 0x00219dda clang::CodeGen::CodeGenModule::EmitDeferred() + 360 25 clang 0x0021a010 clang::CodeGen::CodeGenModule::Release() + 24 26 clang 0x00231352 (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) + 88 27 clang 0x00044e66 (anonymous namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 100 28 clang 0x0024002c clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 673 29 clang 0x00063d6f clang::ASTFrontendAction::ExecuteAction() + 269 30 clang 0x00063e8c clang::FrontendAction::Execute() + 278 31 clang 0x00047ea3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 32 clang 0x0002ab7f cc1_main(char const**, char const**, char const*, void*) + 1979 33 clang 0x0002eaa5 main + 272 34 clang 0x000298bd start + 53 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name crash_without_assert.cpp -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -w -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 119 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-8ie7Vq.s -x c++ crash_without_assert.cpp 1. parser at end of file 2. Per-file LLVM IR generation 3. crash_without_assert.cpp:14:1: Generating code for declaration 'massive_hash_function_test::massive_hash_function_test' 4. crash_without_assert.cpp:15:1: LLVM IR generation of compound statement ('{}') clang: error: compiler command failed due to signal 10 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 12:26:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 12:26:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 7028] New: Assertion in CGClass.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7028 Summary: Assertion in CGClass.cpp Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4809) --> (http://llvm.org/bugs/attachment.cgi?id=4809) Unreduced testcase $ ./clang++ qresource.ii clang: /home/asl/proj/llvm/src/tools/clang/lib/CodeGen/CGClass.cpp:732: void clang::CodeGen::CodeGenFunction::EmitCtorPrologue(const clang::CXXConstructorDecl*, clang::CXXCtorType): Assertion `LiveTemporaries.empty() && "Should not have any live temporaries at initializer start!"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 12:28:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 12:28:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7029] New: Assertion in Sema Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7029 Summary: Assertion in Sema Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4810) --> (http://llvm.org/bugs/attachment.cgi?id=4810) Unreduced testcase $ ./clang++ qfilesystemwatcher_inotify.ii /usr/include/sys/inotify.h:36:8: error: cannot initialize a parameter of type 'void *' with an rvalue of type 'char (*)[]' struct inotify_event ^~~~~~~~~~~~~ In file included from io/qfilesystemwatcher_inotify.cpp:1: io/qfilesystemwatcher_inotify.cpp:366:13: note: in instantiation of member function 'QMap::insert' requested here eventForId.insert(event->wd, *event); ^ clang: /home/asl/proj/llvm/src/tools/clang/lib/Sema/SemaDeclCXX.cpp:4495: void clang::Sema::DefineImplicitCopyAssignment(clang::SourceLocation, clang::CXXMethodDecl*): Assertion `!Call.isInvalid() && "Call to __builtin_memcpy cannot fail!"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 13:07:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 13:07:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 4174] LoopIndexSplit executes loop body too many times! In-Reply-To: References: Message-ID: <20100503180715.D9E3F3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4174 devang.patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |devang.patel at gmail.com Resolution| |FIXED --- Comment #10 from devang.patel 2010-05-03 13:07:15 CDT --- Looks good. Applied. r102928. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 13:14:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 13:14:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7030] New: [META] Compiling Loki with clang Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7030 Summary: [META] Compiling Loki with clang Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: syntheticpp at gmx.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Wasn't there a time when Loki was THE stress-test for C++ compilers? ;) clang++ fails compiling with this errors: In file included from SmartPtr.cpp:20: ../include/loki/SmartPtr.h:1418:24: error: expected unqualified-id return OP::template Merge( rhs ); Reproduce: svn co https://loki-lib.svn.sourceforge.net/svnroot/loki-lib cd trunk export CXX=clang++ make -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 13:55:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 13:55:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 5210] clang crashes when parsing bogus c++ method definition In-Reply-To: References: Message-ID: <20100503185541.0CB053128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5210 Nuno Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #5 from Nuno Lopes 2010-05-03 13:55:40 CDT --- thanks for the heads up. It's fixed in my machine as well. Valgrind still reports a few memory leaks, but there are many more to be fixed first. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 14:04:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 14:04:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7031] New: 'Linear Scan Register Allocator' + -g crashes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7031 Summary: 'Linear Scan Register Allocator' + -g crashes Product: clang Version: unspecified Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4813) --> (http://llvm.org/bugs/attachment.cgi?id=4813) test case pes delta$ clang -O2 -c bwn.c && echo success ...warnings.... success pes delta$ clang -O2 -g -c bwn.c && echo success ....warnings... Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name bwn.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -g -resource-dir /usr/local/lib/clang/2.0 -O2 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 152 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-DG7JQf.s -x c bwn.c 1. parser at end of file 2. Code generation 3. Running pass 'Linear Scan Register Allocator' on function '@bwn_key_dowrite' clang: error: compiler command failed due to signal 11 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 14:34:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 14:34:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 7032] New: Sizeless array definition in class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7032 Summary: Sizeless array definition in class Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu class __attribute__ ((aligned(16))) test { int m; __attribute__ ((aligned(16))) unsigned int mDummy[]; }; C:\Sony\Clang\exp>clang -cc1 AttributeAligned.cpp AttributeAligned.cpp:3:44: error: field has incomplete type 'unsigned int []' __attribute__ ((aligned(16))) unsigned int mDummy[]; ^ 1 error generated. I suppose this is not necessarily a bug, but it compiles in gcc. The user is using the field to align the class size, which is why I left in the alignment attributes. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 15:00:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 15:00:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 7027] crash without assert in boost code In-Reply-To: References: Message-ID: <20100503200038.EB6B73128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7027 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-03 15:00:38 CDT --- Fixed in r102942. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 15:22:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 15:22:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7016] Assertion: 'declaration was not instantiated in this scope' in boost code In-Reply-To: References: Message-ID: <20100503202256.4BDF3312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7016 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-05-03 15:22:55 CDT --- Fixed in r102945. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 16:34:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 16:34:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 7033] New: Error on cast involving const and non const cast operators Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7033 Summary: Error on cast involving const and non const cast operators Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu class String { public: String(); operator char *(); operator const char *(); }; String s; const char * p = (const char *)s; C:\Sony\Clang\exp>clang -cc1 pctchar.cpp pctchar.cpp:9:18: error: cannot cast from type 'String' to pointer type 'char const *' const char * p = (const char *)s; ^~~~~~~~~~~~~~ 1 error generated. gcc compiles the above without error. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 16:37:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 16:37:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 7019] Definition and Declaration if LLVMUnionType do not match In-Reply-To: References: Message-ID: <20100503213703.D0E75312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7019 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from Nick Lewycky 2010-05-03 16:37:03 CDT --- Fixed in r102959. Thanks for the bug report! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 16:40:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 16:40:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 6980] Assertion in boost::exception test In-Reply-To: References: Message-ID: <20100503214036.D824C3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6980 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from John McCall 2010-05-03 16:40:36 CDT --- Fixed in r102961. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 17:51:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 17:51:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 6941] x86-64 regalloc miscompilation In-Reply-To: References: Message-ID: <20100503225132.6B7093128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6941 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Jakob Stoklund Olesen 2010-05-03 17:51:32 CDT --- Fixed here: http://llvm.org/viewvc/llvm-project?rev=102770&view=rev -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 18:30:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 18:30:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7013] Error-on-valid and assert on templated friend function In-Reply-To: References: Message-ID: <20100503233001.DC5483128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7013 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-05-03 18:30:01 CDT --- Fixed in r102974. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 19:19:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 19:19:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7034] New: Are default args allowed in template function definitions? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7034 Summary: Are default args allowed in template function definitions? Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu template class test { void func(int a); }; template inline void test::func(int a = 1) {} clang -cc1 hashset.cpp hashset.cpp:5:53: error: default arguments cannot be added to an out-of-line definition of a member of a class template template inline void test::func(int a = 1) {} ^ ~ This compiles without error in gcc. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 20:54:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 20:54:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 7028] Assertion in CGClass.cpp In-Reply-To: References: Message-ID: <20100504015405.EA3B23128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7028 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from John McCall 2010-05-03 20:54:05 CDT --- Fixed in r102998. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 3 21:25:13 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 May 2010 21:25:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 7035] New: Qualifiers with extern? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7035 Summary: Qualifiers with extern? Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu namespace A { void f(); } extern void A::f(); clang -cc1 extqual.cpp extqual.cpp:4:16: error: out-of-line declaration of a member must be a definition extern void A::f(); ~~~^ This compiles in gcc. It appears gcc allows a lot of things I wouldn't expect. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 00:11:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 00:11:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7024] Private access error In-Reply-To: References: Message-ID: <20100504051156.CBBFE312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7024 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from John McCall 2010-05-04 00:11:56 CDT --- Fixed in r102999. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 02:47:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 02:47:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7031] 'Linear Scan Register Allocator' + -g crashes In-Reply-To: References: Message-ID: <20100504074745.31F683128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7031 Roman Divacky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Roman Divacky 2010-05-04 02:47:44 CDT --- yes, it's fixed, thnx! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 03:01:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 03:01:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 7036] New: Redundant "andl $1, %eax" instruction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7036 Summary: Redundant "andl $1, %eax" instruction 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: mdevan.foobar at gmail.com CC: llvmbugs at cs.uiuc.edu [Linux/amd64, LLVM r100854] LLVM seems to like adding a redundant "andl $1, %eax" instruction in the code generated (via clang) for the C code: ------------------------------------------------------------ extern int f(); int test(int a) { return a && f(); } ------------------------------------------------------------ define i32 @test(i32 %a) nounwind { entry: %tobool = icmp eq i32 %a, 0 ; [#uses=1] br i1 %tobool, label %land.end, label %land.rhs land.rhs: ; preds = %entry %call = tail call i32 (...)* @f() nounwind ; [#uses=1] %tobool1 = icmp ne i32 %call, 0 ; [#uses=1] br label %land.end land.end: ; preds = %entry, %land.rhs %0 = phi i1 [ false, %entry ], [ %tobool1, %land.rhs ] ; [#uses=1] %land.ext = zext i1 %0 to i32 ; [#uses=1] ret i32 %land.ext } ------------------------------------------------------------ test: .Leh_func_begin1: pushq %rbp .Ltmp0: movq %rsp, %rbp .Ltmp1: testl %edi, %edi jne .LBB1_2 xorb %al, %al jmp .LBB1_3 .LBB1_2: xorb %al, %al callq f testl %eax, %eax setne %al .LBB1_3: movzbl %al, %eax andl $1, %eax popq %rbp ret ------------------------------------------------------------ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 4 04:11:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 04:11:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 7037] New: Incorrect FAQ on site Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7037 Summary: Incorrect FAQ on site Product: new-bugs Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: b60995 at owlpic.com CC: llvmbugs at cs.uiuc.edu http://llvm.org/docs/FAQ.html#translatecxx > % llvm-g++ x.cpp -o program This wouldn't work with latest llmv-gcc. It gets an error and doesn't generate program.bc. This line should be changed to: % llvm-g++ -emit-llvm -c x.cpp -o program.bc -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 04:59:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 04:59:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7038] New: ast-dump crash for inline-declared structs in other structs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7038 Summary: ast-dump crash for inline-declared structs in other structs Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sebastian.redl at getdesigned.at CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following test program crashes -ast-dump mode: struct foo { struct bar *ptr; }; The problem is that struct bar is not a member (for C compatibility, it lives in the global context), but its lexical context is still struct foo. This means that the AST printer will encounter it and try to print its access specifier. But, not being a member, it has none, which hits an assertion. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 09:23:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 09:23:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 7039] New: -print-multi-os-directory doesn't give expected results. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7039 Summary: -print-multi-os-directory doesn't give expected results. Product: clang Version: trunk Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: kwm at FreeBSD.org CC: llvmbugs at cs.uiuc.edu # uname -m amd64 # gcc45 -print-multi-os-directory . # clang -print-multi-os-directory x86_64 # uname -m i386 # gcc45 -print-multi-os-directory . # clang -print-multi-os-directory . Picked gcc 4.5 because its newer then our standard gcc 4.2.1. The result is the same. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 4 10:28:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 10:28:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7040] New: Assertion on reduced boost testcase Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7040 Summary: Assertion on reduced boost testcase 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 Created an attachment (id=4819) --> (http://llvm.org/bugs/attachment.cgi?id=4819) Asserting testcase The attached code is reduced from an 'error on valid code' problem in libs/asio/example/serialization/client.cpp. The reduced is 'assert on valid code', backtrace: t.cc:11:5: warning: control reaches end of non-void function [-Wreturn-type] } ^ Assertion failed: (DefinitionData && "queried property of class with no definition"), function data, file /Users/caj/clang/llvm/tools/clang/lib/AST/../../include/clang/AST/DeclCXX.h, line 317. 0 clang 0x00f542d5 PrintStackTrace(void*) + 45 1 clang 0x00f5481f SignalHandler(int) + 374 2 libSystem.B.dylib 0x91cc842b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1848867839 4 libSystem.B.dylib 0x91d558e5 raise + 26 5 libSystem.B.dylib 0x91d6b99c abort + 93 6 libSystem.B.dylib 0x91d58544 __pthread_markcancel + 0 7 clang 0x00502c1d clang::CXXRecordDecl::data() const + 73 8 clang 0x00296be9 clang::CXXRecordDecl::hasTrivialDestructor() const + 17 9 clang 0x00231e62 hasNonTrivialDestructorOrCopyConstructor(clang::RecordType const*) + 60 10 clang 0x0023748e (anonymous namespace)::X86_32ABIInfo::classifyArgumentType(clang::QualType, clang::ASTContext&, llvm::LLVMContext&) const + 68 11 clang 0x00237ef5 (anonymous namespace)::X86_32ABIInfo::computeInfo(clang::CodeGen::CGFunctionInfo&, clang::ASTContext&, llvm::LLVMContext&) const + 195 12 clang 0x0016087c clang::CodeGen::CodeGenTypes::getFunctionInfo(clang::CanQual, llvm::SmallVectorImpl > const&, clang::FunctionType::ExtInfo const&) + 484 13 clang 0x0016099e getFunctionInfo(clang::CodeGen::CodeGenTypes&, llvm::SmallVectorImpl >&, clang::CanQual) + 250 14 clang 0x00160fc7 clang::CodeGen::CodeGenTypes::getFunctionInfo(clang::CXXMethodDecl const*) + 117 15 clang 0x0018c907 (anonymous namespace)::AggExprEmitter::VisitUnaryAddrOf(clang::UnaryOperator const*) + 631 16 clang 0x0018e31c clang::StmtVisitor<(anonymous namespace)::AggExprEmitter, void>::Visit(clang::Stmt*) + 1090 17 clang 0x0018ede7 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, llvm::Value*, bool, bool, bool, bool) + 293 18 clang 0x00179aa9 clang::CodeGen::CodeGenFunction::EmitLocalBlockVarDecl(clang::VarDecl const&) + 5339 19 clang 0x0017a4be clang::CodeGen::CodeGenFunction::EmitBlockVarDecl(clang::VarDecl const&) + 152 20 clang 0x0017a6f8 clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl const&) + 400 21 clang 0x001eac17 clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) + 105 22 clang 0x001ec959 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 213 23 clang 0x001eacd0 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 88 24 clang 0x001ec751 clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, llvm::Value*, bool) + 253 25 clang 0x001ec93a clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 182 26 clang 0x001eacd0 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 88 27 clang 0x0020dfe5 clang::CodeGen::CodeGenFunction::EmitFunctionBody(llvm::SmallVector, 16u>&) + 151 28 clang 0x0020f2ae clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl, llvm::Function*) + 1234 29 clang 0x002176b0 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl) + 708 30 clang 0x002181d4 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl) + 298 31 clang 0x00218c06 clang::CodeGen::CodeGenModule::EmitDeferred() + 360 32 clang 0x00218e3c clang::CodeGen::CodeGenModule::Release() + 24 33 clang 0x002300a6 (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) + 88 34 clang 0x000441d2 (anonymous namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 100 35 clang 0x0023ede0 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 673 36 clang 0x0006333b clang::ASTFrontendAction::ExecuteAction() + 269 37 clang 0x00063458 clang::FrontendAction::Execute() + 278 38 clang 0x000472eb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 39 clang 0x0002a13b cc1_main(char const**, char const**, char const*, void*) + 1979 40 clang 0x0002e03b main + 272 41 clang 0x00028e79 start + 53 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name t.cc -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 133 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-RdFfRN.s -x c++ t.cc 1. parser at end of file 2. Per-file LLVM IR generation 3. t.cc:6:9: Generating code for declaration 'connection::foo' 4. t.cc:7:5: LLVM IR generation of compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 4 10:29:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 10:29:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 7041] New: Crash without assert on invalid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7041 Summary: Crash without assert on invalid code 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 Created an attachment (id=4820) --> (http://llvm.org/bugs/attachment.cgi?id=4820) Crashing testcase The attached test case crashes clang++. It came from reducing boost test cases, but I am unsure if it would actually fix any boost problems. /temp$ clang++ ~/Dropbox/crash_without_assert.cpp /Users/caj/Dropbox/crash_without_assert.cpp:2:1: error: expected unqualified-id } ^ /Users/caj/Dropbox/crash_without_assert.cpp:2:1: error: expected external declaration /Users/caj/Dropbox/crash_without_assert.cpp:9:7: error: field has incomplete type 'mutex' (aka 'posix_mutex') mutex mutex_ ^ /Users/caj/Dropbox/crash_without_assert.cpp:1:8: note: forward declaration of 'posix_mutex' struct posix_mutex ^ /Users/caj/Dropbox/crash_without_assert.cpp:9:13: error: expected ';' at end of declaration list mutex mutex_ ^ ; /Users/caj/Dropbox/crash_without_assert.cpp:9:13: error: expected '}' /Users/caj/Dropbox/crash_without_assert.cpp:5:1: note: to match this '{' { ^ 0 clang 0x00f542d5 PrintStackTrace(void*) + 45 1 clang 0x00f5481f SignalHandler(int) + 374 2 libSystem.B.dylib 0x91cc842b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1848867839 4 clang 0x003228a7 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, clang::ASTMultiPtr<&(clang::ActionBase::DeleteExpr(void*))>, clang::QualType*) + 101 5 clang 0x002b0522 BuildImplicitMemberInitializer(clang::Sema&, clang::CXXConstructorDecl*, ImplicitInitializerKind, clang::FieldDecl*, clang::CXXBaseOrMemberInitializer*&) + 430 6 clang 0x002bd09d clang::Sema::SetBaseOrMemberInitializers(clang::CXXConstructorDecl*, clang::CXXBaseOrMemberInitializer**, unsigned int, bool) + 1543 7 clang 0x002bd75c clang::Sema::ActOnDefaultCtorInitializers(clang::OpaquePtr<0>) + 100 8 clang 0x005c83ea clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 1284 9 clang 0x005dd01a clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::OpaquePtr<0>) + 1534 10 clang 0x005de384 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 4786 11 clang 0x005d1670 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 6508 12 clang 0x006103ab clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 85 13 clang 0x0061078c clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 66 14 clang 0x00612504 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2222 15 clang 0x0061264a clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 268 16 clang 0x0023ece9 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 426 17 clang 0x0006333b clang::ASTFrontendAction::ExecuteAction() + 269 18 clang 0x00063458 clang::FrontendAction::Execute() + 278 19 clang 0x000472eb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 20 clang 0x0002a13b cc1_main(char const**, char const**, char const*, void*) + 1979 21 clang 0x0002e03b main + 272 22 clang 0x00028e79 start + 53 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name crash_without_assert.cpp -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 133 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-j6zcE4.s -x c++ /Users/caj/Dropbox/crash_without_assert.cpp 1. /Users/caj/Dropbox/crash_without_assert.cpp:7:1: current parser token '{' 2. /Users/caj/Dropbox/crash_without_assert.cpp:4:1: parsing struct/union/class body 'descriptor_state' clang: error: compiler command failed due to signal 10 (use -v to see invocation) ~/temp$ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 4 10:30:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 10:30:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 6962] A Concrete class inside a template class is identified as abstract In-Reply-To: References: Message-ID: <20100504153058.9B7E23128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6962 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-05-04 10:30:58 CDT --- Yes, and I can confirm that it works correctly now. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 4 13:16:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 13:16:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7037] Incorrect FAQ on site In-Reply-To: References: Message-ID: <20100504181606.D60963128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7037 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-05-04 13:16:06 CDT --- Fixed in r103023, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 4 13:21:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 13:21:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 6621] Assertion in boost code In-Reply-To: References: Message-ID: <20100504182154.1C6933128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6621 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-04 13:21:53 CDT --- John fixed this a day or two ago. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 13:55:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 13:55:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 2394] llvm-gcc generates wrong code for load from bitfield in packed struct In-Reply-To: References: Message-ID: <20100504185557.811F9312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2394 Stuart Hastings changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |stuart at apple.com Resolution| |FIXED --- Comment #5 from Stuart Hastings 2010-05-04 13:55:57 CDT --- Fixed in r102979. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 14:08:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 14:08:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 7043] New: Clang error handling crashes following LLVM stream error (in teardown) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7043 Summary: Clang error handling crashes following LLVM stream error (in teardown) Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu I haven't found a way to reproduce this outside of Boost's build system, but the issue here is that, if an error occurs during the destruction of the standard output or standard error stream objects (raw_stderr_ostream, raw_stdout_ostream), that error will be passed up to the Clang diagnostic system... which has already been destroyed by this point. We should report errors during teardown directly to standard error, ignoring the LLVM error handler and without using llvm::errs(), whose destruction might cause the problem. Here's a stack trace I was able to capture when this problem occurred: #0 0x00007fff855f0886 in __kill () #1 0x00007fff85690eae in abort () #2 0x00007fff805a35d2 in __gnu_cxx::__verbose_terminate_handler () #3 0x00007fff805a1ae1 in __cxxabiv1::__terminate () #4 0x00007fff805a1b16 in std::terminate () #5 0x00007fff805a1fd6 in __cxa_pure_virtual () #6 0x00000001001e1180 in llvm::raw_ostream::tell (this=0x10231a990) at raw_ostream.h:88 #7 0x00000001001db99e in clang::TextDiagnosticPrinter::HandleDiagnostic (this=0x104b08700, Level=Fatal, Info=@0x7fff5fbfed78) at TextDiagnosticPrinter.cpp:713 #8 0x0000000100adb3e5 in clang::Diagnostic::ProcessDiag (this=0x104b08500) at Diagnostic.cpp:579 #9 0x0000000100adb499 in clang::DiagnosticBuilder::Emit (this=0x7fff5fbfee30) at Diagnostic.cpp:603 #10 0x0000000100050788 in clang::DiagnosticBuilder::~DiagnosticBuilder (this=0x7fff5fbfee30) at Diagnostic.h:648 #11 0x0000000100049dd8 in clang::DiagnosticBuilder::~DiagnosticBuilder (this=0x7fff5fbfee30) at Diagnostic.h:648 #12 0x00000001000479d2 in LLVMErrorHandler (UserData=0x104b08500, Message=@0x7fff5fbfee90) at cc1_main.cpp:49 #13 0x00000001016ddc7d in llvm::report_fatal_error (reason=@0x7fff5fbfeec0) at ErrorHandling.cpp:53 #14 0x00000001016ddbec in llvm::report_fatal_error (reason=0x1018c3410 "IO failure on output stream.") at ErrorHandling.cpp:42 #15 0x0000000101700a85 in llvm::raw_ostream::~raw_ostream (this=0x10231a990) at raw_ostream.cpp:64 #16 0x0000000101701565 in llvm::raw_fd_ostream::~raw_fd_ostream (this=0x10231a990) at raw_ostream.cpp:417 #17 0x0000000101702947 in llvm::raw_stderr_ostream::~raw_stderr_ostream (this=0x10231a990) at raw_ostream.h:394 #18 0x0000000101702740 in llvm::raw_stderr_ostream::~raw_stderr_ostream (this=0x10231a990) at raw_ostream.h:394 #19 0x00007fff855b4c58 in __cxa_finalize () #20 0x00007fff855b4b70 in exit () #21 0x000000010003fe9b in start () at TimeValue.cpp:47 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 14:28:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 14:28:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 7044] New: Assertion failed: (V && "DeclRefExpr not entered in LocalDeclMap?"), function EmitDeclRefLValue, file CGExpr.cpp, line 1139. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7044 Summary: Assertion failed: (V && "DeclRefExpr not entered in LocalDeclMap?"), function EmitDeclRefLValue, file CGExpr.cpp, line 1139. Product: clang Version: unspecified Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu pes delta$ cat label.c typedef struct _dmenu_item { } dialogMenuItem; typedef struct _part_info { union { struct { } newfs_custom; } newfs_data; }; int diskLabelEditor(dialogMenuItem *self) { int key = 0; char *msg = ((void *)0); switch (__sbtoupper(key)) { static char _msg[40]; case '\014': clear_wins(); msg = _msg; } } pes delta$ clang label.c ...warnings... Assertion failed: (V && "DeclRefExpr not entered in LocalDeclMap?"), function EmitDeclRefLValue, file CGExpr.cpp, line 1139. Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name label.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 152 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-g3apn2.s -x c label.c 1. parser at end of file 2. label.c:12:11: LLVM IR generation of declaration 'diskLabelEditor' 3. label.c:12:11: Generating code for declaration 'diskLabelEditor' 4. label.c:12:49: LLVM IR generation of compound statement ('{}') 5. label.c:15:31: LLVM IR generation of compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) pes delta$ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 15:46:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 15:46:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 7044] assert related to unreachable static local variable. In-Reply-To: References: Message-ID: <20100504204625.273243128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7044 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from John McCall 2010-05-04 15:46:24 CDT --- Yep, this was my fault. Fixed in r103052. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 16:41:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 16:41:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 7045] New: Analyzer should honor __attribute__((const)) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7045 Summary: Analyzer should honor __attribute__((const)) Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: boris.dusek at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4821) --> (http://llvm.org/bugs/attachment.cgi?id=4821) Minimal test case Hi, clang static analyzer should honor __attribute__((const)) - see the attached test case. tested with ANALYZER BUILD: checker-240 (2010-04-11 10:44:34) Attaching a minimal test case. The real case (from which the test case is derived) had "strcmp" as the "const" function. Since in string.h, strcmp is not tagged as "const", this raises another and separate problem and that is tagging all "const" functions accordingly (using the macro __pure2, like I have seen), so that the proposed functionality becomes usable. Attribute "pure" might also be worth looking at, but I am not sure it's OK to do the same thing with it as I proposed with "const". -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 4 16:58:02 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 16:58:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 7046] New: crash without assert in boost code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7046 Summary: crash without assert in boost code 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 Created an attachment (id=4822) --> (http://llvm.org/bugs/attachment.cgi?id=4822) crashing testcase The attached test case, which is valid code (according to g++) crashes without an assert. /Users/caj/Dropbox/crash_without_assert.cpp:31:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ /Users/caj/Dropbox/crash_without_assert.cpp:15:3: warning: control reaches end of non-void function [-Wreturn-type] } ^ /Users/caj/Dropbox/crash_without_assert.cpp:24:8: note: in instantiation of member function 'hash_function<1>::op' requested here m->op( 0 ); ^ 0 clang 0x00f542d5 PrintStackTrace(void*) + 45 1 clang 0x00f5481f SignalHandler(int) + 374 2 libSystem.B.dylib 0x91cc842b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1848867839 4 clang 0x0055c851 clang::CallExpr::getCallReturnType() const + 147 5 clang 0x001a160b (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) + 23 6 clang 0x001a722d clang::StmtVisitor<(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 2747 7 clang 0x001a77ba clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 142 8 clang 0x00185cec clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, llvm::Value*, bool, bool, bool) + 76 9 clang 0x001eae60 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 488 10 clang 0x001ec751 clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, llvm::Value*, bool) + 253 11 clang 0x001ec93a clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 182 12 clang 0x001eacd0 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 88 13 clang 0x0020dfe5 clang::CodeGen::CodeGenFunction::EmitFunctionBody(llvm::SmallVector, 16u>&) + 151 14 clang 0x0020f2ae clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl, llvm::Function*) + 1234 15 clang 0x002176b0 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl) + 708 16 clang 0x002181d4 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl) + 298 17 clang 0x00218c06 clang::CodeGen::CodeGenModule::EmitDeferred() + 360 18 clang 0x00218e3c clang::CodeGen::CodeGenModule::Release() + 24 19 clang 0x002300a6 (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) + 88 20 clang 0x000441d2 (anonymous namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 100 21 clang 0x0023ede0 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 673 22 clang 0x0006333b clang::ASTFrontendAction::ExecuteAction() + 269 23 clang 0x00063458 clang::FrontendAction::Execute() + 278 24 clang 0x000472eb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 25 clang 0x0002a13b cc1_main(char const**, char const**, char const*, void*) + 1979 26 clang 0x0002e03b main + 272 27 clang 0x00028e79 start + 53 28 clang 0x00000020 start + 4294799836 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name crash_without_assert.cpp -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 80 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-eEB284.s -x c++ /Users/caj/Dropbox/crash_without_assert.cpp 1. parser at end of file 2. Per-file LLVM IR generation 3. /Users/caj/Dropbox/crash_without_assert.cpp:12:7: Generating code for declaration 'hash_function<1>::op' 4. /Users/caj/Dropbox/crash_without_assert.cpp:13:3: LLVM IR generation of compound statement ('{}') clang: error: compiler command failed due to signal 10 (use -v to see invocation) ~$ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 4 17:19:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 17:19:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 7047] New: Nuisance "self-comparison" Warning from Template code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7047 Summary: Nuisance "self-comparison" Warning from Template code Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: me22.ca at gmail.com CC: llvmbugs at cs.uiuc.edu With this code template B)> struct base {}; template struct other : base {}; template struct other : base {}; I get the following warnings $ clang++ clang.cc -Wall -Wextra -fsyntax-only clang.cc:2:36: warning: self-comparison always results in a constant value template B)> ^ clang.cc:9:21: note: in instantiation of default argument for 'base' required here struct other : base {}; ^~~~~~~~~ clang.cc:2:52: warning: self-comparison always results in a constant value template B)> ^ 3 diagnostics generated. which are just a nuisance in this case. g++ does not give a warning for this code. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 4 17:32:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 17:32:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7048] New: ARM JIT for armv7 does not emit an immed correctly if its spread of "1"s is greater than 8 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7048 Summary: ARM JIT for armv7 does not emit an immed correctly if its spread of "1"s is greater than 8 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: sliao at google.com CC: llvmbugs at cs.uiuc.edu Nick asked to file armv7 bugs/patches upstream. Here you go: A simple test case (foo.c) is as follows: int main() { printf("%d\n", 1001); return 0; } After you generate foo.bc, jitting it on an ARMv7 will result in: assertion "SoImmVal != -1 && "Not a valid so_imm value!"" failed: file "lib/Target/ARM/ARMCodeEmitter.cpp" Stack dump: 0. Running pass 'ARM Machine Code Emitter' on function '@main' [1] Segmentation fault This bug is in a way similar to my bug http://llvm.org/bugs/show_bug.cgi?id=6265. Fundamentally, the code emission for ARMv7's movt and movw in LLVM is not finished. I have a 29-line patch for this bug on lib/Target/ARM/ARMCodeEmitter.cpp. Someone told me that I shouldn't fix it in lib/Target/ARM/ARMCodeEmitter.cpp, but should fix it in the ".td" file. I agree that let's see what the community wants, before submitting patches for armv7 bugs. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 4 17:51:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 May 2010 17:51:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 7049] New: ARM JIT for armv7 doesn't output several VFP instructions correctly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7049 Summary: ARM JIT for armv7 doesn't output several VFP instructions correctly 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: sliao at google.com CC: llvmbugs at cs.uiuc.edu I narrowed down to th fact that LLVM's ARM JIT will generate correct code if the value of a float immed is greater than 32. Otherwise, LLVM's ARM JIT will generate incorrect code. A small test code is as follows. On ARM JIT, the result should be: x = 100.000000 x = 114.000000 But on my armv7 device, it outputs: x = 100.000000 x = 102.000000 ---------- Beginning test code ---------- #define PULSE_SIZE 14 #define TRAIL_SIZE 40 struct pulse_s { float originX; float originY; }; int main() { struct pulse_s pulseSet[1]; int i = 0; float x; for (i = 0; i < 1; i++) { pulseSet[i].originX = (float) 100; pulseSet[i].originY = (float) i; } x = pulseSet[0].originX; printf("x = %f\n", x); x += PULSE_SIZE; printf("x = %f\n", x); return 0; } ---------- End of Code -------------- If PULSE_SIZE < 32.0f, LLVM JIT generates: vmov.f32 s0, #0 vadd.f32 s0, s16, s0 (s16 is x), which is incorrect. Otherwise, it will generate: vldr.32 s0, [pc, #32] vadd.f32 s0, s16, s0, which is correct. This is because the Instruction Selection in LLVM is doing the right thing that vmov can take immed values that's less than 32. But the code emission is not implemented. This code is worse than the bug in http://llvm.org/bugs/show_bug.cgi?id=7048. At least in Bug #7048, the unimplemented paths are guarded by assertion failures. For this bug, the emitMiscInstruction() just didn't check. As a result, it took a while for narrowing down/fixing. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 00:51:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 00:51:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 5989] Clang crashes on copy constructor combination with default arguments In-Reply-To: References: Message-ID: <20100505055157.613623128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5989 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2010-05-05 00:51:56 CDT --- Fixed in r103079. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 00:52:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 00:52:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 6887] assertion failed: Default argument is not yet instantiated! In-Reply-To: References: Message-ID: <20100505055242.80B0A3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6887 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-05 00:52:42 CDT --- Fixed in r103079. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 00:53:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 00:53:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 6928] Assertion with implicitly-generated copy constructor call with default arguments In-Reply-To: References: Message-ID: <20100505055316.E19263128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6928 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-05 00:53:16 CDT --- Fixed in r103079. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 01:00:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 01:00:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 7030] C++ 'template' kw as disambiguator not supported In-Reply-To: References: Message-ID: <20100505060049.E34333128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7030 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Douglas Gregor 2010-05-05 01:00:49 CDT --- Applied Alp's latest patch in r103081. 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 May 5 04:11:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 04:11:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 7050] New: Global variable initialisation issue Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7050 Summary: Global variable initialisation issue 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 Created an attachment (id=4826) --> (http://llvm.org/bugs/attachment.cgi?id=4826) Singleton test case The following testcase is reduced from boost::serialization. It asserts at runtime in clang. It appears to be fixed if lines 'assert(! detail::singleton_wrapper::m_is_destroyed);' and 'use(instance);' are swapped around (lines 34 and 35). This bug is very sensitive. On apple you need to add '-m64 -O' to trigger it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 5 07:06:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 07:06:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7051] New: assert 'C++ binary operator overloading is missing candidates!' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7051 Summary: assert 'C++ binary operator overloading is missing candidates!' 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 Created an attachment (id=4827) --> (http://llvm.org/bugs/attachment.cgi?id=4827) Asserting test case derived from boost This is reduced from the boost file './libs/test/example/unit_test_example_12.cpp'. (the original did not produce this assert, it just crashed). Assertion failed: (Result.isInvalid() && "C++ binary operator overloading is missing candidates!"), function CreateOverloadedBinOp, file SemaOverload.cpp, line 6210. 0 clang 0x00f57119 PrintStackTrace(void*) + 45 1 clang 0x00f57663 SignalHandler(int) + 374 2 libSystem.B.dylib 0x91cc842b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1848867839 4 libSystem.B.dylib 0x91d558e5 raise + 26 5 libSystem.B.dylib 0x91d6b99c abort + 93 6 libSystem.B.dylib 0x91d58544 __pthread_markcancel + 0 7 clang 0x0035a04f clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int, clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*) + 5001 8 clang 0x002f3901 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperator::Opcode, clang::Expr*, clang::Expr*) + 295 9 clang 0x002f3aa9 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>) + 263 10 clang 0x005ebd6d clang::Parser::ParseRHSOfBinaryExpression(clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>, clang::prec::Level) + 2501 11 clang 0x005e4326 clang::Parser::ParseAssignmentExpression() + 444 12 clang 0x005e4763 clang::Parser::ParseExpression() + 25 13 clang 0x006050c3 clang::Parser::ParseStatementOrDeclaration(bool) + 1679 14 clang 0x006097cb clang::Parser::ParseCompoundStatementBody(bool) + 215 15 clang 0x00609e2f clang::Parser::ParseFunctionStatementBody(clang::OpaquePtr<0>) + 199 16 clang 0x005ca01e clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 1304 17 clang 0x005ca185 clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 1663 18 clang 0x005dec3a clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::OpaquePtr<0>) + 1534 19 clang 0x005dffa4 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 4786 20 clang 0x005d3290 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 6508 21 clang 0x0060d877 clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation&, clang::AccessSpecifier) + 341 22 clang 0x0060e0f9 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 985 23 clang 0x0060e1e0 clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 178 24 clang 0x005d74dc clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::CXX0XAttributeList) + 330 25 clang 0x006141bf clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 1993 26 clang 0x006143ea clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 268 27 clang 0x0023f3f1 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 426 28 clang 0x0006367f clang::ASTFrontendAction::ExecuteAction() + 269 29 clang 0x0006379c clang::FrontendAction::Execute() + 278 30 clang 0x00047427 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 31 clang 0x0002a11f cc1_main(char const**, char const**, char const*, void*) + 1979 32 clang 0x0002e039 main + 272 33 clang 0x00028e5d start + 53 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name operator_missing.cc -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmacro-backtrace-limit 6 -ftemplate-backtrace-limit 10 -fmessage-length 131 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-qKj9hz.s -x c++ operator_missing.cc 1. operator_missing.cc:13:16: current parser token ';' 2. operator_missing.cc:6:1: parsing struct/union/class body 'basic_istream' 3. operator_missing.cc:11:5: parsing function body 'basic_istream::sentry::sentry' 4. operator_missing.cc:11:5: in compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 5 10:06:39 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 10:06:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 7052] New: Global Value Numbering assertion failure: "bitwidth too small" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7052 Summary: Global Value Numbering assertion failure: "bitwidth too small" Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: matti.niemenmaa+llvmbugs at iki.fi CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4829) --> (http://llvm.org/bugs/attachment.cgi?id=4829) test case The Global Value Numbering pass asserts on the attached bitcode file, using LLVM r103084: $ opt -gvn bugpoint-reduced-simplified.bc >/dev/null opt: src/llvm/trunk/lib/VMCore/Type.cpp:806: static const llvm::IntegerType* llvm::IntegerType::get(llvm::LLVMContext&, unsigned int): Assertion `NumBits >= MIN_INT_BITS && "bitwidth too small"' failed. Stack dump: 0. Program arguments: bin/opt -gvn 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'Global Value Numbering' on function '@main' In 2.7 it does one better and segfaults: $ opt -gvn bugpoint-reduced-simplified.bc >/dev/null 0 opt 0x000000000088102f 1 opt 0x000000000088156d 2 libpthread.so.0 0x00007fe59349af20 3 opt 0x00000000004fe79f 4 opt 0x0000000000503180 5 opt 0x0000000000503918 6 opt 0x000000000080e366 llvm::FPPassManager::runOnFunction(llvm::Function&) + 502 7 opt 0x000000000080e43b llvm::FPPassManager::runOnModule(llvm::Module&) + 75 8 opt 0x000000000080dfd1 llvm::MPPassManager::runOnModule(llvm::Module&) + 369 9 opt 0x000000000080e10f llvm::PassManagerImpl::run(llvm::Module&) + 111 10 opt 0x00000000004a4653 main + 2003 11 libc.so.6 0x00007fe5927a7b1d __libc_start_main + 253 12 opt 0x0000000000499d99 Stack dump: 0. Program arguments: opt -gvn foo.bc 1. Running pass 'Function Pass Manager' on module 'foo.bc'. 2. Running pass 'Global Value Numbering' on function '@main' -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 5 11:06:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 11:06:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7053] New: clang++ accepts invalid template code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7053 Summary: clang++ accepts invalid template code Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang++ accepts and compiles the following invalid code: template< int ; int main() { } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 5 11:07:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 11:07:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 7054] New: Assertion `Symbol->isUndefined() && "Cannot define a symbol twice!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7054 Summary: Assertion `Symbol->isUndefined() && "Cannot define a symbol twice!"' failed. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hv at crypt.org CC: llvmbugs at cs.uiuc.edu, hv at crypt.org Created an attachment (id=4830) --> (http://llvm.org/bugs/attachment.cgi?id=4830) Example C code Attached code was cut down from an attempt to compile (latest) perl, at the point it first tried to #include . zen% /opt/clang-latest/bin/clang --version clang version 2.0 (trunk 102861) Target: i386-pc-linux-gnu Thread model: posix zen% /opt/clang-latest/bin/clang -c clangtest.c clang: MCAsmStreamer.cpp:220: virtual void::MCAsmStreamer::EmitLabel(llvm::MCSymbol*): Assertion `Symbol->isUndefined() && "Cannot define a symbol twice!"' failed. 0 clang 0x08fbafe3 1 clang 0x08fbaea7 2 0xb7f34420 __kernel_sigreturn + 0 3 libc.so.6 0x0044b4b1 abort + 257 4 libc.so.6 0x004431db __assert_fail + 251 5 clang 0x08e67ce3 6 clang 0x08b0ef6c 7 clang 0x08b0ec34 8 clang 0x08950dd5 9 clang 0x08b8be3f 10 clang 0x08f2c3a0 11 clang 0x08f2c0c9 12 clang 0x08f2bd2f 13 clang 0x0808011c 14 clang 0x0807eee4 15 clang 0x082de2ba 16 clang 0x08099c39 17 clang 0x08099834 18 clang 0x08085491 19 clang 0x0806d915 20 clang 0x08072693 main + 202 21 libc.so.6 0x00436dec __libc_start_main + 220 22 clang 0x0806c231 Stack dump: 0. Program arguments: /opt/clang-latest/bin/clang -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name clangtest.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir /opt/clang-latest/lib/clang/2.0 -ferror-limit 19 -ftemplate-backtrace-limit 10 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-meTmGU.s -x c clangtest.c 1. parser at end of file 2. Code generation 3. Running pass 'X86 AT&T-Style Assembly Printer' on function '@stat64' clang: error: compiler command failed due to signal 6 (use -v to see invocation) zen% -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 11:14:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 11:14:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 7055] New: Constructor is not used for type conversion. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7055 Summary: Constructor is not used for type conversion. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: syntheticpp at gmx.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Next Loki bug: ./../include/loki/Functor.h:1619:16: error: functional-style cast from 'std::auto_ptr' to 'Outgoing' (aka 'Functor') is not allowed return Outgoing(std::auto_ptr( ^~~~~~~~~ In file included from Test.cpp:58: ./FunctorTest.h:60:44: note: in instantiation of function template specialization 'Loki::BindFirst, ::Loki::SingleThreaded> >' requested here Functor bindFunctor(BindFirst(function,testResult)); ^ In file included from Test.cpp:55: Comment: But Functor has a constructor which takes a std::auto_ptr: typedef FunctorImpl Impl; ... Functor(std::auto_ptr spImpl) : spImpl_(spImpl) {} If Alp isn't faster I try to make a reduced test case Reproduce: svn co https://loki-lib.svn.sourceforge.net/svnroot/loki-lib cd trunk export CXX=clang++ make . -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 12:05:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 12:05:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 7056] New: Confusion by friend declaration of global template function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7056 Summary: Confusion by friend declaration of global template function Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: syntheticpp at gmx.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Found with Loki. Disable definition in /include/loki/SmartPtr.h line 54: //#define LOKI_ENABLE_FRIEND_TEMPLATE_TEMPLATE_PARAMETER_WORKAROUND Build test/SmartPtr/main.cpp main.cpp:1326:5: error: call to 'Release' is ambiguous Release( w1, pNull ); ^~~~~~~ In file included from main.cpp:18: ../../include/loki/SmartPtr.h:1386:21: note: candidate function [with $0 = BaseClass, OP1 = RefCounted, $2 = Loki::DisallowConversion, KP1 = AssertCheck, SP1 = DefaultSPStorage, CNP1 = DontPropagateConst] friend void Release(SmartPtr& sp, ^ ../../include/loki/SmartPtr.h:1586:17: note: candidate function [with T = BaseClass, OP = RefCounted, CP = Loki::DisallowConversion, KP = AssertCheck, SP = DefaultSPStorage, CNP = DontPropagateConst] inline void Release(SmartPtr& sp, ^ The first declaration is only a friend declaration. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 5 12:17:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 12:17:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7057] New: Too early resolving of template argument's member functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7057 Summary: Too early resolving of template argument's member functions Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: syntheticpp at gmx.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Found with Loki. Disable definition in /include/loki/SmartPtr.h line 54: //#define LOKI_ENABLE_FRIEND_TEMPLATE_TEMPLATE_PARAMETER_WORKAROUND Call 'make -k" in test/SmartPtr. clang++ output: In file included from LockTest.cpp:38: ../../include/loki/StrongPtr.h:1495:15: error: 'T' does not refer to a value if ( !sp.RP::OnReleaseAll( sp.IsStrong() || sp.OP::HasStrongPointer() ) ) ^ ../../include/loki/StrongPtr.h:1483:14: note: declared here typename T, ^ clang++ tries to find 'sp.RP::OnReleaseAll' which does not work without an concrete type T. Should the resolving of T's member functions not be done at instantiation time? Or there are problems with parsing 'foo.ABC::XYZ'. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 14:35:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 14:35:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7058] New: non-virtual thunk functions can mangle objects passed by value Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7058 Summary: non-virtual thunk functions can mangle objects passed by value Product: clang Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4831) --> (http://llvm.org/bugs/attachment.cgi?id=4831) Testcase showing a non-virtual thunk mangling an object passed by value While trying out clang self-hosting on FreeBSD/i386, I encountered a number of segfaults. Apparently this was only the case for i386, since a number of people have successfully self-hosted clang on amd64. Then, when I built an instance of the llvm/clang trunk (r103083) using the system gcc (v4.2.1), and used that instance to build llvm/clang itself, many tests in the llvm and clang test suite failed with segfaults too. I concentrated on one of the particular tests that failed with a segfault: ./Debug/bin/opt -gvn foo I found that one of the CallSite objects passed by value was screwed up. This happens in one of the llvm::AliasAnalysis::getModRefInfo instances: include/llvm/Analysis/AliasAnalysis.h, around line 258: virtual ModRefResult getModRefInfo(CallSite CS, Value *P, unsigned Size); // [0] ... ModRefResult getModRefInfo(CallInst *C, Value *P, unsigned Size) { // [1] return getModRefInfo(CallSite(C), P, Size); // [2] } which gets called by: ModRefResult getModRefInfo(Instruction *I, Value *P, unsigned Size) { // [3] switch (I->getOpcode()) { case Instruction::VAArg: return getModRefInfo((VAArgInst*)I, P, Size); case Instruction::Load: return getModRefInfo((LoadInst*)I, P, Size); case Instruction::Store: return getModRefInfo((StoreInst*)I, P, Size); case Instruction::Call: return getModRefInfo((CallInst*)I, P, Size); // [4] case Instruction::Invoke: return getModRefInfo((InvokeInst*)I, P, Size); default: return NoModRef; } } which gets called by MemoryDependenceAnalysis::getPointerDependencyFrom: MemDepResult MemoryDependenceAnalysis:: getPointerDependencyFrom(Value *MemPtr, uint64_t MemSize, bool isLoad, BasicBlock::iterator ScanIt, BasicBlock *BB) { ... // See if this instruction (e.g. a call or vaarg) mod/ref's the pointer. switch (AA->getModRefInfo(Inst, MemPtr, MemSize)) { Now when AA->getModRefInfo is called, Inst apparently points to an Instruction object that has an Instruction:Call opcode, so the getModRefInfo function at [3] casts it to a CallInst pointer at [4], and calls the specialized getModRefInfo at [1]. So far so good, however, at [2] four different things happen: 1. A temp object CallSite(C) is constructed. 2. It is passed by value (e.g. copied) to the 'virtual' getModRefInfo member function at [0]. 3. The getModRefInfo member at [0] is *not* directly called, but a non-virtual thunk is used, since the AA variable points to a BasicAliasAnalysis object, which inherits from multiple classes. 4. The thunk function calls the intended getModRefInfo at [0]. Now, in that step 4, the thunk function screws something up with the CallInst object. The non-virtual thunk is visible in the backtrace in gdb (the top-level assert is triggered because I added on to getInstruction, to check for bogus pointers.): #0 0x28cd1927 in kill () from /lib/libc.so.7 #1 0x28cd1886 in raise () from /lib/libc.so.7 #2 0x28cd041a in abort () from /lib/libc.so.7 #3 0x28cb8826 in __assert () from /lib/libc.so.7 #4 0x083e4c37 in llvm::CallSiteBase::getInstruction (this=0xbfbfda68) at CallSite.h:87 #5 0x086f1a17 in (anonymous namespace)::BasicAliasAnalysis::getModRefInfo (this=0x29104080, P=0x2900948c, Size=4294967295, CS={ = {I = {Value = 4393129}}, }) at AnalysisWrappers.cpp:166 #6 0x086f2423 in non-virtual thunk to (anonymous namespace)::BasicAliasAnalysis::getModRefInfo(llvm::CallSite, llvm::Value*, unsigned int) () at AnalysisWrappers.cpp:166 #7 0x0856d192 in llvm::AliasAnalysis::getModRefInfo (this=0x29104090, C=0x290094cc, P=0x2900948c, Size=4294967295) at AnalysisWrappers.cpp:166 #8 0x086538ee in llvm::AliasAnalysis::getModRefInfo (this=0x29104090, I=0x290094cc, P=0x2900948c, Size=4294967295) at AnalysisWrappers.cpp:166 #9 0x0874ccf9 in llvm::MemoryDependenceAnalysis::getPointerDependencyFrom (this=0x29102080, MemPtr=0x2900948c, MemSize=4294967295, isLoad=true, BB=0x2900c370, ScanIt={ = {}, NodePtr = 0x290094cc}) at AnalysisWrappers.cpp:166 At #5, you can see the CallSite object, which is represented by CS={}, and the Value turns out to be 4393129 (0x4308a9). However, this Value is supposed to be a pointer, and this value is way too low. When you go up in the stack to #6, and examine the Value, it turns out to be 0x290094ce instead. In the non-virtual thunk function, it looks like the code generator inserts an unwanted redirection at [5]: .align 16, 0x90 .type _ZThn16_N12_GLOBAL__N_118BasicAliasAnalysis13getModRefInfoEN4llvm8CallSiteEPNS1_5ValueEj, at function _ZThn16_N12_GLOBAL__N_118BasicAliasAnalysis13getModRefInfoEN4llvm8CallSiteEPNS1_5ValueEj: .Leh_func_begin51: pushl %ebp .Ltmp425: movl %esp, %ebp .Ltmp426: pushl %ebx pushl %edi pushl %esi subl $36, %esp .Ltmp427: call .L51$pb .L51$pb: popl %eax .Ltmp428: addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp428-.L51$pb), %eax movl 8(%ebp), %ecx movl 12(%ebp), %edx movl 16(%ebp), %esi movl 20(%ebp), %edi movl %ecx, -20(%ebp) movl %esi, -24(%ebp) movl %edi, -28(%ebp) movl -20(%ebp), %ecx addl $-16, %ecx leal -32(%ebp), %esi movl (%edx), %edx // [5] movl %edx, (%esi) movl -24(%ebp), %edx movl -28(%ebp), %esi movl %esp, %edi movl %ecx, (%edi) movl -32(%ebp), %ecx movl %ecx, 4(%edi) movl %edx, 8(%edi) movl %esi, 12(%edi) movl %eax, %ebx call _ZN12_GLOBAL__N_118BasicAliasAnalysis13getModRefInfoEN4llvm8CallSiteEPNS1_5ValueEj movl %eax, -16(%ebp) movl -16(%ebp), %eax addl $36, %esp popl %esi popl %edi popl %ebx popl %ebp ret .Ltmp429: .size _ZThn16_N12_GLOBAL__N_118BasicAliasAnalysis13getModRefInfoEN4llvm8CallSiteEPNS1_5ValueEj, .Ltmp429-_ZThn16_N12_GLOBAL__N_118BasicAliasAnalysis13getModRefInfoEN4llvm8CallSiteEPNS1_5ValueEj .Leh_func_end51: If I tell gdb to break at [5], and jump to the next instruction, e.g. without performing the indirection, the program completes successfully, and produces the expected output file. The non-virtual thunk to BasicAliasAnalysis::getModRefInfo is generated by compiling lib/Analysis/BasicAliasAnalysis.cpp, so I have attempted to reduce this file to a testcase that is as small as possible. It is attached as 'thunkbug.cpp'. To reproduce the crash, simply compile the testcase with clang++ and run it, on either FreeBSD or Linux on i386. It should crash both with and without optimization. The same code compiles and runs fine with g++, and also with clang on amd64 (I only tested that on FreeBSD, but I bet it will apply to Linux amd64 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 Wed May 5 15:17:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 15:17:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7050] Global variable initialisation issue In-Reply-To: References: Message-ID: <20100505201732.5AFA93128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7050 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-05-05 15:17:32 CDT --- Well, that was "fun". Fixed in r103115. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 15:20:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 15:20:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 7057] Too early resolving of template argument's member functions In-Reply-To: References: Message-ID: <20100505202054.E82DC3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7057 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Douglas Gregor 2010-05-05 15:20:54 CDT --- This is a bug in Loki. For "RP" to be parsed as a template-name when "sp" is a type-dependent expression, it needs the template keyword, e.g., sp.template RP otherwise, RP gets parsed as a member and '<' as a less-than operator. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 5 16:00:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 16:00:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7059] New: Exception std::bad_cast thrown by dynamic_cast is not caught correctly. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7059 Summary: Exception std::bad_cast thrown by dynamic_cast is not caught correctly. Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pasi.parviainen at iki.fi CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4832) --> (http://llvm.org/bugs/attachment.cgi?id=4832) Failing example. Exception std::bad_cast thrown by dynamic_cast is not caught correctly on same level where the throw did occur. Attached failing example code demonstrates the problem. Output of the example program compiled as "clang++ badcast.cpp": DoDynamicCast(a); => std::bad_cast caught incorrectly. Expected outcome: DoDynamicCast(a); => std::bad_cast caught 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 Wed May 5 16:50:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 16:50:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 7060] New: -print-before-all/-print-after-all segfault on OSX Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7060 Summary: -print-before-all/-print-after-all segfault on OSX Product: tools Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: grosbach at apple.com CC: llvmbugs at cs.uiuc.edu $ cat t.ll define i32 @f1(i32 %a, i32 %b) { entry: %tmp1 = sdiv i32 %a, %b ; [#uses=1] ret i32 %tmp1 } $ llc -print-before-all t.ll Segmentation fault -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 5 16:52:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 16:52:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 7060] -print-before-all/-print-after-all segfault on OSX In-Reply-To: References: Message-ID: <20100505215221.55E363128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7060 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Chris Lattner 2010-05-05 16:52:21 CDT --- *** This bug has been marked as a duplicate of bug 6875 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 16:54:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 16:54:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 7061] New: Website: CMake files also work with Linux Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7061 Summary: Website: CMake files also work with Linux Product: Build scripts Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: cmake AssignedTo: unassignedbugs at nondot.org ReportedBy: syntheticpp at gmx.net CC: llvmbugs at cs.uiuc.edu CMake files also work under Linux, but it is not mentioned at the web site 'Getting Started'. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 17:08:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 17:08:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 2809] Avoid execution domain bypass In-Reply-To: References: Message-ID: <20100505220821.92A373128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2809 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #9 from Jakob Stoklund Olesen 2010-05-05 17:08:20 CDT --- Fixed by the SSEDomainFixPass -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 17:19:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 17:19:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7062] New: [C++ CodeGen] Destruction of partial-constructed member arrays in implicitly-defined constructors Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7062 Summary: [C++ CodeGen] Destruction of partial-constructed member arrays in implicitly-defined constructors Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4833) --> (http://llvm.org/bugs/attachment.cgi?id=4833) Failing test case When an exception occurs while constructing an element in a non-static array member, we need to destroy all of the elements constructed before the exception occurred. The attached tested case (copy-constructor-synthesis-3.cpp) is a simple run-time test that checks for this behavior, which we currently fail. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 17:38:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 17:38:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 6999] [C++ CodeGen] Reimplement synthesis of implicit copy assignment operators In-Reply-To: References: Message-ID: <20100505223830.9F8B13128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6999 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-05 17:38:30 CDT --- This work is done as of r103127. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 17:56:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 17:56:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 7058] non-virtual thunk functions can mangle objects passed by value In-Reply-To: References: Message-ID: <20100505225604.F25283128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7058 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Chris Lattner 2010-05-05 17:56:04 CDT --- Fixed here, thanks for the great report! http://llvm.org/viewvc/llvm-project?rev=103131&view=rev -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 18:11:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 18:11:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 6520] [inline asm] early clobber + forced register + -O0 == wrong register allocation In-Reply-To: References: Message-ID: <20100505231120.A0D633128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6520 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Jakob Stoklund Olesen 2010-05-05 18:11:20 CDT --- Fixed in r103133 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 18:40:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 18:40:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 1642] SjLj (setjmp/longjmp)-based exception handling in LLVM-GCC seems to be unsupported In-Reply-To: References: Message-ID: <20100505234056.148113128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=1642 Jim Grosbach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |grosbach at apple.com Resolution| |FIXED --- Comment #5 from Jim Grosbach 2010-05-05 18:40:55 CDT --- llvm has had sjlj EH for ARM for a while now. Closing. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 18:46:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 18:46:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 5717] thumb2 mode doesn't distinguish the v7-M variant In-Reply-To: References: Message-ID: <20100505234614.088EC3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5717 Jim Grosbach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Jim Grosbach 2010-05-05 18:46:13 CDT --- Fixed in Fixed in r103119, r103120, r103122 and r103136. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 5 19:05:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 May 2010 19:05:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 7054] Assertion `Symbol->isUndefined() && "Cannot define a symbol twice!"' failed. In-Reply-To: References: Message-ID: <20100506000549.19CD33128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7054 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-05-05 19:05:48 CDT --- Fixed in r103140 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 01:08:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 01:08:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7063] New: Assertation failure, class copying Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7063 Summary: Assertation failure, class copying Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: scoopr at iki.fi CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Attached test-case fails. Needed -arch i386 flag for triggering it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 01:35:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 01:35:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 7063] Assertation failure, class copying In-Reply-To: References: Message-ID: <20100506063537.B5B5E3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7063 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-05-06 01:35:37 CDT --- Fixed in r103171, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 01:51:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 01:51:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 7064] New: Crash with synthesized ivar of incomplete struct type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7064 Summary: Crash with synthesized ivar of incomplete struct type Product: clang Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: kyle at omnigroup.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4837) --> (http://llvm.org/bugs/attachment.cgi?id=4837) st.m I am able to crash clang with this simple file and the following command line: $ clang -ObjC -framework Foundation -o st st.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 Thu May 6 02:26:13 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 02:26:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 7065] New: Inconsistent treatment of using declarations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7065 Summary: Inconsistent treatment of using declarations 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 In the following code, clang complains about g, but not about f. Comeau and g++ are both happy with all of it. namespace X { int f(); int g(); } using X::f; using X::f; void h() { using X::g; using X::g; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 02:31:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 02:31:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 7066] New: local register allocator fails on inline asm Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7066 Summary: local register allocator fails on inline asm Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4838) --> (http://llvm.org/bugs/attachment.cgi?id=4838) testcase .ll $ llc -regalloc=local c.ll llc: RegAllocLocal.cpp:348: void::RALocal::spillPhysReg(llvm::MachineBasicBlock&, llvm::MachineInstr*, unsigned int, bool): Assertion `PhysRegsUsed[PhysReg] != -2 && "Non allocable reg used!"' failed. Program received signal SIGABRT, Aborted. 0x00007ffff6ef6095 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007ffff6ef6095 in raise () from /lib/libc.so.6 #1 0x00007ffff6ef7af0 in abort () from /lib/libc.so.6 #2 0x00007ffff6eef2df in __assert_fail () from /lib/libc.so.6 #3 0x0000000000edf818 in spillPhysReg (this=0x18aca20, MBB=..., I=0x18c7308, PhysReg=116, OnlyVirtRegs=true) at RegAllocLocal.cpp:348 #4 0x0000000000ee0797 in AllocateBasicBlock (this=0x18aca20, MBB=...) at RegAllocLocal.cpp:852 #5 0x0000000000ee223b in runOnMachineFunction (this=0x18aca20, Fn=...) at RegAllocLocal.cpp:1208 #6 0x0000000000e91a71 in llvm::MachineFunctionPass::runOnFunction ( this=0x18aca20, F=...) at MachineFunctionPass.cpp:33 #7 0x000000000117efc0 in llvm::FPPassManager::runOnFunction (this=0x188ba80, F=...) at PassManager.cpp:1418 #8 0x00000000011804f5 in llvm::FunctionPassManagerImpl::run (this=0x188f480, F=...) at PassManager.cpp:1369 #9 0x00000000011806b4 in llvm::FunctionPassManager::run (this=0x7fffffffe5f0, F=...) at PassManager.cpp:1299 #10 0x0000000000986539 in main (argc=3, argv=0x7fffffffe868) at llc.cpp:378 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 03:12:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 03:12:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 7067] New: Destructor not invoked Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7067 Summary: Destructor not invoked 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 Created an attachment (id=4839) --> (http://llvm.org/bugs/attachment.cgi?id=4839) Example showing missing destructor In the attached code, by observing the output we can see that 'X(int i, int j)' is being invoked repeatedly on the same memory location, but '~X()' is never being called. It is in g++, and should be. This was reduced from a 'circualar_buffer' test case in boost. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 04:47:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 04:47:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 1642] SjLj (setjmp/longjmp)-based exception handling in LLVM-GCC seems to be unsupported for anything non arm/darwin In-Reply-To: References: Message-ID: <20100506094715.BD88F3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=1642 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #7 from Anton Korobeynikov 2010-05-06 04:47:15 CDT --- Definitely should be reopened -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 05:23:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 05:23:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 5274] clang: doesn't add noalias attribute for restrict qualifier In-Reply-To: References: Message-ID: <20100506102301.7120A3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5274 Pekka J??skel?inen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |pekka.jaaskelainen at tut.fi Version|unspecified |2.7 Resolution|FIXED | --- Comment #2 from Pekka J??skel?inen 2010-05-06 05:23:01 CDT --- This is broken (still/again?) in LLVM 2.7: test2.c: int foo(char *restrict s) { return 0; } clang test2.c -c -emit-llvm -o - | llvm-dis ... define i32 @foo(i8* %s) nounwind { entry: %retval = alloca i32, align 4 ; [#uses=2] %s.addr = alloca i8*, align 8 ; [#uses=1] store i8* %s, i8** %s.addr store i32 0, i32* %retval %0 = load i32* %retval ; [#uses=1] ret i32 %0 } vs. tce-llvm-gcc --std=c99 test2.c -c --emit-llvm -o - | llvm-dis ... define i32 @foo(i8* noalias %s) nounwind { entry: %s_addr = alloca i8* ; [#uses=1] %retval = alloca i32 ; [#uses=2] %"alloca point" = bitcast i32 0 to i32 ; [#uses=0] store i8* %s, i8** %s_addr store i32 0, i32* %retval, align 4 br label %return return: ; preds = %entry %retval1 = load i32* %retval ; [#uses=1] ret i32 %retval1 } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 05:27:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 05:27:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7068] New: clang stddef.h does not define wint_t Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7068 Summary: clang stddef.h does not define wint_t Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Headers AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu In g++ 4.4.3 (possibly earlier): The code: '#include ' fails on clang, as stddef.h defines (via a series of macros and ifdefs): typedef unsigned int wint_t; On the other hand #include #include works correctly on both compilers, as wchar.h defines wint_t if it is not otherwise defined. This blocks some boost files when using g++ 4.4.3 as the underlying compiler. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 07:15:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 07:15:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 7068] clang stddef.h does not define wint_t In-Reply-To: References: Message-ID: <20100506121527.DC0A23128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7068 Sylv?re Teissier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |quickslyver at free.fr Resolution| |DUPLICATE --- Comment #1 from Sylv?re Teissier 2010-05-06 07:15:27 CDT --- *** This bug has been marked as a duplicate of bug 6691 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 08:09:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 08:09:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7069] New: Clang fails to compile when including Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7069 Summary: Clang fails to compile when including Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nbigaouette at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I compiled Clang from SVN (tried revision 102493 and 103172) on ArchLinux using this: http://aur.archlinux.org/packages.php?ID=20222 Compiling my project failed and I identified the problem. Here is the simplest file where the problem arise: #include //#include int main() { //std::cout << "Hello, world!\n"; } Compiling gives: clang++ test.cpp -o test In file included from test.cpp:1: /usr/include/c++/4.5.0/iomanip:63:12: error: expected expression { return { __mask }; } ^ /usr/include/c++/4.5.0/iomanip:93:12: error: expected expression { return { __mask }; } ^ /usr/include/c++/4.5.0/iomanip:124:12: error: expected expression { return { __base }; } ^ /usr/include/c++/4.5.0/iomanip:162:14: error: expected expression { return { __c }; } ^ /usr/include/c++/4.5.0/iomanip:192:12: error: expected expression { return { __n }; } ^ /usr/include/c++/4.5.0/iomanip:222:12: error: expected expression { return { __n }; } ^ 6 errors generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 09:16:07 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 09:16:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 7065] Inconsistent treatment of using declarations In-Reply-To: References: Message-ID: <20100506141607.A8FC23128042@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7065 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Douglas Gregor 2010-05-06 09:16:07 CDT --- Clang is correct; Comeau and g++ are wrong not to diagnose these errors. See C++ [namespace.udecl]p10: A using-declaration is a declaration and can therefore be used repeatedly where (and only where) multiple declarations are allowed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 10:18:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 10:18:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 7070] New: Scalar cast to vector, implicit conversion, and function selection Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7070 Summary: Scalar cast to vector, implicit conversion, and function selection Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu I think the following three issues are all related. Scalars cast to vectors should not be allowed (http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf 2.4.6): float f = 1.0f; __attribute__((vector_size(16))) float v = (__attribute__((vector_size(16))) float)f; clang -cc1 vcast.cpp (no error generated) Problem with function selection: class test { public: test( float x ); test(__attribute__((vector_size(16))) float v ); }; int vi = 0; void func() { test object(vi); } >clang -cc1 scalar.cpp scalar.cpp:13:7: error: call to constructor of 'test' is ambiguous test object(vi); ^ ~~ scalar.cpp:5:2: note: candidate constructor test( float x ); ^ scalar.cpp:6:2: note: candidate constructor test(__attribute__((vector_size(16))) float v ); ^ scalar.cpp:2:7: note: candidate is the implicit copy constructor class test ^ 1 error generated. Because casts of scalars to vectors should not be allowed, there should really only be one candidate function. Adding "explicit" to the vector constructor doesn't help either. This is probably the same issue, but just in case: class SimdReal { public: SimdReal(const __attribute__((vector_size(16))) float x); SimdReal(float x); }; class Vector4 { public: Vector4(const __attribute__((vector_size(16))) float q); }; void mul(const SimdReal& r); void mul(const Vector4& v); float vf = 0.0f; void func() { mul(vf); } >clang -cc1 consel.cpp consel.cpp:20:2: error: call to 'mul' is ambiguous mul(vf); ^~~ consel.cpp:13:6: note: candidate function void mul(const SimdReal& r); ^ consel.cpp:14:6: note: candidate function void mul(const Vector4& v); ^ 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 Thu May 6 10:48:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 10:48:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7071] New: Less-than-awesome warning about unreachable code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7071 Summary: Less-than-awesome warning about unreachable code Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: hv at crypt.org CC: llvmbugs at cs.uiuc.edu zen% cat clangtest3.c #define limited(type, value) type ? ((type * value <= 1) ? value : 1) : value unsigned int arena_value = limited(0, sizeof(int)); zen% clang -c -W clangtest3.c clangtest3.c:2:28: warning: comparison of 0 <= unsigned expression is always true [-Wsign-compare] unsigned int arena_value = limited(0, sizeof(int)); ^~~~~~~~~~~~~~~~~~~~~~~ clangtest3.c:1:52: note: instantiated from: #define limited(type, value) type ? ((type * value <= 1) ? value : 1) : value ^ ~ 1 warning generated. zen% (This is cut down from an example using FIT_ARENA() in the perl source code.) Note that if 'sizeof(int)' is replaced with a literal 4, this does not warn. While the warning is true, it is unuseful: it would in principle be possible to determine that due to the constant in the conditional, the complained-of code is not reached. Hugo -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 10:57:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 10:57:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 7072] New: Small crashing example: ()( Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7072 Summary: Small crashing example: ()( 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 Created an attachment (id=4846) --> (http://llvm.org/bugs/attachment.cgi?id=4846) tiny crashing example clang++ crashes on a file containing the three characters: ()( ()( ^ Assertion failed: (!IncludeMacroStack.empty() && "Ran out of stack entries to load"), function RemoveTopOfLexerStack, file PPLexerChange.cpp, line 286. 0 clang 0x00f57119 PrintStackTrace(void*) + 45 1 clang 0x00f57663 SignalHandler(int) + 374 2 libSystem.B.dylib 0x91cc842b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1848867839 4 libSystem.B.dylib 0x91d558e5 raise + 26 5 libSystem.B.dylib 0x91d6b99c abort + 93 6 libSystem.B.dylib 0x91d58544 __pthread_markcancel + 0 7 clang 0x00633430 clang::Preprocessor::RemoveTopOfLexerStack() + 94 8 clang 0x00629b2e clang::Preprocessor::ExitCachingLexMode() + 32 9 clang 0x006293cf clang::Preprocessor::CachingLex(clang::Token&) + 123 10 clang 0x00617390 clang::Preprocessor::Lex(clang::Token&) + 192 11 clang 0x005f44f5 clang::Parser::ConsumeParen() + 209 12 clang 0x00610f17 clang::Parser::SkipUntil(clang::tok::TokenKind const*, unsigned int, bool, bool) + 403 13 clang 0x00617548 clang::Parser::SkipUntil(clang::tok::TokenKind, bool, bool) + 60 14 clang 0x005d6d6b clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 193 15 clang 0x006124df clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 1001 16 clang 0x0061252c clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 66 17 clang 0x006142a4 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2222 18 clang 0x006143ea clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 268 19 clang 0x0023f3f1 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 426 20 clang 0x0006367f clang::ASTFrontendAction::ExecuteAction() + 269 21 clang 0x0006379c clang::FrontendAction::Execute() + 278 22 clang 0x00047427 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 23 clang 0x0002a11f cc1_main(char const**, char const**, char const*, void*) + 1979 24 clang 0x0002e039 main + 272 25 clang 0x00028e5d start + 53 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name t.cc -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmacro-backtrace-limit 6 -ftemplate-backtrace-limit 10 -fmessage-length 80 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-TT0otg.s -x c++ t.cc 1. t.cc:1:3: current parser token '(' clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 10:57:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 10:57:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7073] New: Tiny crashing example: ::( Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7073 Summary: Tiny crashing example: ::( 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 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 11:03:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 11:03:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 7074] New: Small crashing example Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7074 Summary: Small crashing example Product: clang Version: unspecified Platform: Other OS/Version: Linux 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 Created an attachment (id=4848) --> (http://llvm.org/bugs/attachment.cgi?id=4848) Tiny crashing testcase The code a(struct a::a crashes clang++ with: clang: Decl.cpp:1550: void clang::TagDecl::setQualifierInfo(clang::NestedNameSpecifier*, clang::SourceRange): Assertion `QualifierRange.isInvalid()' failed. 0 clang 0x00000000014a52a6 1 clang 0x00000000014a518d 2 libpthread.so.0 0x00007fa7816fe8f0 3 libc.so.6 0x00007fa7809eea75 gsignal + 53 4 libc.so.6 0x00007fa7809f25c0 abort + 384 5 libc.so.6 0x00007fa7809e7941 __assert_fail + 241 6 clang 0x00000000009b9ee9 7 clang 0x00000000006d9139 8 clang 0x0000000000a711c0 9 clang 0x0000000000a65a0a 10 clang 0x0000000000a6acea 11 clang 0x0000000000a6a31e 12 clang 0x0000000000a694e7 13 clang 0x0000000000a690ef 14 clang 0x0000000000a629f8 15 clang 0x0000000000a5d2ae 16 clang 0x0000000000a5d317 17 clang 0x0000000000a5cca6 18 clang 0x0000000000a5c57d 19 clang 0x00000000006914dc 20 clang 0x0000000000437558 21 clang 0x00000000004371c3 22 clang 0x00000000004213ef 23 clang 0x0000000000409172 24 clang 0x000000000040dcfe main + 259 25 libc.so.6 0x00007fa7809d9c4d __libc_start_main + 253 26 clang 0x0000000000407b49 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.bashed.24036.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 181 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-lNN2N6.s -x c++ t.bashed.24036.cc 1. parser at end of file clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 11:05:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 11:05:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 7075] New: Crashing example: struct{a():}}{ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7075 Summary: Crashing example: struct{a():}}{ Product: clang Version: unspecified Platform: Other OS/Version: Linux 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 Created an attachment (id=4849) --> (http://llvm.org/bugs/attachment.cgi?id=4849) Tiny crashing testcase clang++ crashes on: struct{a():}}{ caj at nyanko:~/fuzzed$ clang++ -c t.bashed.26786.cc t.bashed.26786.cc:1:8: error: C++ requires a type specifier for all declarations struct{a():}}{ ^ t.bashed.26786.cc:1:12: error: expected class member or base class name struct{a():}}{ ^ t.bashed.26786.cc:1:12: error: expected '{' or ',' t.bashed.26786.cc:1:11: error: only constructors take base initializers struct{a():}}{ ^ t.bashed.26786.cc:1:15: error: expected '}' struct{a():}}{ ^ clang: ParseCXXInlineMethods.cpp:237: void clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&): Assertion `!PP.getSourceManager().isBeforeInTranslationUnit(origLoc, Tok.getLocation()) && "We consumed more than the cached tokens!"' failed. 0 clang 0x00000000014a52a6 1 clang 0x00000000014a518d 2 libpthread.so.0 0x00007f868af558f0 3 libc.so.6 0x00007f868a245a75 gsignal + 53 4 libc.so.6 0x00007f868a2495c0 abort + 384 5 libc.so.6 0x00007f868a23e941 __assert_fail + 241 6 clang 0x0000000000a8d857 7 clang 0x0000000000a734cf 8 clang 0x0000000000a7136c 9 clang 0x0000000000a65a0a 10 clang 0x0000000000a5ced1 11 clang 0x0000000000a5d317 12 clang 0x0000000000a5cca6 13 clang 0x0000000000a5c57d 14 clang 0x00000000006914dc 15 clang 0x0000000000437558 16 clang 0x00000000004371c3 17 clang 0x00000000004213ef 18 clang 0x0000000000409172 19 clang 0x000000000040dcfe main + 259 20 libc.so.6 0x00007f868a230c4d __libc_start_main + 253 21 clang 0x0000000000407b49 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.bashed.26786.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 181 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Mer49r.s -x c++ t.bashed.26786.cc 1. parser at end of file 2. t.bashed.26786.cc:1:1: parsing struct/union/class body '' clang: error: compiler command failed due to signal 6 (use -v to see invocation) caj at nyanko:~/fuzzed$ cat t.c^C caj at nyanko:~/fuzzed$ cat t.bashed.26786.cc struct{a():}}{ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 12:26:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 12:26:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 7067] Destructor not invoked In-Reply-To: References: Message-ID: <20100506172621.D60B0312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7067 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-05-06 12:26:21 CDT --- Fixed in r103187. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 13:41:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 13:41:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 7076] New: extern "C" handled like "extern" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7076 Summary: extern "C" handled like "extern" Product: clang Version: trunk Platform: PC OS/Version: NetBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: m.drochner at fz-juelich.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The error message tells it all: version.cpp:3:24: error: 'extern' variable has an initializer extern "C" const char *Version_string = "1.19.2"; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 16:22:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 16:22:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 7077] New: Hang when optimizations enabled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7077 Summary: Hang when optimizations enabled Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: scoopr at iki.fi CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4852) --> (http://llvm.org/bugs/attachment.cgi?id=4852) testcase Attached testcase hangs in what seems to be LoopStrengthReduce (when attaching gdb) with -arch i386 and -O1 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 16:57:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 16:57:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7078] New: clang -ast-print output doesn't build Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7078 Summary: clang -ast-print output doesn't build Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alp at nuanti.com CC: llvmbugs at cs.uiuc.edu clang -ast-print output, with source code generated from the clang AST is a good marker of how close our AST is to the syntactic representation. As such, it'd be great to make sure the output can be parsed, build, and perhaps eventually be tested for token-equivalence to the input (rountripping AST). This could be important in refactoring consumers, for example. Right now, this happens (examples from system siginfo.h): Input: typedef union sigval { int sival_int; void *sival_ptr; } sigval_t; Output: union sigval { public: int sival_int; void *sival_ptr; }; typedef union sigval sigval_t; The above perhaps isn't so bad, but the current AST representation falls down completely in cases like this: Input: /* kill(). */ struct { __pid_t si_pid; /* Sending process ID. */ __uid_t si_uid; /* Real user ID of sending process. */ } _kill; Output: struct { public: __pid_t si_pid; __uid_t si_uid; }; struct siginfo:: _kill; First thoughts are that this might need changes to TypeDecl / TagDecl / RecordDecl and maybe TypedefDecl. Alternatively perhaps getTypedefForAnonDecl() provides enough information to stitch back the original representation and the AST doesn't need such a rework? Filed as 'enhancement'. Thoughts welcome. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 16:58:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 16:58:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7061] Website: CMake files also work with Linux In-Reply-To: References: Message-ID: <20100506215816.259063128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7061 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2010-05-06 16:58:15 CDT --- Ah, I didn't realize you were talking about the clang dox. Fixed in r103202, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 18:53:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 18:53:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 5685] clang: warning with function attribute sentinel In-Reply-To: References: Message-ID: <20100506235316.02B943128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5685 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from John McCall 2010-05-06 18:53:15 CDT --- Fixed in r103216. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 19:09:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 19:09:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 7079] New: Clang does not mark declarations used in non-dependent types as referenced Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7079 Summary: Clang does not mark declarations used in non-dependent types as referenced Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Blocks: 6023 When we're parsing a template, we don't "mark" declarations we reference as referenced, since we intend to do that when the template is instantiated. However, if those declarations are only referenced from a non-dependent type, we don't rebuild the type so we don't end up marking the declarations as referenced at instantiation time. The example below (distilled from the Boost concept-checking library) illustrates how one can use template arguments in a non-dependent type to trigger instantiation... but Clang doesn't do the instantiation. We have the same issue with non-dependent expressions used in default arguments; see http://llvm.org/bugs/show_bug.cgi?id=5810 . terfin:clang dgregor$ cat t.cpp template struct X1 { static void member() { T* x = 1; } }; template struct instantiate { }; template struct X2 { typedef instantiate<&X1::member> i; }; X2 x; terfin:clang dgregor$ clang++ -fsyntax-only t.cpp terfin:clang dgregor$ g++ -fsyntax-only t.cpp t.cpp: In static member function ?static void X1::member() [with T = int]?: t.cpp:3: instantiated from here t.cpp:3: error: invalid conversion from ?int? to ?int*? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 19:18:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 19:18:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 7080] New: Failure in is_convertible implementation in boost Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7080 Summary: Failure in is_convertible implementation in boost Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code shows a reduced example of the is_convertible implementation used in boost for the implementation of rvalue references. This code compiles in g++ but doesn't compile in clang++. template class is_convertible { typedef char true_t; class false_t { char dummy[2]; }; static true_t dispatch(U); static false_t dispatch(...); static T trigger(); public: enum { value = sizeof(dispatch(trigger())) == sizeof(true_t) }; }; template class rv : public T { }; int main(void) { is_convertible&>::value; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 6 19:20:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 19:20:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 7081] New: Assertion "Stack not empty at end of basic block?" when using target_cpu=i486 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7081 Summary: Assertion "Stack not empty at end of basic block?" when using target_cpu=i486 Product: tools Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu While compiling a file from the ntp component of FreeBSD using clang r103176, I ended up with the following assertion: Assertion failed: (isStackEmpty() && "Stack not empty at end of basic block?"), function processBasicBlock, file X86FloatingPoint.cpp, line 300. Stack dump: 0. Program arguments: /home/dim/llvm/103176-gcc-dbg-1/bin/clang -cc1 -triple i386-undermydesk-freebsd9.0 -S -disable-free -main-file-name ntp_proto.i -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu i486 -resource-dir /usr/obj/home/dim/src/clangbsd/tmp/usr/lib/clang/2.0 -O2 -Wno-pointer-sign -std=gnu99 -ferror-limit 19 -fmessage-length 254 -fheinous-gnu-extensions -stack-protector 1 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -x cpp-output ntp_proto.i 1. parser at end of file 2. Code generation 3. Running pass 'X86 FP Stackifier' on function '@clock_filter' This is because the clang imported in FreeBSD uses 'i486' as its default target CPU, not 'pentium4', which is the clang default. When clang passes -mcpu=pentium4 to llc, it generates SSE instructions, but when -mcpu=i486 is used instead, it apparently uses 'old-school' FP instructions. The reduced testcase in C is this: extern signed char sys_precision; void clock_filter(void) { double dst[8]; int ord[8]; int i, j, k, m; double dtemp, etemp; for (i = 1; i < 8; i++) { for (j = 0; j < i; j++) { if (dst[j] > dst[i] + ((sys_precision) < 0 ? 1. / (1L << -(sys_precision)) : 1L << (int)(sys_precision))) { k = ord[j]; ord[j] = ord[i]; ord[i] = k; etemp = dst[j]; dst[j] = dst[i]; dst[i] = etemp; } } } } compiling this with: clang -cc1 -target-cpu i486 -O2 -emit-llvm ntp_proto.i -o - | \ llc -mcpu=i486 will fire the assertion. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 19:29:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 19:29:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 7080] Failure in is_convertible implementation in boost In-Reply-To: References: Message-ID: <20100507002927.8E9703128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7080 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-06 19:29:27 CDT --- Fixed in r103220. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 20:20:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 20:20:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 4262] llvm-gcc should generate available_externally function bodies etc In-Reply-To: References: Message-ID: <20100507012047.5E21F3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4262 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |dalej at apple.com Resolution| |FIXED --- Comment #7 from Dale Johannesen 2010-05-06 20:20:46 CDT --- Fixed here. http://llvm.org/viewvc/llvm-project?rev=103229&view=rev Testcases fixed here (all behavior matches gcc-4.2) http://llvm.org/viewvc/llvm-project?rev=103230&view=rev -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 20:45:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 20:45:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 6520] [inline asm] early clobber + forced register + -O0 == wrong register allocation In-Reply-To: References: Message-ID: <20100507014558.281F03128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6520 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |nlewycky at google.com Resolution|FIXED | --- Comment #3 from Nick Lewycky 2010-05-06 20:45:57 CDT --- I reverted this patch when it caused bug 7066. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 6 20:47:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 May 2010 20:47:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 7066] local register allocator fails on inline asm In-Reply-To: References: Message-ID: <20100507014709.AA8413128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7066 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Nick Lewycky 2010-05-06 20:47:09 CDT --- Sorry Jakob, but this is blocking clang builds of all programs at Google at -O0. I've reverted your patch, added the testcase, and reopened bug 6520. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 02:02:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 02:02:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7082] New: No warning/error for matching class and member variable/function names. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7082 Summary: No warning/error for matching class and member variable/function names. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alex55miller+bug at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4857) --> (http://llvm.org/bugs/attachment.cgi?id=4857) Test case. Overview: Both MSVC (http://msdn.microsoft.com/en-us/library/2bcktt82) and GCC do not allow for a member variable/function of a class to have the same name as the class. Clang (both 2.7 and compiled from SVN r101755) will compile the attached test case with no warning or error and the program runs as expected. I am not a standards guru, so I am not sure if this is in the standard or not. Steps to Reproduce: 1) Run clang on test.cpp. Actual Results: No warnings/errors, and a fully working executable. Expected Results: A warning or error (like gcc's "test.cpp:9: error: field 'int C::C' with same name as class") Build Date & Platform: >From r101755: clang version 1.5 (trunk 101758) Target: x86_64-unknown-linux-gnu Thread model: posix llvm version 2.8svn DEBUG build with assertions. Built Apr 18 2010 (20:04:13). Host: x86_64-unknown-linux-gnu Host CPU: penryn and from 2.7: clang version 1.1 (branches/release_27) Target: x86_64-pc-linux-gnu Thread model: posix llvm version 2.8svn DEBUG build with assertions. Built Apr 18 2010 (20:04:13). Host: x86_64-unknown-linux-gnu Host CPU: penryn -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 02:50:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 02:50:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 6872] BASH 4.1 fails to compile using self hosted clang (r101748) In-Reply-To: References: Message-ID: <20100507075001.50EB23128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6872 Diego Iastrubni changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |FIXED --- Comment #3 from Diego Iastrubni 2010-05-07 02:50:00 CDT --- as of r103193, 3rd stage is working, and even compiles a working bash. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 03:30:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 03:30:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 6442] Assertion failed: (Tok.is(tok::l_brace)) In-Reply-To: References: Message-ID: <20100507083057.60CFB3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6442 Sebastian Redl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WORKSFORME --- Comment #4 from Sebastian Redl 2010-05-07 03:30:56 CDT --- Can't reproduce the assertion, though. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 7 04:06:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 04:06:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 7083] New: Many PIC16 "make check" failures when building with --enable-expensive-checks Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7083 Summary: Many PIC16 "make check" failures when building with --enable-expensive-checks Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu It looks like there may be just one underlying bug: Running /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/dg.exp ... FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/2009-07-17-PR4566-pic16.ll Failed with signal(SIGABRT) at line 1 while running: llc < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/2009-07-17-PR4566-pic16.ll -march=pic16 | FileCheck /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/2009-07-17-PR4566-pic16.ll /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7fff10ffe590 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7fff10ffe590 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002b6ad801caf0 3 libc.so.6 0x00002b6ad801ca75 gsignal + 53 4 libc.so.6 0x00002b6ad80205c0 abort + 384 5 libstdc++.so.6 0x00002b6ad78b0454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002b6ad8022262 exit + 226 9 libc.so.6 0x00002b6ad8007c54 __libc_start_main + 260 10 llc 0x0000000000de3639 FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/2009-11-20-NewNode.ll for PR5558 Failed with signal(SIGABRT) at line 1 while running: llc -march=pic16 < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/2009-11-20-NewNode.ll #include p16f1xxx.inc #include stdmacros.inc ; Function Declarations - BEGIN global @_strtoll_r global @_strtoll_r.ret. global @_strtoll_r.args. extern @abort extern @abort.ret. extern @abort.args. ; Function Declarations - END @_strtoll_r.frame_section.# UDATA_OVR @_strtoll_r.frame.: @_strtoll_r.ret. RES 8 @_strtoll_r.args. RES 2 @_strtoll_r.temp. RES 8 @_strtoll_r.code_section.# CODE retlw low(@_strtoll_r.frame.) retlw high(@_strtoll_r.frame.) @_strtoll_r: banksel @_strtoll_r.args. movf @_strtoll_r.args. + 0, W movwf @_strtoll_r.temp. + 3 movlw -128 movwf @_strtoll_r.temp. + 4 movf @_strtoll_r.args. + 1, W movwf @_strtoll_r.temp. + 5 movf @_strtoll_r.temp. + 4, W movwf @_strtoll_r.temp. + 0 subwf @_strtoll_r.temp. + 0, W bne .BB0_1 .BB0_1: ; %if.end27 banksel @_strtoll_r.temp. movf @_strtoll_r.temp. + 5, W banksel @.lib.sra.i8.args. movwf @.lib.sra.i8.args. + 0 movlw 7 movwf @.lib.sra.i8.args. + 1 movlp @.lib.sra.i8 call @.lib.sra.i8 banksel @.lib.sra.i8.ret. movf @.lib.sra.i8.ret. + 0, W banksel @_strtoll_r.temp. movwf @_strtoll_r.temp. + 6 movf @_strtoll_r.temp. + 4, W movwf @_strtoll_r.temp. + 1 movlw 0 movwf @_strtoll_r.temp. + 7 sublw -128 movlp $ bne .BB0_3 ; BB#2: ; %if.end27 movlw -1 banksel @_strtoll_r.temp. movwf @_strtoll_r.temp. + 7 .BB0_3: ; %if.end27 banksel @_strtoll_r.temp. subwf @_strtoll_r.temp. + 1, W bne .BB0_5 ; BB#4: ; %if.end27 movlw 127 banksel @_strtoll_r.temp. movwf @_strtoll_r.temp. + 4 .BB0_5: ; %if.end27 banksel @_strtoll_r.temp. movf @_strtoll_r.temp. + 7, W banksel @__udivdi3.args. movwf @__udivdi3.args. + 0 movwf @__udivdi3.args. + 1 movwf @__udivdi3.args. + 2 movwf @__udivdi3.args. + 3 movwf @__udivdi3.args. + 4 movwf @__udivdi3.args. + 5 movwf @__udivdi3.args. + 6 banksel @_strtoll_r.temp. movf @_strtoll_r.temp. + 4, W banksel @__udivdi3.args. movwf @__udivdi3.args. + 7 banksel @_strtoll_r.temp. movf @_strtoll_r.temp. + 3, W banksel @__udivdi3.args. movwf @__udivdi3.args. + 8 banksel @_strtoll_r.temp. movf @_strtoll_r.temp. + 5, W banksel @__udivdi3.args. movwf @__udivdi3.args. + 9 banksel @_strtoll_r.temp. movf @_strtoll_r.temp. + 6, W banksel @__udivdi3.args. movwf @__udivdi3.args. + 10 movwf @__udivdi3.args. + 11 movwf @__udivdi3.args. + 12 movwf @__udivdi3.args. + 13 movwf @__udivdi3.args. + 14 movwf @__udivdi3.args. + 15 movlp __udivdi3 call __udivdi3 banksel @__udivdi3.ret. movf @__udivdi3.ret. + 0, W movf @__udivdi3.ret. + 1, W movf @__udivdi3.ret. + 2, W movf @__udivdi3.ret. + 3, W movf @__udivdi3.ret. + 4, W movf @__udivdi3.ret. + 5, W movf @__udivdi3.ret. + 6, W movf @__udivdi3.ret. + 7, W movlp $ ; BB#6: ; %if.then152 movlw -128 banksel @_strtoll_r.temp. movwf @_strtoll_r.temp. + 2 subwf @_strtoll_r.temp. + 2, W bne .BB0_7 .BB0_7: ; %if.end182 banksel @_strtoll_r.temp. movf @_strtoll_r.temp. + 7, W movwf @_strtoll_r.frame. + 0 movwf @_strtoll_r.frame. + 1 movwf @_strtoll_r.frame. + 2 movwf @_strtoll_r.frame. + 3 movwf @_strtoll_r.frame. + 4 movwf @_strtoll_r.frame. + 5 movwf @_strtoll_r.frame. + 6 movf @_strtoll_r.temp. + 4, W movwf @_strtoll_r.frame. + 7 return ; External decls for libcalls - BEGIN extern @.lib.sra.i8 extern @.lib.sra.i8.args. extern @.lib.sra.i8.ret. ; External decls for libcalls - END END /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7fff67385b40 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7fff67385b40 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002b68513a2af0 3 libc.so.6 0x00002b68513a2a75 gsignal + 53 4 libc.so.6 0x00002b68513a65c0 abort + 384 5 libstdc++.so.6 0x00002b6850c36454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002b68513a8262 exit + 226 9 libc.so.6 0x00002b685138dc54 __libc_start_main + 260 10 llc 0x0000000000de3639 FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/C16-15.ll Failed with signal(SIGABRT) at line 1 while running: llc < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/C16-15.ll -march=pic16 | /bin/grep "extern" | /bin/grep "@.lib.unordered.f32" | count 3 /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7fff67d1b8e0 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7fff67d1b8e0 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002b4e9f90daf0 3 libc.so.6 0x00002b4e9f90da75 gsignal + 53 4 libc.so.6 0x00002b4e9f9115c0 abort + 384 5 libstdc++.so.6 0x00002b4e9f1a1454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002b4e9f913262 exit + 226 9 libc.so.6 0x00002b4e9f8f8c54 __libc_start_main + 260 10 llc 0x0000000000de3639 FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/C16-49.ll Failed with signal(SIGABRT) at line 1 while running: llvm-as < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/C16-49.ll | llc -march=pic16 #include p16f1xxx.inc #include stdmacros.inc ; Function Declarations - BEGIN global @foo global @foo.ret. global @foo.args. extern @abort extern @abort.ret. extern @abort.args. ; Function Declarations - END ; Imported Variables - BEGIN extern @PORTD ; Imported Variables - END ; Exported Variables - BEGIN global @aa global @bb ; Exported Variables - END @idata.0.# IDATA @aa dw 55 ; 0x37 @bb dw 44 ; 0x2c @foo.frame_section.# UDATA_OVR @foo.frame.: @foo.ret.: @foo.args. RES 0 @foo.temp. RES 1 @foo.code_section.# CODE retlw low(@foo.frame.) retlw high(@foo.frame.) @foo: banksel @aa movf @aa + 0, W banksel @foo.temp. movwf @foo.temp. + 0 banksel @bb movf @bb + 0, W banksel @foo.temp. subwf @foo.temp. + 0, W banksel @PORTD movwf @PORTD + 0 return END /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7fffbc9fa1c0 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7fffbc9fa1c0 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002ae4bae1faf0 3 libc.so.6 0x00002ae4bae1fa75 gsignal + 53 4 libc.so.6 0x00002ae4bae235c0 abort + 384 5 libstdc++.so.6 0x00002ae4ba6b3454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002ae4bae25262 exit + 226 9 libc.so.6 0x00002ae4bae0ac54 __libc_start_main + 260 10 llc 0x0000000000de3639 FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/check_inc_files.ll Failed with signal(SIGABRT) at line 1 while running: llvm-as < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/check_inc_files.ll | llc -march=pic16 | FileCheck /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/check_inc_files.ll /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7ffff6a1aea0 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7ffff6a1aea0 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002b4ea2ce5af0 3 libc.so.6 0x00002b4ea2ce5a75 gsignal + 53 4 libc.so.6 0x00002b4ea2ce95c0 abort + 384 5 libstdc++.so.6 0x00002b4ea2579454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002b4ea2ceb262 exit + 226 9 libc.so.6 0x00002b4ea2cd0c54 __libc_start_main + 260 10 llc 0x0000000000de3639 FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/global-in-user-section.ll Failed with signal(SIGABRT) at line 1 while running: llc < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/global-in-user-section.ll -march=pic16 | FileCheck /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/global-in-user-section.ll /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7fff0ab9e8d0 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7fff0ab9e8d0 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002b84672f6af0 3 libc.so.6 0x00002b84672f6a75 gsignal + 53 4 libc.so.6 0x00002b84672fa5c0 abort + 384 5 libstdc++.so.6 0x00002b8466b8a454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002b84672fc262 exit + 226 9 libc.so.6 0x00002b84672e1c54 __libc_start_main + 260 10 llc 0x0000000000de3639 FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/globals.ll Failed with signal(SIGABRT) at line 1 while running: llc < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/globals.ll -march=pic16 | FileCheck /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/globals.ll /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7fffbc87ec80 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7fffbc87ec80 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002ad469565af0 3 libc.so.6 0x00002ad469565a75 gsignal + 53 4 libc.so.6 0x00002ad4695695c0 abort + 384 5 libstdc++.so.6 0x00002ad468df9454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002ad46956b262 exit + 226 9 libc.so.6 0x00002ad469550c54 __libc_start_main + 260 10 llc 0x0000000000de3639 FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/result_direction.ll Failed with signal(SIGABRT) at line 1 while running: llvm-as < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/result_direction.ll | llc -march=pic16 | FileCheck /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/result_direction.ll /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7fff053ce480 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7fff053ce480 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002ae470509af0 3 libc.so.6 0x00002ae470509a75 gsignal + 53 4 libc.so.6 0x00002ae47050d5c0 abort + 384 5 libstdc++.so.6 0x00002ae46fd9d454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002ae47050f262 exit + 226 9 libc.so.6 0x00002ae4704f4c54 __libc_start_main + 260 10 llc 0x0000000000de3639 FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/sext.ll Failed with signal(SIGABRT) at line 1 while running: llc < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/sext.ll -march=pic16 #include p16f1xxx.inc #include stdmacros.inc ; Function Declarations - BEGIN global @main global @main.ret. global @main.args. extern @abort extern @abort.ret. extern @abort.args. ; Function Declarations - END @main.frame_section.# UDATA_OVR @main.frame.: @main.ret. RES 2 @main.args. RES 0 @main.temp. RES 2 @main.code_section.# CODE retlw low(@main.frame.) retlw high(@main.frame.) @main: banksel @main.auto.c movf @main.auto.c + 0, W banksel @main.temp. movwf @main.temp. + 0 banksel @.lib.sra.i8.args. movwf @.lib.sra.i8.args. + 0 movlw 7 movwf @.lib.sra.i8.args. + 1 movlp @.lib.sra.i8 call @.lib.sra.i8 banksel @.lib.sra.i8.ret. movf @.lib.sra.i8.ret. + 0, W banksel @main.temp. movwf @main.temp. + 1 movf @main.temp. + 0, W movwf @main.frame. + 0 movf @main.temp. + 1, W movwf @main.frame. + 1 return @main.autos_section.# UDATA_OVR @main.auto.c RES 1 ; External decls for libcalls - BEGIN extern @.lib.sra.i8 extern @.lib.sra.i8.args. extern @.lib.sra.i8.ret. ; External decls for libcalls - END END /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7fff0b1455d0 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7fff0b1455d0 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002ba4654ffaf0 3 libc.so.6 0x00002ba4654ffa75 gsignal + 53 4 libc.so.6 0x00002ba4655035c0 abort + 384 5 libstdc++.so.6 0x00002ba464d93454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002ba465505262 exit + 226 9 libc.so.6 0x00002ba4654eac54 __libc_start_main + 260 10 llc 0x0000000000de3639 FAIL: /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/test_indf_name.ll Failed with signal(SIGABRT) at line 1 while running: llvm-as < /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/test_indf_name.ll | llc -march=pic16 | FileCheck /home/duncan/LLVM/llvm.top/llvm/test/CodeGen/PIC16/test_indf_name.ll /usr/local/gcc-4.5/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../include/c++/4.5.1/debug/safe_iterator.h:252: error: attempt to decrement a dereferenceable (start-of-sequence) iterator. Objects involved in the operation: iterator "this" @ 0x0x7fff7a95d730 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPcNSt6__norm6vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIPcSaIS1_EEE' @ 0x0x7fff7a95d730 } 0 llc 0x00000000018f0425 1 llc 0x00000000018f030c 2 libc.so.6 0x00002b7603375af0 3 libc.so.6 0x00002b7603375a75 gsignal + 53 4 libc.so.6 0x00002b76033795c0 abort + 384 5 libstdc++.so.6 0x00002b7602c09454 __gnu_debug::_Error_formatter::_M_error() const + 356 6 llc 0x0000000000f5c178 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >::operator--(int) + 130 7 llc 0x0000000000f5aa87 llvm::ESNames::~ESNames() + 159 8 libc.so.6 0x00002b760337b262 exit + 226 9 libc.so.6 0x00002b7603360c54 __libc_start_main + 260 10 llc 0x0000000000de3639 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 04:25:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 04:25:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 6466] Assertion failed: (BaseType->isPointerType()) In-Reply-To: References: Message-ID: <20100507092553.5A4C93128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6466 Sebastian Redl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 7 05:34:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 05:34:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7084] New: Incompatible functions in declarative region not being checked for overload compatibility Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7084 Summary: Incompatible functions in declarative region not being checked for overload compatibility Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub-johannes at web.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I think clang should diagnose the following: struct string { }; void f() { string g(); g(); } void g() { } // diagnostic expected here int main() { f(); } Currently it generates code that segfaults at runtime for me. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 7 05:47:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 05:47:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 7085] New: is_convertible miscompile in boost Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7085 Summary: is_convertible miscompile in boost 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 Created an attachment (id=4859) --> (http://llvm.org/bugs/attachment.cgi?id=4859) convertible testcase The attached code is reduced from how boost::shared_ptr implements is_convertible. This code does not correctly deal with converting between 'int' to 'int const', and therefore fails to compile. Both g++ and comeau accept the code as shown. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 09:22:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 09:22:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 7087] New: __builtin_powil failure Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7087 Summary: __builtin_powil failure 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 Created an attachment (id=4860) --> (http://llvm.org/bugs/attachment.cgi?id=4860) crashing example using builtin __builtin_powil The attached code causes an assertion in clang++. This bug is reduced from libs/config/test/math_info.cpp in boost. The resulting testcase is itself valid C The original version of this problem required at least -O2 to trigger, this one does not. ~$ cd ~/Dropbox ~/Dropbox$ clang++ -c pow.cc Assertion failed: (semantics == rhs.semantics), function divideSignificand, file APFloat.cpp, line 969. 0 clang 0x00f57119 PrintStackTrace(void*) + 45 1 clang 0x00f57663 SignalHandler(int) + 374 2 libSystem.B.dylib 0x9008942b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1878486015 4 libSystem.B.dylib 0x901168e5 raise + 26 5 libSystem.B.dylib 0x9012c99c abort + 93 6 libSystem.B.dylib 0x90119544 __pthread_markcancel + 0 7 clang 0x00f0e41b llvm::APFloat::divideSignificand(llvm::APFloat const&) + 77 8 clang 0x00f0f5d7 llvm::APFloat::divide(llvm::APFloat const&, llvm::APFloat::roundingMode) + 131 9 clang 0x00a4f9d9 llvm::SelectionDAG::getNode(unsigned int, llvm::DebugLoc, llvm::EVT, llvm::SDValue, llvm::SDValue) + 8467 10 clang 0x00a68221 ExpandPowI(llvm::DebugLoc, llvm::SDValue, llvm::SDValue, llvm::SelectionDAG&) + 669 11 clang 0x00a7d82b llvm::SelectionDAGBuilder::visitIntrinsicCall(llvm::CallInst const&, unsigned int) + 11289 12 clang 0x00a7f501 llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 231 13 clang 0x00a6c26a llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) + 1330 14 clang 0x00a89d37 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 111 15 clang 0x00aa0949 llvm::SelectionDAGISel::SelectBasicBlock(llvm::MachineBasicBlock*, llvm::BasicBlock const*, llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 45 16 clang 0x00aa0d71 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 895 17 clang 0x00aa11f2 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 668 18 clang 0x00b6f3bb llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 77 19 clang 0x00ecddc5 llvm::FPPassManager::runOnFunction(llvm::Function&) + 287 20 clang 0x00ecf2d8 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 80 21 clang 0x00ecf4cd llvm::FunctionPassManager::run(llvm::Function&) + 171 22 clang 0x000442af (anonymous namespace)::BackendConsumer::EmitAssembly() + 811 23 clang 0x000443ad (anonymous namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 151 24 clang 0x0023f4e8 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 673 25 clang 0x0006367f clang::ASTFrontendAction::ExecuteAction() + 269 26 clang 0x0006379c clang::FrontendAction::Execute() + 278 27 clang 0x00047427 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 879 28 clang 0x0002a11f cc1_main(char const**, char const**, char const*, void*) + 1979 29 clang 0x0002e039 main + 272 30 clang 0x00028e5d start + 53 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -S -disable-free -main-file-name pow.cc -pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmacro-backtrace-limit 6 -ftemplate-backtrace-limit 10 -fmessage-length 102 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-ceIyqj.s -x c++ pow.cc 1. parser at end of file 2. Code generation 3. Running pass 'X86 DAG->DAG Instruction Selection' on function '@main' clang: error: compiler command failed due to signal 6 (use -v to see invocation) ~/Dropbox$ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 09:43:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 09:43:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 7088] New: Instantiation of anonymous union in function template crashes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7088 Summary: Instantiation of anonymous union in function template crashes Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub-johannes at web.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com template void f() { union { int a; } } template void f(); clang: /home/js/svn/llvm/tools/clang/lib/Sema/SemaTemplateInstantiate.cpp:1603: clang::Decl* clang::Sema::LocalInstantiationScope::getInstantiationOf(const clang::Decl*): Assertion `D->isInvalidDecl() && "declaration was not instantiated in this scope!"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 7 10:08:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 10:08:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7089] New: Problem matching in member functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7089 Summary: Problem matching in member functions Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4861) --> (http://llvm.org/bugs/attachment.cgi?id=4861) Example code if template matching issue In the following piece of code, the call to g(*t) compiles fine, whereas the call to r.f(*t) fails to compile. Comeau and g++ compile both fine. template struct pair { template pair( pair<_U1, _U2> ) { } }; template struct basic_string; struct _Rb_tree { int f( const pair, int>& ); }; int g( const pair, int>& ); void foo() { pair* t; _Rb_tree r; r.f(*t); // This line fails to compile. g(*t); // This line compiles fine. } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 10:25:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 10:25:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 4386] Constant evaluation doesn't handle converting the address of a weak global to a boolean correctly In-Reply-To: References: Message-ID: <20100507152543.7F7DD3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4386 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Rafael ?vila de Esp?ndola 2010-05-07 10:25:43 CDT --- Fixed in r103253. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 11:02:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 11:02:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 7090] New: llvm-ld -native and llvm-ld -native-cbe cause llc error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7090 Summary: llvm-ld -native and llvm-ld -native-cbe cause llc error Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: kevin.fan at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4862) --> (http://llvm.org/bugs/attachment.cgi?id=4862) patch: don't pass -f to llc llvm-ld -native and llvm-ld -native-cbe don't work because they pass the -f flag to llc. llc no longer accepts this flag. Attached patch should fix it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 7 11:09:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 11:09:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7091] New: Assertion `I != E && "Did not find a destructor! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7091 Summary: Assertion `I != E && "Did not find a destructor! 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 Created an attachment (id=4863) --> (http://llvm.org/bugs/attachment.cgi?id=4863) Example showing destructor problem. The attached test, reduced from a boost test case run at -O2 (but this reduced test does not need optimisation) causes clang++ to assert. This bug was found on x86_64-unknown-linux-gnu. caj at nyanko:/dev/shm/clang-usagecpp$ clang++ -c /home/caj/Dropbox/destructor.cpp clang: DeclCXX.cpp:578: clang::CXXDestructorDecl* clang::CXXRecordDecl::getDestructor(clang::ASTContext&) const: Assertion `I != E && "Did not find a destructor!"' failed. 0 clang 0x00000000014a5806 1 clang 0x00000000014a56ed 2 libpthread.so.0 0x00007fc2d1ebf8f0 3 libc.so.6 0x00007fc2d11afa75 gsignal + 53 4 libc.so.6 0x00007fc2d11b35c0 abort + 384 5 libc.so.6 0x00007fc2d11a8941 __assert_fail + 241 6 clang 0x00000000009c83ec 7 clang 0x000000000077808b 8 clang 0x00000000006d3ffe 9 clang 0x000000000082576a 10 clang 0x000000000082d919 11 clang 0x000000000082a116 12 clang 0x00000000007f43e7 13 clang 0x00000000008022c9 14 clang 0x00000000007f91c5 15 clang 0x0000000000816781 16 clang 0x000000000080218d 17 clang 0x00000000007f90f7 18 clang 0x00000000007f75da 19 clang 0x000000000082b6b2 20 clang 0x000000000082d438 21 clang 0x000000000069403a 22 clang 0x0000000000a5d9eb 23 clang 0x0000000000691bc4 24 clang 0x0000000000437580 25 clang 0x00000000004371eb 26 clang 0x0000000000421417 27 clang 0x0000000000409172 28 clang 0x000000000040dcfe main + 259 29 libc.so.6 0x00007fc2d119ac4d __libc_start_main + 253 30 clang 0x0000000000407b49 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name destructor.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 194 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-QAsF99.s -x c++ /home/caj/Dropbox/destructor.cpp 1. parser at end of file 2. /home/caj/Dropbox/destructor.cpp:11:3: instantiating function definition 'basic_parameter >::basic_parameter' clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 7 11:27:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 11:27:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 7090] llvm-ld -native and llvm-ld -native-cbe cause llc error In-Reply-To: References: Message-ID: <20100507162715.280783128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7090 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2010-05-07 11:27:14 CDT --- Thanks, applied in r103263! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 12:09:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 12:09:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 7092] New: [patch] Makes Module::getOrInsertFunction accept va_args in addition to ellipsis Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7092 Summary: [patch] Makes Module::getOrInsertFunction accept va_args in addition to ellipsis Product: compiler-rt Version: unspecified Platform: PC OS/Version: FreeBSD Status: NEW Severity: enhancement Priority: P Component: compiler-rt AssignedTo: unassignedbugs at nondot.org ReportedBy: yuri at tsoft.com CC: llvmbugs at cs.uiuc.edu getOrInsertFunction gets it's vgetOrInsertFunction counterpart, just like sprintf has vsprintf in C library. This makes it easier for user to wrap this function. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 7 14:50:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 14:50:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7093] New: configure script keys should be sufficient to build in Debug mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7093 Summary: configure script keys should be sufficient to build in Debug mode Product: Build scripts Version: 2.7 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: yuri at tsoft.com CC: llvmbugs at cs.uiuc.edu In 2.7 to enable Debug build I need: 1. run configure with --enable-debug-runtime --enable-debug-symbols 2. run gmake with OPTIMIZE_OPTION="-O0 -g" ENABLE_OPTIMIZED=0 configure options should be enough to determine build type. --enable-debug-runtime --enable-debug-symbols should automatically pass OPTIMIZE_OPTION="-O0 -g" ENABLE_OPTIMIZED=0 to gmake. And if there is the need to override, gmake can be explicitly passed those options. Today's situation when I have to pass options to both configure and gmake is very confusing. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 15:01:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 15:01:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 7094] New: Warns "this partial specialization will never be used", but still (correctly) uses it. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7094 Summary: Warns "this partial specialization will never be used", but still (correctly) uses it. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub-johannes at web.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang wrongfully warns about the following "check" partial specialization // cut struct X { template struct Y { }; }; template struct A { }; template struct hasit { template struct check { }; /* notice: X is known here, doesn't need deduction! */ template struct check< typename X::template Y > { typedef void does; typedef T arg1_type; }; }; template struct A< X, T, typename hasit::template check::does > { typedef int Type; }; A >::Type t; // cut It compiles and links fine. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 16:19:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 16:19:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 6052] DIDescriptor (etc) constructors don't take const arguments In-Reply-To: References: Message-ID: <20100507211923.A3A45312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6052 devang.patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |devang.patel at gmail.com Resolution| |FIXED --- Comment #1 from devang.patel 2010-05-07 16:19:23 CDT --- Fixed. r103295. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 16:37:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 16:37:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 7087] __builtin_powil failure In-Reply-To: References: Message-ID: <20100507213743.E0B423128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7087 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Dale Johannesen 2010-05-07 16:37:43 CDT --- Fixed. http://llvm.org/viewvc/llvm-project?rev=103299&view=rev Note llvm-gcc doesn't exhibit this bug because this call to builtin_powil is resolved by the gcc FE. I found no way to disable this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 7 17:30:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 17:30:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7095] New: Error: Ambiguous user-defined conversion sequence Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7095 Summary: Error: Ambiguous user-defined conversion sequence Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com terfin:clang dgregor$ cat t3.cpp struct X { }; struct Y { operator const X*(); operator X*(); }; void f(const X *); void g(Y y) { f(y); } terfin:clang dgregor$ clang++ t3.cpp t3.cpp:9:17: error: conversion from 'Y' to 'X const *' is ambiguous void g(Y y) { f(y); } ^ t3.cpp:4:3: note: candidate function operator const X*(); ^ t3.cpp:5:3: note: candidate function operator X*(); ^ t3.cpp:8:17: note: passing argument to parameter here void f(const X *); ^ 1 error generated. terfin:clang dgregor$ g++ -fsyntax-only t3.cpp terfin:clang dgregor$ eccp t3.cpp terfin:clang dgregor Revert commit r103312 when this is fixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 7 18:12:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 18:12:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 7079] Clang does not mark declarations used in non-dependent types as referenced In-Reply-To: References: Message-ID: <20100507231243.645AB3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7079 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-07 18:12:43 CDT --- Fixed in r103323 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 19:04:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 19:04:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7077] LSR Hang when optimizations enabled In-Reply-To: References: Message-ID: <20100508000451.05DD83128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7077 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Dan Gohman 2010-05-07 19:04:50 CDT --- This is fixed in r103328. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 7 22:46:13 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 May 2010 22:46:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 7096] New: Compiler crash while compiling guile Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7096 Summary: Compiler crash while compiling guile Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping.elias at gmail.com CC: llvmbugs at cs.uiuc.edu I've spent an enormous amount of time trying to reduce this to something even remotely resembling a minimal test case and I've failed miserably. So I'm afraid this is the best example I can come up with. pipping at bogus ~/Downloads $ clang --version clang version 2.0 (trunk 103331) Target: x86_64-pc-linux-gnu Thread model: posix pipping at bogus ~/Downloads $ tar xf guile-1.9.10.tar.gz pipping at bogus ~/Downloads $ cd guile-1.9.10/ pipping at bogus ~/Downloads/guile-1.9.10 $ ./configure CC=clang >/dev/null pipping at bogus ~/Downloads/guile-1.9.10 $ cd libguile/ pipping at bogus ~/Downloads/guile-1.9.10/libguile $ make -s version.h vm-i-{loader,scheme,system}.i pipping at bogus ~/Downloads/guile-1.9.10/libguile $ make -s vm.x libtool: link: clang -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -fvisibility=hidden -g -O2 -o gen-scmconfig gen-scmconfig.o -lgc -lunistring -lcrypt -lm -lltdl pipping at bogus ~/Downloads/guile-1.9.10/libguile $ make vm.o clang -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/usr/lib64/libffi-3.0.9/include -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -fvisibility=hidden -g -O2 -MT vm.o -MD -MP -MF .deps/vm.Tpo -c -o vm.o vm.c 0 libLLVM-2.8svn.so 0x00002abde4ff728f 1 libLLVM-2.8svn.so 0x00002abde4ff7779 2 libpthread.so.0 0x00002abde57b5c50 3 libLLVM-2.8svn.so 0x00002abde4b12824 llvm::SSAUpdaterImpl::CheckIfPHIMatches(llvm::MachineInstr*) + 244 4 libLLVM-2.8svn.so 0x00002abde4b12022 llvm::SSAUpdaterImpl::FindAvailableVals(llvm::SmallVectorImpl::BBInfo*>*) + 162 5 libLLVM-2.8svn.so 0x00002abde4b1164a llvm::SSAUpdaterImpl::GetValue(llvm::MachineBasicBlock*) + 314 6 libLLVM-2.8svn.so 0x00002abde4b10a1a llvm::MachineSSAUpdater::GetValueAtEndOfBlockInternal(llvm::MachineBasicBlock*) + 186 7 libLLVM-2.8svn.so 0x00002abde4b11348 llvm::MachineSSAUpdater::RewriteUse(llvm::MachineOperand&) + 200 8 libLLVM-2.8svn.so 0x00002abde4b916a1 9 libLLVM-2.8svn.so 0x00002abde4afae2d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 61 10 libLLVM-2.8svn.so 0x00002abde4c4f577 llvm::FPPassManager::runOnFunction(llvm::Function&) + 375 11 libLLVM-2.8svn.so 0x00002abde4c4ed99 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 201 12 libLLVM-2.8svn.so 0x00002abde4c4ec9e llvm::FunctionPassManager::run(llvm::Function&) + 142 13 clang 0x000000000041effd 14 clang 0x00000000005e3c59 15 clang 0x00000000004220e4 16 clang 0x00000000004156b1 17 clang 0x0000000000416c49 main + 233 18 libc.so.6 0x00002abde637eb6d __libc_start_main + 253 19 clang 0x0000000000413819 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -S -disable-free -main-file-name vm.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -g -resource-dir /usr/lib/clang/2.0 -dependency-file .deps/vm.Tpo -sys-header-deps -MP -MT vm.o -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/usr/lib64/libffi-3.0.9/include -O2 -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -ferror-limit 19 -fmessage-length 238 -fvisibility hidden -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-MEz3jO.s -x c vm.c 1. parser at end of file 2. Code generation 3. Running pass 'Tail Duplication' on function '@vm_regular_engine' clang: error: compiler command failed due to signal 11 (use -v to see invocation) make: *** [vm.o] Error 245 pipping at bogus ~/Downloads/guile-1.9.10/libguile $ The issue is apparently related to optimization: pipping at bogus ~/Downloads/guile-1.9.10/libguile $ clang -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/usr/lib64/libffi-3.0.9/include -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -fvisibility=hidden -g -O2 -MT vm.o -MD -MP -MF .deps/vm.Tpo -c -o vm.o vm.c 2>/dev/null; echo $? 245 pipping at bogus ~/Downloads/guile-1.9.10/libguile $ clang -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/usr/lib64/libffi-3.0.9/include -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -fvisibility=hidden -g -O1 -MT vm.o -MD -MP -MF .deps/vm.Tpo -c -o vm.o vm.c 2>/dev/null; echo $? 245 pipping at bogus ~/Downloads/guile-1.9.10/libguile $ clang -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/usr/lib64/libffi-3.0.9/include -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -fvisibility=hidden -g -O0 -MT vm.o -MD -MP -MF .deps/vm.Tpo -c -o vm.o vm.c 2>/dev/null; echo $? 0 pipping at bogus ~/Downloads/guile-1.9.10/libguile $ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 8 08:54:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 May 2010 08:54:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 7097] New: Calling a function with bad signature Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7097 Summary: Calling a function with bad signature Product: clang Version: trunk Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: grzegorz.dabrowski at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4868) --> (http://llvm.org/bugs/attachment.cgi?id=4868) Test case $ clang NotificationManager.cpp -c -o NotificationMamager.o -fno-use-cxa-atexit clang: Instructions.cpp:286:void llvm::CallInst::init(llvm::Value*, llvm::Value*): (FTy->getNumParams() == 1 || (FTy->isVarArg() && FTy->getNumParams() == 0)) && "Calling a function with bad signature" clang: error: compiler command failed due to signal 21 (use -v to see invocation) OS: Haiku -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 8 13:20:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 May 2010 13:20:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 7098] New: Incorrectly return by implicit copy constructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7098 Summary: Incorrectly return by implicit copy constructor Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dnljms at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In the attached test case the pointer member of derived doesn't get returned from foo correctly. Normal copies seem fine. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 8 14:11:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 May 2010 14:11:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7099] New: Duplicate macro "instantiated from" messages in building googletest Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7099 Summary: Duplicate macro "instantiated from" messages in building googletest Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu To reproduce, check out r423 of http://googletest.googlecode.com/svn/trunk. Use autoreconf -i to create configure. configure with CC=clang and CXX=clang++. Then make and make check. During the make check, you'll get the following. Note that gtest_unittest.cc:3280:3 appears 5 times, gtest.h:1681:3 appears 3 times, and gtest.h:1681:52 appears twice. /bin/sh ./libtool --tag=CXX --mode=link /Users/jyasskin/src/llvm/clang/obj/Release-Asserts/bin/clang++ -D_THREAD_SAFE -DGTEST_HAS_PTHREAD=1 -g -O2 -o samples/sample10_unittest samples/sample10_unittest.o lib/libgtest.la libtool: link: /Users/jyasskin/src/llvm/clang/obj/Release-Asserts/bin/clang++ -D_THREAD_SAFE -DGTEST_HAS_PTHREAD=1 -g -O2 -o samples/.libs/sample10_unittest samples/sample10_unittest.o -Wl,-bind_at_load lib/.libs/libgtest.dylib depbase=`echo test/gtest_all_test.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ /Users/jyasskin/src/llvm/clang/obj/Release-Asserts/bin/clang++ -DHAVE_CONFIG_H -I. -I../src -I./build-aux -I../src -I../src/include -D_THREAD_SAFE -DGTEST_HAS_PTHREAD=1 -g -O2 -MT test/gtest_all_test.o -MD -MP -MF $depbase.Tpo -c -o test/gtest_all_test.o ../src/test/gtest_all_test.cc &&\ mv -f $depbase.Tpo $depbase.Po In file included from ../src/test/gtest_all_test.cc:46: ../src/test/gtest_unittest.cc:3280:3: warning: 'gtest_msg' is always NULL in this context EXPECT_THROW({ // NOLINT ^ In file included from ../src/test/gtest_all_test.cc:36: In file included from ../src/test/gtest-filepath_test.cc:42: ../src/include/gtest/gtest.h:1681:3: note: instantiated from: GTEST_TEST_THROW_(statement, expected_exception, GTEST_NONFATAL_FAILURE_) ^ In file included from ../src/test/gtest_all_test.cc:46: ../src/test/gtest_unittest.cc:3280:3: note: instantiated from: EXPECT_THROW({ // NOLINT ^ In file included from ../src/test/gtest_all_test.cc:36: In file included from ../src/test/gtest-filepath_test.cc:42: ../src/include/gtest/gtest.h:1681:52: note: instantiated from: GTEST_TEST_THROW_(statement, expected_exception, GTEST_NONFATAL_FAILURE_) ^ In file included from ../src/test/gtest_all_test.cc:36: In file included from ../src/test/gtest-filepath_test.cc:42: In file included from ../src/include/gtest/gtest.h:57: ../src/include/gtest/internal/gtest-internal.h:798:3: note: instantiated from: GTEST_MESSAGE_(message, ::testing::TestPartResult::kNonFatalFailure) ^ In file included from ../src/test/gtest_all_test.cc:46: ../src/test/gtest_unittest.cc:3280:3: note: instantiated from: EXPECT_THROW({ // NOLINT ^ In file included from ../src/test/gtest_all_test.cc:36: In file included from ../src/test/gtest-filepath_test.cc:42: ../src/include/gtest/gtest.h:1681:3: note: instantiated from: GTEST_TEST_THROW_(statement, expected_exception, GTEST_NONFATAL_FAILURE_) ^ In file included from ../src/test/gtest_all_test.cc:46: ../src/test/gtest_unittest.cc:3280:3: note: instantiated from: EXPECT_THROW({ // NOLINT ^ In file included from ../src/test/gtest_all_test.cc:36: In file included from ../src/test/gtest-filepath_test.cc:42: ../src/include/gtest/gtest.h:1681:52: note: instantiated from: GTEST_TEST_THROW_(statement, expected_exception, GTEST_NONFATAL_FAILURE_) ^ In file included from ../src/test/gtest_all_test.cc:46: ../src/test/gtest_unittest.cc:3280:3: note: instantiated from: EXPECT_THROW({ // NOLINT ^ In file included from ../src/test/gtest_all_test.cc:36: In file included from ../src/test/gtest-filepath_test.cc:42: ../src/include/gtest/gtest.h:1681:3: note: instantiated from: GTEST_TEST_THROW_(statement, expected_exception, GTEST_NONFATAL_FAILURE_) ^ In file included from ../src/test/gtest_all_test.cc:36: In file included from ../src/test/gtest-filepath_test.cc:42: In file included from ../src/include/gtest/gtest.h:57: ../src/include/gtest/internal/gtest-internal.h:832:12: note: instantiated from: fail(gtest_msg) ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 8 14:39:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 May 2010 14:39:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7100] New: False accusation of NULL-ness after ingenious control flow Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7100 Summary: False accusation of NULL-ness after ingenious control flow 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, zhanyong.wan at gmail.com $ cat test.cc #include int main() { puts(0); // Generates the first line, containing "(null)" if (const char* msg = "") { goto label; } else label: puts(msg); // Generates the second line, blank } $ clang++ test.cc -o test -Wall test.cc:8:14: warning: 'msg' is always NULL in this context puts(msg); ^ 1 warning generated. $ ./test (null) $ Note that msg will always be non-NULL (""), so the if branch will be taken. It then jumps into the else branch and uses msg, so msg will never be NULL, contrary to the warning. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 8 19:52:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 May 2010 19:52:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 7101] New: Crash in codegen on local class access to static variable in containing function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7101 Summary: Crash in codegen on local class access to static variable in containing 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 crash_test.cc void foo() { static int n = 0; struct Helper { static void Execute() { n++; } }; Helper::Execute(); } -fsyntax-only and g++ complete successfully, but: $ gdb --args /Users/jyasskin/src/llvm/clang/obj/Debug/bin/clang -cc1 -S -o /dev/null crash_test.cc (gdb) run Starting program: /Users/jyasskin/src/llvm/clang/obj/Debug/bin/clang -cc1 -S -o /dev/null crash_test.cc Reading symbols for shared libraries +++. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x65706c75 0x00190b4d in llvm::Type::getForwardedType (this=0x65706c65) at Type.h:357 357 public: (gdb) bt #0 0x00190b4d in llvm::Type::getForwardedType (this=0x65706c65) at Type.h:357 #1 0x0018b4b7 in llvm::PATypeHolder::get (this=0x1907c54) at Type.h:507 #2 0x0018b4f5 in llvm::PATypeHolder::operator llvm::Type* (this=0x1907c54) at AbstractTypeUser.h:158 #3 0x0018b50c in llvm::Value::getType (this=0x1907c4c) at Value.h:110 #4 0x00174cf2 in clang::CodeGen::CodeGenFunction::EmitLoadOfLValue (this=0xbfffdff0, LV={LVType = clang::CodeGen::LValue::Simple, V = 0x1907c4c, {VectorIdx = 0xbfffd9f8, VectorElts = 0xbfffd9f8, BitFieldInfo = 0xbfffd9f8, PropertyRefExpr = 0xbfffd9f8, KVCRefExpr = 0xbfffd9f8}, Quals = {Mask = 0}, Ivar = false, ObjIsArray = false, NonGC = false, GlobalObjCRef = false, BaseIvarExp = 0x0}, ExprType={Value = {Value = 26229792}}) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGExpr.cpp:595 #5 0x00175098 in clang::CodeGen::CodeGenFunction::EmitScalarPrePostIncDec (this=0xbfffdff0, E=0x1907850, LV={LVType = clang::CodeGen::LValue::Simple, V = 0x1907c4c, {VectorIdx = 0xbfffd9f8, VectorElts = 0xbfffd9f8, BitFieldInfo = 0xbfffd9f8, PropertyRefExpr = 0xbfffd9f8, KVCRefExpr = 0xbfffd9f8}, Quals = {Mask = 0}, Ivar = false, ObjIsArray = false, NonGC = false, GlobalObjCRef = false, BaseIvarExp = 0x0}, isInc=true, isPre=false) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGExpr.cpp:295 #6 0x001a1a42 in (anonymous namespace)::ScalarExprEmitter::VisitPrePostIncDec (this=0xbfffdc30, E=0x1907850, isInc=true, isPre=false) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGExprScalar.cpp:214 #7 0x001a1a70 in (anonymous namespace)::ScalarExprEmitter::VisitUnaryPostInc (this=0xbfffdc30, E=0x1907850) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGExprScalar.cpp:220 #8 0x001a4da8 in clang::StmtVisitor<(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit (this=0xbfffdc30, S=0x1907850) at StmtVisitor.h:88 #9 0x0019afeb in clang::CodeGen::CodeGenFunction::EmitScalarExpr (this=0xbfffdff0, E=0x1907850, IgnoreResultAssign=true) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGExprScalar.cpp:1889 #10 0x0017324a in clang::CodeGen::CodeGenFunction::EmitAnyExpr (this=0xbfffdff0, E=0x1907850, AggLoc=0x0, IsAggLocVolatile=false, IgnoreResult=true, IsInitializer=false) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGExpr.cpp:98 #11 0x001e6690 in clang::CodeGen::CodeGenFunction::EmitStmt (this=0xbfffdff0, S=0x1907850) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGStmt.cpp:74 #12 0x001e7f6b in clang::CodeGen::CodeGenFunction::EmitCompoundStmt (this=0xbfffdff0, S=@0x1907870, GetLast=false, AggLoc=0x0, isAggVol=false) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGStmt.cpp:160 #13 0x001e8158 in clang::CodeGen::CodeGenFunction::EmitSimpleStmt (this=0xbfffdff0, S=0x1907870) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGStmt.cpp:128 #14 0x001e63c8 in clang::CodeGen::CodeGenFunction::EmitStmt (this=0xbfffdff0, S=0x1907870) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CGStmt.cpp:43 #15 0x0020b283 in clang::CodeGen::CodeGenFunction::EmitFunctionBody (this=0xbfffdff0, Args=@0xbfffde80) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CodeGenFunction.cpp:250 #16 0x0020def7 in clang::CodeGen::CodeGenFunction::GenerateCode (this=0xbfffdff0, GD={Value = {Value = 26243824}}, Fn=0x1908030) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CodeGenFunction.cpp:307 #17 0x002191af in clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition (this=0x2032c00, GD={Value = {Value = 26243824}}) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CodeGenModule.cpp:1339 #18 0x0021938c in clang::CodeGen::CodeGenModule::EmitGlobalDefinition (this=0x2032c00, GD={Value = {Value = 26243824}}) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CodeGenModule.cpp:740 #19 0x0021955a in clang::CodeGen::CodeGenModule::EmitDeferred (this=0x2032c00) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CodeGenModule.cpp:530 #20 0x00219964 in clang::CodeGen::CodeGenModule::Release (this=0x2032c00) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/CodeGenModule.cpp:84 #21 0x00233a2a in (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit (this=0x1906190, Ctx=@0x2023000) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/CodeGen/ModuleBuilder.cpp:83 #22 0x00023f68 in (anonymous namespace)::BackendConsumer::HandleTranslationUnit (this=0x1906010, C=@0x2023000) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/CodeGenAction.cpp:158 #23 0x002428e8 in clang::ParseAST (PP=@0x1903640, Consumer=0x1906010, Ctx=@0x2023000, PrintStats=false, CompleteTranslationUnit=true, CompletionConsumer=0x0) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Sema/ParseAST.cpp:108 #24 0x00044d44 in clang::ASTFrontendAction::ExecuteAction (this=0x1903120) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/FrontendAction.cpp:224 #25 0x00044c34 in clang::FrontendAction::Execute (this=0x1903120) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/FrontendAction.cpp:150 #26 0x00025aeb in clang::CompilerInstance::ExecuteAction (this=0x19018c0, Act=@0x1903120) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/CompilerInstance.cpp:511 #27 0x00003448 in cc1_main (ArgBegin=0xbffff678, ArgEnd=0xbffff688, Argv0=0xbffff734 "/Users/jyasskin/src/llvm/clang/obj/Debug/bin/clang", MainAddr=0x6278) at /Users/jyasskin/src/llvm/clang/src/tools/clang/tools/driver/cc1_main.cpp:285 #28 0x00007009 in main (argc=6, argv=0xbffff670) at /Users/jyasskin/src/llvm/clang/src/tools/clang/tools/driver/driver.cpp:181 (gdb) Reduced from a crash in compiling googletest. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 8 22:06:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 May 2010 22:06:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7102] New: Clang fails to pack template containing packed union Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7102 Summary: Clang fails to pack template containing packed union 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 dhcp-172-31-154-126:~/src/llvm/clang/obj$ cat ~/tmp/test.cc #include class NotTpl { public: union { char space[11]; void* ptr; } __attribute__((packed)); }; template class Tpl { public: union { char space[N]; void* ptr; } __attribute__((packed)); }; int main() { printf("%zd\n", sizeof(NotTpl)); printf("%zd\n", sizeof(Tpl<11>)); } dhcp-172-31-154-126:~/src/llvm/clang/obj$ g++ ~/tmp/test.cc && ./a.out 11 11 dhcp-172-31-154-126:~/src/llvm/clang/obj$ Debug/bin/clang++ ~/tmp/test.cc && ./a.out 11 12 dhcp-172-31-154-126:~/src/llvm/clang/obj$ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 9 02:33:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 May 2010 02:33:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 7103] New: Warning when c-style (T)x or functional T(x) cast does anything other than static_cast(x) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7103 Summary: Warning when c-style (T)x or functional T(x) cast does anything other than static_cast(x) Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I'd like a -Wpowerful-c-cast (or a better name) that fires when a C-style cast behaves like a reinterpret_ or const_cast instead of the safer static_cast. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 9 22:59:39 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 May 2010 22:59:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 7104] New: Assertion `D.Verify() && "invalid DIVariable passed to dbg.declare"' failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7104 Summary: Assertion `D.Verify() && "invalid DIVariable passed to dbg.declare"' failed Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu $ llvm-gcc -S -g ptrtomember-overload-resolution.cpp cc1plus: llvm/lib/Analysis/DebugInfo.cpp:1138: llvm::Instruction* llvm::DIFactory::InsertDeclare(llvm::Value*, llvm::DIVariable, llvm::BasicBlock*): Assertion `D.Verify() && "invalid DIVariable passed to dbg.declare"' failed. struct A { int Ai; }; struct B : public A {}; struct C : public B {}; const char * f(int C::*){ return ""; } int f(int B::*) { return 1; } struct D : public C {}; const char * g(int B::*){ return ""; } int g(int D::*) { return 1; } void test() { int i = f(&A::Ai); const char * str = g(&A::Ai); } // conversion of B::* to C::* is better than conversion of A::* to C::* typedef void (A::*pmfa)(); typedef void (B::*pmfb)(); typedef void (C::*pmfc)(); struct X { operator pmfa(); operator pmfb(); }; void g(pmfc); void test2(X x) { g(x); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 9 23:17:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 May 2010 23:17:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 7105] New: Metadata parsing problem Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7105 Summary: Metadata parsing problem Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Testcase: define void @foo() { call void @llvm.foo(metadata !1, i64 0, metadata !1) ret void } declare void @llvm.foo(metadata, i64, metadata) nounwind readnone !named = !{!0} !0 = metadata !{i8** null} !1 = metadata !{i8* null} Running llvm-as metadata.ll -o - | llvm-dis results in ; ModuleID = '' define void @foo() { call void @llvm.foo(metadata !-1, i64 0, metadata !-1) ret void } declare void @llvm.foo(metadata, i64, metadata) nounwind readnone !named = !{!0} !0 = metadata !{i8** null} Notice "metadata ! -1". Curiously, if llvm.foo is renamed to llvm.dbg.value then the metadata is parsed properly: ; ModuleID = '' define void @foo() { call void @llvm.dbg.value(metadata !1, i64 0, metadata !1) ret void } declare void @llvm.dbg.value(metadata, i64, metadata) nounwind readnone !named = !{!0} !0 = metadata !{i8** null} !1 = metadata !{i8* null} -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 02:37:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 02:37:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 7106] New: clang++ should accept -R argument (at least on FreeBSD) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7106 Summary: clang++ should accept -R argument (at least on FreeBSD) Product: clang Version: 2.7 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: yuri at tsoft.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I got this warning: clang: warning: argument unused during compilation: '-R/usr/local/binutils/2.20/lib' gcc accepts -R and passes it to linker (as -rpath parameter?) clang++ should do the same. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 10:11:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 10:11:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 7107] New: SIGABRT when compiling Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7107 Summary: SIGABRT when compiling Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping.elias at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com pipping at bogus ~ $ cat foo.cpp #include int main() { return 0; } pipping at bogus ~ $ clang++ foo.cpp -c -ferror-limit=0 -std=c++0x In file included from foo.cpp:1: In file included from /usr/include/c++/4.4.4/tr1/unordered_map:37: In file included from /usr/include/c++/4.4.4/utility:62: In file included from /usr/include/c++/4.4.4/bits/stl_pair.h:60: In file included from /usr/include/c++/4.4.4/bits/move.h:38: In file included from /usr/include/c++/4.4.4/type_traits:50: /usr/include/c++/4.4.4/tr1_impl/type_traits:230:41: error: expected ')' struct is_function<_Res(_ArgTypes......)> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:230:28: note: to match this '(' struct is_function<_Res(_ArgTypes......)> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:230:12: error: redefinition of 'is_function' struct is_function<_Res(_ArgTypes......)> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/4.4.4/tr1_impl/type_traits:227:12: note: previous definition is here struct is_function<_Res(_ArgTypes...)> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:233:29: error: type qualifier is not allowed on this function struct is_function<_Res(_ArgTypes...) const> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:233:12: error: redefinition of 'is_function' struct is_function<_Res(_ArgTypes...) const> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/4.4.4/tr1_impl/type_traits:227:12: note: previous definition is here struct is_function<_Res(_ArgTypes...)> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:236:41: error: expected ')' struct is_function<_Res(_ArgTypes......) const> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:236:28: note: to match this '(' struct is_function<_Res(_ArgTypes......) const> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:236:29: error: type qualifier is not allowed on this function struct is_function<_Res(_ArgTypes......) const> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:236:12: error: redefinition of 'is_function' struct is_function<_Res(_ArgTypes......) const> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/4.4.4/tr1_impl/type_traits:227:12: note: previous definition is here struct is_function<_Res(_ArgTypes...)> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:239:29: error: type qualifier is not allowed on this function struct is_function<_Res(_ArgTypes...) volatile> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:239:12: error: redefinition of 'is_function' struct is_function<_Res(_ArgTypes...) volatile> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/4.4.4/tr1_impl/type_traits:227:12: note: previous definition is here struct is_function<_Res(_ArgTypes...)> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:242:41: error: expected ')' struct is_function<_Res(_ArgTypes......) volatile> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:242:28: note: to match this '(' struct is_function<_Res(_ArgTypes......) volatile> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:242:29: error: type qualifier is not allowed on this function struct is_function<_Res(_ArgTypes......) volatile> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:242:12: error: redefinition of 'is_function' struct is_function<_Res(_ArgTypes......) volatile> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/4.4.4/tr1_impl/type_traits:227:12: note: previous definition is here struct is_function<_Res(_ArgTypes...)> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:245:29: error: type qualifier is not allowed on this function struct is_function<_Res(_ArgTypes...) const volatile> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:245:12: error: redefinition of 'is_function' struct is_function<_Res(_ArgTypes...) const volatile> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/4.4.4/tr1_impl/type_traits:227:12: note: previous definition is here struct is_function<_Res(_ArgTypes...)> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:248:41: error: expected ')' struct is_function<_Res(_ArgTypes......) const volatile> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:248:28: note: to match this '(' struct is_function<_Res(_ArgTypes......) const volatile> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:248:29: error: type qualifier is not allowed on this function struct is_function<_Res(_ArgTypes......) const volatile> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:248:12: error: redefinition of 'is_function' struct is_function<_Res(_ArgTypes......) const volatile> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/4.4.4/tr1_impl/type_traits:227:12: note: previous definition is here struct is_function<_Res(_ArgTypes...)> ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:345:38: error: expected expression : public integral_constant ^ /usr/include/c++/4.4.4/tr1_impl/type_traits:346:5: error: expected class name { }; ^ In file included from foo.cpp:1: In file included from /usr/include/c++/4.4.4/tr1/unordered_map:37: In file included from /usr/include/c++/4.4.4/utility:62: In file included from /usr/include/c++/4.4.4/bits/stl_pair.h:60: In file included from /usr/include/c++/4.4.4/bits/move.h:38: /usr/include/c++/4.4.4/type_traits:207:38: error: expected expression : public integral_constant ^ /usr/include/c++/4.4.4/type_traits:208:5: error: expected class name { }; ^ /usr/include/c++/4.4.4/type_traits:213:38: error: expected expression : public integral_constant ^ /usr/include/c++/4.4.4/type_traits:214:5: error: expected class name { }; ^ /usr/include/c++/4.4.4/type_traits:219:38: error: expected expression : public integral_constant ^ /usr/include/c++/4.4.4/type_traits:220:5: error: expected class name { }; ^ /usr/include/c++/4.4.4/type_traits:225:38: error: expected expression : public integral_constant ^ /usr/include/c++/4.4.4/type_traits:226:5: error: expected class name { }; ^ clang: ExprConstant.cpp:2280: ICEDiag CheckICE(clang::Expr const *, clang::ASTContext &): Assertion `!E->isValueDependent() && "Should not see value dependent exprs!"' failed. 0 libLLVM-2.8svn.so 0x00007f125aded28f 1 libLLVM-2.8svn.so 0x00007f125aded779 2 libpthread.so.0 0x00007f125a146c50 3 libc.so.6 0x00007f1259477ec5 gsignal + 53 4 libc.so.6 0x00007f125947916f abort + 383 5 libc.so.6 0x00007f1259471121 __assert_fail + 241 6 clang 0x0000000000871cab 7 clang 0x0000000000870e82 8 clang 0x000000000062a892 9 clang 0x0000000000629f61 10 clang 0x000000000062328a 11 clang 0x00000000008e4795 12 clang 0x00000000008d7da5 13 clang 0x00000000008e61c0 14 clang 0x00000000008e50a0 15 clang 0x00000000008e4845 16 clang 0x00000000008d7da5 17 clang 0x00000000008e61c0 18 clang 0x00000000008e50a0 19 clang 0x00000000008e4845 20 clang 0x00000000008d7da5 21 clang 0x00000000008f9a81 22 clang 0x00000000008f9614 23 clang 0x00000000008f92d5 24 clang 0x00000000008d66ac 25 clang 0x00000000008d2473 26 clang 0x00000000008e1a80 27 clang 0x00000000008d670f 28 clang 0x00000000008d2473 29 clang 0x00000000008d1bca 30 clang 0x00000000005e3c3e 31 clang 0x00000000004220e4 32 clang 0x00000000004156b1 33 clang 0x0000000000416c49 main + 233 34 libc.so.6 0x00007f1259464b6d __libc_start_main + 253 35 clang 0x0000000000413819 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -S -disable-free -main-file-name foo.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/lib/clang/2.0 -std=c++0x -ferror-limit 0 -fmessage-length 118 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-RMKuz3.s -x c++ foo.cpp 1. /usr/include/c++/4.4.4/type_traits:309:48: current parser token '{' 2. /usr/include/c++/4.4.4/type_traits:57:1: parsing namespace 'std' 3. /usr/include/c++/4.4.4/type_traits:304:5: parsing struct/union/class body 'std::aligned_storage' 4. /usr/include/c++/4.4.4/type_traits:306:7: parsing struct/union/class body 'std::aligned_storage::type' clang: error: compiler command failed due to signal 6 (use -v to see invocation) pipping at bogus ~ $ clang++ --version clang version 2.0 (trunk 103331) Target: x86_64-pc-linux-gnu Thread model: posix pipping at bogus ~ $ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 10:32:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 10:32:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 7108] New: internal compiler error: Segmentation fault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7108 Summary: internal compiler error: Segmentation fault Product: Build scripts Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: jurij at o2online.de CC: llvmbugs at cs.uiuc.edu build llvm-gcc V2.7 cause on RHE 4.8 /CENTOS 4.8 32bit x86, a egmentation fault in make flow. OUTPUT: ---------------> ../../llvm-gcc/gcc/crtstuff.c:378: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[3]: *** [crtbegin.o] Error 1 make[3]: Leaving directory `/local/build/xpic-compiler/llvm/llvm-gcc-objects/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/local/build/xpic-compiler/llvm/llvm-gcc-objects' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/local/build/xpic-compiler/llvm/llvm-gcc-objects' <--------------- -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 12:18:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 12:18:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 7107] SIGABRT when compiling In-Reply-To: References: Message-ID: <20100510171858.139423128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7107 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #3 from Douglas Gregor 2010-05-10 12:18:57 CDT --- *** This bug has been marked as a duplicate of bug 5893 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 12:50:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 12:50:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7104] Assertion `D.Verify() && "invalid DIVariable passed to dbg.declare"' failed In-Reply-To: References: Message-ID: <20100510175000.6C9D43128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7104 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Devang Patel 2010-05-10 12:50:00 CDT --- Fixed. r103414. testcase @ r103415. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 12:51:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 12:51:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7096] Compiler crash while compiling guile In-Reply-To: References: Message-ID: <20100510175114.AB7C03128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7096 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Bob Wilson 2010-05-10 12:51:14 CDT --- This is fixed in svn r103407. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 14:04:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 14:04:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 7018] UNREACHABLE executed at SelectionDAG.cpp:653! In-Reply-To: References: Message-ID: <20100510190440.892143128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7018 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Evan Cheng 2010-05-10 14:04:39 CDT --- Fixed: 103419. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 15:24:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 15:24:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 6875] llc -print-after-all crashes In-Reply-To: References: Message-ID: <20100510202447.1BFA03128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6875 David Greene changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #9 from David Greene 2010-05-10 15:24:46 CDT --- Fixed with 103425. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 15:53:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 15:53:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 7105] Metadata printing problem In-Reply-To: References: Message-ID: <20100510205341.892D93128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7105 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Summary|Metadata parsing problem |Metadata printing problem --- Comment #3 from Chris Lattner 2010-05-10 15:53:41 CDT --- Fixed in r103428, I will fix the verifier next. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 17:57:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 17:57:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 2258] LLVM does not properly handle compile units in debug records In-Reply-To: References: Message-ID: <20100510225726.28AC93128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2258 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Devang Patel 2010-05-10 17:57:25 CDT --- This is now fixed. Last patch r103439 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 20:34:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 20:34:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7109] New: __builtin_offsetof - non-POD type warning Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7109 Summary: __builtin_offsetof - non-POD type warning Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu class test { public: test(); int member; }; class testStruct { public: testStruct(); test t; }; int i = __builtin_offsetof (testStruct, t); >clang -cc1 offsetof1.cpp offsetof1.cpp:15:9: warning: offset of on non-POD type 'testStruct' int i = __builtin_offsetof (testStruct, t); ^ ~ 1 warning generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 22:53:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 22:53:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 7110] New: llc generates a non thumb instruction when thumb is specified Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7110 Summary: llc generates a non thumb instruction when thumb is specified Product: new-bugs Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dwelch at dwelch.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4878) --> (http://llvm.org/bugs/attachment.cgi?id=4878) input to llc that generates this problem llc -march=thumb file.bc -f -o fileout.s generated a push with register 8 in the list, a push is limited to r0-7 and lr, r8 is not valid. .code 16 .thumb_func SHA1: @ @SHA1 @ BB#0: @ %entry push {r4, r5, r6, r7, r8, lr} ldr r2, .LCPI2_9 add sp, r2 cmp r1, #0 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 23:12:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 23:12:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7111] New: Diagnostic for typename used in a complete specialization? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7111 Summary: Diagnostic for typename used in a complete specialization? Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: me22.ca at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I don't understand 14.6/5 well enough to know who's right, here: $ clang++ clang.cc -fsyntax-only $ g++-4.4.3 clang.cc -fsyntax-only clang.cc:11: error: using ?typename? outside of template $ g++-4.3.4 clang.cc -fsyntax-only clang.cc:11: error: using ?typename? outside of template The code: template struct uint_t { typedef unsigned long least; }; template struct all_ones { typedef typename uint_t::least type; static type const value = (type(all_ones::value) << 1) | 1; }; template <> struct all_ones<0> { typedef typename uint_t<0>::least type; static type const value = 0; }; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 10 23:15:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 May 2010 23:15:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7112] New: clang does not diagnose illegal uses of typename. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7112 Summary: clang does not diagnose illegal uses of typename. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rideau3 at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang does not diagnose uses of typename outside dependent contexts, which is forbidden in C++03. Testcase: struct foo { typedef int bar; } typename foo::bar i; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 11 02:22:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 02:22:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7112] clang does not diagnose illegal uses of typename. In-Reply-To: References: Message-ID: <20100511072255.9E3013128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7112 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Douglas Gregor 2010-05-11 02:22:55 CDT --- *** This bug has been marked as a duplicate of bug 7111 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 11 04:54:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 04:54:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7113] New: Clang should warn on absurd implicit conversions to NULL Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7113 Summary: Clang should warn on absurd implicit conversions to NULL Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Keywords: quality-of-implementation Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Because the programmer never in a million years wanted this to happen: % cat t6.cc #include std::string f() { return false; } % ./bin/clang++ -fsyntax-only t6.cc % It seems reasonable to print a warning for false -> (char *)0, at least in C++ where converting implicitly to NULL can have such surprising side-effects. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 11 13:30:24 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 13:30:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 7114] New: Clang instantiates implicit virtual destructor too early Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7114 Summary: Clang instantiates implicit virtual destructor too early Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Blocks: 6023 lackthorn:clang dgregor$ cat t.cpp class A { virtual ~A(); }; template class B { public: class Inner : public A { }; static Inner i; static const unsigned value = sizeof(i) == 4; }; int f() { return B::value; } Blackthorn:clang dgregor$ clang++ t.cpp t.cpp:6:17: error: base class 'A' has private destructor class Inner : public A { }; ^~~~~~~~ t.cpp:1:19: note: declared private here class A { virtual ~A(); }; ^ 1 error generated. Here, we should not be instantiating the implicit, virtual destructor because it is never "used" (nor is anything that involves the vtable). While this code is rather sketchy to start with (compilers are allowed to try to instantiate the virtual member function definitions whenever they want), it happens to be used in Boost's is_polymorphic type trait, so it has to work. See Boost.Serialization's test_static_warning test. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 11 13:30:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 13:30:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 7115] New: Assertion failed: (isa(Val) && "cast_or_null() argument of incompatible type!"), function cast_or_null, file /Users/az/Programmierung/CppIDE/llvm-src/include/llvm/Support/Casting.h, line 213. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7115 Summary: Assertion failed: (isa(Val) && "cast_or_null() argument of incompatible type!"), function cast_or_null, file /Users/az/Programmierung/CppIDE/llvm-src/include/llvm/ Support/Casting.h, line 213. Product: tools Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: lli AssignedTo: unassignedbugs at nondot.org ReportedBy: ich at az2000.de CC: llvmbugs at cs.uiuc.edu Process: lli [86741] Path: /Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/lli Identifier: lli Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [86347] Interval Since Last Report: 181238 sec Crashes Since Last Report: 3 Per-App Interval Since Last Report: 0 sec Per-App Crashes Since Last Report: 1 Date/Time: 2010-05-11 20:28:20.463 +0200 OS Version: Mac OS X 10.5.8 (9L30) Report Version: 6 Anonymous UUID: C99325D9-953E-44CB-A0FE-88CB8BF0B517 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Application Specific Information: Stack dump: 0. Program arguments: /Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/lli CMakeFiles/openlierox.dir/src/MacMain.o 1. Running pass 'X86 DAG->DAG Instruction Selection' on function '@main' Thread 0 Crashed: 0 libSystem.B.dylib 0x94cbee42 __kill + 10 1 libSystem.B.dylib 0x94d3123a raise + 26 2 libSystem.B.dylib 0x94d3d622 __abort + 97 3 libSystem.B.dylib 0x94d3d68a _cproc_fork_child + 0 4 libSystem.B.dylib 0x94d323db __assert_rtn + 101 5 lli 0x005444a3 llvm::cast_retty::ret_type llvm::cast_or_null(llvm::Value*) + 107 6 lli 0x0059ac2b llvm::DbgDeclareInst::getAddress() const + 33 7 lli 0x001c3edb llvm::SelectionDAGBuilder::visitIntrinsicCall(llvm::CallInst const&, unsigned int) + 4807 8 lli 0x001c7523 llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 231 9 lli 0x001c87fa llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) + 1328 10 lli 0x001e15d7 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 111 11 lli 0x001fda81 llvm::SelectionDAGISel::SelectBasicBlock(llvm::MachineBasicBlock*, llvm::BasicBlock const*, llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 45 12 lli 0x001fe116 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1510 13 lli 0x001fe422 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 668 14 lli 0x002d6e59 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 77 15 lli 0x005be399 llvm::FPPassManager::runOnFunction(llvm::Function&) + 287 16 lli 0x005be5ba llvm::FunctionPassManagerImpl::run(llvm::Function&) + 80 17 lli 0x005be70f llvm::FunctionPassManager::run(llvm::Function&) + 195 18 lli 0x0023d353 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 123 19 lli 0x0023d6e6 llvm::JIT::getPointerToFunction(llvm::Function*) + 622 20 lli 0x0023e5b9 llvm::JIT::runFunction(llvm::Function*, std::vector > const&) + 99 21 lli 0x002649a3 llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::vector, std::allocator >, std::allocator, std::allocator > > > const&, char const* const*) + 1135 (ExecutionEngine.cpp:423) 22 lli 0x000021ad main + 2313 (lli.cpp:234) 23 lli 0x00001836 start + 54 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x94d3d639 ecx: 0xbfffe2cc edx: 0x94cbee42 edi: 0x01807520 esi: 0x006a177c ebp: 0xbfffe2e8 esp: 0xbfffe2cc ss: 0x0000001f efl: 0x00000282 eip: 0x94cbee42 cs: 0x00000007 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x2c23a042 Binary Images: 0x1000 - 0x6d3fab +lli ??? (???) <2e06ca8c8123338262f3c3b240af242b> /Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/lli 0x8fe00000 - 0x8fe2db43 dyld 97.1 (???) <458eed38a009e5658a79579e7bc26603> /usr/lib/dyld 0x92737000 - 0x9273efe9 libgcc_s.1.dylib ??? (???) /usr/lib/libgcc_s.1.dylib 0x946e4000 - 0x94741ffb libstdc++.6.dylib ??? (???) <04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib 0x94c50000 - 0x94db7ff3 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib 0x95237000 - 0x9523bfff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 11 14:08:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 14:08:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 7116] New: generated C code is not valid C code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7116 Summary: generated C code is not valid C code Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: C AssignedTo: unassignedbugs at nondot.org ReportedBy: ich at az2000.de CC: llvmbugs at cs.uiuc.edu 93-018:build-llvm-bitcode az$ ~/Programmierung/CppIDE/llvm-src/Debug/bin/clang test.optim.o.cbe.c test.optim.o.cbe.c:159:1: error: 'main' must return 'int' unsigned int main(void); ^ test.optim.o.cbe.c:202:1: error: 'main' must return 'int' unsigned int main(void) { ^ 2 errors generated. Also not by clang++: 93-018:build-llvm-bitcode az$ ~/Programmierung/CppIDE/llvm-src/Debug/bin/clang++ test.optim.o.cbe.c clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated test.optim.o.cbe.c:159:1: error: 'main' must return 'int' unsigned int main(void); ^ test.optim.o.cbe.c:173:58: error: redefinition of '_ZStL8__ioinit' static struct l_class_OC_std_KD__KD_ios_base_KD__KD_Init _ZStL8__ioinit; ^ test.optim.o.cbe.c:168:58: note: previous definition is here static struct l_class_OC_std_KD__KD_ios_base_KD__KD_Init _ZStL8__ioinit; ^ test.optim.o.cbe.c:174:26: error: redefinition of '_OC_str' static struct l_unnamed2 _OC_str = { "Hello World" }; ^ test.optim.o.cbe.c:169:26: note: previous definition is here static struct l_unnamed2 _OC_str; ^ test.optim.o.cbe.c:202:1: error: 'main' must return 'int' unsigned int main(void) { ^ 4 errors generated. GCC only gives a warning about it: 93-018:build-llvm-bitcode az$ gcc test.optim.o.cbe.c /usr/lib/libstdc++.6.dylib test.optim.o.cbe.c: In function ?main?: test.optim.o.cbe.c:202: warning: return type of ?main? is not ?int? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 11 15:23:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 15:23:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 7117] New: regparm attribute combined with K&R declarations causes illegal instruction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7117 Summary: regparm attribute combined with K&R declarations causes illegal instruction 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 While building and testing the FreeBSD version of GNU libregex with clang, I consistently got 'illegal instruction' from it at runtime. It turned out clang had inserted instruction "ud2" at many places inside the object code. This seems to have been caused by quite a number of functions inside the regex compiler having this attribute tacked on: __attribute ((regparm (3), stdcall)) While this in itself should probably cause no harm, it apparently does become problematic, when used in combination with K&R-style function declarations. I reduced this phenomenon to the following testcase: int re_string_construct(int) __attribute__((regparm(3), stdcall)); int re_string_construct(dfa) { } int re_compile_internal(void) { init_dfa(); re_string_construct(0); } Compile with "clang -cc1 -O2 -emit-llvm" and the last function becomes: define i32 @re_compile_internal() noreturn nounwind { entry: %call = tail call i32 (...)* @init_dfa() nounwind ; [#uses=0] tail call void @llvm.trap() unreachable } which is obviously incorrect. Compiling with -O0, or removing the attribute altogether produces correct output. (Yes, I realize K&R is really really deprecated now, but unfortunately a lot of code out there still uses it, especially older GNU stuff... :) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 11 16:16:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 16:16:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 7098] Incorrectly return by implicit copy constructor In-Reply-To: References: Message-ID: <20100511211609.41921312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7098 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Daniel Dunbar 2010-05-11 16:16:09 CDT --- Fixed here: http://llvm.org/viewvc/llvm-project?view=rev&revision=103514 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 11 17:09:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 17:09:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 7119] New: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7119 Summary: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. Product: tools Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: lli AssignedTo: unassignedbugs at nondot.org ReportedBy: ich at az2000.de CC: llvmbugs at cs.uiuc.edu az at acompneu ~/Programmierung/openlierox/build-llvm-bitcode $ ~/Programmierung/CppIDE/llvm-src/Debug/bin/lli olx.o.bc lli: /home/az/Programmierung/CppIDE/llvm-src/include/llvm/Support/Casting.h:202: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = llvm::MDNode, Y = llvm::Value*]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. 0 lli 0x08b6500e 1 lli 0x08b64edf 2 0xb78e6400 __kernel_sigreturn + 0 3 0xb78e6424 __kernel_vsyscall + 16 4 libc.so.6 0xb76202c1 gsignal + 81 5 libc.so.6 0xb7621a02 abort + 386 6 libc.so.6 0xb761946e __assert_fail + 238 7 lli 0x08507b21 llvm::cast_retty::ret_type llvm::cast(llvm::Value* const&) + 0 8 lli 0x08ab5607 llvm::DbgValueInst::getValue() const + 51 9 lli 0x0868a2a5 llvm::SelectionDAGBuilder::visitIntrinsicCall(llvm::CallInst const&, unsigned int) + 4839 10 lli 0x0868f45f llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 235 11 lli 0x086713c9 llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) + 1103 12 lli 0x08670edd llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 123 13 lli 0x086abe89 llvm::SelectionDAGISel::SelectBasicBlock(llvm::MachineBasicBlock*, llvm::BasicBlock const*, llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 55 14 lli 0x086aeab4 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1524 15 lli 0x086abcca llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 602 16 lli 0x087b6e49 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 87 17 lli 0x08adc089 llvm::FPPassManager::runOnFunction(llvm::Function&) + 313 18 lli 0x08adbdbc llvm::FunctionPassManagerImpl::run(llvm::Function&) + 90 19 lli 0x08adba5e llvm::FunctionPassManager::run(llvm::Function&) + 176 20 lli 0x08744e8d llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 123 21 lli 0x087451a4 llvm::JIT::getPointerToFunction(llvm::Function*) + 516 22 lli 0x08743c6d llvm::JIT::runFunction(llvm::Function*, std::vector > const&) + 99 23 lli 0x0876c038 llvm::ExecutionEngine::runStaticConstructorsDestructors(llvm::Module*, bool) + 466 24 lli 0x0876c0dd llvm::ExecutionEngine::runStaticConstructorsDestructors(bool) + 97 25 lli 0x084ed1ee main + 1815 26 libc.so.6 0xb760ca66 __libc_start_main + 230 27 lli 0x084ec8b1 Stack dump: 0. Program arguments: /home/az/Programmierung/CppIDE/llvm-src/Debug/bin/lli olx.o.bc 1. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_GLOBAL__I_a2357' Aborted (core dumped) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 11 18:26:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 18:26:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 6951] bugpoint crashes when debugging a miscompilation In-Reply-To: References: Message-ID: <20100511232659.74F003128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6951 Jeffrey Yasskin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED AssignedTo|unassignedbugs at nondot.org |jyasskin at google.com --- Comment #2 from Jeffrey Yasskin 2010-05-11 18:26:58 CDT --- r103523 should fix this. If it doesn't, the problem is probably more Modules that bugpoint fails to destroy. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 11 19:12:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 19:12:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7120] New: Assertion failed: (!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"), function runJITOnFunctionUnlocked, file JIT.cpp, line 627. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7120 Summary: Assertion failed: (!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"), function runJITOnFunctionUnlocked, file JIT.cpp, line 627. Product: tools Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: lli AssignedTo: unassignedbugs at nondot.org ReportedBy: ich at az2000.de CC: llvmbugs at cs.uiuc.edu 93-018:build-llvm-bitcode az$ ~/Programmierung/CppIDE/llvm-src/Debug/bin/lli olx.nodebug.bc.bc LLVM ERROR: Program used external function 'SDL_CreateMutex' which could not be resolved! Assertion failed: (!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"), function runJITOnFunctionUnlocked, file JIT.cpp, line 627. 0 lli 0x006446da llvm::SearchForAddressOfSpecialSymbol(char const*) + 478 1 lli 0x00644b20 llvm::sys::SetInterruptFunction(void (*)()) + 436 2 libSystem.B.dylib 0x94cbd2bb _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1798581615 4 libSystem.B.dylib 0x94d3123a raise + 26 5 libSystem.B.dylib 0x94d3d679 abort + 73 6 libSystem.B.dylib 0x94d323db __assert_rtn + 101 7 lli 0x0023d320 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 72 8 lli 0x0023d6e6 llvm::JIT::getPointerToFunction(llvm::Function*) + 622 9 lli 0x0024f8cf (anonymous namespace)::JITResolver::JITCompilerFn(void*) + 673 10 lli 0x000c1453 llvm::X86JITInfo::replaceMachineCodeForFunction(void*, void*) + 257 11 lli 0x000c1331 X86CompilationCallback_SSE + 49 pure virtual method called terminate called without an active exception Abort trap Process: lli [89067] Path: /Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/lli Identifier: lli Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [88696] Interval Since Last Report: 18994 sec Crashes Since Last Report: 2 Per-App Interval Since Last Report: 0 sec Per-App Crashes Since Last Report: 2 Date/Time: 2010-05-12 01:45:06.632 +0200 OS Version: Mac OS X 10.5.8 (9L30) Report Version: 6 Anonymous UUID: C99325D9-953E-44CB-A0FE-88CB8BF0B517 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Application Specific Information: Stack dump: 0. Program arguments: /Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/lli olx.nodebug.bc.bc 1. Running pass 'X86 Machine Code Emitter' on function '@_GLOBAL__I_a2502' Thread 0 Crashed: 0 libSystem.B.dylib 0x94cbee42 __kill + 10 1 libSystem.B.dylib 0x94d3123a raise + 26 2 libSystem.B.dylib 0x94d3d679 abort + 73 3 libstdc++.6.dylib 0x9472c005 0x946e4000 + 294917 4 libstdc++.6.dylib 0x9472a10c __gxx_personality_v0 + 1108 5 libstdc++.6.dylib 0x9472a14b std::terminate() + 29 6 libstdc++.6.dylib 0x9472a6da std::type_info::~type_info() + 0 7 lli 0x00638c0f llvm::raw_ostream::write(char const*, unsigned long) + 99 (raw_ostream.cpp:250) 8 lli 0x00206a3a llvm::raw_ostream::operator<<(llvm::StringRef) + 78 9 lli 0x0062745d CrashHandler(void*) + 225 10 lli 0x00644b20 SignalHandler(int) + 372 11 libSystem.B.dylib 0x94cbd2bb _sigtramp + 43 12 ??? 0xffffffff 0 + 4294967295 13 libSystem.B.dylib 0x94d3123a raise + 26 14 libSystem.B.dylib 0x94d3d679 abort + 73 15 libSystem.B.dylib 0x94d323db __assert_rtn + 101 16 lli 0x0023d320 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 72 17 lli 0x0023d6e6 llvm::JIT::getPointerToFunction(llvm::Function*) + 622 18 lli 0x0024f8cf (anonymous namespace)::JITResolver::JITCompilerFn(void*) + 673 (JITEmitter.cpp:752) 19 lli 0x000c1453 X86CompilationCallback2 + 179 20 lli 0x000c1331 X86CompilationCallback_SSE + 49 21 ??? 0x0379005d 0 + 58261597 22 libSystem.B.dylib 0x94c79c90 exit + 33 23 lli 0x00623266 llvm::report_fatal_error(std::basic_string, std::allocator > const&) + 0 24 lli 0x00623289 llvm::report_fatal_error(std::basic_string, std::allocator > const&) + 35 25 lli 0x0023bee6 llvm::JIT::getPointerToNamedFunction(std::basic_string, std::allocator > const&, bool) + 382 26 lli 0x0023d69b llvm::JIT::getPointerToFunction(llvm::Function*) + 547 27 lli 0x0024e8ec (anonymous namespace)::JITEmitter::getPointerToGlobal(llvm::GlobalValue*, void*, bool) + 340 (JITEmitter.cpp:810) 28 lli 0x00250196 (anonymous namespace)::JITEmitter::finishFunction(llvm::MachineFunction&) + 814 (JITEmitter.cpp:1150) 29 lli 0x0002eaec (anonymous namespace)::Emitter::runOnMachineFunction(llvm::MachineFunction&) + 780 30 lli 0x002d6e59 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 77 31 lli 0x005be399 llvm::FPPassManager::runOnFunction(llvm::Function&) + 287 32 lli 0x005be5ba llvm::FunctionPassManagerImpl::run(llvm::Function&) + 80 33 lli 0x005be70f llvm::FunctionPassManager::run(llvm::Function&) + 195 34 lli 0x0023d353 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 123 35 lli 0x0023d6e6 llvm::JIT::getPointerToFunction(llvm::Function*) + 622 36 lli 0x0023e5b9 llvm::JIT::runFunction(llvm::Function*, std::vector > const&) + 99 37 lli 0x0026428a llvm::ExecutionEngine::runStaticConstructorsDestructors(llvm::Module*, bool) + 490 (ExecutionEngine.cpp:340) 38 lli 0x0026431b llvm::ExecutionEngine::runStaticConstructorsDestructors(bool) + 85 (ExecutionEngine.cpp:350) 39 lli 0x000020a1 main + 2045 (lli.cpp:225) 40 lli 0x00001836 start + 54 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x94d3d639 ecx: 0xbfffd9ac edx: 0x94cbee42 edi: 0x00000012 esi: 0x0062737c ebp: 0xbfffd9c8 esp: 0xbfffd9ac ss: 0x0000001f efl: 0x00000282 eip: 0x94cbee42 cs: 0x00000007 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x004feb16 Binary Images: 0x1000 - 0x6d3fab +lli ??? (???) <2e06ca8c8123338262f3c3b240af242b> /Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/lli 0x8fe00000 - 0x8fe2db43 dyld 97.1 (???) <458eed38a009e5658a79579e7bc26603> /usr/lib/dyld 0x92737000 - 0x9273efe9 libgcc_s.1.dylib ??? (???) /usr/lib/libgcc_s.1.dylib 0x946e4000 - 0x94741ffb libstdc++.6.dylib ??? (???) <04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib 0x94c50000 - 0x94db7ff3 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib 0x95237000 - 0x9523bfff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 11 21:01:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 May 2010 21:01:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 7121] New: LLVM ERROR: Could not resolve external global address: __dso_handle, pure virtual method called Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7121 Summary: LLVM ERROR: Could not resolve external global address: __dso_handle, pure virtual method called Product: tools Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: lli AssignedTo: unassignedbugs at nondot.org ReportedBy: ich at az2000.de CC: llvmbugs at cs.uiuc.edu I am not sure if the LLVM ERROR is also a bug in lli (or just related to a problem in my code). At least the pure virtual method call seems to be a bug in lli. LLVM ERROR: Could not resolve external global address: __dso_handle pure virtual method called terminate called without an active exception Program received signal SIGABRT, Aborted. 0x94cbee42 in __kill () (gdb) bt #0 0x94cbee42 in __kill () #1 0x94cbee34 in kill$UNIX2003 () #2 0x94d3123a in raise () #3 0x94d3d679 in abort () #4 0x9472c005 in __gnu_cxx::__verbose_terminate_handler () #5 0x9472a10c in __gxx_personality_v0 () #6 0x9472a14b in std::terminate () #7 0x9472a6da in __cxa_pure_virtual () #8 0x00638c0f in llvm::raw_ostream::write (this=0x6f9b80, Ptr=0x69494d "While deleting: ", Size=16) at raw_ostream.cpp:249 #9 0x0063810e in llvm::circular_raw_ostream::write_impl (this=0x6f98c0, Ptr=0x69494d "While deleting: ", Size=16) at circular_raw_ostream.cpp:20 #10 0x00638c0f in llvm::raw_ostream::write (this=0x6f98c0, Ptr=0x69494d "While deleting: ", Size=16) at raw_ostream.cpp:249 #11 0x00206a3a in llvm::raw_ostream::operator<< (this=0x6f98c0, Str={static npos = 4294967295, Data = 0x69494d "While deleting: ", Length = 16}) at raw_ostream.h:179 #12 0x001ac141 in llvm::raw_ostream::operator<< (this=0x6f98c0, Str=0x69494d "While deleting: ") at raw_ostream.h:190 #13 0x005e1e24 in llvm::Value::~Value (this=0x48dc3d0) at Value.cpp:69 #14 0x000125e2 in llvm::User::~User (this=0x48dc3d0) at User.h:79 #15 0x000132f8 in llvm::Constant::~Constant (this=0x48dc3d0) at Constant.h:42 #16 0x000139f4 in llvm::ConstantExpr::~ConstantExpr (this=0x48dc3d0) at Constants.h:650 #17 0x00541de4 in llvm::GetElementPtrConstantExpr::~GetElementPtrConstantExpr (this=0x48dc3d0) at ConstantsContext.h:204 #18 0x005a080f in llvm::ConstantUniqueMap::freeConstants (this=0x180728c) at ConstantsContext.h:604 #19 0x0059c9d0 in llvm::LLVMContextImpl::~LLVMContextImpl (this=0x1807000) at LLVMContextImpl.cpp:64 #20 0x0059ae1c in llvm::LLVMContext::~LLVMContext (this=0x1501330) at LLVMContext.cpp:35 #21 0x0059b855 in llvm::object_deleter::call (Ptr=0x1501330) at ManagedStatic.h:31 #22 0x00624af4 in llvm::ManagedStaticBase::destroy (this=0x6f9308) at ManagedStatic.cpp:61 #23 0x00624b2d in llvm::llvm_shutdown () at ManagedStatic.cpp:71 #24 0x0000189e in do_shutdown () at lli.cpp:102 #25 0x94c79da7 in __cxa_finalize () #26 0x94c79c90 in exit () #27 0x00623266 in llvm::report_fatal_error (reason=@0xbfffe74c) at ErrorHandling.cpp:55 #28 0x00267e44 in llvm::ExecutionEngine::emitGlobals (this=0x1501620) at ExecutionEngine.cpp:1055 #29 0x0023b5ee in llvm::Interpreter::Interpreter (this=0x1501620, M=0x1511680) at Interpreter.cpp:55 #30 0x0023b663 in llvm::Interpreter::create (M=0x1511680, ErrStr=0xbfffe988) at Interpreter.cpp:41 #31 0x00263384 in llvm::EngineBuilder::create (this=0xbfffe910) at ExecutionEngine.cpp:480 #32 0x00001da3 in main (argc=30, argv=0xbfffea64, envp=0xbfffeae0) at lli.cpp:175 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 12 01:46:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 May 2010 01:46:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7119] Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. In-Reply-To: References: Message-ID: <20100512064656.8C1C03128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7119 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |baldrick at free.fr Resolution| |DUPLICATE --- Comment #3 from Duncan Sands 2010-05-12 01:46:56 CDT --- *** This bug has been marked as a duplicate of bug 7115 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 12 04:53:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 May 2010 04:53:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 7122] New: assert on invalid: Wrong callback for declspec without declarator Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7122 Summary: assert on invalid: Wrong callback for declspec without declarator 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 line causes an assertion in clang++ typedef typename selector::template rebind<1> I get the following output: $ clang++ t.cc t.cc:1:18: error: use of undeclared identifier 'selector' typedef typename selector::template rebind<1> ^ t.cc:1:28: error: expected a qualified name after 'typename' typedef typename selector::template rebind<1> ^ clang: SemaDecl.cpp:4815: clang::TypedefDecl* clang::Sema::ParseTypedefDecl(clang::Scope*, clang::Declarator&, clang::QualType, clang::TypeSourceInfo*): Assertion `D.getIdentifier() && "Wrong callback for declspec without declarator"' failed. 0 clang 0x000000000127ddaf 1 clang 0x000000000127ff3a 2 libpthread.so.0 0x00007f419c7938f0 3 libc.so.6 0x00007f419ba83a75 gsignal + 53 4 libc.so.6 0x00007f419ba875c0 abort + 384 5 libc.so.6 0x00007f419ba7c941 __assert_fail + 241 6 clang 0x000000000064f964 7 clang 0x00000000006563d0 8 clang 0x000000000065e537 9 clang 0x00000000006179a4 10 clang 0x000000000097706a 11 clang 0x0000000000978635 12 clang 0x000000000097e7d8 13 clang 0x000000000097e92c 14 clang 0x00000000009736a0 15 clang 0x00000000009738aa 16 clang 0x00000000006136db 17 clang 0x0000000000419811 18 clang 0x0000000000409d96 19 clang 0x000000000040cf33 main + 2435 20 libc.so.6 0x00007f419ba6ec4d __libc_start_main + 253 21 clang 0x0000000000407679 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 177 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-cwX1ly.s -x c++ t.cc 1. parser at end of file clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 12 05:53:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 May 2010 05:53:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 7123] New: boost accepts invalid code in boost::concept_check Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7123 Summary: boost accepts invalid code in boost::concept_check 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 Created an attachment (id=4881) --> (http://llvm.org/bugs/attachment.cgi?id=4881) Concept failing testcase The attached code compiles successfully in clang, but fails in g++ and comeau. I believe it is supposed to fail, and comes from a boost concept_check testcase. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 12 12:20:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 May 2010 12:20:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 6951] bugpoint crashes when debugging a miscompilation In-Reply-To: References: Message-ID: <20100512172023.7A5993128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6951 Jeffrey Yasskin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Jeffrey Yasskin 2010-05-12 12:20:22 CDT --- Darn. If you're up to debugging this, you should look for leaked Module objects. You may be able to find them by commenting out the llvm_shutdown_obj in bugpoint.cpp and valgrinding the bugpoint invocation that otherwise crashes. You can also track it down by gdb'ing to the crash, printing the address of the Module containing that @.str, then setting a conditional breakpoint in Module's constructor (b 'llvm::Module::Module' if this==0xaddr) and looking at the backtrace to see if that shows where ownership is lost. I may be able to work from just the valgrind leak reports. I can definitely fix it if you can send me a way to reproduce the problem on x86. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 12 12:27:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 May 2010 12:27:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 7123] clang accepts invalid code in boost::concept_check In-Reply-To: References: Message-ID: <20100512172738.2F6143128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7123 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-12 12:27:37 CDT --- Thanks for the reduction! Fixed in r103624 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 12 16:23:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 May 2010 16:23:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7085] is_convertible miscompile in boost In-Reply-To: References: Message-ID: <20100512212332.6F0BB3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7085 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Douglas Gregor 2010-05-12 16:23:32 CDT --- Clang seems to be behaving the same way as GCC and EDG on this example (successfully compiling the example). Please re-open if you are seeing different behavior. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 12 23:32:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 May 2010 23:32:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 7125] New: TargetData::getAlignmentInfo() cannot handle FLOAT_ALIGN Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7125 Summary: TargetData::getAlignmentInfo() cannot handle FLOAT_ALIGN Product: new-bugs Version: trunk Platform: All OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: bparadie at adobe.com CC: llvmbugs at cs.uiuc.edu Compile this code: long double return_long_double() { return -1; } llc -march=sparc throws this assert: Assertion failed: (AlignType == VECTOR_ALIGN && "Unknown alignment type!"), function getAlignmentInfo, file TargetData.cpp, line 296. I used the latest version of TargetData.cpp: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/TargetData.cpp?revision=102206&view=markup Works in llvm-2.1. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 13 01:24:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 01:24:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 7126] New: Clang should always provide (aka ...) info Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7126 Summary: Clang should always provide (aka ...) info Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Keywords: quality-of-implementation Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This is just embarressing: % cat t7.cc typedef long Py_ssize_t; int foo(Py_ssize_t *); int bar() { typedef int Py_ssize_t; Py_ssize_t pos; return foo(&pos); } % ./bin/clang++ -fsyntax-only t7.cc t7.cc:8:9: error: no matching function for call to 'foo' return foo(&pos); ^~~ t7.cc:3:5: note: candidate function not viable: no known conversion from 'Py_ssize_t *' to 'Py_ssize_t *' for 1st argument int foo(Py_ssize_t *); ^ 1 error generated. GCC does the same thing because it doesn't even *have* the real type names, but we can do 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 Thu May 13 03:23:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 03:23:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 7127] New: clang confused by double throw Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7127 Summary: clang confused by double throw 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 Created an attachment (id=4882) --> (http://llvm.org/bugs/attachment.cgi?id=4882) Example showing double throw issue. The attached code causes termination by an exception escaping. The 'rethrow' does not appear to be caught by the (...). This bug does not appear on Snow Leopard, but it does occur on both Leopard and Ubuntu. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 04:19:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 04:19:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7052] Global Value Numbering assertion failure: "bitwidth too small" In-Reply-To: References: Message-ID: <20100513091900.946883128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7052 Jakub Staszak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kuba at gcc.gnu.org Resolution| |FIXED --- Comment #5 from Jakub Staszak 2010-05-13 04:19:00 CDT --- Fixed in r103347. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 04:19:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 04:19:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 7129] New: clang -O1 -g doesn't add !dbg metadata, but clang -g -O0 + opt -O1 has !dbg metadata Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7129 Summary: clang -O1 -g doesn't add !dbg metadata, but clang -g -O0 + opt -O1 has !dbg metadata Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4884) --> (http://llvm.org/bugs/attachment.cgi?id=4884) testcase With Clang 2.7. On the attached testcase: -O0 -g generates proper debug info: $ clang -w -O0 -g x.i -emit-llvm -S -o -|grep hex2int %call23.i.i.i = call i32 (...)* @cli_hex2int(i32 %conv22.i.i.i) nounwind, !dbg !146 ; [#uses=1] %call30.i.i.i = call i32 (...)* @cli_hex2int(i32 %conv29.i.i.i) nounwind, !dbg !146 ; [#uses=1] declare i32 @cli_hex2int(...) But -O1 -g doesn't have it anymore: $ clang -w -O1 -g x.i -emit-llvm -S -o -|grep hex2int %call23.i.i.i = call i32 (...)* @cli_hex2int(i32 %conv22.i.i.i) nounwind ; [#uses=1] %call30.i.i.i = call i32 (...)* @cli_hex2int(i32 %conv29.i.i.i) nounwind ; [#uses=1] declare i32 @cli_hex2int(...) If I save -O0 to bitcode and use opt -O1 the debug info is still there: $ clang -w -O0 -g x.i -emit-llvm -c -o x.bc $ opt -O1 x.bc -S -o -|grep hex2int %call23.i.i.i = call i32 (...)* @cli_hex2int(i32 %conv22.i.i.i) nounwind, !dbg !63 ; [#uses=1] %call30.i.i.i = call i32 (...)* @cli_hex2int(i32 %conv29.i.i.i) nounwind, !dbg !63 ; [#uses=1] declare i32 @cli_hex2int(...) Looks like something related to always_inline attribute, if I remove it from the first function, then there is !dbg metadata. Is clang's inliner loosing track of debug locations? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 07:11:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 07:11:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 7000] Diagnostic for Invalid Cast should give Actual Type Name in addition to Typedef Type Name In-Reply-To: References: Message-ID: <20100513121133.8F52A3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7000 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |chandlerc at gmail.com Resolution| |FIXED --- Comment #1 from Chandler Carruth 2010-05-13 07:11:32 CDT --- As of r103712, Clang should produce: % ./bin/clang++ t8.cc t8.cc:4:25: error: static_cast from 'char *' to 'value_type const *' (aka 'unsigned char const *') is not allowed value_type const *p = static_cast(p_); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ t8.cc:8:3: note: in instantiation of function template specialization 'update_n' requested here update_n(s); ^ 1 error generated. I think this fixes the issue, but feel free to re-open if there are further tweaks. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 07:13:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 07:13:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 7126] Clang should always provide (aka ...) info In-Reply-To: References: Message-ID: <20100513121328.E45D63128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7126 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chandler Carruth 2010-05-13 07:13:28 CDT --- As of r103712: % ./bin/clang++ t7.cc t7.cc:8:9: error: no matching function for call to 'foo' return foo(&pos); ^~~ t7.cc:3:5: note: candidate function not viable: no known conversion from 'Py_ssize_t *' (aka 'int *') to 'Py_ssize_t *' (aka 'long *') for 1st argument int foo(Py_ssize_t *); ^ 1 error generated. Which is I think enough detail to clear up the confusion. If folks really want a note on the colliding typedefs, reopen, but I'm not entirely sold on the idea. I think the aka tells you why the conversion failed, and looking up the types shouldn't be that bad. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 10:43:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 10:43:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 7130] New: Clang++ fails to calculate const double for global variables Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7130 Summary: Clang++ fails to calculate const double for global variables Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nbigaouette at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4886) --> (http://llvm.org/bugs/attachment.cgi?id=4886) Simple source file showing the problem. In my project I put const doubles in a header file for global variables. But I just realized that clang++ failed to calculate them correctly. I've created an example program which shows the problem. I'll be attaching it next. The file only contains variables with the factors to convert bytes, kibibyte, mebibytes and gibibyte. The values are then outputed. If the variables are declared/defined globally, their values are wrong. If they are declared/defined locally, they are good. g++ correctly calculates them. $ clang++ const_double.cpp -o const_double && ./const_double B_to_KiB =0.000976562 B_to_MiB =9.53674e-07 B_to_GiB =0 KiB_to_B =1024 KiB_to_MiB =0 KiB_to_GiB =0 MiB_to_B =inf MiB_to_KiB =inf MiB_to_GiB =0.000976562 GiB_to_B =inf GiB_to_KiB =inf GiB_to_MiB =1024 compared to: $ g++ const_double.cpp -o const_double && ./const_double B_to_KiB = 0.000976562 B_to_MiB = 9.53674e-07 B_to_GiB = 9.31323e-10 KiB_to_B = 1024 KiB_to_MiB = 1 KiB_to_GiB = 0.000976562 MiB_to_B = 1.04858e+06 MiB_to_KiB = 1 MiB_to_GiB = 0.000976562 GiB_to_B = 1.07374e+09 GiB_to_KiB = 1024 GiB_to_MiB = 1024 Using clang built from svn revision 103172 on ArchLinux. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 12:17:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 12:17:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 6564] Assertion failed: Key function changed In-Reply-To: References: Message-ID: <20100513171748.589483128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6564 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2010-05-13 12:17:47 CDT --- This ended up getting fixed as part of a major reworking of how/when we emit vtables, in r103718. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 12:17:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 12:17:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7114] Clang instantiates implicit virtual destructor too early In-Reply-To: References: Message-ID: <20100513171755.EB56C3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7114 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-13 12:17:55 CDT --- Fixed in r103718. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 12:23:13 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 12:23:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 6583] Missing symbol in binary causes undefined symbol error during linking... In-Reply-To: References: Message-ID: <20100513172313.926DA3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6583 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-13 12:23:13 CDT --- Should be fixed in r103718. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 12:25:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 12:25:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 6610] rejects valid friend declaration In-Reply-To: References: Message-ID: <20100513172550.C41AF3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6610 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #10 from Douglas Gregor 2010-05-13 12:25:49 CDT --- Clang is now accepting all of the test cases in this Bugzilla. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 13 12:29:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 12:29:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 6957] specialization of virtual function member trigger a compilation error In-Reply-To: References: Message-ID: <20100513172950.4BDDA3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6957 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-13 12:29:49 CDT --- Fixed in r103718. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 12:32:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 12:32:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 7091] Assertion `I != E && "Did not find a destructor! In-Reply-To: References: Message-ID: <20100513173233.89DB43128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7091 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Douglas Gregor 2010-05-13 12:32:33 CDT --- This appears to be working now. Please re-open if you're still seeing 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 May 13 14:29:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 14:29:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 7131] New: simple Cocoa application crashes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7131 Summary: simple Cocoa application crashes Product: tools Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: lli AssignedTo: unassignedbugs at nondot.org ReportedBy: ich at az2000.de CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4889) --> (http://llvm.org/bugs/attachment.cgi?id=4889) code az at ip245 70 (build-llvm-bitcode) %~/Programmierung/CppIDE/llvm-src/Debug/bin/lli -load=/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa hello.bc 0 lli 0x006446da PrintStackTrace(void*) + 46 1 lli 0x00644b20 SignalHandler(int) + 372 2 libSystem.B.dylib 0x91c3f42b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1849428991 4 lli 0x002649a3 llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::vector > const&, char const* const*) + 1135 5 lli 0x000021ad main + 2313 6 lli 0x00001836 start + 54 7 lli 0x00000003 start + 4294961155 Stack dump: 0. Program arguments: /Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/lli -load=/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa hello.bc zsh: segmentation fault ~/Programmierung/CppIDE/llvm-src/Debug/bin/lli hello.bc -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 14:36:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 14:36:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 4936] Win64 visual studio build does not compile ASM correctly In-Reply-To: References: Message-ID: <20100513193626.E429A3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4936 ?scar Fuentes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from ?scar Fuentes 2010-05-13 14:36:26 CDT --- Patch applied on r 103727. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 13 14:58:39 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 14:58:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 7110] llc generates a non thumb instruction when thumb is specified In-Reply-To: References: Message-ID: <20100513195839.73E573128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7110 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Bob Wilson 2010-05-13 14:58:39 CDT --- Fixed in svn 103730. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 16:38:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 16:38:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 6747] missed optimization for inline virtual methods In-Reply-To: References: Message-ID: <20100513213812.9820D3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6747 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #6 from Douglas Gregor 2010-05-13 16:38:12 CDT --- We've had to remove this optimization in r103741; see the comment in that commit. We can revisit this optimization later. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 16:44:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 16:44:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 7132] New: [C++ CodeGen] Cannot catch std::bad_cast Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7132 Summary: [C++ CodeGen] Cannot catch std::bad_cast Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Blocks: 6023 We aren't able to catch a std::bad_cast in a catch block, as in the following test: terfin:clang dgregor$ cat t.cpp #include extern "C" void abort(); extern "C" int printf(const char*, ...); struct A { virtual ~A() { } }; struct B : A { virtual ~B() { } }; int main() { A *a = new A(); try { (void)dynamic_cast(*a); printf("Survived dynamic_cast?\n"); abort(); } catch (const std::bad_cast &) { // Okay return 0; } printf("Did not catch std::bad_cast?\n"); abort(); return 0; } terfin:clang dgregor$ clang++ t.cpp && ./a.out Survived dynamic_cast? Abort trap terfin:clang dgregor$ g++ t.cpp && ./a.out The problem is in the "catch" handling; if g++ compiles the try/catch and either clang or g++ compile the dynamic_cast, the program works as expected. If clang compiles the try/catch, it fails. This affects Boost.StateChart. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 18:00:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 18:00:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 7133] New: clang doesn't enter intermediate scopes for out-of-line definitions of namespace members Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7133 Summary: clang doesn't enter intermediate scopes for out-of-line definitions of namespace members Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com namespace A { class Foo; } namespace A { namespace B { bool foo(Foo &); } } bool A::B::foo(Foo &) { return false; } daysthatwere:clang rjmccall$ clang++ /tmp/red.cpp /tmp/red.cpp:11:12: error: redefinition of 'foo' as different kind of symbol bool A::B::foo(Foo &) { ^ /tmp/red.cpp:7:10: note: previous definition is here bool foo(Foo &); ^ /tmp/red.cpp:11:16: error: use of undeclared identifier 'Foo' bool A::B::foo(Foo &) { ^ /tmp/red.cpp:11:22: error: invalid token after top level declarator bool A::B::foo(Foo &) { ^ ; 3 errors generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 13 18:13:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 18:13:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 7131] simple Cocoa application crashes In-Reply-To: References: Message-ID: <20100513231352.2F9CD3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7131 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2010-05-13 18:13:51 CDT --- This is because objc classes aren't registered with the runtime when run through the JIT. Getting this to work is a huge amount of hassle that isn't worth the trouble. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 19:58:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 19:58:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 7134] New: the gold plugin is installed as liblibLLVMgold.so Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7134 Summary: the gold plugin is installed as liblibLLVMgold.so Product: Build scripts Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu $ ls Release/lib/*gold*so Release/lib/libLLVMgold.so OK $ ls ../llvm-inst/lib/*gold*so ../llvm-inst/lib/liblibLLVMgold.so That is one lib too many :-) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 21:29:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 21:29:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 7135] New: cast unsigned long -> double -> int gets assertion with -mno-mmx Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7135 Summary: cast unsigned long -> double -> int gets assertion with -mno-mmx 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: nomura at netapp.com CC: llvmbugs at cs.uiuc.edu [cyclsvl01]$ /u/nomura/dl/Installed/clang/bin/clang -mno-mmx -c bug.i fatal error: error in backend: Cannot yet select: 0x1509e0d0: f64 = bit_convert 0x1509ded0 [ID=20] 0x1509ded0: i64 = or 0x1509dbd0, 0x1509c690 [ID=18] 0x1509dbd0: i64 = and 0x1509c290, 0x1509cf90 [ID=15] 0x1509c290: i64,ch = CopyFromReg 0x15085af8, 0x1509c190 [ORD=1] [ID=12] 0x15085af8: ch = EntryToken [ORD=1] [ID=0] 0x1509c190: i64 = Register %reg1024 [ORD=1] [ID=1] 0x1509cf90: i64 = Constant<4294967295> [ID=8] 0x1509c690: i64 = Constant<4841369599423283200> [ID=6] [cyclsvl01]$ cat bug.i unsigned long x; int foo() { return (int)(double)x; } I checked out llvm and clang from svn a couple days ago: [cyclsvl01]$ svnversion . 103473 and built with ../llvm/configure --prefix=/u/nomura/dl/Installed/clang --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --target=x86_64-unknown-freebsd7 --enable-debug-symbols 2>&1 | tee log host is Linux cyclsvl01.eng.netapp.com 2.6.18-164.10.1.el5 #1 SMP Wed Dec 30 18:35:28 EST 2009 x86_64 x86_64 x86_64 GNU/Linux -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 23:02:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 23:02:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7136] New: InstCombine lowerize w/TD to lose type information Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7136 Summary: InstCombine lowerize w/TD to lose type information Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu A simple example to allocate and initialize an object. --- define %struct.A* @foo(i32 %a, i32 %b) nounwind { entry: %0 = call noalias i8* @malloc(i32 8) nounwind ; [#uses=1] %1 = bitcast i8* %0 to %struct.A* ; <%struct.A*> [#uses=4] %2 = icmp ne %struct.A* %1, null ; [#uses=1] br i1 %2, label %bb, label %return bb: %3 = getelementptr inbounds %struct.A* %1, i32 0, i32 0 ; [#uses=1] store i32 %a, i32* %3, align 4 %4 = getelementptr inbounds %struct.A* %1, i32 0, i32 1 ; [#uses=1] store i32 %b, i32* %4, align 4 br label %return return: ret %struct.A* %1 } --- The pass "InstCombine" strips and lowerizes type information as below. --- define %struct.A* @foo(i32 %a, i32 %b) nounwind { entry: %0 = call noalias i8* @malloc(i32 8) nounwind ; [#uses=4] %1 = bitcast i8* %0 to %struct.A* ; <%struct.A*> [#uses=1] %2 = icmp eq i8* %0, null ; [#uses=1] br i1 %2, label %return, label %bb bb: ; preds = %entry %3 = bitcast i8* %0 to i32* ; [#uses=1] store i32 %a, i32* %3, align 4 %4 = getelementptr inbounds i8* %0, i32 4 ; [#uses=1] %5 = bitcast i8* %4 to i32* ; [#uses=1] store i32 %b, i32* %5, align 4 br label %return return: ; preds = %bb, %entry ret %struct.A* %1 } --- It makes following analysis harder, I guess. I think, it would not needed to convert when; * origBase has generic pointer type (eg. i8 *) * origBase is derived from allocation at InstCombiner::commonPointerCastTransforms(CastInst &CI); (FYI, my environment as below) --- target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i386-mingw32" %struct.A = type { i32, i32 } declare noalias i8* @malloc(i32) nounwind --- -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 23:53:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 May 2010 23:53:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7133] clang doesn't enter intermediate scopes for out-of-line definitions of namespace members In-Reply-To: References: Message-ID: <20100514045355.3BAB8312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7133 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-13 23:53:54 CDT --- Fixed in r103766. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 00:08:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 00:08:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 6596] Assertion failed: (Ctx->isFileContext() && "We should have been looking only at file context here already."), function CppLookupName, file SemaLookup.cpp, line 730. In-Reply-To: References: Message-ID: <20100514050834.9099B3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6596 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2010-05-14 00:08:33 CDT --- Fixed in r103767. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 01:26:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 01:26:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7136] InstCombine lowerize w/TD to lose type information In-Reply-To: References: Message-ID: <20100514062614.DAF8D312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7136 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2010-05-14 01:26:14 CDT --- This is behaving correctly. You can disable this by removing the targetdata string. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 14 02:28:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 02:28:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7137] New: Dead store elimination removes only one store per pass in simple case Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7137 Summary: Dead store elimination removes only one store per pass in simple case Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: matti.niemenmaa+llvmbugs at iki.fi CC: llvmbugs at cs.uiuc.edu The dead store elimination pass removes only one store every time it is run on the IR given by clang for the following C. #include #include int main() { long *x = malloc(512); x[0] = 100; x[1] = 200; x[2] = 300; x[3] = 400; putchar((int)x[0]); free(x); putchar(10); return 0; } The IR generated by 'clang -emit-llvm -c' looks like this to start with: target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" define i32 @main() nounwind { %1 = alloca i32, align 4 ; [#uses=3] %x = alloca i64*, align 8 ; [#uses=7] store i32 0, i32* %1 %2 = call i8* @malloc(i64 512) ; [#uses=1] %3 = bitcast i8* %2 to i64* ; [#uses=1] store i64* %3, i64** %x %4 = load i64** %x ; [#uses=1] %5 = getelementptr inbounds i64* %4, i64 0 ; [#uses=1] store i64 100, i64* %5 %6 = load i64** %x ; [#uses=1] %7 = getelementptr inbounds i64* %6, i64 1 ; [#uses=1] store i64 200, i64* %7 %8 = load i64** %x ; [#uses=1] %9 = getelementptr inbounds i64* %8, i64 2 ; [#uses=1] store i64 300, i64* %9 %10 = load i64** %x ; [#uses=1] %11 = getelementptr inbounds i64* %10, i64 3 ; [#uses=1] store i64 400, i64* %11 %12 = load i64** %x ; [#uses=1] %13 = getelementptr inbounds i64* %12, i64 0 ; [#uses=1] %14 = load i64* %13 ; [#uses=1] %15 = trunc i64 %14 to i32 ; [#uses=1] %16 = call i32 @putchar(i32 %15) ; [#uses=0] %17 = load i64** %x ; [#uses=1] %18 = bitcast i64* %17 to i8* ; [#uses=1] call void @free(i8* %18) nounwind %19 = call i32 @putchar(i32 10) ; [#uses=0] store i32 0, i32* %1 %20 = load i32* %1 ; [#uses=1] ret i32 %20 } declare noalias i8* @malloc(i64) nounwind declare i32 @putchar(i32) declare void @free(i8*) nounwind One round of 'opt -O3' (using opt from SVN trunk, r103765) later main looks like: define i32 @main() nounwind { %1 = tail call i8* @malloc(i64 512) ; [#uses=4] %2 = bitcast i8* %1 to i64* ; [#uses=1] store i64 100, i64* %2 %3 = getelementptr inbounds i8* %1, i64 8 ; [#uses=1] %4 = bitcast i8* %3 to i64* ; [#uses=1] store i64 200, i64* %4 %5 = getelementptr inbounds i8* %1, i64 16 ; [#uses=1] %6 = bitcast i8* %5 to i64* ; [#uses=1] store i64 300, i64* %6 %7 = tail call i32 @putchar(i32 100) nounwind ; [#uses=0] tail call void @free(i8* %1) nounwind %8 = tail call i32 @putchar(i32 10) nounwind ; [#uses=0] ret i32 0 } It may be enough of a bug that it's not already been optimized to just the two putchar calls, given that the malloc/free and stores are all redundant. If we run 'opt -dse' on the above, we're left with: define i32 @main() nounwind { %1 = tail call i8* @malloc(i64 512) ; [#uses=3] %2 = bitcast i8* %1 to i64* ; [#uses=1] store i64 100, i64* %2 %3 = getelementptr inbounds i8* %1, i64 8 ; [#uses=1] %4 = bitcast i8* %3 to i64* ; [#uses=1] store i64 200, i64* %4 %5 = tail call i32 @putchar(i32 100) nounwind ; [#uses=0] tail call void @free(i8* %1) nounwind %6 = tail call i32 @putchar(i32 10) nounwind ; [#uses=0] ret i32 0 } Only one store was removed! This means that in order to get rid of all the stores, we need to run DSE three more times after the original -O3 passes. And indeed, 'opt -O3 -dse -dse -dse' is sufficient to get rid of all the stores; we then only need another '-instcombine' to get rid of the malloc/free. This seems terribly suboptimal: can't it be done in a single pass? Ideally, the original 'opt -O3' would've reduced the whole thing. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 14 03:51:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 03:51:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 7138] New: clang incorrectly double-instantiates friend of template class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7138 Summary: clang incorrectly double-instantiates friend of template class 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 Created an attachment (id=4890) --> (http://llvm.org/bugs/attachment.cgi?id=4890) Friend example The attached code is reduced from a boost test which should fail, but passes in clang++. This technique is used to stop inconsistencies in boost::units, so the compile-invalid can lead to invalid code (from the library point of view) being compiled. Problematic code: template struct base_dimension { friend int boost_units_is_registered( ) { } }; struct int1 : base_dimension {}; struct dim2 : base_dimension {}; -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 10:14:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 10:14:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7138] clang incorrectly double-instantiates friend of template class In-Reply-To: References: Message-ID: <20100514151414.07A313128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7138 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Douglas Gregor 2010-05-14 10:14:13 CDT --- *** This bug has been marked as a duplicate of bug 6952 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 11:52:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 11:52:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 7139] New: ptr to member not zeroed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7139 Summary: ptr to member not zeroed 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 Created an attachment (id=4892) --> (http://llvm.org/bugs/attachment.cgi?id=4892) Ptr to member example The attached code shows that clang++ is not correctly zeroing pointers to members. This code compiles and runs correctly in g++. This code is reduced from boost. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 11:59:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 11:59:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7140] New: Return retain-count assumptions are invalid Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7140 Summary: Return retain-count assumptions are invalid Product: clang Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: lukes.dylan at gmail.com CC: llvmbugs at cs.uiuc.edu In a method for example named: -dataNoCopyForColumnIndex: the static analyzer does not take into consideration the "No", which by the camelcase convention is clearly a whole word, not a portion. The clang analyzer should not expect a +1 return value if "NoCopy" is explicitly used. "NoCopy" is used as a phase in various standard library components, such as NSData as well. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 14 12:11:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 12:11:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7142] New: Assertion failed: (CurFn->isDeclaration() && "Function already has body?"), function StartFunction, file CodeGenFunction.cpp, line 172. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7142 Summary: Assertion failed: (CurFn->isDeclaration() && "Function already has body?"), function StartFunction, file CodeGenFunction.cpp, line 172. Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu pes delta$ clang BasicAliasAnalysis.cpp Assertion failed: (CurFn->isDeclaration() && "Function already has body?"), function StartFunction, file CodeGenFunction.cpp, line 172. Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name BasicAliasAnalysis.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 116 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-EnUuMi.s -x c++ BasicAliasAnalysis.cpp 1. parser at end of file 2. Per-file LLVM IR generation 3. BasicAliasAnalysis.cpp:65:26: Generating code for declaration '::BasicAliasAnalysis::~BasicAliasAnalysis' clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 14 12:25:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 12:25:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7140] Return retain-count assumptions are invalid In-Reply-To: References: Message-ID: <20100514172542.639993128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7140 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |INVALID --- Comment #1 from Ted Kremenek 2010-05-14 12:25:42 CDT --- I have been over the 'NoCopy' issue with the Cocoa folks, and technically this violates the Cocoa naming convention. You have an out: use the 'ns_returns_not_retained' attribute. Currently this is available in the latest open source checker builds. Usage is identical to 'ns_returns_retained', see: http://clang-analyzer.llvm.org/annotations.html#attr_ns_returns_retained -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 13:00:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 13:00:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7140] Return retain-count assumptions are invalid In-Reply-To: References: Message-ID: <20100514180056.DCAC8312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7140 lukes.dylan at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |FIXED --- Comment #2 from lukes.dylan at gmail.com 2010-05-14 13:00:56 CDT --- 'ns_returns_not_retained' should be included on the annotations page. If I'd been able to find it earlier that would have been helpful. Thank you very much for your help. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 14 16:43:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 16:43:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 7143] New: error: SSE register return with SSE disabled (with -mno-mmx) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7143 Summary: error: SSE register return with SSE disabled (with -mno-mmx) 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: nomura at netapp.com CC: llvmbugs at cs.uiuc.edu Compiling floating-point code with -mno-mmx, clang aborts as follows: [cyclsvl05]$ cat bug.i double bar (void); double foo() { return bar()+1.0; } /u/nomura/dl/Installed/clang/bin/clang -c -O0 -mno-mmx -w bug.i fatal error: error in backend: SSE register return with SSE disabled gcc would issue a similar error if -mno-sse were specified. But gcc with -mno-mmx appears to proceed happily using SSE registers, for example: [cyclsvl05]$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-46) [cyclsvl05]$ gcc -O0 -mno-mmx -S bug.i [cyclsvl05]$ .LCFI0: movq %rsp, %rbp .LCFI1: subq $16, %rsp .LCFI2: call bar movapd %xmm0, %xmm1 movsd .LC0(%rip), %xmm0 addsd %xmm1, %xmm0 movsd %xmm0, -8(%rbp) movq -8(%rbp), %rax movq %rax, -8(%rbp) movsd -8(%rbp), %xmm0 leave ret I'm using a sync of clang+llvm from a couple days ago. Is clang doing the right thing by aborting? (If so, what clang options would you suggest to obtain compatibility with gcc and -mno-mmx?) Thanks. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 14 16:44:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 16:44:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7132] [C++ CodeGen] Cannot catch std::bad_cast In-Reply-To: References: Message-ID: <20100514214456.264723128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7132 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-05-14 16:44:55 CDT --- This is fixed in r103810. Boost.Statechart is passing now, and the Boost.ProgramOptions failures seem distinct from this bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 14 17:05:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 17:05:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 7143] error: SSE register return with SSE disabled (with -mno-mmx) In-Reply-To: References: Message-ID: <20100514220533.D02E6312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7143 Kevin Nomura changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Depends on| |7135 Resolution| |DUPLICATE --- Comment #1 from Kevin Nomura 2010-05-14 17:05:33 CDT --- *** This bug has been marked as a duplicate of bug 7135 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 17:44:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 17:44:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 7144] New: [C++ CodeGen] Erroneous __cxa_guard_abort call when throwing after a static is fully initialized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7144 Summary: [C++ CodeGen] Erroneous __cxa_guard_abort call when throwing after a static is fully initialized Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Blocks: 6023 Created an attachment (id=4893) --> (http://llvm.org/bugs/attachment.cgi?id=4893) Affected test case When compiled with Clang, the attached test case aborts at run-time. Here's what's happening: - We call __cxa_guard_acquire before initializing the static - We initialize the static X - We call __cxa_guard_release after initializing the static (good) - We throw Y as an exception - Unwinding calls __cxa_guard_abort on the static X - Boom! It appears that the __cxa_guard_abort call is in the wrong EH cleanup block. This breaks Boost.ProgramOptions. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 19:29:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 19:29:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 7145] New: Error with handling casting operator to SSE2 SIMD types Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7145 Summary: Error with handling casting operator to SSE2 SIMD types Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joel.falcou at lri.fr CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Here is a sample file that compiles correctly on g++ and MSVC: #include #include template struct foo { V m; operator V() const { return m; } }; int main() { foo <__m128> x = {{1, 2, 3, 4}}; __m128 y = _mm_shuffle_ps(x, x, 0); } Latets clang (fresh from the SVN) on Linux x86 give the following error: src/pipo.cpp:16:14: error: first two arguments to __builtin_shufflevector must be vectors __m128 y = _mm_shuffle_ps(x, x, 0); ^~~~~~~~~~~~~~~~~~~~~~~ In file included from src/pipo.cpp:2: /usr/local/lib/clang/2.0/include/xmmintrin.h:726:10: note: instantiated from: (__builtin_shufflevector(a, b, (mask) & 0x3, ((mask) & 0xc) >> 2, \ ^ 1 error generated. This error doesn't appear if we use _mm_add_ps or other intrinsics. Same behavior for __m128i and __m128d -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 23:33:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 May 2010 23:33:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7071] Less-than-awesome warning about unreachable code In-Reply-To: References: Message-ID: <20100515043351.B77A83128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7071 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2010-05-14 23:33:51 CDT --- This is the same root issue as 5544. *** This bug has been marked as a duplicate of bug 5544 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 15 11:22:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 May 2010 11:22:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7145] Error with handling casting operator to SSE2 SIMD types In-Reply-To: References: Message-ID: <20100515162206.D099F3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7145 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2010-05-15 11:22:06 CDT --- Oh, this was the discussion on cfe-dev. Fixed in mainline, 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 Sat May 15 12:56:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 May 2010 12:56:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7144] [C++ CodeGen] Erroneous __cxa_guard_abort call when throwing after a static is fully initialized In-Reply-To: References: Message-ID: <20100515175632.46EC23128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7144 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-15 12:56:32 CDT --- Fixed in r103880. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 15 19:44:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 May 2010 19:44:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7144] [C++ CodeGen] Erroneous __cxa_guard_abort call when throwing after a static is fully initialized In-Reply-To: References: Message-ID: <20100516004414.4E0693128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7144 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #2 from Douglas Gregor 2010-05-15 19:44:14 CDT --- Patch reverted in r103890. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 15 20:24:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 May 2010 20:24:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 7144] [C++ CodeGen] Erroneous __cxa_guard_abort call when throwing after a static is fully initialized In-Reply-To: References: Message-ID: <20100516012438.12E6B3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7144 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-15 20:24:37 CDT --- Re-fixed in r103892. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 10:45:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 10:45:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 7147] New: Error new'ing with typedef of array type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7147 Summary: Error new'ing with typedef of array type Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Blocks: 6023 In the following test, from Boost.Python, we appear to be new'ing the wrong type: cove:test dgregor$ cat t.cpp struct foo { foo() {} ~foo() {} }; int main() { typedef int a[2]; foo* f1 = new foo; foo* f2 = new foo[2]; typedef foo x[2]; typedef foo y[2][2]; x* f3 = new y; return 0; } cove:test dgregor$ clang++ t.cpp t.cpp:10:8: error: cannot initialize a variable of type 'x *' (aka 'foo (*)[2]') with an rvalue of type 'y *' (aka 'foo (*)[2][2]') x* f3 = new y; ^ 1 error generated. cove:test dgregor$ g++ t.cpp cove:test dgregor$ eccp t.cpp -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 11:01:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 11:01:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 7147] Error new'ing with typedef of array type In-Reply-To: References: Message-ID: <20100516160157.8184D3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7147 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-16 11:01:57 CDT --- Fixed in r103908. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 13:24:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 13:24:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 7135] cast unsigned long -> double -> int gets assertion with -mno-mmx In-Reply-To: References: Message-ID: <20100516182426.8FC013128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7135 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Dale Johannesen 2010-05-16 13:24:26 CDT --- I fixed the crash here. http://llvm.org/viewvc/llvm-project?rev=103911&view=rev The clang mishandling of -no-mmx is a separate problem, so I'll reopen 7143 for 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 Sun May 16 13:28:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 13:28:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 7143] error: SSE register return with SSE disabled (with -mno-mmx) In-Reply-To: References: Message-ID: <20100516182859.845FF3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7143 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |dalej at apple.com Component|new bugs |-New Bugs Resolution|DUPLICATE | AssignedTo|unassignedbugs at nondot.org |unassignedclangbugs at nondot. | |org Product|new-bugs |clang --- Comment #2 from Dale Johannesen 2010-05-16 13:28:58 CDT --- 7135 is really about a crash with -mno-sse, a different bug. The fact that -mno-mmx is handled differently by clang than by gcc is a clang bug. -mno-mmx should not turn on -mno-sse. (It is a not a description of what hardware is available, but an instruction to the compiler.) As for the error, the calling convention in that environment uses SSE (I think), so it's reasonable to give an error if that is not available, IMO. I'm not sure of the details of the environment though. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 15:07:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 15:07:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 7148] New: alignment attribute don't pass through template meta-function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7148 Summary: alignment attribute don't pass through template meta-function Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joel.falcou at lri.fr CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code: #include template struct align_on_16 { typedef T __attribute__((aligned(16))) type; }; int main() { // this works float __attribute__((aligned(16))) x; std::cout << (void*)(&x) << std::endl; // this works typedef float __attribute__((aligned(16))) x_t; x_t y; std::cout << (void*)(&y) << std::endl; // this doesn't work typedef align_on_16::type a_t; a_t z; std::cout << (void*)(&z) << std::endl; } don't produce expected result for &z. It seems related to Bug #6322. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 15:21:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 15:21:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 7135] cast unsigned long -> double -> int gets assertion with -mno-mmx In-Reply-To: References: Message-ID: <20100516202123.E09003128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7135 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #5 from Dale Johannesen 2010-05-16 15:21:23 CDT --- Had to back out this patch because it broke something else. Shouldn't be hard to fix along the lines suggested in the reversion commit message, but I don't have time right now. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 16:27:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 16:27:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 7149] New: clang boost boost.geometry Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7149 Summary: clang boost boost.geometry Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: barend at xs4all.nl CC: llvmbugs at cs.uiuc.edu The file stops the clang compiler. It compiles fine in gcc and MSVC. Most (if not all) other files compile fine and I found some errors (additional .template necessary) in my code, so thanks very much for this great compiler. Commands to reproduce: 1) Checking out Boost.Geometry, e.g. svn co https://svn.boost.org/svn/boost/sandbox/geometry boost_geometry 2) cd boost_geometry/libs/geometry/test/geometries 3) clang -I.. -I../../../.. segment.cpp -lstdc++ -v (I did try to make a minimal sample without Boost.Geometry but that one compiled fine) Message: (...) #include "..." search starts here: #include <...> search starts here: .. ../../../.. /home/barend/svn/llvm/Release/lib/clang/2.0/include /usr/include/c++/4.4 /usr/include/c++/4.4/backward /usr/include/c++/4.4/i486-linux-gnu /usr/local/include /usr/include End of search list. clang: CodeGenFunction.h:1341: void clang::CodeGen::CodeGenFunction::EmitCallArgs(clang::CodeGen::CallArgList&, const T*, clang::ConstExprIterator, clang::ConstExprIterator) [with T = clang::FunctionProtoType]: Assertion `getContext().getCanonicalType(ArgType.getNonReferenceType()). getTypePtr() == getContext().getCanonicalType(Arg->getType()).getTypePtr() && "type mismatch in call argument!"' failed. 0 clang 0x09007368 Stack dump: 0. Program arguments: /home/barend/svn/llvm/Release/bin/clang -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name segment.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -v -resource-dir /home/barend/svn/llvm/Release/lib/clang/2.0 -I.. -I../../../.. -ferror-limit 19 -fmessage-length 0 -fexceptions -fgnu-runtime -fdiagnostics-show-option -o /tmp/cc-tULQw7.s -x c++ segment.cpp 1. parser at end of file 2. Per-file LLVM IR generation 3. segment.cpp:31:6: Generating code for declaration 'test_all' 4. segment.cpp:32:1: LLVM IR generation of compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 17:05:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 17:05:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 7150] New: transparent_unions makes clang ICE Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7150 Summary: transparent_unions makes clang ICE Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: madcoder at debian.org CC: llvmbugs at cs.uiuc.edu clang sometimes ICEs with transparent unions for code that compiles fine with gcc. $ gcc -O2 -Wall -Wextra -c a.i -o /dev/null $ clang -O2 -Wall -Wextra -c a.i -o /dev/null clang: /home/madcoder/dev/llvm/lib/VMCore/Instructions.cpp:1046: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed. Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name a.i -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -O2 -Wall -Wextra -ferror-limit 19 -fmessage-length 239 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-IwZQDv.s -x cpp-output a.i 1. parser at end of file 2. a.i:11:6: LLVM IR generation of declaration 'bar' 3. a.i:11:6: Generating code for declaration 'bar' 4. a.i:12:1: LLVM IR generation of compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) ===================== a.i content =================== typedef union tu_t { unsigned long long u64; void *ptr; } tu_t __attribute__((transparent_union)); typedef struct some_type_t some_type_t; extern void foo(tu_t); extern void bar(some_type_t *ic); void bar(some_type_t *ic) { foo(ic); } ===================================================== For what it's worth, foo((void *)ic) compiles fine. For one, as in C any point casts implicitely to void *, the some_type_t * should find its way through the "ptr" member of the transparent union, second even if that's not supported yet, it should not make clang abort :) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 17:25:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 17:25:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 7151] New: problem with anonymous union + c99 initializers Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7151 Summary: problem with anonymous union + c99 initializers Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: madcoder at debian.org CC: llvmbugs at cs.uiuc.edu ===================== a.i ==================== struct bt_key_range { int nkeys; struct bt_key_range_rec { int dpos; int dlen; } *keys; union { void *data; }; }; extern void foo(struct bt_key_range *btkr); void foo(struct bt_key_range *btkr) { *btkr = (struct bt_key_range){ .keys = (void *)0L, { .data = (void *)0L }, }; } ============================================ $ clang -std=c99 -O2 -Wall -Wextra -c a.i -o /dev/null clang: /home/madcoder/dev/llvm/include/llvm/Instructions.h:276: const llvm::Type* llvm::checkType(const llvm::Type*): Assertion `Ty && "Invalid GetElementPtrInst indices for type!"' failed. Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name a.i -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -O2 -Wall -Wextra -std=c99 -ferror-limit 19 -fmessage-length 119 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-ia7KTn.s -x cpp-output a.i 1. parser at end of file 2. a.i:13:6: LLVM IR generation of declaration 'foo' 3. a.i:13:6: Generating code for declaration 'foo' 4. a.i:14:1: LLVM IR generation of compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 17:34:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 17:34:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 7152] New: Static Analyzer false positive Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7152 Summary: Static Analyzer false positive Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: swildner at erpicon.de CC: llvmbugs at cs.uiuc.edu The following short program, when run through scan-build, generates a warning ("warning: Undefined or garbage value returned to caller"): ----------8<---------- #define FLAG 0x200 int moo = FLAG; int main(void) { int uninit; if (moo & FLAG) uninit = 1; if ((moo & FLAG) == 0) return 0; return uninit; } ---------->8---------- However, it shouldn't, since a valid value is returned in any case. Regards, Sascha Wildner -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 16 18:04:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 18:04:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 5188]
include in C++ should also search in clang's own dir In-Reply-To: References: Message-ID: <20100516230429.1224B3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5188 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2010-05-16 18:04:28 CDT --- I think mikem fixed this in r 103912, please reopen if 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 Sun May 16 21:50:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 May 2010 21:50:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 7117] regparm attribute combined with K&R declarations causes illegal instruction In-Reply-To: References: Message-ID: <20100517025046.7D59A3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7117 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #2 from Eli Friedman 2010-05-16 21:50:46 CDT --- Fixed in r103932. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 08:58:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 08:58:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 7153] New: clang r103774 fails to compile "class E { struct A {} mutable *member; }; " Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7153 Summary: clang r103774 fails to compile "class E { struct A {} mutable *member;};" Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: razeh at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following gives me a compile error: razeh2 at kubuntu:~/test$ cat mut.cpp class EnclosingClass { struct A { } mutable *member; }; razeh2 at kubuntu:~/test$ ~/src/llvm/Debug/bin/clang++ mut.cpp mut.cpp:6:6: error: expected ';' after struct } mutable *member; ^ ; mut.cpp:6:16: error: C++ requires a type specifier for all declarations } mutable *member; ~~~~~~~ ^ mut.cpp:6:16: error: C++ requires a type specifier for all declarations } mutable *member; ~~~~~~~ ^ 3 errors generated. razeh2 at kubuntu:~/test$ ~/src/llvm/Debug/bin/clang++ --version clang version 2.0 (trunk 103774) Target: x86_64-unknown-linux-gnu Thread model: posix It seems like this should compile, but I'm not a language lawyer. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 09:08:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 09:08:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 7134] the gold plugin is installed as liblibLLVMgold.so In-Reply-To: References: Message-ID: <20100517140857.1E0693128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7134 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Rafael ?vila de Esp?ndola 2010-05-17 09:08:56 CDT --- Fixed in 103897. We still create a useless .a file, but it is also harmless. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 09:50:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 09:50:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 5274] clang: doesn't add noalias attribute for restrict qualifier In-Reply-To: References: Message-ID: <20100517145030.455193128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5274 Pekka J??skel?inen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME --- Comment #6 from Pekka J??skel?inen 2010-05-17 09:50:29 CDT --- (In reply to comment #5) > Does it work for you with trunk? Yes: clang test2.c -c -emit-llvm -o - | llvm-dis ... define i32 @foo(i8* noalias %s) nounwind { entry: %retval = alloca i32, align 4 ; [#uses=2] %s.addr = alloca i8*, align 8 ; [#uses=1] store i8* %s, i8** %s.addr store i32 0, i32* %retval %0 = load i32* %retval ; [#uses=1] ret i32 %0 } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 12:33:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 12:33:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 5586] clang struct layout crash: Converting to packed did not help! In-Reply-To: References: Message-ID: <20100517173329.EFD5A312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5586 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Daniel Dunbar 2010-05-17 12:33:29 CDT --- Chris fixed this here: http://llvm.org/viewvc/llvm-project?view=rev&revision=101536 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 12:38:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 12:38:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 7152] Static Analyzer false positive In-Reply-To: References: Message-ID: <20100517173848.A3707312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7152 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |DUPLICATE --- Comment #1 from Ted Kremenek 2010-05-17 12:38:48 CDT --- Same as PR 3098. The analyzer isn't tracking bit-level constraints on symbolic values. *** This bug has been marked as a duplicate of bug 3098 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 12:58:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 12:58:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 6952] Clang allows redefinition of namespace-scope function via friend instantiation In-Reply-To: References: Message-ID: <20100517175809.472E83128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6952 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2010-05-17 12:58:08 CDT --- Fixed in r103952. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 13:20:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 13:20:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 7153] clang r103774 fails to compile "class E { struct A {} mutable *member; }; " In-Reply-To: References: Message-ID: <20100517182029.BAA2E3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7153 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-17 13:20:29 CDT --- Fixed in r103954 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 13:45:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 13:45:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 7149] clang boost boost.geometry In-Reply-To: References: Message-ID: <20100517184554.6B95D3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7149 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Douglas Gregor 2010-05-17 13:45:54 CDT --- Should be fixed in r103958. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 14:49:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 14:49:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 7154] New: Nightly test failures for -O0 -g Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7154 Summary: Nightly test failures for -O0 -g Product: libraries Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Register Allocator AssignedTo: unassignedbugs at nondot.org ReportedBy: stoklund at 2pi.dk CC: llvmbugs at cs.uiuc.edu I ran the nightly test suite on x86_64-darwin in a debug build with -regalloc=local and -regalloc=fast. There were failures: Fast allocator failures: $ make TEST=nightly OPTFLAGS=-O0 EXTRA_OPTIONS=-g PIC_CODEGEN=1 DISABLE_LTO=1 LLCFLAGS='-O0 -relocation-model=pic -disable-fp-elim -regalloc=fast' ENABLE_PARALLEL_REPORT=1 DISABLE_CBE=1 DISABLE_JIT=1 report -j10 External/SPEC/CFP2006/447.dealII/447.dealII External/SPEC/CINT2000/176.gcc/176.gcc External/SPEC/CINT2006/403.gcc/403.gcc MultiSource/Applications/JM/ldecod/ldecod MultiSource/Applications/JM/lencod/lencod MultiSource/Applications/aha/aha Local allocator failures: $ make TEST=nightly OPTFLAGS=-O0 EXTRA_OPTIONS=-g PIC_CODEGEN=1 DISABLE_LTO=1 LLCFLAGS='-O0 -relocation-model=pic -disable-fp-elim -regalloc=local' ENABLE_PARALLEL_REPORT=1 DISABLE_CBE=1 DISABLE_JIT=1 report -j10 External/SPEC/CFP2006/447.dealII/447.dealII External/SPEC/CINT2000/176.gcc/176.gcc External/SPEC/CINT2006/403.gcc/403.gcc MultiSource/Applications/aha/aha Bugpoint isolates the vararg function gen_rtx() in the two gcc tests. It is interesting that the two register allocators miscompile the same tests. Does linear scan have secrets? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 15:49:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 15:49:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7155] New: stage2 and stag3 of clang are not identical Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7155 Summary: stage2 and stag3 of clang are not identical Product: clang Version: trunk Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: diegoiast at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I am bootstapping clang, and in theory stage2 and stage should be identical binaries (at least on linux). Binaries are different for the last 3 weeks here (Fedora 12, 32bit, bootstrapping from gcc-4.4.3). I am compiling out of source using cmake. [elcuco at pinky ~/src/llvm] ls -l bootstrap-stage-{2,3}/bin/clang -rwxrwxr-x. 1 elcuco elcuco 24576970 2010-05-17 20:14 bootstrap-stage-2/bin/clang -rwxrwxr-x. 1 elcuco elcuco 24580575 2010-05-17 20:35 bootstrap-stage-3/bin/clang I attach here the build script I used, just save it under the root of your llvm checkout, and it will create 3 new directories, + bootstrap.log file with all the build log. not tested on mac, but I assume it will work as well. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 16:28:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 16:28:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7156] New: Assertion for ARM NEON code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7156 Summary: Assertion for ARM NEON code Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4897) --> (http://llvm.org/bugs/attachment.cgi?id=4897) LLVM IR to test Consider the bytecode attached. I'm having: $ ./llc bugpoint-reduced-simplified.ll -mcpu=cortex-a8 llc: /home/asl/proj/llvm/src_arm/include/llvm/CodeGen/LiveIntervalAnalysis.h:94: llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int): Assertion `I != r2iMap_.end() && "Interval does not exist for register"' failed. This is a fallout from REG_SEQUENCE stuff -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 17:10:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 17:10:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7156] Assertion for ARM NEON code In-Reply-To: References: Message-ID: <20100517221001.98C813128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7156 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Evan Cheng 2010-05-17 17:10:01 CDT --- Fixed: 103984. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 17:26:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 17:26:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7157] New: Unreachabe in TwoAddressInstructionPass.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7157 Summary: Unreachabe in TwoAddressInstructionPass.cpp Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Register Allocator AssignedTo: evan.cheng at apple.com ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4898) --> (http://llvm.org/bugs/attachment.cgi?id=4898) Testcase Consider the bytecode attached. I'm having: $ ./llc -mcpu=cortex-a8 bugpoint-reduced-simplified.ll UNREACHABLE executed at /home/asl/proj/llvm/src_arm/lib/CodeGen/TwoAddressInstructionPass.cpp:1249! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 17:44:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 17:44:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7158] New: Assertion in DAG combiner Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7158 Summary: Assertion in DAG combiner 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: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4899) --> (http://llvm.org/bugs/attachment.cgi?id=4899) Testcase Consider the attached testcase. I'm seeing: $ ./llc -mcpu=cortex-a8 bugpoint-reduced-simplified.ll llc: /home/asl/proj/llvm/src_arm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6353: llvm::SDValue::DAGCombiner::SimplifyVBinOp(llvm::SDNode*): Assertion `(Ops.back().getOpcode() == ISD::UNDEF || Ops.back().getOpcode() == ISD::Constant || Ops.back().getOpcode() == ISD::ConstantFP) && "Scalar binop didn't fold!"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 18:24:24 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 18:24:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 7157] Unreachabe in TwoAddressInstructionPass.cpp In-Reply-To: References: Message-ID: <20100517232424.5B7543128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7157 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Evan Cheng 2010-05-17 18:24:24 CDT --- Fixed: 103994 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 18:48:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 18:48:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 7159] New: Audit handling of attributes in templates Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7159 Summary: Audit handling of attributes in templates Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang's template instantiation mechanism does not properly cope with attributes. It needs to deal with dependent attributes (see, e.g., http://llvm.org/bugs/show_bug.cgi?id=6322), maintain attributes through template instantiation on all declarations, and type-check the application of attributes to declarations/types after instantiation. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 18:49:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 18:49:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7148] alignment attribute don't pass through template meta-function In-Reply-To: References: Message-ID: <20100517234930.564F23128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7148 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-17 18:49:30 CDT --- This specific bug is fixed in r103999. I've opened a separate bug for the auditing of attribute support in templates at http://llvm.org/bugs/show_bug.cgi?id=7159 , since this area needs a lot more 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 Mon May 17 18:52:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 18:52:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 6884] Clang fails to account for no-return destructors in warnings In-Reply-To: References: Message-ID: <20100517235258.0B6EE3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6884 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #7 from Chandler Carruth 2010-05-17 18:52:57 CDT --- (In reply to comment #6) > (In reply to comment #3) > > Created an attachment (id=4870) --> (http://llvm.org/bugs/attachment.cgi?id=4870) [details] [details] > > proposed patch > > > > I've attached a patch that implements this logic for C++ temporaries. I'd > > appreciate a sanity check on this patch, but it seems to address the specific > > cases in this bug. > > Sorry for the delay. Somehow my email notification for this PR got buried in > my inbox. > > I think the patch is okay as an intermediate solution, but overall I don't > think it's the right approach. Instead, destructor calls should be explicitly > modeled in the CFG (including destructor calls for temporaries). I'm fine with > this patch getting committed, but there should be a FIXME comment above the > code that this should be removed once destructors are properly modeled in the > CFG. Thanks, submitted with appropriate FIXME in r104000 so we can deal with this later when more thoroughly fixing the CFG code. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 18:59:07 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 18:59:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 7160] New: LLVM doesn't compile in VS2005 "error C2733: second C linkage of overloaded function" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7160 Summary: LLVM doesn't compile in VS2005 "error C2733: second C linkage of overloaded function" Product: libraries Version: 2.7 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: System Library AssignedTo: unassignedbugs at nondot.org ReportedBy: mark.macvicar at caustic.com CC: llvmbugs at cs.uiuc.edu LLVM doesn't compile in VS2005 "error C2733: second C linkage of overloaded function" Visual Studio 2005 wont compile LLVM 2.7 Reproducible Steps: 1. Generate VS2005 projects using "cmake -G Visual Studio 8 2005" 2. Open LLVM.sln in VS2005 3. Build LLVMSystem The following error is reported: ------------------------------ 2>Host.cpp 2>C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\intrin.h(944) : error C2733: second C linkage of overloaded function '_interlockedbittestandset' not allowed 2> C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\intrin.h(944) : see declaration of '_interlockedbittestandset' 2>C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\intrin.h(945) : error C2733: second C linkage of overloaded function '_interlockedbittestandreset' not allowed 2> C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\intrin.h(945) : see declaration of '_interlockedbittestandreset' ------------------------------ VS2008 doesn't have this issue. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 17 19:03:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 May 2010 19:03:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7158] Assertion in DAG combiner In-Reply-To: References: Message-ID: <20100518000351.4DC843128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7158 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |evan.cheng at apple.com Resolution| |FIXED --- Comment #1 from Evan Cheng 2010-05-17 19:03:51 CDT --- Fixed: 104004. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 18 00:46:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 00:46:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 6952] Clang allows redefinition of namespace-scope function via friend instantiation In-Reply-To: References: Message-ID: <20100518054606.B405E3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6952 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Blocks|6023 | Resolution|FIXED | --- Comment #5 from Douglas Gregor 2010-05-18 00:46:06 CDT --- Un-fixed in r104014, because other compilers don't actually seem to enforce C++98/03 [temp.friend]p5, and doing so breaks a bunch of Boost code. The Boost.Units issue is, however, solved by that commit, so this no longer blocks Boost compilation. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 18 01:08:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 01:08:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 7162] New: Assertion in InstrEmitter.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7162 Summary: Assertion in InstrEmitter.cpp 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: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4900) --> (http://llvm.org/bugs/attachment.cgi?id=4900) Testcase Consider the attached bytecode. I'm having: $ ./llc -mcpu=cortex-a8 bugpoint-reduced-simplified.bc llc: /home/asl/proj/llvm/src_arm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:555: void llvm::InstrEmitter::EmitRegSequence(llvm::SDNode*, llvm::DenseMap, llvm::DenseMapInfo >&, bool, bool): Assertion `SRC == RC && "Invalid subregister index in REG_SEQUENCE"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 18 07:40:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 07:40:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 7163] New: Assertion from AST during checking of address of member access Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7163 Summary: Assertion from AST during checking of address of member access Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com % cat t.cc template void h(R (*func)(P)) {} class C { public: template void f(T*); private: template static void g(T*); }; template void C::f(T* t) { h(g); } template void C::g(T* t) {} void test(C* c, int i) { c->f(&i); } % ./bin/clang++ -fsyntax-only t.cc clang: /home/chandlerc/src/llvm/trunk/tools/clang/include/clang/AST/ASTContext.h:574: clang::QualType clang::ASTContext::getTypeDeclType(const clang::TypeDecl*, const clang::TypeDecl*): Assertion `Decl && "Passed null for Decl param"' failed. Stack dump: 0. Program arguments: /home/chandlerc/src/llvm/trunk/build/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -disable-free -main-file-name t.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /home/chandlerc/src/llvm/trunk/build/lib/clang/2.0 -ferror-limit 19 -fmessage-length 179 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -x c++ t.cc 1. parser at end of file 2. t.cc:10:31: instantiating function definition 'C::f' clang: error: compiler command failed due to signal 6 (use -v to see invocation) >From GDB: #3 0x0000000000e73cb8 in clang::ASTContext::getTypeDeclType (this=0x2ea1c50, Decl=0x0, PrevDecl=0x0) at /home/chandlerc/src/llvm/trunk/tools/clang/include/clang/AST/ASTContext.h:574 #4 0x00000000012c751c in clang::Sema::CheckAddressOfMemberAccess (this=0x7fffffffc290, OvlExpr=0x2ed4190, Found=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaAccess.cpp:1263 #5 0x0000000001210d80 in clang::Sema::ResolveAddressOfOverloadedFunction (this=0x7fffffffc290, From=0x2ed4190, ToType=..., Complain=true, FoundResult=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaOverload.cpp:5744 #6 0x00000000011c233e in clang::Sema::PerformImplicitConversion (this=0x7fffffffc290, From=@0x7fffffff4968, ToType=..., SCS=..., Action=clang::Sema::AA_Converting, IgnoreBaseAccess=false) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaExprCXX.cpp:1705 #7 0x00000000011c19b8 in clang::Sema::PerformImplicitConversion (this=0x7fffffffc290, From=@0x7fffffff4968, ToType=..., ICS=..., Action=clang::Sema::AA_Converting, IgnoreBaseAccess=false) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaExprCXX.cpp:1582 #8 0x00000000011e17c7 in clang::InitializationSequence::Perform (this=0x7fffffff5140, S=..., Entity=..., Kind=..., Args=..., ResultType=0x0) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaInit.cpp:3736 #9 0x00000000011e495f in clang::Sema::PerformCopyInitialization (this=0x7fffffffc290, Entity=..., EqualLoc=..., Init=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaInit.cpp:4359 #10 0x0000000001193e7c in clang::Sema::GatherArgumentsForCall (this=0x7fffffffc290, CallLoc=..., FDecl=0x2ed5690, Proto=0x2ed5650, FirstProtoArg=0, Args=0x7fffffffae08, NumArgs=1, AllArgs=..., CallType=clang::Sema::VariadicDoesNotApply) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaExpr.cpp:3467 #11 0x0000000001193b2e in clang::Sema::ConvertArgumentsForCall (this=0x7fffffffc290, Call=0x2ed4d40, Fn=0x2ed4d00, FDecl=0x2ed5690, Proto=0x2ed5650, Args=0x7fffffffae08, NumArgs=1, RParenLoc=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaExpr.cpp:3418 #12 0x0000000001195719 in clang::Sema::BuildResolvedCallExpr (this=0x7fffffffc290, Fn=0x2ed4d00, NDecl=0x2ed5690, LParenLoc=..., Args=0x7fffffffae08, NumArgs=1, RParenLoc=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaExpr.cpp:3677 #13 0x0000000001212728 in clang::Sema::BuildOverloadedCallExpr (this=0x7fffffffc290, S=0x0, Fn=0x2ed58e0, ULE=0x2ed39e0, LParenLoc=..., Args=0x7fffffffae08, NumArgs=1, CommaLocs=0x7fffffffae78, RParenLoc=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaOverload.cpp:6084 #14 0x0000000001195002 in clang::Sema::ActOnCallExpr (this=0x7fffffffc290, S=0x0, fn=..., LParenLoc=..., args=..., CommaLocs=0x7fffffffae78, RParenLoc=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaExpr.cpp:3617 #15 0x00000000012945e5 in RebuildCallExpr (this=0x7fffffffbb50, Callee=..., LParenLoc=..., Args=..., CommaLocs=0x7fffffffae78, RParenLoc=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/TreeTransform.h:1120 #16 0x000000000128380c in TransformCallExpr (this=0x7fffffffbb50, E=0x2ed2c30) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/TreeTransform.h:4359 #17 0x000000000126daf3 in TransformExpr (this=0x7fffffffbb50, E=0x2ed2c30) at /home/chandlerc/src/llvm/trunk/build/tools/clang/include/clang/AST/StmtNodes.inc:209 #18 0x000000000126caff in TransformStmt (this=0x7fffffffbb50, S=0x2ed2c30) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/TreeTransform.h:1965 #19 0x00000000012909de in TransformCompoundStmt (this=0x7fffffffbb50, S=0x2ed2c90, IsStmtExpr=false) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/TreeTransform.h:3361 #20 0x00000000012765cb in TransformCompoundStmt (this=0x7fffffffbb50, S=0x2ed2c90) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/TreeTransform.h:3350 #21 0x000000000126bf09 in TransformStmt (this=0x7fffffffbb50, S=0x2ed2c90) at /home/chandlerc/src/llvm/trunk/build/tools/clang/include/clang/AST/StmtNodes.inc:39 #22 0x000000000126a1e0 in clang::Sema::SubstStmt (this=0x7fffffffc290, S=0x2ed2c90, TemplateArgs=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaTemplateInstantiate.cpp:1571 #23 0x00000000012a802f in clang::Sema::InstantiateFunctionDefinition (this=0x7fffffffc290, PointOfInstantiation=..., Function=0x2ed40c0, Recursive=true, DefinitionRequired=false) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:2083 #24 0x00000000012a9fa1 in clang::Sema::PerformPendingImplicitInstantiations (this=0x7fffffffc290, LocalOnly=false) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:2693 #25 0x00000000010e5136 in clang::Sema::ActOnEndOfTranslationUnit (this=0x7fffffffc290) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/Sema.cpp:214 #26 0x0000000001500bfd in clang::Parser::ParseTopLevelDecl (this=0x7fffffffcf50, Result=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Parse/Parser.cpp:344 #27 0x00000000010e1837 in clang::ParseAST (PP=..., Consumer=0x2eacf50, Ctx=..., PrintStats=false, CompleteTranslationUnit=true, CompletionConsumer=0x0) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Sema/ParseAST.cpp:87 ---Type to continue, or q to quit--- #28 0x0000000000e4f0a2 in clang::ASTFrontendAction::ExecuteAction (this=0x2e98c70) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Frontend/FrontendAction.cpp:224 #29 0x0000000000e4ed05 in clang::FrontendAction::Execute (this=0x2e98c70) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Frontend/FrontendAction.cpp:150 #30 0x0000000000e3431c in clang::CompilerInstance::ExecuteAction (this=0x2e92ea0, Act=...) at /home/chandlerc/src/llvm/trunk/tools/clang/lib/Frontend/CompilerInstance.cpp:511 #31 0x0000000000e1879d in cc1_main (ArgBegin=0x7fffffffdff8, ArgEnd=0x7fffffffe008, Argv0=0x7fffffffe2c3 "/home/chandlerc/src/llvm/trunk/build/bin/clang", MainAddr=0xe11af4) at /home/chandlerc/src/llvm/trunk/tools/clang/tools/driver/cc1_main.cpp:285 #32 0x0000000000e12ae5 in main (argc=4, argv=0x7fffffffdfe8) at /home/chandlerc/src/llvm/trunk/tools/clang/tools/driver/driver.cpp:181 The root cause seems to be on line 1260 of SemaAccess.cpp we request Ovl->NamingClass(), and this overloaded expression does not have a naming class: (gdb) p NamingClass $1 = (class clang::CXXRecordDecl *) 0x0 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 18 11:23:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 11:23:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 7164] New: LatticeMico32 (LM32) backend Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7164 Summary: LatticeMico32 (LM32) backend Product: libraries Version: trunk Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P Component: Target Description Classes AssignedTo: unassignedbugs at nondot.org ReportedBy: sebastien.bourdeauducq at lekernel.net CC: llvmbugs at cs.uiuc.edu LatticeMico32 is an open source microprocessor core designed by Lattice Semiconductor and typically used in FPGAs: http://www.latticesemi.com/mico32 It is already supported by GNU Binutils and GCC (4.5+). It is used by the Milkymist (www.milkymist.org) and RTEMS (www.rtems.org) projects. The Milkymist project would like to use the LLVM compiler toolchain as an alternative to GCC, which requires developing a LM32 backend. Thanks. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 18 11:24:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 11:24:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7164] LatticeMico32 (LM32) backend In-Reply-To: References: Message-ID: <20100518162432.B34633128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7164 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Chris Lattner 2010-05-18 11:24:32 CDT --- This isn't going to happen because of this PR. I suggest bringing it up on the llvm dev mailing list, asking if anyone is interested in doing the 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 May 18 11:53:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 11:53:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 6441] Assertion failed: (!RD->getNumBases() && "FIXME: Handle zero-initializing structs with bases and " "pointers to data members.") In-Reply-To: References: Message-ID: <20100518165306.0343E3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6441 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |andersca at mac.com Resolution| |FIXED --- Comment #3 from Anders Carlsson 2010-05-18 11:53:05 CDT --- Fixed in r104025. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 18 12:35:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 12:35:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 7165] New: Can't call instance methods from within a block Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7165 Summary: Can't call instance methods from within a block Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: oliver at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4901) --> (http://llvm.org/bugs/attachment.cgi?id=4901) Testcase clang++ does not correctly handle instance methods being called from within a block -- it believes that they are being called without "this". These two variations produce: Carrot:~ oliver$ llvm/Debug/bin/clang++ foo.cpp foo.cpp:12:10: error: call to non-static member function without an object argument g(^{ wibble(); }); ^~~~~~ 1 error generated. and Carrot:~ oliver$ llvm/Debug/bin/clang++ foo.cpp foo.cpp:12:10: error: invalid use of 'this' outside of a nonstatic member function g(^{ this->wibble(); }); -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 18 15:08:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 15:08:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7162] REG_SEQUENCE Assertion in InstrEmitter.cpp In-Reply-To: References: Message-ID: <20100518200832.7703B3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7162 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Evan Cheng 2010-05-18 15:08:32 CDT --- Fixed: 104050 and 104051. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 18 16:05:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 16:05:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7166] New: clang boost boost.geometry Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7166 Summary: clang boost boost.geometry Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: barend at xs4all.nl CC: llvmbugs at cs.uiuc.edu About Boost.Geometry, I made a bug report a few days ago and it is solved. One (probably the only) other test fails compiling using clang. It does not crash but reports an error. I don't know exactly why. Probably it is something in Boost.UBLAS. Can also be in glibcc. Might also be an error in our code. GCC succeeds, as does MSVC. A Boost.Geometry sample also fails for the same reason. File: Commands to reproduce: 1) Checking out Boost.Geometry, e.g. svn co https://svn.boost.org/svn/boost/sandbox/geometry boost_geometry 2) cd boost_geometry/libs/geometry/test/strategies 3) clang -I.. -I../../../.. transformer.cpp -lstdc++ -v This time I didn't try to create a minimal sample. Messages: transformer.cpp clang version 2.0 (trunk 103958) Target: i386-pc-linux-gnu Thread model: posix "/home/barend/svn/llvm/Release/bin/clang" -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name transformer.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -v -resource-dir /home/barend/svn/llvm/Release/lib/clang/2.0 -I. -I.. -I../.. -I../../.. -I../../../.. -I../../../../.. -ferror-limit 19 -fmessage-length 0 -fexceptions -fgnu-runtime -fdiagnostics-show-option -o /tmp/cc-OPAt2J.s -x c++ transformer.cpp clang -cc1 version 2.0 based upon llvm 2.8svn hosted on i386-pc-linux-gnu ignoring nonexistent directory "/usr/include/c++/4.4/x86_64-linux-gnu/32" (...) ignoring duplicate directory "/usr/include/c++/4.4/backward" #include "..." search starts here: #include <...> search starts here: . .. ../.. ../../.. ../../../.. ../../../../.. /usr/include/c++/4.4 /usr/include/c++/4.4/backward /usr/include/c++/4.4/i486-linux-gnu /usr/local/include /home/barend/svn/llvm/Release/lib/clang/2.0/include /usr/include End of search list. In file included from transformer.cpp:10: In file included from ../geometry_test_common.hpp:22: In file included from /usr/include/boost/foreach.hpp:27: In file included from /usr/include/c++/4.4/utility:62: In file included from /usr/include/c++/4.4/bits/stl_pair.h:60: /usr/include/c++/4.4/bits/move.h:82:11: error: read-only variable is not assignable __a = _GLIBCXX_MOVE(__b); ~~~ ^ In file included from transformer.cpp:12: In file included from ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:16: In file included from /usr/include/boost/numeric/ublas/lu.hpp:16: In file included from /usr/include/boost/numeric/ublas/operation.hpp:16: In file included from /usr/include/boost/numeric/ublas/matrix_proxy.hpp:16: In file included from /usr/include/boost/numeric/ublas/matrix_expression.hpp:16: In file included from /usr/include/boost/numeric/ublas/vector_expression.hpp:16: In file included from /usr/include/boost/numeric/ublas/expression_types.hpp:17: /usr/include/boost/numeric/ublas/functional.hpp:318:13: note: in instantiation of function template specialization 'std::swap' requested here std::swap (t1, t2); ^ In file included from transformer.cpp:12: In file included from ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:16: In file included from /usr/include/boost/numeric/ublas/lu.hpp:16: In file included from /usr/include/boost/numeric/ublas/operation.hpp:16: In file included from /usr/include/boost/numeric/ublas/matrix_proxy.hpp:18: /usr/include/boost/numeric/ublas/detail/matrix_assign.hpp:1317:31: note: in instantiation of member function 'boost::numeric::ublas::scalar_swap::apply' requested here functor_type::apply (*it2, *it2e), ++ it2, ++ it2e; ^ /usr/include/boost/numeric/ublas/detail/matrix_assign.hpp:1610:9: note: in instantiation of function template specialization 'boost::numeric::ublas::matrix_swap, boost::numeric::ublas::triangular_adaptor, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower >, boost::numeric::ublas::triangular_adaptor, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower > >' requested here matrix_swap (m, e, storage_category (), orientation_category ()); ^ In file included from transformer.cpp:12: In file included from ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:16: In file included from /usr/include/boost/numeric/ublas/lu.hpp:20: /usr/include/boost/numeric/ublas/triangular.hpp:1117:17: note: in instantiation of function template specialization 'boost::numeric::ublas::matrix_swap, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower >, boost::numeric::ublas::triangular_adaptor, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower > >' requested here matrix_swap (*this, m); ^ /usr/include/boost/numeric/ublas/triangular.hpp:1121:16: note: in instantiation of member function 'boost::numeric::ublas::triangular_adaptor, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower >::swap' requested here m1.swap (m2); ^ /usr/include/boost/numeric/ublas/triangular.hpp:2450:24: note: (skipping 2 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all) inplace_solve (triangular_adaptor (e1 ()), e2, ^ In file included from transformer.cpp:12: In file included from ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:16: /usr/include/boost/numeric/ublas/lu.hpp:294:9: note: in instantiation of function template specialization 'boost::numeric::ublas::lu_substitute, boost::numeric::ublas::unbounded_array > >, boost::numeric::ublas::matrix, boost::numeric::ublas::unbounded_array > > >' requested here lu_substitute (m, mv); ^ In file included from transformer.cpp:12: ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:60:13: note: in instantiation of function template specialization 'boost::numeric::ublas::lu_substitute, boost::numeric::ublas::unbounded_array > >, unsigned int, boost::numeric::ublas::unbounded_array >, boost::numeric::ublas::matrix, boost::numeric::ublas::unbounded_array > > >' requested here boost::numeric::ublas::lu_substitute(copy, pm, this->m_matrix); ^ transformer.cpp:30:69: note: in instantiation of function template specialization 'boost::geometry::strategy::transform::inverse_transformer, boost::tuples::tuple >::inverse_transformer, boost::tuples::tuple, 2, 2> >' requested here boost::geometry::strategy::transform::inverse_transformer inverse(trans); ^ transformer.cpp:53:9: note: in instantiation of function template specialization 'check_inverse, boost::geometry::strategy::transform::translate_transformer, boost::tuples::tuple, 2, 2> >' requested here check_inverse(tp, trans); ^ transformer.cpp:99:5: note: in instantiation of function template specialization 'test_all >' requested here test_all >(); ^ In file included from transformer.cpp:10: In file included from ../geometry_test_common.hpp:22: In file included from /usr/include/boost/foreach.hpp:27: In file included from /usr/include/c++/4.4/utility:62: In file included from /usr/include/c++/4.4/bits/stl_pair.h:60: /usr/include/c++/4.4/bits/move.h:82:11: error: read-only variable is not assignable __a = _GLIBCXX_MOVE(__b); ~~~ ^ In file included from transformer.cpp:12: In file included from ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:16: In file included from /usr/include/boost/numeric/ublas/lu.hpp:16: In file included from /usr/include/boost/numeric/ublas/operation.hpp:16: In file included from /usr/include/boost/numeric/ublas/matrix_proxy.hpp:16: In file included from /usr/include/boost/numeric/ublas/matrix_expression.hpp:16: In file included from /usr/include/boost/numeric/ublas/vector_expression.hpp:16: In file included from /usr/include/boost/numeric/ublas/expression_types.hpp:17: /usr/include/boost/numeric/ublas/functional.hpp:318:13: note: in instantiation of function template specialization 'std::swap' requested here std::swap (t1, t2); ^ In file included from transformer.cpp:12: In file included from ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:16: In file included from /usr/include/boost/numeric/ublas/lu.hpp:16: In file included from /usr/include/boost/numeric/ublas/operation.hpp:16: In file included from /usr/include/boost/numeric/ublas/matrix_proxy.hpp:18: /usr/include/boost/numeric/ublas/detail/matrix_assign.hpp:1317:31: note: in instantiation of member function 'boost::numeric::ublas::scalar_swap::apply' requested here functor_type::apply (*it2, *it2e), ++ it2, ++ it2e; ^ /usr/include/boost/numeric/ublas/detail/matrix_assign.hpp:1610:9: note: in instantiation of function template specialization 'boost::numeric::ublas::matrix_swap, boost::numeric::ublas::triangular_adaptor, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower >, boost::numeric::ublas::triangular_adaptor, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower > >' requested here matrix_swap (m, e, storage_category (), orientation_category ()); ^ In file included from transformer.cpp:12: In file included from ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:16: In file included from /usr/include/boost/numeric/ublas/lu.hpp:20: /usr/include/boost/numeric/ublas/triangular.hpp:1117:17: note: in instantiation of function template specialization 'boost::numeric::ublas::matrix_swap, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower >, boost::numeric::ublas::triangular_adaptor, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower > >' requested here matrix_swap (*this, m); ^ /usr/include/boost/numeric/ublas/triangular.hpp:1121:16: note: in instantiation of member function 'boost::numeric::ublas::triangular_adaptor, boost::numeric::ublas::unbounded_array > > const, boost::numeric::ublas::basic_unit_lower >::swap' requested here m1.swap (m2); ^ /usr/include/boost/numeric/ublas/triangular.hpp:2450:24: note: (skipping 2 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all) inplace_solve (triangular_adaptor (e1 ()), e2, ^ In file included from transformer.cpp:12: In file included from ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:16: /usr/include/boost/numeric/ublas/lu.hpp:294:9: note: in instantiation of function template specialization 'boost::numeric::ublas::lu_substitute, boost::numeric::ublas::unbounded_array > >, boost::numeric::ublas::matrix, boost::numeric::ublas::unbounded_array > > >' requested here lu_substitute (m, mv); ^ In file included from transformer.cpp:12: ../../../../boost/geometry/strategies/transform/inverse_transformer.hpp:60:13: note: in instantiation of function template specialization 'boost::numeric::ublas::lu_substitute, boost::numeric::ublas::unbounded_array > >, unsigned int, boost::numeric::ublas::unbounded_array >, boost::numeric::ublas::matrix, boost::numeric::ublas::unbounded_array > > >' requested here boost::numeric::ublas::lu_substitute(copy, pm, this->m_matrix); ^ transformer.cpp:30:69: note: in instantiation of function template specialization 'boost::geometry::strategy::transform::inverse_transformer, boost::geometry::point >::inverse_transformer, boost::geometry::point, 2, 2> >' requested here boost::geometry::strategy::transform::inverse_transformer inverse(trans); ^ transformer.cpp:53:9: note: in instantiation of function template specialization 'check_inverse, boost::geometry::strategy::transform::translate_transformer, boost::geometry::point, 2, 2> >' requested here check_inverse(tp, trans); ^ transformer.cpp:103:5: note: in instantiation of function template specialization 'test_all >' requested here test_all >(); ^ 2 errors generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 18 16:19:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 16:19:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 7160] LLVM doesn't compile in VS2005 "error C2733: second C linkage of overloaded function" In-Reply-To: References: Message-ID: <20100518211954.6957B312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7160 Mark MacVicar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Mark MacVicar 2010-05-18 16:19:54 CDT --- Apparently this is a known issue with VS2005. http://social.msdn.microsoft.com/Forums/en/vcprerelease/thread/61b5becd-90f9-40a4-b545-5f171fe45daa http://forums.steampowered.com/forums/showthread.php?t=647499&highlight=intrin.h https://connect.microsoft.com/VisualStudio/feedback/details/262047/compiler-error-when-including-windows-h-and-intrin-h-in-the-same-compilation-unit?wa=wsignin1.0#details -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 18 22:40:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 22:40:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 7102] Clang fails to pack template containing packed union In-Reply-To: References: Message-ID: <20100519034003.DC00B3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7102 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-18 22:40:03 CDT --- Fixed in r104106. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 18 23:14:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 May 2010 23:14:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 6851] Spurious mismatch of out-of-line method definition and method declaration. In-Reply-To: References: Message-ID: <20100519041400.CA6AE3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6851 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-18 23:14:00 CDT --- Fixed in r104107. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 04:39:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 04:39:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 7163] Assertion from AST during checking of address of member access In-Reply-To: References: Message-ID: <20100519093935.165943128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7163 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chandler Carruth 2010-05-19 04:39:34 CDT --- Fixed in r104117. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 05:16:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 05:16:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7167] New: Assertion failure "Unexpected illegal type!" in LegalizeDAG.cpp when using shufflevector Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7167 Summary: Assertion failure "Unexpected illegal type!" in LegalizeDAG.cpp when using shufflevector Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: Edmund.Grimley-Evans at arm.com CC: llvmbugs at cs.uiuc.edu Almost any use of shufflevector that doesn't correspond to a recognised NEON instruction seems to lead to: llc: LegalizeDAG.cpp:778: llvm::SDValue::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `(isTypeLegal(Node->getOperand(i).getValueType()) || Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexpected illegal type!"' failed. My command line is: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard I'm on revision 104116. Here are some examples: ; Ideally this would turn into a VREV32.16, I think: define <8 x i8> @f1(<8 x i8> %x) nounwind { %y = shufflevector <8 x i8> %x, <8 x i8> undef, <8 x i32> ret <8 x i8> %y } ; Ideally this would turn into a VSWP, I think: define <4 x i64> @f1(<4 x i64> %x) nounwind { %y = shufflevector <4 x i64> %x, <4 x i64> undef, <4 x i32> ret <4 x i64> %y } ; This is just a random permutation: define <8 x i8> @f1(<8 x i8> %x) nounwind { %y = shufflevector <8 x i8> %x, <8 x i8> undef, <8 x i32> ret <8 x i8> %y } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 06:41:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 06:41:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 7168] New: Computed gotos and more Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7168 Summary: Computed gotos and more Product: new-bugs Version: 2.7 Platform: PC OS/Version: Windows XP Status: NEW Keywords: code-quality Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: bearophile at mailas.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4903) --> (http://llvm.org/bugs/attachment.cgi?id=4903) C source of the look and say sequence counter Generally here when I report a performance problem I try to show a synthetic benchmark, that is a minimal piece of code that makes it easy to spot where the problem is. But while benchmarking LLVM 2.7 I have found two performance problems that I am not able to locate in few lines of asm, so I have to show a bit larger code example. This bug report is about one of those two problems. This C benchmark is related to the Audioactive sequence: http://en.wikipedia.org/wiki/Look-and-say_sequence This program just prints the length of the strings up to a max iteration count, very quickly. This is a reduced program, I have stripped out the not essential parts. This program contains a computed gotos, to improve its performance a little. I have seen that LLVM 2.7 (llvm-gcc) is able to run this program faster than LLVM 2.6, thanks to the recent improvements in the implementation of computed gotos. But there is a significant performance gap still between GCC and llvm-gcc. I have compiled the code with just, on a 32 bit Windows system: -O3 -s Timings, N=71 (output redirected to file), seconds: llvm-gcc: 3.88 gcc: 2.46 In this program GCC uses this instruction to implement the computed goto: jmp *-232(%ebp,%ecx,4) but even replacing the computed goto with a normal switch and compiling the program again with both llvm-gcc and gcc shows that some performance difference persists (but it's lower), so probably this performance problem is not all in the computed goto implementation. This benchmark is also interesting because it's a minimal example of a common class of programs, that simulate finite state machines using the CPU program counter for max performance. This program can be used for benchmarks and tests of llvm. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 07:14:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 07:14:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 7169] New: llc infinite loop in LegalizeDAG Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7169 Summary: llc infinite loop in LegalizeDAG Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4906) --> (http://llvm.org/bugs/attachment.cgi?id=4906) testcase .ll This is a recent regression. Doing "llc pr23135.ll" results in llc apparently computing forever. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 07:18:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 07:18:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7170] New: llc infinite loop in getMemcpyLoadsAndStores Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7170 Summary: llc infinite loop in getMemcpyLoadsAndStores Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4907) --> (http://llvm.org/bugs/attachment.cgi?id=4907) testcase .ll This is a recent regression. Doing "llc 20050622-1.ll" apparently runs for ever, chewing up ever more memory. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 19 07:21:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 07:21:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 7171] New: target datalayout needed to perform optimization Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7171 Summary: target datalayout needed to perform optimization Product: libraries Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: jos.decoster at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, In the example below: ; ModuleID = 'test.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" define i32 @test4(i32 %x, i32 %y) readnone { block0: %stack = alloca [100 x i32], align 4 %p1 = getelementptr inbounds [100 x i32]* %stack, i32 0, i32 0 store i32 %x, i32* %p1 %p2 = getelementptr inbounds [100 x i32]* %stack, i32 0, i32 1 store i32 %y, i32* %p2 %p3 = getelementptr inbounds [100 x i32]* %stack, i32 0, i32 0 %v1 = load i32* %p3 %p4 = getelementptr inbounds [100 x i32]* %stack, i32 0, i32 1 %v2 = load i32* %p4 %result = add i32 %v1, %v2 ret i32 %result } the 'target datalayout' is required to perform optimization to: define i32 @test4(i32 %x, i32 %y) nounwind readnone { block0: %result = add i32 %x, %y ; [#uses=1] ret i32 %result } Why is the datalayout important in this example? Kind regards, Jos. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 10:25:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 10:25:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 6558] Assertion failed: Unexpected linkage decl! In-Reply-To: References: Message-ID: <20100519152536.7DD0E3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6558 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-19 10:25:36 CDT --- Glad to hear it! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 19 11:21:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 11:21:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 7034] Are default args allowed in template function definitions? In-Reply-To: References: Message-ID: <20100519162147.6F113312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7034 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Resolution| |INVALID --- Comment #1 from Douglas Gregor 2010-05-19 11:21:47 CDT --- Clang is correct. C++ [dcl.fct.default]p6 says: Except for member functions of class templates, the default arguments in a member function definition that appears outside of the class definition are added to the set of default arguments provided by the member function declaration in the class definition. Default arguments for a member function of a class template shall be specified on the initial declaration of the member function within the class template. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 11:34:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 11:34:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 7172] New: UNREACHABLE hit in Live Interval Analysis Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7172 Summary: UNREACHABLE hit in Live Interval Analysis 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: jvoung at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4908) --> (http://llvm.org/bugs/attachment.cgi?id=4908) 403.gcc reduced test case running llc with arguments: llc 403.gcc.linked.bc -tool-args -asm-verbose=false -O0 on revision 104079 results in a crash: 0 llc 0x0000000000af55ff 1 llc 0x0000000000af5d7a 2 libpthread.so.0 0x00007f07e89ca7d0 3 libc.so.6 0x00007f07e7ae6095 gsignal + 53 4 libc.so.6 0x00007f07e7ae7af0 abort + 272 5 llc 0x0000000000ad51b2 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 370 6 llc 0x00000000008863c6 llvm::LiveIntervals::handleVirtualRegisterDef(llvm::MachineBasicBlock*, llvm::ilist_iterator, llvm::SlotIndex, llvm::MachineOperand&, unsigned int, llvm::LiveInterval&) + 3910 7 llc 0x00000000008883c9 llvm::LiveIntervals::handleRegisterDef(llvm::MachineBasicBlock*, llvm::ilist_iterator, llvm::SlotIndex, llvm::MachineOperand&, unsigned int) + 409 8 llc 0x000000000088ad80 llvm::LiveIntervals::computeIntervals() + 2496 9 llc 0x000000000088b50f llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&) + 447 10 llc 0x00000000007b3113 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 115 11 llc 0x0000000000a7a740 llvm::FPPassManager::runOnFunction(llvm::Function&) + 688 12 llc 0x0000000000a7a793 llvm::FPPassManager::runOnModule(llvm::Module&) + 67 13 llc 0x0000000000a7a2e3 llvm::MPPassManager::runOnModule(llvm::Module&) + 515 14 llc 0x0000000000a7a3c2 llvm::PassManagerImpl::run(llvm::Module&) + 114 15 llc 0x0000000000a7a45d llvm::PassManager::run(llvm::Module&) + 13 16 llc 0x00000000004d3122 main + 2802 17 libc.so.6 0x00007f07e7ad21c4 __libc_start_main + 244 18 llc 0x00000000004d0b19 Stack dump: 0. Program arguments: Release+Debug-Asserts/bin/llc -asm-verbose=false -O0 -o bugpoint-test-program.bc.llc.s bugpoint-test-program.bc 1. Running pass 'Function Pass Manager' on module 'bugpoint-test-program.bc'. 2. Running pass 'Live Interval Analysis' on function '@nonlocal_mentioned_p' Reduced test case attached. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 19 12:02:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 12:02:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7102] Clang fails to pack template containing packed union In-Reply-To: References: Message-ID: <20100519170256.386A23128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7102 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #2 from Douglas Gregor 2010-05-19 12:02:55 CDT --- Patch reverted in r104121 because it broke Boost.Serialization. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 12:32:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 12:32:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7171] target datalayout needed to perform optimization In-Reply-To: References: Message-ID: <20100519173242.35D04312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7171 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2010-05-19 12:32:41 CDT --- This is because basicaa needs to know element offsets and it gets that from TargetData. Though it looks obvious from this example, teaching basicaa to handle &A[0] != &A[1] without target data is very tricky and would add a lot of complexity. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 14:47:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 14:47:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7173] New: Invalid warning on references in structs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7173 Summary: Invalid warning on references in structs Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code produces an invalid warning, as the reference being returned is itself a reference, not stack memory. Code like this exists in boost::parameter. struct X { int& i; }; int& getX(X x) { return x.i; } ------- temp.cc:5:10: warning: reference to stack memory associated with local variable 'x' returned { return x.i; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 19 15:13:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 15:13:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 7174] New: Can't assemble LLVM-GCC's assembly with multiple case statements Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7174 Summary: Can't assemble LLVM-GCC's assembly with multiple case statements Product: new-bugs Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: mark.aldham at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4910) --> (http://llvm.org/bugs/attachment.cgi?id=4910) Simple test case to illustrate issue. Since the MIPS backend cannot yet produce elf files, my current flow is as follows: 1) LLVM-GCC compiles C->bitcode 2) LLC compiles bitcode->mips assembly 3) GCC's AS assembles the mips assembly into object file 4) GCC's LD links object files into ELF file When the C file contains a switch statement with many cases (it seems to be >3 cases causes the problem), the assembly produced with LLC cannot be assembled. It fails with the following result: switches.s: Assembler messages: switches.s:27: Error: illegal operands `lw $3,0(%lo($JTI1_0))' This is with LLVM 2.7, and llvm-gcc (GCC) 4.2.1. The cross-compiler used is: GNU assembler (GNU Binutils) 2.20 The following commands are used to compile: llvm-gcc switches.c -O2 -emit-llvm -c -o switches.bc llc switches.bc -march=mipsel -relocation-model=static -mips-ssection-threshold=0 -mcpu=mips1 -f -o switches.s mipsel-unknown-elf-as switches.s -g -mips1 -mabi=eabi -o switches.o -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 19 15:29:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 15:29:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 7175] New: LLVM-GCC produces MIPS assembly that compares 64-bit longs incorrectly. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7175 Summary: LLVM-GCC produces MIPS assembly that compares 64-bit longs incorrectly. Product: new-bugs Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: mark.aldham at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4911) --> (http://llvm.org/bugs/attachment.cgi?id=4911) Simple test case to illustrate issue. Since the MIPS backend cannot yet produce elf files, my current flow is as follows: 1) LLVM-GCC compiles C->bitcode 2) LLC compiles bitcode->mips assembly 3) GCC's AS assembles the mips assembly into object file 4) GCC's LD links object files into ELF file When run, comparisons between two longs isn't done properly -- it seems to just compare the lower 32bits. My system: Linux x86_64 GNU/Linux This is with LLVM 2.7, and llvm-gcc (GCC) 4.2.1. The cross-compiler used is: GNU assembler (GNU Binutils) 2.20 The following commands are used to compile: llvm-gcc long_compare.c -O2 -emit-llvm -c -o long_compare.bc llc long_compare.bc -march=mipsel -relocation-model=static -mips-ssection-threshold=0 -mcpu=mips1 -f -o long_compare.s mipsel-unknown-elf-as long_compare.s -g -mips1 -mabi=eabi -o long_compare.o mipsel-unknown-elf-ld -Ttext 0x80030000 -e main long_compare.o -o long_compare.elf -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 17:16:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 17:16:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 7176] New: Assertion failed: (BaseType.isCanonical() && "Base type must be the canonical type") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7176 Summary: Assertion failed: (BaseType.isCanonical() && "Base type must be the canonical type") Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: niebuhr at niebuhrt.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This is what I did. The included libraries compile just fine but compiling this object trigers an assertion. Let me know if you need some code. /Users/gmthor85/llvm//llvm/Debug/bin/clang++ -c fire.cpp -O2 -I ~/Downloads/ -I ~/Downloads/odemx/external/poco.rev.1094/Data/include/ -I ~/Downloads/odemx/external/poco.rev.1094/Foundation/include/ -I ~/Downloads/odemx/external/poco.rev.1094/XML/include/ -I ~/Downloads/odemx/external -I ~/Downloads/odemx/external/poco.rev.1094/Data/SQLite/include Assertion failed: (BaseType.isCanonical() && "Base type must be the canonical type"), function isAmbiguous, file CXXInheritance.cpp, line 53. 0 clang 0x0000000100fd345c PrintStackTrace(void*) + 38 1 clang 0x0000000100fd393c SignalHandler(int) + 312 2 libSystem.B.dylib 0x00007fff87f5f80a _sigtramp + 26 3 libSystem.B.dylib 0x00007fff87f0450a tiny_malloc_from_free_list + 1196 4 libSystem.B.dylib 0x00007fff87fdaef0 __pthread_markcancel + 0 5 clang 0x0000000100552b3a clang::CXXBasePaths::isAmbiguous(clang::QualType) + 82 6 clang 0x0000000100256e11 TryStaticMemberPointerUpcast(clang::Sema&, clang::Expr*&, clang::QualType, clang::QualType, bool, clang::SourceRange const&, unsigned int&, clang::CastExpr::CastKind&, clang::UsuallyTinyPtrVector&) + 608 7 clang 0x0000000100257fa0 TryStaticCast(clang::Sema&, clang::Expr*&, clang::QualType, bool, clang::SourceRange const&, unsigned int&, clang::CastExpr::CastKind&, clang::UsuallyTinyPtrVector&) + 667 8 clang 0x0000000100259989 clang::Sema::CXXCheckCStyleCast(clang::SourceRange, clang::QualType, clang::Expr*&, clang::CastExpr::CastKind&, clang::UsuallyTinyPtrVector&, bool) + 387 9 clang 0x00000001002f474a clang::Sema::CheckCastTypes(clang::SourceRange, clang::QualType, clang::Expr*&, clang::CastExpr::CastKind&, clang::UsuallyTinyPtrVector&, bool) + 166 10 clang 0x00000001002f5175 clang::Sema::BuildCStyleCastExpr(clang::SourceLocation, clang::TypeSourceInfo*, clang::SourceLocation, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>) + 165 11 clang 0x00000001002f5f17 clang::Sema::ActOnCastExpr(clang::Scope*, clang::SourceLocation, void*, clang::SourceLocation, clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>) + 527 12 clang 0x0000000100612115 clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool, void*, void*&, clang::SourceLocation&) + 2017 13 clang 0x000000010060f0f9 clang::Parser::ParseCastExpression(bool, bool, bool&, void*) + 1105 14 clang 0x000000010061188f clang::Parser::ParseCastExpression(bool, bool, void*) + 97 15 clang 0x000000010060c2ad clang::Parser::ParseAssignmentExpression() + 237 16 clang 0x000000010060c4cd clang::Parser::ParseExpressionList(llvm::SmallVector&, llvm::SmallVector&, void (clang::Action::*)(clang::Scope*, void*, void**, unsigned int), void*) + 245 17 clang 0x000000010060cdc7 clang::Parser::ParsePostfixExpressionSuffix(clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>) + 1155 18 clang 0x000000010060fa4a clang::Parser::ParseCastExpression(bool, bool, bool&, void*) + 3490 19 clang 0x000000010061188f clang::Parser::ParseCastExpression(bool, bool, void*) + 97 20 clang 0x000000010060c2ad clang::Parser::ParseAssignmentExpression() + 237 21 clang 0x000000010060c828 clang::Parser::ParseExpression() + 42 22 clang 0x000000010062c8cc clang::Parser::ParseStatementOrDeclaration(bool) + 1636 23 clang 0x0000000100630dfe clang::Parser::ParseCompoundStatementBody(bool) + 220 24 clang 0x0000000100631429 clang::Parser::ParseFunctionStatementBody(clang::OpaquePtr<0>) + 193 25 clang 0x000000010063ad80 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1240 26 clang 0x00000001005fee2c clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 478 27 clang 0x0000000100639e25 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 1053 28 clang 0x0000000100639e91 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 83 29 clang 0x000000010063bbcd clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2211 30 clang 0x000000010063bd0b clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 247 31 clang 0x0000000100248cf7 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 456 32 clang 0x00000001000668f6 clang::ASTFrontendAction::ExecuteAction() + 256 33 clang 0x00000001000669f3 clang::FrontendAction::Execute() + 239 34 clang 0x0000000100049892 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 784 35 clang 0x00000001000278b2 cc1_main(char const**, char const**, char const*, void*) + 1761 36 clang 0x000000010002b719 main + 252 37 clang 0x0000000100026754 start + 52 Stack dump: 0. Program arguments: /Users/gmthor85/llvm/llvm/Debug/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name fire.cpp -pic-level 1 -mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir /Users/gmthor85/llvm/llvm/Debug/lib/clang/2.0 -I /Users/gmthor85/Downloads/ -I /Users/gmthor85/Downloads/odemx/external/poco.rev.1094/Data/include/ -I /Users/gmthor85/Downloads/odemx/external/poco.rev.1094/Foundation/include/ -I /Users/gmthor85/Downloads/odemx/external/poco.rev.1094/XML/include/ -I /Users/gmthor85/Downloads/odemx/external -I /Users/gmthor85/Downloads/odemx/external/poco.rev.1094/Data/SQLite/include -O2 -ferror-limit 19 -fmessage-length 188 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/3C/3Cjb8XqLGZ4CudBSDgvEJE+++TI/-Tmp-/cc-vRD5G6.s -x c++ fire.cpp 1. fire.cpp:33:46: current parser token ')' 2. fire.cpp:28:18: parsing function body 'Fire::main' 3. fire.cpp:28:18: in compound statement ('{}') clang: error: compiler command failed due to signal 6 (use -v to see invocation) make: *** [fire.o] Error 250 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 19:29:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 19:29:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 7177] New: Case-sensitivity of included files Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7177 Summary: Case-sensitivity of included files Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu This should probably work on Windows: //once.cpp #include "onlyOnce.h" #include "OnlyOnce.h" //onlyOnce.h #pragma once int def; But the preprocessor creates separate entries for the include file, and thus the #pragma once doesn't prevent the double 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 May 19 20:19:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 May 2010 20:19:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7165] Can't call instance methods from within a block In-Reply-To: References: Message-ID: <20100520011912.8936F3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7165 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from John McCall 2010-05-19 20:19:12 CDT --- Fixed in r104202. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 05:23:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 05:23:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7178] New: Crash on invalid extra typename Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7178 Summary: Crash on invalid extra typename 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 $ cat bug.cc template struct v { }; template struct s { typedef typename v a; }; s::a x; $ ~/llvm_new/Debug/bin/clang++ -cc1 bug.cc bug.cc:6:19: error: expected a qualified name after 'typename' typedef typename v a; ^ clang++: SemaDecl.cpp:4866: clang::TypedefDecl* clang::Sema::ParseTypedefDecl(clang::Scope*, clang::Declarator&, clang::QualType, clang::TypeSourceInfo*): Assertion `D.getIdentifier() && "Wrong callback for declspec without declarator"' failed. 0 clang++ 0x000000000139dcd5 1 clang++ 0x000000000139e1c0 2 libpthread.so.0 0x00000036aa80f0f0 3 libc.so.6 0x00000036a9c32f05 gsignal + 53 4 libc.so.6 0x00000036a9c34a73 abort + 387 5 libc.so.6 0x00000036a9c2bef9 __assert_fail + 233 6 clang++ 0x00000000006ba405 7 clang++ 0x00000000006c9b0f 8 clang++ 0x00000000006cd44d 9 clang++ 0x00000000006f836f 10 clang++ 0x0000000000a1c79f 11 clang++ 0x0000000000a1cf6c 12 clang++ 0x0000000000a1e449 13 clang++ 0x0000000000a13943 14 clang++ 0x0000000000a342dc 15 clang++ 0x0000000000a34b08 16 clang++ 0x0000000000a34be6 17 clang++ 0x0000000000a17830 18 clang++ 0x0000000000a0a0ae 19 clang++ 0x0000000000a0a2e0 20 clang++ 0x0000000000686b83 21 clang++ 0x000000000045e26c 22 clang++ 0x000000000045e369 23 clang++ 0x000000000044afa5 24 clang++ 0x0000000000431e94 25 clang++ 0x0000000000436338 main + 233 26 libc.so.6 0x00000036a9c1e576 __libc_start_main + 230 27 clang++ 0x0000000000430d19 Stack dump: 0. Program arguments: /home/abagnara/llvm_new/Debug/bin/clang++ -cc1 bug.cc 1. bug.cc:6:24: current parser token 'a' 2. bug.cc:5:1: parsing struct/union/class body 's' -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 20 05:59:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 05:59:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 7179] New: assert on warning Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7179 Summary: assert on warning 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 Created an attachment (id=4913) --> (http://llvm.org/bugs/attachment.cgi?id=4913) Code which crashes with warnings enabled. clang asserts on the following code when given '-Wall', but compiles it fine without that flag, as does g++. Comeau rejects it. Backtrace: $ clang++ warning_assert.cc -Wall Assertion failed: (PrevInit && "initializer not found in initializer list"), function DiagnoseBaseOrMemInitializerOrder, file SemaDeclCXX.cpp, line 1980. 0 clang 0x0000000100ff23f8 PrintStackTrace(void*) + 38 1 clang 0x0000000100ff28d8 SignalHandler(int) + 312 2 libSystem.B.dylib 0x00007fff880a580a _sigtramp + 26 3 clang 0x0000000100400ab0 clang::TypeSpecTypeLoc::setNameLoc(clang::SourceLocation) + 24 4 libSystem.B.dylib 0x00007fff88120ef0 __pthread_markcancel + 0 5 clang 0x00000001002cb5d8 DiagnoseBaseOrMemInitializerOrder(clang::Sema&, clang::CXXConstructorDecl const*, clang::CXXBaseOrMemberInitializer**, unsigned int) + 614 6 clang 0x00000001002cdb93 clang::Sema::ActOnMemInitializers(clang::OpaquePtr<0>, clang::SourceLocation, void**, unsigned int, bool) + 537 7 clang 0x000000010061034c clang::Parser::ParseConstructorInitializer(clang::OpaquePtr<0>) + 448 8 clang 0x00000001005feb78 clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 1098 9 clang 0x00000001005fedd6 clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 1704 10 clang 0x00000001006131aa clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::OpaquePtr<0>) + 1518 11 clang 0x000000010061459a clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 4922 12 clang 0x0000000100607b37 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 6275 13 clang 0x0000000100646336 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 118 14 clang 0x0000000100646749 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 83 15 clang 0x0000000100648485 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2211 16 clang 0x00000001006485c3 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 247 17 clang 0x000000010024d503 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 456 18 clang 0x0000000100067402 clang::ASTFrontendAction::ExecuteAction() + 256 19 clang 0x00000001000674ff clang::FrontendAction::Execute() + 239 20 clang 0x000000010004a17c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 784 21 clang 0x0000000100027b8a cc1_main(char const**, char const**, char const*, void*) + 1761 22 clang 0x000000010002bec1 main + 252 23 clang 0x0000000100026a2c start + 52 24 clang 0x0000000000000021 start + 4294809129 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name warning_assert.cc -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -resource-dir /usr/local/lib/clang/2.0 -Wall -ferror-limit 19 -fmessage-length 177 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-bcozsy.o -x c++ warning_assert.cc 1. warning_assert.cc:7:3: current parser token '{' 2. warning_assert.cc:1:1: parsing struct/union/class body 'mpi_datatype_primitive' clang: error: assembler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 20 06:00:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 06:00:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7180] New: Crash on invalid - using undefined namespaces Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7180 Summary: Crash on invalid - using undefined namespaces 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 function prototype crashes clang. Such code is easy to generate if headers for libraries are not included. void f( a::b::c ); backtrace: $ clang++ t.cc -c t.cc:1:8: error: use of undeclared identifier 'a' void f(a::b::c); ^ Assertion failed: (CachedTokens[CachedLexPos-1].getLastLoc() == Tok.getAnnotationEndLoc() && "The annotation should be until the most recent cached token"), function AnnotatePreviousCachedTokens, file PPCaching.cpp, line 95. 0 clang 0x0000000100ff23f8 PrintStackTrace(void*) + 38 1 clang 0x0000000100ff28d8 SignalHandler(int) + 312 2 libSystem.B.dylib 0x00007fff880a580a _sigtramp + 26 3 libSystem.B.dylib 0x00007fff8804a50a tiny_malloc_from_free_list + 1196 4 libSystem.B.dylib 0x00007fff88120ef0 __pthread_markcancel + 0 5 clang 0x000000010065e981 clang::Preprocessor::AnnotatePreviousCachedTokens(clang::Token const&) + 261 6 clang 0x000000010064b7bf clang::Preprocessor::AnnotateCachedTokens(clang::Token const&) + 145 7 clang 0x0000000100645d6f clang::Parser::TryAnnotateTypeOrScopeToken(bool) + 2521 8 clang 0x0000000100643344 clang::Parser::isCXXDeclarationSpecifier() + 882 9 clang 0x00000001006435f5 clang::Parser::TryParseDeclarationSpecifier() + 21 10 clang 0x0000000100643c38 clang::Parser::TryParseParameterDeclarationClause() + 100 11 clang 0x0000000100643f4e clang::Parser::isCXXFunctionDeclarator(bool) + 68 12 clang 0x00000001006099e5 clang::Parser::ParseDirectDeclarator(clang::Declarator&) + 2123 13 clang 0x0000000100603c9e clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void (clang::Parser::*)(clang::Declarator&)) + 960 14 clang 0x0000000100604150 clang::Parser::ParseDeclarator(clang::Declarator&) + 56 15 clang 0x000000010060b340 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 98 16 clang 0x00000001006466dd clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 1053 17 clang 0x0000000100646749 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 83 18 clang 0x0000000100648485 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2211 19 clang 0x00000001006485c3 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 247 20 clang 0x000000010024d503 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 456 21 clang 0x0000000100067402 clang::ASTFrontendAction::ExecuteAction() + 256 22 clang 0x00000001000674ff clang::FrontendAction::Execute() + 239 23 clang 0x000000010004a17c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 784 24 clang 0x0000000100027b8a cc1_main(char const**, char const**, char const*, void*) + 1761 25 clang 0x000000010002bec1 main + 252 26 clang 0x0000000100026a2c start + 52 27 clang 0x0000000000000020 start + 4294809128 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name t.cc -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 177 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 1. t.cc:1:8: at annotation token clang: error: assembler command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 20 12:55:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 12:55:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 6968] add -N to options.td and -N/-S to freebsd linker driver In-Reply-To: References: Message-ID: <20100520175511.52EAA3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6968 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Daniel Dunbar 2010-05-20 12:55:11 CDT --- Please just use -Wl, that is what it is there for. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 13:40:18 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 13:40:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 7167] Assertion failure "Unexpected illegal type!" in LegalizeDAG.cpp when using shufflevector In-Reply-To: References: Message-ID: <20100520184019.11E03312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7167 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Bob Wilson 2010-05-20 13:40:18 CDT --- The remaining issue is fixed in svn r104257. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 14:24:22 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 14:24:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 7181] New: Allows looser exception specification in overriding function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7181 Summary: Allows looser exception specification in overriding function Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub-johannes at web.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang does not correctly check that overriders' exception specifications are at most as loose as their base class functions. struct eB { }; struct eD : eB { }; struct A { virtual void fx() throw(eB*) { } }; struct B : A { virtual void fx() throw(eD const*) { } }; I expected this code to be rejeced, because "eD const*" is not allowed by A::fx but allowed by "B::fx". -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 18:19:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 18:19:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 7182] New: Dangerous assertions in Parser::ParseLexedMethodDefs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7182 Summary: Dangerous assertions in Parser::ParseLexedMethodDefs Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Keywords: crash-on-invalid Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, akyrtzi at gmail.com, dgregor at apple.com In two places, this method has the following assertions: assert(!PP.getSourceManager().isBeforeInTranslationUnit(origLoc, Tok.getLocation()) && "We consumed more than the cached tokens!"); assert(Tok.getLocation() == origLoc && "Tokens were left in the token stream!"); However, as part of error recovery, it's very possible that we'll end up skipping beyond the end of the function or leaving tokens in the token stream, so we shouldn't assert. Rather, we should gracefully drain the remaining tokens (that were left over in the stream) and move on. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 20 18:49:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 18:49:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 7179] assert on warning In-Reply-To: References: Message-ID: <20100520234944.19B683128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7179 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-20 18:49:43 CDT --- Fixed in r104299 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 19:31:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 19:31:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 7088] Instantiation of anonymous union in function template crashes In-Reply-To: References: Message-ID: <20100521003143.0A4843128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7088 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-20 19:31:42 CDT --- Fixed in r104305. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 19:32:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 19:32:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 7183] New: llc "Type is not extended!" assertion failure Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7183 Summary: llc "Type is not extended!" assertion failure 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: ondra.hosek at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4914) --> (http://llvm.org/bugs/attachment.cgi?id=4914) bugpoint terminal output Bleeding-edge (SVN rev 104301) llc fails to compile the simplest bitcode file, emitting an assertion failure: llc: ValueTypes.cpp:144: const llvm::Type* llvm::EVT::getTypeForEVT(llvm::LLVMContext&) const: Assertion `isExtended() && "Type is not extended!"' failed. This is a release-with-assertions build hosted on and targeting x86_64 on a Linux 2.6.34 kernel, built with GCC 4.5.0. "bugpoint --run-llc min.bc" terminal output attached as "bugpoint-type-not-extended.txt"; simplified bitcode file as "bugpoint-type-not-extended.bc". -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 19:55:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 19:55:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 7135] cast unsigned long -> double -> int gets assertion with -mno-mmx In-Reply-To: References: Message-ID: <20100521005528.673D83128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7135 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #6 from Dale Johannesen 2010-05-20 19:55:27 CDT --- Fixed here, hopefully permanently this time. http://llvm.org/viewvc/llvm-project?rev=104308&view=rev -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 22:51:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 May 2010 22:51:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7184] New: compiler command failed due to signal 6 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7184 Summary: compiler command failed due to signal 6 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: nomura at netapp.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4916) --> (http://llvm.org/bugs/attachment.cgi?id=4916) output from clang -v Using clang+llvm at svnversion 104310 /x/eng/build2/scratch/nomura/clang-LATEST/bin/clang -c -x c++ xx.i clang: error: compiler command failed due to signal 6 (use -v to see invocation) Here's the testcase as reduced by 'delta' - a wonderful timesaver! (Curiously enough, the original program was well-formed, but delta reduced it to a syntactically incorrect fragment.) [bldlsvl102]$ cat xx.i typedef struct spinnp_repl_result_t { } namespace util { class __Callback { typedef void (__Callback::*MemFunPtr) (); }; template < typename TArg1, typename TArg2, typename TArg3 > class Callback3:public __Callback { }; template < typename T, typename Arg1, typename Arg2, typename Arg3 > util::Callback3 < Arg1, Arg2, Arg3 > create_callback (void (T::*mem_fun) (Arg1, Arg2, Arg3), T * t_p) { typedef void (T::*TMemFun) (Arg1, Arg2, Arg3); void staticAssertDummyFunction (int _staticAssertReason__[((sizeof (__Callback:: MemFunPtr) == sizeof (TMemFun))) ? 1 : -1]); } class Request; class Response; class repl_spinnp::Response:virtual protected util::Noncopyable { public:class Callback:virtual protected util::Noncopyable, public ResponseCallback { private:void _callback (Request & request, spinnp_repl_result_t result, Response * response_p) { } protected: Callback ():ResponseCallback (util:: create_callback (&Callback::_callback, this)) { -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 21 04:55:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 04:55:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 7185] New: template evaluated to early Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7185 Summary: template evaluated to early Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: niebuhr at niebuhrt.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I am not sure if this is a bug. Given the code below, clang states that the function hash is not know. But doesn't the C++ standard say, that template expressions are only evaluated where they are used? And since the functions are defined below, the compiler shouldn't complain. Remark: This code snippet is from the pocolib project. template struct Hash /// A generic hash function. { std::size_t operator () (T value) const /// Returns the hash for the given value. { return hash(value); } }; std::size_t Foundation_API hash(Int8 n); std::size_t Foundation_API hash(UInt8 n); std::size_t Foundation_API hash(Int16 n); std::size_t Foundation_API hash(UInt16 n); std::size_t Foundation_API hash(Int32 n); std::size_t Foundation_API hash(UInt32 n); std::size_t Foundation_API hash(Int64 n); std::size_t Foundation_API hash(UInt64 n); std::size_t Foundation_API hash(const std::string& str); ..... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 05:22:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 05:22:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7186] New: CLang (C++) fails build of Wt 3.1.3 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7186 Summary: CLang (C++) fails build of Wt 3.1.3 Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: koen at emweb.be CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com CLang fails compiling WCanvasPaintDevice.C, WSvgImage.C, and XSSFilter.C (which compile fine with MSVC, gcc, and other compilers) of the latest release of Wt (http://prdownloads.sourceforge.net/witty/wt-3.1.3.tar.gz?download). You can also browse the source code of Wt online at: http://www.webtoolkit.eu/wt/examples/gitmodel/gitview.wt This is the error for WCanvasPaintDevice.C (it seems like WSvgImage.C suffers exactly the same problem): clang: CGExprAgg.cpp:766: void clang::CodeGen::CodeGenFunction::EmitAggregateCopy(llvm::Value*, llvm::Value*, clang::QualType, bool): Assertion `(Record->hasTrivialCopyConstructor() || Record->hasTrivialCopyAssignment()) && "Trying to aggregate-copy a type without a trivial copy " "constructor or assignment operator"' failed. 0 clang 0x00000000014e4872 1 clang 0x00000000014e4749 2 libpthread.so.0 0x00002b23b0b0d190 3 libc.so.6 0x00002b23b16fd4b5 gsignal + 53 4 libc.so.6 0x00002b23b1700f50 abort + 384 5 libc.so.6 0x00002b23b16f6481 __assert_fail + 241 6 clang 0x00000000005ea7b4 7 clang 0x00000000005e7802 8 clang 0x00000000005e7898 9 clang 0x00000000005e764e 10 clang 0x00000000005e742f 11 clang 0x00000000005eb6a3 12 clang 0x00000000005ea575 13 clang 0x00000000005d6d5b 14 clang 0x00000000005d6e73 15 clang 0x00000000005b2dc8 16 clang 0x0000000000669fb1 17 clang 0x000000000066a978 18 clang 0x000000000066aaeb 19 clang 0x000000000057bf1f 20 clang 0x000000000057bd34 21 clang 0x00000000005806ad 22 clang 0x000000000058049e 23 clang 0x0000000000580712 24 clang 0x000000000057856d 25 clang 0x0000000000422ea0 26 clang 0x00000000006a4c22 27 clang 0x000000000043e790 28 clang 0x000000000043e3fb 29 clang 0x0000000000429393 30 clang 0x000000000040931e 31 clang 0x0000000000411f4c main + 357 32 libc.so.6 0x00002b23b16e8abd __libc_start_main + 253 33 clang 0x0000000000407cb9 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name WCanvasPaintDevice.C -pic-level 2 -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -g -resource-dir /usr/local/lib/clang/2.0 -Dwt_EXPORTS -DWT_WITH_OLD_INTERNALPATH_API -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DWT_THREADED -D_REENTRANT -DBOOST_SPIRIT_THREADSAFE -DQT_NO_DEBUG -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/opt/software/boost-trunk-clang/include -I/home/koen/project/wt/git/wt/build-clang -I/home/koen/project/wt/git/wt/src/web -I/home/koen/project/wt/git/wt/src -I/home/koen/project/wt/git/wt/build-clang/src -I/home/koen/project/wt/git/wt/src/Wt/Dbo/backend/amalgamation -O2 -ferror-limit 19 -fmessage-length 224 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-w1xvdT.s -x c++ /home/koen/project/wt/git/wt/src/Wt/WCanvasPaintDevice.C 1. parser at end of file 2. /home/koen/project/wt/git/wt/src/Wt/WCanvasPaintDevice.C:23:11: LLVM IR generation of declaration 'Wt' 3. /home/koen/project/wt/git/wt/src/Wt/WCanvasPaintDevice.C:83:26: Generating code for declaration 'Wt::WCanvasPaintDevice::setPaintFlags' clang: error: compiler command failed due to signal 6 (use -v to see invocation) XSSFilter.C fails because of a compile error, which I do not think is valid (you should be able to use methods in inline implementations which are declared further down the class definition ?). In this case, print_children() is declared also in print_node, but below the invocation from an inline method. In file included from /home/koen/project/wt/git/wt/src/web/XSSFilter.C:19: /home/koen/project/wt/git/wt/src/rapidxml/rapidxml_print.hpp:115:23: error: use of undeclared identifier 'print_children' out = print_children(out, node, flags, indent); ^ /home/koen/project/wt/git/wt/src/rapidxml/rapidxml_print.hpp:390:16: note: in instantiation of function template specialization 'rapidxml::internal::print_node' requested here return internal::print_node(out, &node, flags, 0); ^ /home/koen/project/wt/git/wt/src/web/XSSFilter.C:81:5: note: in instantiation of function template specialization 'rapidxml::print' requested here print(out.back_inserter(), *doc.first_node(), print_no_indenting); ^ 1 error generated. make[2]: *** [src/CMakeFiles/wt.dir/web/XSSFilter.o] Error 1 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 21 05:24:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 05:24:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 7185] template evaluated to early In-Reply-To: References: Message-ID: <20100521102424.341DA3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7185 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |chandlerc at gmail.com Resolution| |INVALID --- Comment #1 from Chandler Carruth 2010-05-21 05:24:23 CDT --- (In reply to comment #0) > I am not sure if this is a bug. I'm pretty sure Clang is correct here. I'll try to explain... > Given the code below, clang states that the function hash is not know. But > doesn't the C++ standard say, that template expressions are only evaluated > where they are used? While this is true, the *name lookup* is more complicated than that. See [temp.dep.res] 14.6.4 in C++'03 for the details of this. The idea is called two-phase name lookup -- some names are looked up in the context of the template definition, others in the context of the instantiation. Even for names which are dependent (can change based on instantiation due to a type-dependent expression as an argument), they will not in all cases find names which occur after the template definition. Let's look at your specific case: > template > struct Hash > /// A generic hash function. > { > std::size_t operator () (T value) const > /// Returns the hash for the given value. > { > return hash(value); 'value' is type-dependent here, and so 'hash' is a dependent name, so we *might* consider names only visible in the instantiation context, but... > } > }; > > std::size_t Foundation_API hash(Int8 n); In order for an instantiation to see this declaration for the name 'hash', it must find it when searching associated namespaces, not via the usual unqualified-id name lookup. The latter only sees names visible in the template definition's context. ([temp.dep.candidate] 14.6.4.2) For the search of associated namespaces to find this declaration, its argument's type must contribute the namespace in which this function is declared to the set searched. I assume that 'Int8' is a typedef. However, C++'03 [basic.lookup.koenig] 3.4.2/2 says "Typedef names and using-declarations used to specify the types do not contribute to this set." and the first bullet point in that paragraph goes on to say "If T is a fundamental type, its associated sets of namespaces and classes are both empty." Because of this I don't think any associated namespaces will be contributed from the arguments to this function, and thus this declaration cannot be found. This is an area where GCC is known to be exceedingly lax, but Clang tries very hard to precisely enforce the standard's requirements of name lookup. Hope this helps! (And if I've missed anything I'm sure dgregor or others will chime in.) -Chandler -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 07:06:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 07:06:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 7187] New: Add zero-cost exceptions for ARM (EHABI) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7187 Summary: Add zero-cost exceptions for ARM (EHABI) Product: clang Version: trunk Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rengolin at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4918) --> (http://llvm.org/bugs/attachment.cgi?id=4918) Example of ASM files created by clang and GCC. Compile with arm-none-eabi-g++. Dwarf exceptions are available for x86 and SjLj for ARM. While there is a bug report to make SjLj work on other platforms (as fail-safe), would be good to have zero-cost exception handling in clang for ARM too. To do this, there are three steps that need to be followed: 1. Make sure that the dwarf table generated by LLVM is compatible with the ARM ABI. While the tables are very similar, some problems are being observed when assembling with clang and compiling with GCC in the table format (will attach example). In order to test that, we can run all clang/LLVM exception tests by assembling it with arch=arm-eabi and finishing the compilation process with arm-none-eabi-g++. All tests should run flawlessly in an ARM chip or simulator. 2. Once the assembly is correct and working with arm-gcc, we can start working in the codegen section to create ARM specific tables (Generic mode first, then Compact). To test this, a full compilation with clang/LLVM shall be done on the same tests. The third step below is more important than implementing the compact EH table mode. 3. Make sure the generated tables link together with GCC. To test this, a compilation with clang/LLVM until object files shall be done and linkage with arm-none-eabi-ld. The same tests should pass. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 21 08:36:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 08:36:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 7188] New: Virtual inheritance crashes clang++ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7188 Summary: Virtual inheritance crashes clang++ Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mmo at vizrt.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4920) --> (http://llvm.org/bugs/attachment.cgi?id=4920) Small contrived example which crashes clang++ The code (attached: crashes.cc) with virtual inheritance crashes clang++ with the following stack trace: $ clang++ crashes.cc -v clang version 2.0 (trunk 104313) Target: x86_64-unknown-linux-gnu Thread model: posix "/usr/local/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name crashes.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 174 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Euw0c9.s -x c++ crashes.cc clang -cc1 version 2.0 based upon llvm 2.8svn hosted on x86_64-unknown-linux-gnu #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.4 /usr/include/c++/4.4/x86_64-linux-gnu /usr/include/c++/4.4/backward /usr/local/include /usr/local/lib/clang/2.0/include /usr/include End of search list. clang: CGExprAgg.cpp:766: void clang::CodeGen::CodeGenFunction::EmitAggregateCopy(llvm::Value*, llvm::Value*, clang::QualType, bool): Assertion `(Record->hasTrivialCopyConstructor() || Record->hasTrivialCopyAssignment()) && "Trying to aggregate-copy a type without a trivial copy " "constructor or assignment operator"' failed. 0 clang 0x000000000129aedf 1 clang 0x000000000129d06a 2 libpthread.so.0 0x00007f7b43e948f0 3 libc.so.6 0x00007f7b43184a75 gsignal + 53 4 libc.so.6 0x00007f7b431885c0 abort + 384 5 libc.so.6 0x00007f7b4317d941 __assert_fail + 241 6 clang 0x0000000000576608 7 clang 0x00000000005766bd 8 clang 0x000000000057685a 9 clang 0x0000000000579242 10 clang 0x0000000000579968 11 clang 0x0000000000567210 12 clang 0x000000000056734e 13 clang 0x0000000000542921 14 clang 0x00000000005e6e8d 15 clang 0x00000000005e7dd3 16 clang 0x00000000005f1a6c 17 clang 0x000000000052728e 18 clang 0x00000000005274e0 19 clang 0x0000000000527599 20 clang 0x0000000000419125 21 clang 0x000000000061bf2f 22 clang 0x000000000041c461 23 clang 0x0000000000409d46 24 clang 0x000000000040fcd1 main + 3185 25 libc.so.6 0x00007f7b4316fc4d __libc_start_main + 253 26 clang 0x0000000000407629 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name crashes.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 174 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Euw0c9.s -x c++ crashes.cc 1. parser at end of file 2. Per-file LLVM IR generation 3. crashes.cc:23:10: Generating code for declaration 'foobarbaz::baz' clang: error: compiler command failed due to signal 6 (use -v to see invocation) If instead bar takes std::string as an argument, and baz does not have any arguments, the example compiles without problems. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 10:59:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 10:59:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 7189] New: Miscompilation of Qt foreach macro Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7189 Summary: Miscompilation of Qt foreach macro Product: clang Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ogoffart at kde.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4921) --> (http://llvm.org/bugs/attachment.cgi?id=4921) preprocessed clang miscompile the qt foreach macro. Only the first iteration is executed. #include #include #include int main() { std::vector v(3); v[0] = 0; v[1] = 1; v[2] = 2; foreach(int i, v) std::cout << i << std::endl; } Maybe because of the use of the statements in expressions extension of gcc. This is the reason why uic produces bad result when compiling Qt. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 12:55:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 12:55:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 7188] Virtual inheritance crashes clang++ In-Reply-To: References: Message-ID: <20100521175544.232173128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7188 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-21 12:55:43 CDT --- Fixed in r104327. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 12:56:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 12:56:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 7186] CLang (C++) fails build of Wt 3.1.3 In-Reply-To: References: Message-ID: <20100521175637.63A643128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7186 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2010-05-21 12:56:36 CDT --- This should be fixed in Clang r104327. Please re-open if this problem is not fixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 21 13:18:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 13:18:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 6828] fp stackifier crash In-Reply-To: References: Message-ID: <20100521181805.402283128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6828 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2010-05-21 13:18:04 CDT --- Fixed in r104333 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 13:18:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 13:18:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 7081] Assertion "Stack not empty at end of basic block?" when using target_cpu=i486 In-Reply-To: References: Message-ID: <20100521181859.4F2A03128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7081 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Chris Lattner 2010-05-21 13:18:58 CDT --- Yep, dupe of 6828, which I just fixed. Please reopen if not. *** This bug has been marked as a duplicate of bug 6828 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 13:37:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 13:37:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 7189] Miscompilation of Qt foreach macro In-Reply-To: References: Message-ID: <20100521183717.D75B23128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7189 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-21 13:37:17 CDT --- Fixed in r104335 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 15:29:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 15:29:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 7183] llc "Type is not extended!" assertion failure In-Reply-To: References: Message-ID: <20100521202911.B2573312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7183 Ondra Ho?ek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Ondra Ho?ek 2010-05-21 15:29:11 CDT --- Okay, I just did a clean rebuild of the whole LLVM tree and the problem disappeared. In retrospect, I should've done that before filing a bug. I'm sorry for wasting your time. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 21 15:30:07 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 15:30:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 7176] Assertion failed: (BaseType.isCanonical() && "Base type must be the canonical type") In-Reply-To: References: Message-ID: <20100521203007.3B1913128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7176 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Douglas Gregor 2010-05-21 15:30:06 CDT --- Fixed in r104374 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 16:23:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 16:23:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 7190] New: clang crashes trying to instantiate an invalid friend decl Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7190 Summary: clang crashes trying to instantiate an invalid friend decl Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rideau3 at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In the attached testcase, clang will attempt to instantiate the friend decl which is invalid because Derived has not been declared. Backtrace: #0 0x080e87c1 in clang::TypeSourceInfo::getType (this=0x0) at /home/coppro/code/c++/llvm/tools/clang/lib/Frontend/../../include/clang/AST/Decl.h:55 #1 0x0844123c in clang::Sema::SubstType (this=0xbfffe250, T=0x0, Args=..., Loc=..., Entity=...) at SemaTemplateInstantiate.cpp:945 #2 0x08441696 in clang::Sema::SubstParmVarDecl (this=0xbfffe250, OldParm=0x97bb970, TemplateArgs=...) at SemaTemplateInstantiate.cpp:1022 #3 0x08477102 in VisitParmVarDecl (this=0xbfff95e4, D=0x97bb970) at SemaTemplateInstantiateDecl.cpp:1409 #4 0x08478a90 in SubstFunctionType (this=0xbfff95e4, D=0x97bb9c0, Params=...) at SemaTemplateInstantiateDecl.cpp:1869 #5 0x084754bd in VisitFunctionDecl (this=0xbfff95e4, D=0x97bb9c0, TemplateParams=0x0) at SemaTemplateInstantiateDecl.cpp:962 #6 0x0847b3ec in Visit (this=0xbfff95e4, D=0x97bb9c0) at /home/coppro/code/c++/llvm/tools/clang/lib/Sema/../../include/clang/AST/DeclNodes.def:96 #7 0x08473b62 in VisitFriendDecl (this=0xbfff95e4, D=0x97bba20) at SemaTemplateInstantiateDecl.cpp:528 #8 0x0847b69d in Visit (this=0xbfff95e4, D=0x97bba20) at /home/coppro/code/c++/llvm/tools/clang/lib/Sema/../../include/clang/AST/DeclNodes.def:129 #9 0x0847800e in clang::Sema::SubstDecl (this=0xbfffe250, D=0x97bba20, Owner=0x97bcbcc, TemplateArgs=...) at SemaTemplateInstantiateDecl.cpp:1655 #10 0x08441fb1 in clang::Sema::InstantiateClass (this=0xbfffe250, PointOfInstantiation=..., Instantiation=0x97bcbb0, Pattern=0x97b70e8, TemplateArgs=..., TSK=clang::TSK_ImplicitInstantiation, Complain=true) at SemaTemplateInstantiate.cpp:1200 #11 0x0844283d in clang::Sema::InstantiateClassTemplateSpecialization (this=0xbfffe250, PointOfInstantiation=..., ClassTemplateSpec=0x97bcbb0, TSK=clang::TSK_ImplicitInstantiation, Complain=true) at SemaTemplateInstantiate.cpp:1394 #12 0x084857be in clang::Sema::RequireCompleteType (this=0xbfffe250, Loc=..., T=..., PD=..., Note=...) at SemaType.cpp:2063 #13 0x08485b5e in clang::Sema::RequireCompleteType (this=0xbfffe250, Loc=..., T=..., PD=...) at SemaType.cpp:2114 #14 0x0839f8a8 in clang::Sema::ActOnCXXTypeConstructExpr (this=0xbfffe250, TypeRange=..., TypeRep=0x97bbb28, LParenLoc=..., exprs=..., CommaLocs=0xbfffb3c8, RParenLoc=...) at SemaExprCXX.cpp:515 #15 0x086bdc0b in clang::Parser::ParseCXXTypeConstructExpression (this=0xbfffe9e0, DS=...) at ParseExprCXX.cpp:675 #16 0x086b5875 in clang::Parser::ParseCastExpression (this=0xbfffe9e0, isUnaryExpression=false, isAddressOfOperand=false, NotCastExpr=@0xbfffbb8f, TypeOfCast=0x0) at ParseExpr.cpp:785 #17 0x086b3637 in clang::Parser::ParseCastExpression (this=0xbfffe9e0, isUnaryExpression=false, isAddressOfOperand=false, TypeOfCast=0x0) at ParseExpr.cpp:403 #18 0x086b3d9a in clang::Parser::ParseCastExpression (this=0xbfffe9e0, isUnaryExpression=false, isAddressOfOperand=false, NotCastExpr=@0xbfffc2cf, TypeOfCast=0x0) at ParseExpr.cpp:609 #19 0x086b3637 in clang::Parser::ParseCastExpression (this=0xbfffe9e0, isUnaryExpression=false, isAddressOfOperand=false, TypeOfCast=0x0) at ParseExpr.cpp:403 #20 0x086b22ef in clang::Parser::ParseAssignmentExpression (this=0xbfffe9e0) at ParseExpr.cpp:231 #21 0x086ba8e0 in clang::Parser::ParseExpressionList (this=0xbfffe9e0, Exprs=..., CommaLocs=..., Completer=&virtual table offset 848, Data=0x97bba48) at ParseExpr.cpp:1547 #22 0x086b6b4a in clang::Parser::ParsePostfixExpressionSuffix (this=0xbfffe9e0, LHS=...) at ParseExpr.cpp:961 #23 0x086b423e in clang::Parser::ParseCastExpression (this=0xbfffe9e0, isUnaryExpression=false, isAddressOfOperand=false, NotCastExpr=@0xbfffcd8f, TypeOfCast=0x0) at ParseExpr.cpp:647 #24 0x086b3637 in clang::Parser::ParseCastExpression (this=0xbfffe9e0, isUnaryExpression=false, isAddressOfOperand=false, TypeOfCast=0x0) at ParseExpr.cpp:403 #25 0x086b22ef in clang::Parser::ParseAssignmentExpression (this=0xbfffe9e0) at ParseExpr.cpp:231 #26 0x086b1c01 in clang::Parser::ParseExpression (this=0xbfffe9e0) at ParseExpr.cpp:180 #27 0x086ba182 in clang::Parser::ParseParenExpression (this=0xbfffe9e0, ExprType=@0xbfffd1b4, stopIfCastExpr=true, TypeOfCast=0x0, CastTy=@0xbfffd274, RParenLoc=...) at ParseExpr.cpp:1462 #28 0x086b7821 in clang::Parser::ParseExprAfterTypeofSizeofAlignof (this=0xbfffe9e0, OpTok=..., isCastExpr=@0xbfffd27f, CastTy=@0xbfffd274, CastRange=...) at ParseExpr.cpp:1116 #29 0x086b7af1 in clang::Parser::ParseSizeofAlignofExpression (this=0xbfffe9e0) at ParseExpr.cpp:1158 #30 0x086b503f in clang::Parser::ParseCastExpression (this=0xbfffe9e0, isUnaryExpression=false, isAddressOfOperand=false, NotCastExpr=@0xbfffd9bf, TypeOfCast=0x0) at ParseExpr.cpp:721 #31 0x086b3637 in clang::Parser::ParseCastExpression (this=0xbfffe9e0, isUnaryExpression=false, isAddressOfOperand=false, TypeOfCast=0x0) at ParseExpr.cpp:403 #32 0x086b22ef in clang::Parser::ParseAssignmentExpression (this=0xbfffe9e0) at ParseExpr.cpp:231 #33 0x086c6ed5 in clang::Parser::ParseNonTypeTemplateParameter (this=0xbfffe9e0, Depth=0, Position=0) at ParseTemplate.cpp:590 #34 0x086c63d0 in clang::Parser::ParseTemplateParameter (this=0xbfffe9e0, Depth=0, Position=0) at ParseTemplate.cpp:399 #35 0x086c6164 in clang::Parser::ParseTemplateParameterList (this=0xbfffe9e0, Depth=0, TemplateParams=...) at ParseTemplate.cpp:313 #36 0x086c608a in clang::Parser::ParseTemplateParameters (this=0xbfffe9e0, Depth=0, TemplateParams=..., LAngleLoc=..., RAngleLoc=...) at ParseTemplate.cpp:290 #37 0x086c5765 in clang::Parser::ParseTemplateDeclarationOrSpecialization (this=0xbfffe9e0, Context=0, DeclEnd=..., AS=clang::AS_none) at ParseTemplate.cpp:127 #38 0x086c5538 in clang::Parser::ParseDeclarationStartingWithTemplate (this=0xbfffe9e0, Context=0, DeclEnd=..., AS=clang::AS_none) at ParseTemplate.cpp:32 #39 0x0869d653 in clang::Parser::ParseDeclaration (this=0xbfffe9e0, Context=0, DeclEnd=..., Attr=...) at ParseDecl.cpp:319 #40 0x08697f18 in clang::Parser::ParseExternalDeclaration (this=0xbfffe9e0, Attr=...) at Parser.cpp:461 #41 0x086978db in clang::Parser::ParseTopLevelDecl (this=0xbfffe9e0, Result=...) at Parser.cpp:351 #42 0x082d741c in clang::ParseAST (PP=..., Consumer=0x979f3f0, Ctx=..., PrintStats=false, CompleteTranslationUnit=true, CompletionConsumer=0x0) at ParseAST.cpp:87 #43 0x080808f2 in clang::ASTFrontendAction::ExecuteAction (this=0x9782350) at FrontendAction.cpp:224 #44 0x08080563 in clang::FrontendAction::Execute (this=0x9782350) at FrontendAction.cpp:150 #45 0x0806cc8d in clang::CompilerInstance::ExecuteAction (this=0x9782170, Act=...) at CompilerInstance.cpp:511 #46 0x0804ea75 in cc1_main (ArgBegin=0xbffff40c, ArgEnd=0xbffff410, Argv0=0xbffff580 "/usr/local/bin/clang++", MainAddr=0x80564a4) at cc1_main.cpp:285 #47 0x080572b3 in main (argc=3, argv=0xbffff404) at driver.cpp:186 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 16:25:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 16:25:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 7184] Assertion `D->isInvalidDecl() && "declaration was not instantiated in this scope!"' failed In-Reply-To: References: Message-ID: <20100521212546.36C8B3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7184 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-21 16:25:45 CDT --- Fixed in r104386. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 16:47:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 16:47:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 7139] ptr to member not zeroed In-Reply-To: References: Message-ID: <20100521214735.E4C393128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7139 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Anders Carlsson 2010-05-21 16:47:35 CDT --- Committed revision 104387. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 17:30:39 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 17:30:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 7191] New: [instruction selection] float compare -> int result + march=athlon64-sse3 == "Cannot yet slect ... X86ISD::FP_TO_INT32_IN_MEM" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7191 Summary: [instruction selection] float compare -> int result + march=athlon64-sse3 == "Cannot yet slect ... X86ISD::FP_TO_INT32_IN_MEM" Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: kaffeemonster at googlemail.com CC: llvmbugs at cs.uiuc.edu The only floating point snippet in my programm and clang barfs on it, i think im jinxed... clang/llvm TOT at 104387 unsigned short foo(double d_lat) { unsigned short s_lat; d_lat = (d_lat + 90.0) * 65535.0 / 180.0; s_lat = d_lat < 0.0 ? 0 : (d_lat > 65535.0 ? 65535 : (unsigned short)d_lat); return s_lat; } compile with "clang -c -march=athlon64-sse3 fp.c -o fp.o", result: fatal error: error in backend: Cannot yet select: 0xa13a670: ch = X86ISD::FP_TO_INT32_IN_MEM 0xa12c178, 0xa13a230, 0xa140378 [ID=7] 0xa12c178: ch = EntryToken [ORD=9] [ID=0] 0xa13a230: f64,ch = load 0xa12c178, 0xa13a120, 0xa13a450 [ORD=9] [ID=6] 0xa12c178: ch = EntryToken [ORD=9] [ID=0] 0xa13a120: i32 = FrameIndex<1> [ORD=9] [ID=1] 0xa13a450: i32 = undef [ORD=9] [ID=2] 0xa140378: i32 = FrameIndex<3> [ID=4] Greetings Jan -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 18:31:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 18:31:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 7192] New: clang -Wwrite-strings doesn't allow writing to wchars Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7192 Summary: clang -Wwrite-strings doesn't allow writing to wchars Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nunoplopes at sapo.pt CC: llvmbugs at cs.uiuc.edu $ cat a.c #include void foo(wchar_t *dst) { dst[0] = 0; } $ clang -c -Wwrite-strings a.c a.c:3:11: error: read-only variable is not assignable dst[0] = 0; ~~~~~~ ^ 1 error generated. $ gcc -c -Wwrite-strings a.c (ok) $ clang -E -o - a.c | grep wchar | grep typedef typedef __typeof__(*L"") wchar_t; $ gcc -E -o - a.c | grep wchar | grep typedef typedef long int wchar_t; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 21 18:44:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 18:44:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 5404] Improve diagnostics/recovery for dependent template name after '.' or '->' In-Reply-To: References: Message-ID: <20100521234408.985C73128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5404 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-21 18:44:08 CDT --- Fixed in r104409. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 18:48:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 18:48:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 6945] Failed template argument deduction should mention argument types In-Reply-To: References: Message-ID: <20100521234822.007413128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6945 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-21 18:48:21 CDT --- This was fixed a few weeks ago, and is much more helpful now: t.cpp:4:12: error: no matching function for call to 'max' return std::max(arg1, arg2); ^~~~~~~~ In file included from t.cpp:1: In file included from /usr/include/c++/4.2.1/algorithm:64: /usr/include/c++/4.2.1/bits/stl_algobase.h:204:5: note: candidate template ignored: deduced conflicting types for parameter '_Tp' ('int' vs. 'long') max(const _Tp& __a, const _Tp& __b) ^ /usr/include/c++/4.2.1/bits/stl_algobase.h:246:5: note: candidate function template not viable: requires 3 arguments, but 2 were provided max(const _Tp& __a, const _Tp& __b, _Compare __comp) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 19:08:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 19:08:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7193] New: regparm + call to normal func + >= -O1 == "error in backend: Ran out of registers" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7193 Summary: regparm + call to normal func + >= -O1 == "error in backend: Ran out of registers" Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: kaffeemonster at googlemail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4922) --> (http://llvm.org/bugs/attachment.cgi?id=4922) testcase TOT at 104387 i386 $ clang -c -O1 xm.c fatal error: error in backend: Ran out of registers during register allocation! Greetings Jan -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 20:14:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 20:14:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7194] New: Possible bug when combining functions returning const enum and the conditional operator? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7194 Summary: Possible bug when combining functions returning const enum and the conditional operator? Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: funkytune84 at hotmail.com CC: llvmbugs at cs.uiuc.edu The following code compiles in g++, but gives an error in clang++. If the two 'const' specifiers are removed, it works in clang++ as well. enum My_Enum { A, B }; const My_Enum Get_A() { return A; } int main( int argc, char **argv ) { const My_Enum result = true ? Get_A() : B; return 0; } error: cannot initialize a variable of type 'My_Enum const' with an rvalue of type 'int' const My_Enum result = true ? Get_A() : B; ^ ~~~~~~~~~~~~~~~~~~ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 21 22:43:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 May 2010 22:43:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7195] New: [RFE] Support 16-bit x86 code generation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7195 Summary: [RFE] Support 16-bit x86 code generation Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: cdavis at mymail.mines.edu CC: llvmbugs at cs.uiuc.edu While trying to compile Wine with clang, the configure script produced this: checking whether 16-bit code can be built correctly... no configure: error: Xcode 3.x cannot build 16-bit code correctly. Use --disable-win16 if you don't need 16-bit support But the linker was fixed in Xcode 3.2, and it works with GCC, so I did a little investigation and found that the test program they use does not compile with clang -integrated-as: $ cat test.c asm(".text\n" "bad:\tnop;nop;\n" "good:\tnop;nop;\n" ".globl _testfunc\n" "_testfunc:\tcallw good"); extern void testfunc(); int main(void) { unsigned short *p = (unsigned short*)testfunc; return p[0] != 0xe866 || p[0] != 0xfffa; } $ clang test.c :5:12: error: unrecognized instruction _testfunc: callw good ^ 1 error generated. Since -integrated-as is the default on Mac OS X now, I either have to pass --disable-win16 to Wine configure or set CFLAGS="-no-integrated-as". Now I understand that 16-bit code makes you guys shudder, but it would be really nice if I could just drop in clang and build Wine without setting any additional settings. Besides, imagine the other possible applications. The Wine people, for example, have expressed general interest in a 16-bit compiler. I'll even work on this (since I know no one else wants to). I'm just filing this to keep track of what the rest of you probably consider a non-issue. I know in the past that I suggested making a separate x86-16 backend (which really made Chris recoil in horror, like I predicted he would), but that's not what I'm suggesting here. I just want to extend the existing x86 backend to support 16-bit codegen. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 06:37:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 06:37:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 7196] New: sizeof member doesn't work in enum initializer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7196 Summary: sizeof member doesn't work in enum initializer Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Keywords: compile-fail Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jbytheway+llvm at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following C++ code works fine with g++, but gets a compile error with clang: ======= struct A { int a; void f() { char i[sizeof(a)]; // Works fine enum { x = sizeof(i) }; // Works fine enum { y = sizeof(a) }; // Compile error } }; int main() { return 0; } ======= It yields "error: invalid use of nonstatic data member 'a'". I haven't looked at the standard in detail, but I'm pretty sure this should be possible. In particular it's possible to get at the same value indirectly by first defining a local variable and taking the size of that, as demonstrated above. This issue arose because I had code using BOOST_MPL_ASSERT_RELATION to check the size of a member, which expands to something assigning the asserted relation to an enum value. The above example is simplified from 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 Sat May 22 09:05:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 09:05:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 7197] New: Dereference of undefined pointer value false positive Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7197 Summary: Dereference of undefined pointer value false positive Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: alexei.svitkine at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4924) --> (http://llvm.org/bugs/attachment.cgi?id=4924) test case. See attached file. The pointer can never be undefined because i == MAX_FOO will evaluate to true and the second part of the if statement will not be executed due to short circuit evaluation. But the analyzer makes a mistake in thinking there's a problem here: test.c:26:34: warning: Dereference of undefined pointer value if (i == MAX_FOO || foo_ptr->bar == 123) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 11:18:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 11:18:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 5678] [extension] variable length arrays are not permitted in C++ in GNU mode. In-Reply-To: References: Message-ID: <20100522161842.1C0773128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5678 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Douglas Gregor 2010-05-22 11:18:41 CDT --- Implemented in Clang r104443. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 11:26:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 11:26:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 7196] sizeof member doesn't work in enum initializer In-Reply-To: References: Message-ID: <20100522162650.232643128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7196 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-22 11:26:49 CDT --- Fixed in r104444. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 11:47:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 11:47:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7198] New: Assertion failure "Did not find a destructor!" in clang on valid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7198 Summary: Assertion failure "Did not find a destructor!" in clang on valid code Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Keywords: compile-fail Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jbytheway+llvm at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang suffers an assertion failure when compiling this valid C++ code (which g++ compiles fine): ========== struct A { ~A() { } }; template struct B { struct C : A {}; void f() { C c = C(); } }; int main() { return 0; } ========== The error message is: $ clang ice.cpp clang: DeclCXX.cpp:578: clang::CXXDestructorDecl* clang::CXXRecordDecl::getDestructor(clang::ASTContext&) const: Assertion `I != E && "Did not find a destructor!"' failed. 0 clang 0x00000000012864af 1 clang 0x0000000001288639 2 libpthread.so.0 0x00007f0a2eb69a40 3 libc.so.6 0x00007f0a2de8b065 gsignal + 53 4 libc.so.6 0x00007f0a2de8c490 abort + 384 5 libc.so.6 0x00007f0a2de8410a __assert_fail + 234 6 clang 0x00000000008f7afc 7 clang 0x000000000067308c 8 clang 0x000000000065c282 9 clang 0x000000000065ca46 10 clang 0x000000000098033a 11 clang 0x0000000000986a83 12 clang 0x0000000000987788 13 clang 0x00000000009878ec 14 clang 0x000000000096e199 15 clang 0x000000000096ef56 16 clang 0x000000000096f8b1 17 clang 0x00000000009aea3e 18 clang 0x00000000009912c0 19 clang 0x0000000000991efc 20 clang 0x0000000000983e9c 21 clang 0x00000000009ad68d 22 clang 0x00000000009ae3bc 23 clang 0x00000000009ae63b 24 clang 0x00000000009879cd 25 clang 0x000000000097c5e0 26 clang 0x000000000097c7ea 27 clang 0x000000000061756b 28 clang 0x000000000041de8f 29 clang 0x0000000000409c8e 30 clang 0x000000000040fcd1 main + 3137 31 libc.so.6 0x00007f0a2de77a3d __libc_start_main + 253 32 clang 0x0000000000407639 Stack dump: 0. Program arguments: .../llvm/Debug/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name ice.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir .../llvm/Debug/lib/clang/2.0 -ferror-limit 19 -fmessage-length 80 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-lc2ugx.s -x c++ ice.cpp 1. ice.cpp:11:14: current parser token ';' 2. ice.cpp:7:1: parsing struct/union/class body 'B' 3. ice.cpp:10:3: parsing function body 'B::f' 4. ice.cpp:10:3: in compound statement ('{}') clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 12:13:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 12:13:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 7198] Assertion failure "Did not find a destructor!" in clang on valid code In-Reply-To: References: Message-ID: <20100522171305.C50883128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7198 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-22 12:13:05 CDT --- Fixed in r104445. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 13:03:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 13:03:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 7199] New: Assertion ... "Declaration context must already be complete!"' failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7199 Summary: Assertion ... "Declaration context must already be complete!"' failed Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nomura at netapp.com CC: llvmbugs at cs.uiuc.edu svnversion 104435 "delta" produced a fragment, but the assert string is identical to the one from the original input -- hopefully this testcase is representative. (If delta is told to maintain syntax correctness at each step, it converges extremely slowly.) namespace Coral { template < typename objectclass > class CpuFactoryPalette; template < typename objectclass > class CpuFactory; } template < typename objectclass > class Coral::CpuFactory { typedef struct CpuFactoryPalette < objectclass >::widget widgetclass; struct cpufactory_percpu { } _priorities[1]; }; namespace Coral { class MdpeFactory; class MetaDataPullEngine; class Coral::MdpeFactory { private:CpuFactory < MetaDataPullEngine > _factory; # end testcase [cyclsvl07]$ /x/eng/build2/scratch/nomura/clang-LATEST/bin/clang -c -x c++ xx.i clang: /x/eng/build_scratch2/nomura/clang-llvm_100522_0000/llvm/tools/clang/lib/Sema/SemaLookup.cpp:1101: bool clang::Sema::LookupQualifiedName(clang::LookupResult&, clang::DeclContext*, bool): Assertion `(!isa(LookupCtx) || LookupCtx->isDependentContext() || cast(LookupCtx)->isDefinition() || Context.getTypeDeclType(cast(LookupCtx))->getAs() ->isBeingDefined()) && "Declaration context must already be complete!"' failed. 0 clang 0x00000000014f5c3f 1 clang 0x00000000014f66c7 2 libpthread.so.0 0x000000381100e7c0 3 libc.so.6 0x0000003810430265 gsignal + 53 4 libc.so.6 0x0000003810431d10 abort + 272 5 libc.so.6 0x00000038104296e6 __assert_fail + 246 6 clang 0x00000000007b767b 7 clang 0x000000000083c8ce 8 clang 0x0000000000861e8d 9 clang 0x0000000000851679 10 clang 0x0000000000853b71 11 clang 0x00000000008652c9 12 clang 0x00000000008763f0 13 clang 0x0000000000878992 14 clang 0x000000000087b1e2 15 clang 0x0000000000863b7a 16 clang 0x0000000000864877 17 clang 0x00000000008832a6 18 clang 0x0000000000883493 19 clang 0x00000000006e7e7d 20 clang 0x00000000006e86c5 21 clang 0x000000000070842c 22 clang 0x0000000000aa593d 23 clang 0x0000000000aa84f0 24 clang 0x0000000000aa92f6 25 clang 0x0000000000a990e5 26 clang 0x0000000000a8c779 27 clang 0x0000000000a8cd74 28 clang 0x0000000000a8dd9a 29 clang 0x0000000000aa3bf6 30 clang 0x0000000000a9f96d 31 clang 0x0000000000a8e3d5 32 clang 0x0000000000a8e91a 33 clang 0x000000000069646e 34 clang 0x00000000004408fa 35 clang 0x000000000042d170 36 clang 0x0000000000432c84 main + 2724 37 libc.so.6 0x000000381041d994 __libc_start_main + 244 38 clang 0x000000000042b329 Stack dump: 0. Program arguments: /x/eng/build_scratch2/nomura/clang-llvm_100522_0000/root/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name xx.i -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /x/eng/build_scratch2/nomura/clang-llvm_100522_0000/root/lib/clang/2.0 -ferror-limit 19 -fmessage-length 197 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-xBVlHa.s -x c++ xx.i 1. xx.i:18:53: current parser token ';' 2. xx.i:12:1: parsing namespace 'Coral' 3. xx.i:16:3: parsing struct/union/class body 'Coral::MdpeFactory' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 13:45:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 13:45:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 7200] New: Provide -f flags to turn on individual C++0x features Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7200 Summary: Provide -f flags to turn on individual C++0x features Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jyasskin at google.com CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu, dgregor at apple.com Right now, clang provides --std=c++0x to turn on all the features from C++0x that it's implemented. However, it would be useful for organizations migrating to C++0x to turn on one feature at a time. For example, we might turn on -fenable-c++0x-auto before -fenable-c++0x-lambdas. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 14:14:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 14:14:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7201] New: Undefined references to libstdc++ vtables when compiling with -O2, no problems with -O0 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7201 Summary: Undefined references to libstdc++ vtables when compiling with -O2, no problems with -O0 Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tronic+hfu3 at trn.iki.fi CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com $ cat testi.cc #include #include int main() { std::cout << boost::lexical_cast(1.23) << "Hello\n"; } $ clang++ testi.cc && ./a.out 1.23Hello $ clang++ -O2 testi.cc && ./a.out /tmp/cc.o: In function `bool boost::detail::lexical_stream_limited_src >, std::char_traits >::lcast_put(double const&)': testi.cc:(.gnu.linkonce.t._ZN5boost6detail26lexical_stream_limited_srcIcSt15basic_streambufIcSt11char_traitsIcEES4_E9lcast_putIdEEbRKT_+0x70): undefined reference to `vtable for std::basic_ostream >' testi.cc:(.gnu.linkonce.t._ZN5boost6detail26lexical_stream_limited_srcIcSt15basic_streambufIcSt11char_traitsIcEES4_E9lcast_putIdEEbRKT_+0x7b): undefined reference to `vtable for std::basic_ostream >' testi.cc:(.gnu.linkonce.t._ZN5boost6detail26lexical_stream_limited_srcIcSt15basic_streambufIcSt11char_traitsIcEES4_E9lcast_putIdEEbRKT_+0x89): undefined reference to `vtable for std::basic_ostream >' testi.cc:(.gnu.linkonce.t._ZN5boost6detail26lexical_stream_limited_srcIcSt15basic_streambufIcSt11char_traitsIcEES4_E9lcast_putIdEEbRKT_+0xcf): undefined reference to `VTT for std::basic_ostream >' testi.cc:(.gnu.linkonce.t._ZN5boost6detail26lexical_stream_limited_srcIcSt15basic_streambufIcSt11char_traitsIcEES4_E9lcast_putIdEEbRKT_+0xe1): undefined reference to `VTT for std::basic_ostream >' testi.cc:(.gnu.linkonce.t._ZN5boost6detail26lexical_stream_limited_srcIcSt15basic_streambufIcSt11char_traitsIcEES4_E9lcast_putIdEEbRKT_+0x140): undefined reference to `VTT for std::basic_ostream >' testi.cc:(.gnu.linkonce.t._ZN5boost6detail26lexical_stream_limited_srcIcSt15basic_streambufIcSt11char_traitsIcEES4_E9lcast_putIdEEbRKT_+0x152): undefined reference to `VTT for std::basic_ostream >' collect2: ld returned 1 exit status clang: error: linker command failed with exit code 1 (use -v to see invocation) $ If lexical_cast is removed, the program compiles fine with -O2 too. 20:43 <@baldrick> Tronic: probably the vtable is expected to be output in a different object file, so the optimizers eliminate it in yours -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 14:38:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 14:38:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 7202] New: Boost thread ambiguity when used in a template function, with operator new Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7202 Summary: Boost thread ambiguity when used in a template function, with operator new Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tronic+hfu3 at trn.iki.fi CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com $ cat testi.cc #include struct Foo { template Foo(T) { new boost::thread(boost::ref(*this)); } void operator()() {} }; int main() { Foo foo(1); } $ clang++ testi.cc -lboost_thread-mt testi.cc:5:3: error: call to constructor of 'boost::thread' is ambiguous new boost::thread(boost::ref(*this)); ^ testi.cc:11:6: note: in instantiation of function template specialization 'Foo::Foo' requested here Foo foo(1); ^ In file included from testi.cc:1: In file included from /usr/include/boost/thread.hpp:13: In file included from /usr/include/boost/thread/thread.hpp:22: /usr/include/boost/thread/detail/thread.hpp:185:18: note: candidate constructor [with F = boost::reference_wrapper] explicit thread(F f,typename disable_if >, dummy* >::type=0): ^ /usr/include/boost/thread/detail/thread.hpp:226:9: note: candidate constructor [with F = boost::reference_wrapper, A1 = boost::thread::dummy *] thread(F f,A1 a1): ^ 1 error generated. Make Foo::Foo non-template or remove the new in front of boost::thread and the program builds fine. Workaround: new boost::thread(&Foo::operator(), this) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 17:29:02 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 17:29:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 7203] New: Cast kind 7 not handled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7203 Summary: Cast kind 7 not handled Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: castet.matthieu at free.fr CC: llvmbugs at cs.uiuc.edu The attached testcase produce an assert in clang $scan-build gcc /tmp/test1.c -o /tmp/test1.o -c Cast kind 7 not handled. clang: GRExprEngine.cpp:2397: void clang::GRExprEngine::VisitCast(clang::CastExpr*, clang::Expr*, clang::ExplodedNode*, clang::ExplodedNodeSet&, bool): Assertion `0' failed. 0 clang 0x09014718 Stack dump: 0. Program arguments: /data/build/userspace/llvm/llvm/Release/bin//clang -cc1 -DIBOutlet=__attribute__((iboutlet)) -cc1 -triple i386-unknown-linux-gnu -fsyntax-only -disable-free -main-file-name test1.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir /data/build/userspace/llvm/llvm/Release/lib/clang/2.0 -ferror-limit 19 -fmessage-length 0 -fgnu-runtime -fdiagnostics-show-option -x c /tmp/test1.c -analyze -analyzer-display-progress -analyzer-eagerly-assume -analyzer-opt-analyze-nested-blocks -analyzer-check-objc-mem -analyzer-check-security-syntactic -analyzer-check-dead-stores -analyzer-check-objc-unused-ivars -analyzer-check-objc-methodsigs -analyzer-store=region -analyzer-constraints=range -analyzer-output=html -o /tmp/scan-build-2010-05-23-2 1. parser at end of file 2. /tmp/test1.c:13:2: Error evaluating statement 3. /tmp/test1.c:13:2: Error evaluating statement 4. /tmp/test1.c:13:6: Error evaluating statement -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 17:34:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 17:34:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 7204] New: ccc-analyzer does not support gcc -imacros option Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7204 Summary: ccc-analyzer does not support gcc -imacros option Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: castet.matthieu at free.fr CC: llvmbugs at cs.uiuc.edu clang seems to support it, ccc-analyzer should support it lile -include (adding it in %CompileOptionMap ?) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 18:41:24 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 18:41:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 7205] New: Obj-C++ methods with arguments that reference C++ objects fail under Clang Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7205 Summary: Obj-C++ methods with arguments that reference C++ objects fail under Clang Product: clang Version: 2.7 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bradmarston at mac.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Of the following two Obj-C methods, only the first compiles under Clang (llvm-2.7) but both compile properly under gcc4.2-llvm: [objcObject methodByPointer:cppObject]; [objcObject methodByReference:*cppObject]; where the Obj-C++ methods are declared as: - (void)methodByPointer:(cppClass *)object; - (void)methodByReference:(cppClass &)object; The error returned by Clang for the second method is: /Users/jbm/Desktop/Obj-C++/Test/Test.mm:17:0 /Users/jbm/Desktop/Obj-C++/Test/Test.mm:17:35: error: incompatible type sending 'class cppClass', expected 'class cppClass &' I have attached an Xcode project that illustrates this with minimal lines of code. When compiled under gcc4.2 both methods correctly access the cppObject to return the number 42. Question: Is this an ambiguity in the specification of Obj-C++? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 22 18:48:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 May 2010 18:48:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7205] Obj-C++ methods with arguments that reference C++ objects fail under Clang In-Reply-To: References: Message-ID: <20100522234842.342843128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7205 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-22 18:48:41 CDT --- This is fixed in the latest version of Clang in Subversion. The Clang in LLVM 2.7 is really old (in Clang time) and should not be trusted with any C++ or Objective-C++ code. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 05:54:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 05:54:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7166] clang boost boost.geometry In-Reply-To: References: Message-ID: <20100523105455.8DF033128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7166 Barend changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Barend 2010-05-23 05:54:54 CDT --- (In reply to comment #1) > Can you attach the preprocessed file (result of clang -E)? I did clang -E, giving me a large textfile. But after that I did the make update in llvm, and compiled again. The error is gone now. So it is solved in the meantime, thanks. I change the status to fixed (if this works). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 05:58:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 05:58:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 7206] New: Assertion `(Other.isNull() || Other.isCanonical()) && "Type is not canonical!"' failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7206 Summary: Assertion `(Other.isNull() || Other.isCanonical()) && "Type is not canonical!"' failed Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: grzegorz.dabrowski at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com OS: Haiku and Ubuntu $ clang -v clang version 2.0 (trunk 104460) Target: i386-pc-linux-gnu Thread model: posix $ cat bug.cpp #include int main() { struct edge_info { float left; float right; }; int size = strlen("test"); struct edge_info edgeInfo[size]; return 0; } $ clang++ bug.cpp clang: /home/stuff/download/SCM/llvm/tools/clang/lib/Sema/../../include/clang/AST/CanonicalType.h:708: static clang::CanQual clang::CanQual< >::CreateUnsafe(clang::QualType) [with T = clang::Type]: Assertion `(Other.isNull() || Other.isCanonical()) && "Type is not canonical!"' failed. 0 clang 0x09000508 Stack dump: 0. Program arguments: /home/stuff/download/SCM/llvm/Release/bin/clang -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name bug.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir /home/stuff/download/SCM/llvm/Release/lib/clang/2.0 -ferror-limit 19 -fmessage-length 157 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-aH2VdE.s -x c++ bug.cpp 1. parser at end of file 2. bug.cpp:5:1: parsing function body 'main' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 06:05:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 06:05:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7207] New: [META] Compiling Haiku with clang Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7207 Summary: [META] Compiling Haiku with clang Product: clang Version: trunk Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: grzegorz.dabrowski at gmail.com CC: llvmbugs at cs.uiuc.edu Meta bug for Haiku operating system http://www.haiku-os.org/ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 07:13:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 07:13:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 4504] invalid output constraint '=o' in asm In-Reply-To: References: Message-ID: <20100523121344.9ABBB3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4504 Pawel Worach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |pawel.worach at gmail.com Resolution|FIXED | --- Comment #2 from Pawel Worach 2010-05-23 07:13:44 CDT --- I'm still seeing this with: clang version 2.0 (trunk 104456) libmpcodecs/vf_fspp.c:1597:41: error: invalid output constraint '=o' in asm : "+S"(data), "+D"(output), "+c"(cnt), "=o"(temps) ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 07:44:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 07:44:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7208] New: ((Other.isNull() || Other.isCanonical()) && "Type is not canonical!") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7208 Summary: ((Other.isNull() || Other.isCanonical()) && "Type is not canonical!") Product: clang Version: trunk Platform: Sun OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: kwm at FreeBSD.org CC: llvmbugs at cs.uiuc.edu I think this is related to the fix in http://llvm.org/bugs/show_bug.cgi?id=5678 > cat flac-E.cpp typedef struct { } FLAC__StreamMetadata; namespace FLAC { namespace Metadata { class Prototype { bool set_metadata(FLAC::Metadata::Prototype **metadata, unsigned num_blocks) { ::FLAC__StreamMetadata *m[num_blocks]; } }; } } > clang++ flac-E.cpp Assertion failed: ((Other.isNull() || Other.isCanonical()) && "Type is not canonical!"), function CreateUnsafe, file /usr/home/kwm/llvm/llvm/tools/clang/lib/Frontend/../../include/clang/AST/CanonicalType.h, line 708. Stack dump: 0. Program arguments: /usr/local/clang/bin/clang -cc1 -triple i386-unknown-freebsd9.0 -S -disable-free -main-file-name flac-E.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir /usr/local/clang/lib/clang/2.0 -ferror-limit 19 -fmessage-length 80 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-ofol1y.s -x c++ flac-E.cpp 1. flac-E.cpp:10:2: current parser token ';' 2. flac-E.cpp:3:1: parsing namespace 'FLAC' 3. flac-E.cpp:4:2: parsing namespace 'FLAC::Metadata' 4. flac-E.cpp:5:3: parsing struct/union/class body 'FLAC::Metadata::Prototype' 5. flac-E.cpp:7:3: parsing function body 'FLAC::Metadata::Prototype::set_metadata' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 10:59:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 10:59:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 7209] New: Seek out invalid candidates that GCC would find when overload resolution fails Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7209 Summary: Seek out invalid candidates that GCC would find when overload resolution fails Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Keywords: quality-of-implementation Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com GCC compiles the following example because it performs non-ADL name lookup for operator<< at instantiation time (which is wrong): #include namespace N { struct X { }; } using namespace N; template void log(const T& t) { std::clog << t; } std::ostream &operator<<(std::ostream&, const X& x); template void log(const X&); This has led to some confusion, so we would like to improve the diagnostic. For example, if overload resolution finds nothing or is ambiguous, we could consider adding candidates that shouldn't be visible (but other compilers sometimes see anyway), and, if those candidates are chosen, emit a specific diagnostic about the reason they aren't actually visible. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 11:10:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 11:10:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7206] Assertion with VLAs in C++ In-Reply-To: References: Message-ID: <20100523161042.423EF3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7206 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-23 11:10:41 CDT --- Fixed in r104461. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 11:36:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 11:36:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7208] ((Other.isNull() || Other.isCanonical()) && "Type is not canonical!") In-Reply-To: References: Message-ID: <20100523163601.D4A863128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7208 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |DUPLICATE --- Comment #1 from Benjamin Kramer 2010-05-23 11:36:01 CDT --- *** This bug has been marked as a duplicate of bug 7206 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 15:05:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 15:05:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 5863] Assertion failure with C++ try/catch In-Reply-To: References: Message-ID: <20100523200536.745443128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5863 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Benjamin Kramer 2010-05-23 15:05:35 CDT --- Fixed in r104472. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 15:31:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 15:31:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 7210] New: !!(intval==constant) generates assert in APInt assigment Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7210 Summary: !!(intval==constant) generates assert in APInt assigment Product: tools Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: analyze AssignedTo: unassignedbugs at nondot.org ReportedBy: paul at mediamolecule.com CC: llvmbugs at cs.uiuc.edu I've just got clang's static analyzer up and running on our code base. One of the problems I've come across that it chokes on asserts we have of the form 'ASSERT( x < 20 )'. After some digging, I have this minimal repro: int f(int c) { return !!(c==0); } Which causes clang --analyze to assert in APInt::operator==: $ clang --analyze -v main.cpp clang version 2.0 (trunk 104221) Target: i386-pc-cygwin Thread model: posix "/usr/local/bin/clang" -cc1 -triple i386-pc-cygwin -analyze -disable-free -main-file-name main.cpp -analyzer-store=regi on -analyzer-opt-analyze-nested-blocks -analyzer-check-dead-stores -analyzer-check-objc-mem -analyzer-eagerly-assume -an alyzer-check-objc-methodsigs -analyzer-check-objc-unused-ivars -analyzer-output plist -w -mrelocation-model static -mdis able-fp-elim -mconstructor-aliases -target-cpu pentium4 -v -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmes sage-length 120 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o main.plist -x c++ main.cpp clang -cc1 version 2.0 based upon llvm 2.8svn hosted on i386-pc-cygwin #include "..." search starts here: #include <...> search starts here: /cygdrive/c/dev/libcxx_svn/include /usr/local/lib/clang/2.0/include /usr/include End of search list. assertion "BitWidth == RHS.BitWidth && "Comparison requires equal bit widths"" failed: file "/cygdrive/c/dev/llvm_svn/in clude/llvm/ADT/APInt.h", line 819, function: bool llvm::APInt::operator==(const llvm::APInt&) const Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple i386-pc-cygwin -analyze -disable-free -main-file-name main. cpp -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-check-dead-stores -analyzer-check-objc-mem -ana lyzer-eagerly-assume -analyzer-check-objc-methodsigs -analyzer-check-objc-unused-ivars -analyzer-output plist -w -mreloc ation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -v -resource-dir /usr/local/lib/clang/2. 0 -ferror-limit 19 -fmessage-length 120 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o main .plist -x c++ main.cpp 1. parser at end of file 2. main.cpp:3:2: Error evaluating statement 3. main.cpp:3:2: Error evaluating statement 4. main.cpp:3:9: Error evaluating statement 5. main.cpp:3:9: Error evaluating statement clang: error: analyzer command failed due to signal 6 (use -v to see invocation) I'm compiling clang from source on cygwin/Windows 7, but I suspect this is platform-independent. One thing I did notice was that compiling the same code as main.c failed to generate an assert. Cheers, Paul -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 15:49:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 15:49:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 7211] New: Crash on ill-formed reference to set of overloaded function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7211 Summary: Crash on ill-formed reference to set of overloaded function Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub-johannes at web.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com void f(); void f(int); int main() { &f; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 17:10:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 17:10:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 7095] Error: Ambiguous user-defined conversion sequence In-Reply-To: References: Message-ID: <20100523221047.DCF873128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7095 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-05-23 17:10:47 CDT --- Fixed in r104476 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 23 17:11:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 May 2010 17:11:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7051] assert 'C++ binary operator overloading is missing candidates!' In-Reply-To: References: Message-ID: <20100523221112.8B6783128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7051 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-23 17:11:12 CDT --- Fixed in r104475 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 03:12:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 03:12:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 7169] llc infinite loop in LegalizeDAG In-Reply-To: References: Message-ID: <20100524081208.DEAD93128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7169 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Duncan Sands 2010-05-24 03:12:08 CDT --- Not an infinite loop, just vast amounts of SDag being generated for a byval parameter with a large type. As such, this is a duplicate of PR7170. *** This bug has been marked as a duplicate of bug 7170 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 07:38:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 07:38:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 7212] New: Error while compiling llvm-gcc for ARM Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7212 Summary: Error while compiling llvm-gcc for ARM Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: rengolin at gmail.com CC: llvmbugs at cs.uiuc.edu Compiled LLVM trunk in Release mode. Downloaded LLVM-GCC from svn trunk. Configured LLVM-GCC: /work/temp/obj-arm$ ../llvm-gcc/configure --prefix=/work/temp/obj-arm/install --program-prefix=llvm- --enable-llvm=/work/temp/llvm --enable-languages=c,c++ --target=arm-none-eabi Ran "make", got error: /work/temp/obj-arm/./gcc/xgcc -B/work/temp/obj-arm/./gcc/ -B/work/temp/obj-arm/install/arm-none-eabi/bin/ -B/work/temp/obj-arm/install/arm-none-eabi/lib/ -isystem /work/temp/obj-arm/install/arm-none-eabi/include -isystem /work/temp/obj-arm/install/arm-none-eabi/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../llvm-gcc/gcc -I../../llvm-gcc/gcc/. -I../../llvm-gcc/gcc/../include -I../../llvm-gcc/gcc/../libcpp/include -I../../llvm-gcc/gcc/../libdecnumber -I../libdecnumber -I/work/temp/llvm/include -mthumb -fexceptions -c ../../llvm-gcc/gcc/unwind-c.c -o libgcc/thumb/unwind-c.o cc1: error in backend: Cannot yet select: 0x1cf3d3f0: i32 = sign_extend_inreg 0x1cf56430, 0x1cf39f40 [ID=16] dbg:unwind-pe.h:266 0x1cf56430: i32 = AssertZext 0x1cf3a550, 0x1cf39f40 [ORD=254] [ID=14] dbg:unwind-pe.h:266 0x1cf3a550: i32,ch = CopyFromReg 0x1cee14f0, 0x1cf55920 [ORD=254] [ID=12] dbg:unwind-pe.h:266 0x1cee14f0: ch = EntryToken [ORD=252] [ID=0] 0x1cf55920: i32 = Register %reg1025 [ORD=254] [ID=4] 0x1cf39f40: ch = ValueType:i8 [ORD=254] [ID=5] 0x1cf39f40: ch = ValueType:i8 [ORD=254] [ID=5] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 08:26:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 08:26:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7213] New: Building clang with --enable-doxygen fails if objdir != srcdir Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7213 Summary: Building clang with --enable-doxygen fails if objdir != srcdir Product: Build scripts Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: salimma at fedoraproject.org CC: llvmbugs at cs.uiuc.edu The recommended way of building LLVM used to be to run configure from an empty target directory. This works fine with doxygen off, but when doxygen is turned on, *and* clang is build within tools/clang, it seems that when the build directory is populated with clang sources, the doxygen sources are not copied, and thus the build fails. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 11:02:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 11:02:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 6472] clang C++ segfault In-Reply-To: References: Message-ID: <20100524160256.3690E3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6472 Andrius Morkunas changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #2 from Andrius Morkunas 2010-05-24 11:02:55 CDT --- I can't reproduce this anymore either. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 11:48:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 11:48:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7214] New: Assertion `Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7214 Summary: Assertion `Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!" Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: grzegorz.dabrowski at gmail.com CC: llvmbugs at cs.uiuc.edu clang version 2.0 (trunk 104507) OS: Ubuntu, Haiku $ cat reg.c long double atan2l (long double y, long double x) { long double res; asm ("fpatan" : "=t" (res) : "u" (y), "0" (x) : "st(1)"); return res; } clang: X86FloatingPoint.cpp:178: unsigned int getFPReg(const llvm::MachineOperand&): Assertion `Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"' failed. 0 clang 0x09002658 Stack dump: 0. Program arguments: /home/stuff/download/SCM/llvm/Release/bin/clang -cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name reg.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir /home/stuff/download/SCM/llvm/Release/lib/clang/2.0 -ferror-limit 19 -fmessage-length 157 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-GDadI3.s -x c reg.c 1. parser at end of file 2. Code generation 3. Running pass 'X86 FP Stackifier' on function '@atan2l' -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 13:32:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 13:32:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7215] New: Assertion during ctor/dtor emission Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7215 Summary: Assertion during ctor/dtor emission Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Blocks: 5881 Created an attachment (id=4927) --> (http://llvm.org/bugs/attachment.cgi?id=4927) Testcase Consider the attached testcase. I'm having: $ /home/asl/proj/llvm/build_debug/Debug/bin/clang++ qlayout_widget.ii ome/asl/proj/llvm/src/tools/clang/lib/CodeGen/CodeGenFunction.cpp:172: void clang::CodeGen::CodeGenFunction::StartFunction(clang::CodeGen::GlobalDecl, clang::QualType, llvm::Function*, const clang::CodeGen::FunctionArgList&, clang::SourceLocation): Assertion `CurFn->isDeclaration() && "Function already has body?"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 13:44:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 13:44:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7215] Assertion during ctor/dtor emission In-Reply-To: References: Message-ID: <20100524184400.A658D3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7215 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |DUPLICATE --- Comment #1 from Benjamin Kramer 2010-05-24 13:44:00 CDT --- *** This bug has been marked as a duplicate of bug 7142 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 17:03:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 17:03:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 7216] New: clang++ silently accepts flags it doesn't understand Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7216 Summary: clang++ silently accepts flags it doesn't understand Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com 'clang++ -mnot-a-flag -fnot-a-flag t.cc' runs, and silently ignores the -m and -f flags it does not understand. Adding -Wnot-a-flag produces the useful: warning: unknown warning option '-Wnot-a-fla' [-Wunknown-warning-option] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 18:28:38 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 18:28:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 7217] New: Crash for accessing too-small malloc'd buffer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7217 Summary: Crash for accessing too-small malloc'd buffer Product: clang Version: trunk Platform: Macintosh OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jediknil at belkadan.com CC: llvmbugs at cs.uiuc.edu When accessing a malloc buffer whose size is less than one element wide, Clang crashes, very appropriately in asserting that the region size should be at least one element wide. Statically allocated buffers don't crash but don't warn properly either. Related to PR6123 (check malloc sizes are multiple of access type), since that could keep this error from occurring in the first place. --- #include void test () { int *buf = malloc(2); buf[1] = 'c'; // buf[0] does not crash } --- Assertion failed: (RegionSize % EleSize == 0), function getSizeInElements, file RegionStore.cpp, line 762. 0 clang 0x0000000101005126 PrintStackTrace(void*) + 38 1 clang 0x0000000101005606 SignalHandler(int) + 312 2 libSystem.B.dylib 0x00007fff8451780a _sigtramp + 26 3 libSystem.B.dylib 0x00007fff844bc50a tiny_malloc_from_free_list + 1196 4 libSystem.B.dylib 0x00007fff84592ef0 __pthread_markcancel + 0 5 clang 0x00000001004cee70 (anonymous namespace)::RegionStoreManager::getSizeInElements(clang::GRState const*, clang::MemRegion const*, clang::QualType) + 638 6 clang 0x00000001004165d3 (anonymous namespace)::ArrayBoundChecker::VisitLocation(clang::CheckerContext&, clang::Stmt const*, clang::SVal) + 245 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 24 19:06:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 May 2010 19:06:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7218] New: Assigning to buf[0] makes buf[1] valid Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7218 Summary: Assigning to buf[0] makes buf[1] valid Product: clang Version: trunk Platform: Macintosh OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jediknil at belkadan.com CC: llvmbugs at cs.uiuc.edu When the first element of a buffer is assigned to, the others are all considered defined. This is because when an element doesn't have a value, its super-region is checked (RegionStore.cpp:1170), and looking up the value of a non-element region is the same as looking up the first element (RegionStore.cpp:1644). Independently both of these behaviors are correct -- the latter is used all over the place, while the former can be seen in test/Analysis/no-outofbounds.c. How to fix this combination? --- char working (char a) { char buf[2]; buf[1] = a; return buf[0]; // correctly warns } char broken (char a) { char buf[2]; buf[0] = a; return buf[1]; // should warn but does not } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 25 00:37:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 00:37:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 7220] New: Centos 5.5 causes syntax errors Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7220 Summary: Centos 5.5 causes syntax errors Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mika.heiskanen at fmi.fi CC: llvmbugs at cs.uiuc.edu Using #include on Centos 5.5 (and hence most likely also on RedHat 5.5) generates the following errors: In file included from /usr/include/c++/4.1.2/string:45: In file included from /usr/include/c++/4.1.2/bits/char_traits.h:45: In file included from /usr/include/c++/4.1.2/bits/stl_algobase.h:69: In file included from /usr/include/c++/4.1.2/iosfwd:45: In file included from /usr/include/c++/4.1.2/i386-redhat-linux/bits/c++io.h:38: In file included from /usr/include/c++/4.1.2/i386-redhat-linux/bits/gthr.h:132: /usr/include/c++/4.1.2/i386-redhat-linux/bits/gthr-default.h:100:1: error: weakref declaration of '__gthrw_pthread_once' must be static __gthrw(pthread_once) ^ /usr/include/c++/4.1.2/i386-redhat-linux/bits/gthr-default.h:81:23: note: instantiated from: #define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name) ^ /usr/include/c++/4.1.2/i386-redhat-linux/bits/gthr-default.h:72:46: note: instantiated from: extern __typeof(type) name __attribute__ ((__weakref__(#name2))); \ ^ Used options: -fsyntax-only Version: > clang++ --version clang version 2.0 (trunk 104313) Target: i386-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 Tue May 25 01:52:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 01:52:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 7221] New: [ARM JIT] emitVFPLoadStoreMultipleInstructio() does not handle s* registers Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7221 Summary: [ARM JIT] emitVFPLoadStoreMultipleInstructio() does not handle s* registers 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: sliao at google.com CC: llvmbugs at cs.uiuc.edu In JITting clouds.c on ARM, I found that the VFP instruction "vstmia" is not generated correctly. The problem code is: $ cat clouds.c float xshift[5]; float rotation[5]; void init() { int i; for (i=0;i<5;i++) { xshift[i] = 0.f; rotation[i] = 360.f * i / 5.f; } } The generated code is: JIT: Disassembled code: init 0xf7c68000: mov r0, #0 0xf7c68004: movw r1, #4064 0xf7c68008: movt r1, #63432 0xf7c6800c: movw r2, #4032 0xf7c68010: movt r2, #63432 0xf7c68014: vldr.32 s0, [pc, #44] 0xf7c68018: vmov.f32 s1, #20 0xf7c6801c: mov r3, #0 0xf7c68020: vmov s2, r3 0xf7c68024: add r3, r3, #1 0xf7c68028: str r0, [r2], #4 0xf7c6802c: cmp r3, #5 0xf7c68030: vcvt.f32.s32 s2, s2 0xf7c68034: vmul.f32 s2, s2, s0 0xf7c68038: vdiv.f32 s2, s2, s1 0xf7c6803c: vstmia r1!, {s2, s3} 0xf7c68040: bne #-32 0xf7c68044: bx lr 0xf7c68048: movmis r0, #0 MagicSmoke/clouds.c caused error due to the instruction above: vstmia r1!, {s2, s3}. The right instruction should be vstmia r1!, {r2}. According to ARM Instruction Manual, if an instruction operates on 64-bit registers as load/store extension register, Bit 8 will be 1 and NumReg = (last 8 bit in the instruction) / 2. If an instruction operates on 32-bit registers as load/store extension register, Bit 8 will be 0 and NumReg should be (last 8 bit in the instruction). So, the current implementation only considers the former case: Binary |= NumRegs * 2; The correct code should first determine if it's the former case or the latter and compute the Binary accordingly. After applying the following fix, then all the test cases pass. --- lib/Target/ARM/ARMCodeEmitter.cpp +++ lib/Target/ARM/ARMCodeEmitter.cpp break; ++NumRegs; } - Binary |= NumRegs * 2; + // bit 8 will be set if is consecutive 64-bit registers (e.g., d0) + if(Binary & 0x100) + Binary |= NumRegs * 2; + else + Binary |= NumRegs; emitWordLE(Binary); } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 05:20:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 05:20:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 6265] ARMCodeEmitter can't pass hello_world In-Reply-To: References: Message-ID: <20100525102055.49B8B3128042@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6265 Shih-wei Liao changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sliao at google.com Resolution| |FIXED --- Comment #2 from Shih-wei Liao 2010-05-25 05:20:54 CDT --- Fixed by r104587. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 05:41:22 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 05:41:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 7222] New: [ARM JIT] Bitfield's "clear" and "insert" are not implemented Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7222 Summary: [ARM JIT] Bitfield's "clear" and "insert" are not implemented 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: sliao at google.com CC: llvmbugs at cs.uiuc.edu Using common premul results in an error message in ARM JIT. Below is our premul function: int premul(int rgb, int a) { int r = (rgb >> 16) * a + 1; r = (r + (r >> 8)) >> 8; int g = ((rgb >> 8) & 0xff) * a + 1; g = (g + (g >> 8)) >> 8; int b = (rgb & 0xff) * a + 1; b = (b + (b >> 8)) >> 8; return r << 16 | g << 8 | b; } Then, the error message showed up: "ARMv6t2 JIT is not yet supported." Grep the string "ARMv6t2 JIT is not yet supported." in ARMCodeEmitter.cpp leads to this line in ARMCodeEmitter::emitDataProcessingInstruction(): if (TID.Opcode == ARM::BFC) { report_fatal_error("ARMv6t2 JIT is not yet supported."); } This opcode is not implemented. Straight from ARM Architecture Reference Manual, A8.6.17 BFC and A8.6.18 BFI, the code should be: } else if ((TID.Opcode == ARM::BFC) || (TID.Opcode == ARM::BFI)) { uint32_t v = ~MI.getOperand(2).getImm(); int32_t lsb = CountTrailingZeros_32(v); int32_t msb = (32 - CountLeadingZeros_32(v)) - 1; // Insts[20-16] = msb, Insts[11-7] = lsb Binary |= (msb & 0x1F) << 16; Binary |= (lsb & 0x1F) << 7; emitWordLE(Binary); return; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 25 05:44:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 05:44:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 7223] New: -fcatch-undefined-behaviour doesn't catch missing return values Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7223 Summary: -fcatch-undefined-behaviour doesn't catch missing return values Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com -fcatch-undefined-behaviour doesn't catch functions which fail to return a value when they should. It would be nice if did. Example: int foo() {} Calling foo() when compiled with -fcatch-undefined-behaviour should cause an abort(); I believe hooking an abort() (or other function) onto the end of every method when -fcatch-undefined-behaviour is used would catch such cases. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 06:05:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 06:05:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7224] New: clang find const overloads ambiguous when used with a derived class. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7224 Summary: clang find const overloads ambiguous when used with a derived class. Product: clang Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ogoffart at kde.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com // Code extracted from phonon class A {}; class B : public A {}; static inline int foo(A *const d) { return 0; } static inline int foo(const A *const d) { return 1; } int main() { B *const d = 0; return foo(d); } /* ./main.cpp:15:12: error: call to 'foo' is ambiguous return foo(d); ^~~ ./main.cpp:6:19: note: candidate function static inline int foo(A *const d) ^ ./main.cpp:9:19: note: candidate function static inline int foo(const A *const d) ^ 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 Tue May 25 06:39:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 06:39:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 7225] New: [ARM JIT] Color converter triggers ARM JIT to produce wrong shift operation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7225 Summary: [ARM JIT] Color converter triggers ARM JIT to produce wrong shift operation Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: sliao at google.com CC: llvmbugs at cs.uiuc.edu In our ARGB to ABGR (sorted) color converter, void ARGB2ABGR(int *dst, int newpix, int x, int y) { newpix = (newpix & 0xff00ff00) | ((newpix & 0xff) << 16) | ((newpix >> 16) & 0xff); ... } ARM JIT will produce wrong code. newpix values become incorrect. After narrowing down this further, I got similar but smaller code by making some code dead. void ARGB2ABGR_small(int *dst, int newpix, int x, int y) { unsigned int color = (unsigned int)newpix; unsigned int ag = color & 0xff00ff00; unsigned int b = (color & 0xff) << 16; // DEAD CODE. IGNORE!! unsigned int r = (color & 0x00ff0000) >> 16; dst[y*256+x] = ag | r; } The corresponding JITted code is wrong: JIT: Disassembled code: init 0xf7d0b000: add r2, r2, r3, lsl #8 0xf7d0b004: movw r12, #65280 0xf7d0b008: movt r12, #65280 0xf7d0b00c: and r3, r1, r12 0xf7d0b010: ubfx r1, r0, #0, #2 <--- Should be "ubfx r1, r1, 16, 8" 0xf7d0b014: orr r1, r1, r3 0xf7d0b018: str r1, [r0, r2, lsl #2] 0xf7d0b01c: bx lr This is similar to Bug 7222 where ARM::BFC and ARM::BFI are not implemented. Similarly, straight from ARM's Architecture Reference Manual: A8.6.154 SBFX and A.8.6.236 UBFX, ARMCodeEmitter.cpp should follow the BFC section with: } else if ((TID.Opcode == ARM::UBFX) || (TID.Opcode == ARM::SBFX)) { // Encode Rn in Insts[0-3] Binary |= getMachineOpValue(MI, OpIdx++) << 0; uint32_t lsb = MI.getOperand(OpIdx++).getImm(); uint32_t widthm1 = MI.getOperand(OpIdx++).getImm() - 1; // Insts[20-16] = widthm1, Insts[11-7] = lsb Binary |= (widthm1 & 0x1F) << 16; Binary |= (lsb & 0x1F) << 7; emitWordLE(Binary); return; } This will fix the bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 25 08:04:07 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 08:04:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 7226] New: [ARM JIT] ARM JIT couldn't emit constant pool entry for "ConstantVector" and "ConstantArray" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7226 Summary: [ARM JIT] ARM JIT couldn't emit constant pool entry for "ConstantVector" and "ConstantArray" Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: sliao at google.com CC: llvmbugs at cs.uiuc.edu In file lib/Target/ARM/ARMCodeEmitter.cpp, we found this line at the end of the function "ARMCodeEmitter::emitConstPoolInstruction(const MachineInstr &MI)": llvm_unreachable("Unable to handle this constantpool entry!"); ARM JITting will reach this "unreachable" line when JITting a simple program below: int main(int argc, char** argv) { if(argc == 10000) { int i; float ident[16]; float masterscale = 0.0041f;// / (gXOffset * 4.f + 1.f); int now = argc; timedelta = ((float)(now - lastuptime)) / 44.f; lastuptime = now; if (timedelta > 3) { // Limit the step adjustment factor to 3, so we don't get a sudden jump // after coming back from sleep. timedelta = 3; } i = gPreset; if (i != currentpreset) { currentpreset = i; int rgb = gBackCol; makeTextures(); } } if(argc > 1) gTextureSwap = 1; else gTextureSwap = 0; if (gTextureSwap != 0) scale[0] = .25f; else scale[0] = 4.f; printf("%d %f\n", gTextureSwap, scale[0]); return 55; } The program is adapted from an internal clouds.c, so we can ignore the "if (argc ==10000)" part. Note that the 0.25f and 4.f in the code above will become ConstantArray of 2 elements. The first element will be 0.25f, while the second, 4.f. ConstantArray and ConstantVector should be implemented. Our fix is to replace the last case in "ARMCodeEmitter::emitConstPoolInstruction(const MachineInstr &MI)" with a function call to "emitConstantToMemory()". This new function "emitConstantToMemory" is defined as follows. void ARMCodeEmitter::emitConstantToMemory(unsigned CPI, const Constant* C) { DEBUG({ errs() << " ** Constant pool #" << CPI << " @ " << (void*)MCE.getCurrentPCValue() << " "; if (const Function *F = dyn_cast(C)) errs() << F->getName(); else errs() << *C; errs() << '\n'; }); if (const GlobalValue *GV = dyn_cast(C)) { emitGlobalAddress(GV, ARM::reloc_arm_absolute, isa(GV), false); emitWordLE(0); } else if (const ConstantInt *CI = dyn_cast(C)) { uint32_t Val = *(uint32_t*)CI->getValue().getRawData(); emitWordLE(Val); } else if (const ConstantFP *CFP = dyn_cast(C)) { if (CFP->getType()->isFloatTy()) emitWordLE(CFP->getValueAPF().bitcastToAPInt().getZExtValue()); else if (CFP->getType()->isDoubleTy()) emitDWordLE(CFP->getValueAPF().bitcastToAPInt().getZExtValue()); else { llvm_unreachable("Unable to handle this constantpool entry!"); } } else if (const ConstantVector* CV = dyn_cast(C)) { for (unsigned i=0;igetNumOperands();i++) emitConstantToMemory(CPI, CV->getOperand(i)); } else if (const ConstantArray* CA = dyn_cast(C)) { for (unsigned i=0;igetNumOperands();i++) emitConstantToMemory(CPI, CA->getOperand(i)); } else { llvm_unreachable("Unable to handle this constantpool entry!"); } return; } This will fix the unreachable problem above, which means that we will no longer reach the line llvm_unreachable("Unable to handle this constantpool entry!"). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 08:20:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 08:20:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 7227] New: [ARM JIT] Missing the implementation of ARM::LEApcrel Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7227 Summary: [ARM JIT] Missing the implementation of ARM::LEApcrel Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: sliao at google.com CC: llvmbugs at cs.uiuc.edu In the function "void ARMCodeEmitter::emitLEApcrelJTInstruction(const MachineInstr &MI)", only "case ARM::LEApcrelJT:" is implemented. But "case ARM::LEApcrel:" didn't get implemented. As a result, the PC relative addressing to the constant pool in the following program doesn't work. int main(int argc, char** argv) { if(argc == 10000) { int i; float ident[16]; float masterscale = 0.0041f;// / (gXOffset * 4.f + 1.f); int now = argc; timedelta = ((float)(now - lastuptime)) / 44.f; lastuptime = now; if (timedelta > 3) { // Limit the step adjustment factor to 3, so we don't get a sudden jump // after coming back from sleep. timedelta = 3; } i = gPreset; if (i != currentpreset) { currentpreset = i; int rgb = gBackCol; makeTextures(); } } if(argc > 1) gTextureSwap = 1; else gTextureSwap = 0; if (gTextureSwap != 0) scale[0] = .25f; else scale[0] = 4.f; printf("%d %f\n", gTextureSwap, scale[0]); return 55; } Note that the constants 0.25f and 4.f are in the constant pool. If we implement the ARM::LEApcrel below, then the pc relative address will be correct. That is, it will generate correct code here: 0x400099c4: add r0, pc, #56 ; pc = 0x400099c8, pc + 56 = 0x40009a00 0x400099c8: add r2, r0, #4 0x400099cc: cmp r4, #2 0x400099d0: movlt r2, r0 0x400099d4: vldr.32 s0, [r2] 0x400099d8: movw r0, #7977 0x400099dc: movt r0, #16386 0x400099e0: movw r2, #8000 0x400099e4: movt r2, #16386 0x400099e8: vstr.32 s0, [r2] 0x400099ec: vcvt.f64.f32 d0, s0 0x400099f0: vmov r2, r3, d0 0x400099f4: bl #99620 0x400099f8: mov r0, #55 0x400099fc: pop {r4, pc} ; End of main() 0x40009a00: eormis r0, r0, #0 ; Constant entry #1: 44.f 0x40009a04: addmi r0, r0, r0 ; Constant entry #2[0]: 0.25f 0x40009a08: cdplo p0, #8, cr0, cr0, cr0, #0 ; Constant entry #2[1]: 4.f An implementation of ARM::LEApcrel is: void ARMCodeEmitter::emitLEApcrelInstruction(const MachineInstr &MI) { // It's basically add r, pc, (LCPI - $+8) const TargetInstrDesc &TID = MI.getDesc(); // Emit the 'add' instruction. unsigned Binary = 0x4 << 21; // add: Insts{24-31} = 0b0100 // For VFP load, the immediate offset is multiplied by 4. unsigned Reloc = ((TID.TSFlags & ARMII::FormMask) == ARMII::VFPLdStFrm) ? ARM::reloc_arm_vfp_cp_entry : ARM::reloc_arm_cp_entry; // Set the conditional execution predicate Binary |= II->getPredicate(&MI) << ARMII::CondShift; // Encode S bit if MI modifies CPSR. Binary |= getAddrModeSBit(MI, TID); // Encode Rd. Binary |= getMachineOpValue(MI, 0) << ARMII::RegRdShift; // Encode Rn which is PC. Binary |= ARMRegisterInfo::getRegisterNumbering(ARM::PC) << ARMII::RegRnShift; // Encode the displacement. Binary |= 1 << ARMII::I_BitShift; emitConstPoolAddress(MI.getOperand(1).getIndex(), Reloc); emitWordLE(Binary); } This will fix all the remaining known issues in ARM JIT based on our test suite. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 10:15:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 10:15:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7228] New: Unbalanced Bracket in -ast-dump Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7228 Summary: Unbalanced Bracket in -ast-dump Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chobbs at qnx.com CC: llvmbugs at cs.uiuc.edu See the following program (written to expose this possible error). When I use the command clang -cc1 -ast-dump tryit.c I get the output given below. It appears that the brackets around DeclStmt are not balanced, making parsing impossible. The output from the "clang -v" command is clang version 2.0 (trunk 104588) Target: i386-pc-linux-gnu Thread model: posix ========sample program int main() { int x; x = 6; return 0; } ========output typedef char *__builtin_va_list; int main() (CompoundStmt 0x97dac08 (DeclStmt 0x97f1980 0x97dab80 "int x" (BinaryOperator 0x97f19b8 'int' '=' (DeclRefExpr 0x97f1998 'int' Var='x' 0x97dab80) (IntegerLiteral 0x97e0df0 'int' 6)) (ReturnStmt 0x97f1a08 (IntegerLiteral 0x97f19e0 'int' 0))) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 25 10:32:24 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 10:32:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 7224] clang find const overloads ambiguous when used with a derived class. In-Reply-To: References: Message-ID: <20100525153224.C930E3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7224 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-25 10:32:24 CDT --- Fixed in r104607. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 12:48:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 12:48:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 6997] Bus Error compiling Boost.Uuid In-Reply-To: References: Message-ID: <20100525174854.9FF023128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6997 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #8 from Douglas Gregor 2010-05-25 12:48:54 CDT --- Nobody can reproduce this; closing unless we get more information. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 12:52:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 12:52:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 7191] [instruction selection] float compare -> int result + march=athlon64-sse3 == "Cannot yet slect ... X86ISD::FP_TO_INT32_IN_MEM" In-Reply-To: References: Message-ID: <20100525175250.870EB3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7191 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #9 from Dale Johannesen 2010-05-25 12:52:49 CDT --- Good idea. Fixed here. http://llvm.org/viewvc/llvm-project?view=rev&revision=104619 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 12:57:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 12:57:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7228] Unbalanced Bracket in -ast-dump In-Reply-To: References: Message-ID: <20100525175730.CA5673128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7228 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2010-05-25 12:57:30 CDT --- Oh, I didn't see your patch, sorry nick. Committed a fix in r104620. The -ast-dump output isn't considered to be stable though, it can change in the future. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 15:18:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 15:18:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 7230] New: extern "C" global function can't be made a friend of a class in a namespace Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7230 Summary: extern "C" global function can't be made a friend of a class in a namespace Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bruce.r.stephens at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4931) --> (http://llvm.org/bugs/attachment.cgi?id=4931) Non-working example (Or at least, not easily.) I get these errors: nt.cc:10:19: error: no function named 'F' with type 'void ()' was found in the specified scope friend void ::F(void); ^ nt.cc:15:11: error: 'foo' is a private member of 'N::C' N::bar->foo(); ^ nt.cc:9:10: note: declared private here void foo(void); ^ 2 errors generated. If the function F() is in the namespace (or if everything's global) there's no problem. gcc accepts the code. This is a stripped example from the real code which is accepted by VS, Sun Studio (or whatever it's called now) and HP-UX's compiler. (The code may well still be incorrect, but if it is I'm not sure why.) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 16:15:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 16:15:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 7231] New: LLVMContext's ownership rules are inconsistent with LLVM convention Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7231 Summary: LLVMContext's ownership rules are inconsistent with LLVM convention Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: gohman at apple.com CC: llvmbugs at cs.uiuc.edu Currently, LLVMContext does not own its Modules, meaning that it does not have a list of live Modules and it does not delete Modules in its destructor. This is inconsistent with Module, which owns its Functions, Function, which owns its BasicBlocks, and BasicBlock, which owns its Instructions. I just debugged some LLVM client code which deleted an LLVMContext without deleting the associated Modules, and the failure mode was non-obvious. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 16:26:32 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 16:26:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 7232] New: clang emits invalid IR on isunordered call with vector operands Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7232 Summary: clang emits invalid IR on isunordered call with vector operands Product: clang Version: trunk 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 On this C input: #include typedef float float4 __attribute__((vector_size(16))); void bar(float4 x, float4 y) { isunordered(x, y); } clang produces LLVM IR which triggers a Verifier abort, with the following message: zext source and destination must both be a vector or neither %tmp3 = zext <4 x i1> %cmp to i32 ; [#uses=0] Broken module found, compilation aborted! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue May 25 20:34:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 20:34:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7233] New: ICE on invalid pointer-to-member expression Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7233 Summary: ICE on invalid pointer-to-member expression Product: clang Version: trunk 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 Testcase (C++): struct X { virtual void foo(); }; void foo(struct X *x) { void (*p)(void) = &(x->*(&X::foo)); } clang fails with: Assertion failed: (E && !hasAggregateLLVMType(E->getType()) && "Invalid scalar expression to emit"), function EmitScalarExpr, file CGExprScalar.cpp, line 1885. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 25 22:22:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 May 2010 22:22:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7225] [ARM JIT] Color converter triggers ARM JIT to produce wrong shift operation In-Reply-To: References: Message-ID: <20100526032200.618DF3128075@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7225 Shih-wei Liao changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Shih-wei Liao 2010-05-25 22:22:00 CDT --- Fixed by r104667. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 00:12:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 00:12:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7201] Undefined references to libstdc++ vtables when compiling with -O2, no problems with -O0 In-Reply-To: References: Message-ID: <20100526051245.4ACF23128077@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7201 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-05-26 00:12:44 CDT --- Fixed in r104675. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 02:10:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 02:10:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 7202] Boost thread ambiguity when used in a template function, with operator new In-Reply-To: References: Message-ID: <20100526071019.2D0233128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7202 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-26 02:10:18 CDT --- Fixed in r104690. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 03:28:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 03:28:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 7234] New: linking fails when compiling with -O4 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7234 Summary: linking fails when compiling with -O4 Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: niebuhr at niebuhrt.de CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4934) --> (http://llvm.org/bugs/attachment.cgi?id=4934) The test Code when compiling the attached source with clang++ -O4 -o main main.cpp Out.cpp I get the errors below. Without -O4 it compiles just fine. I guess this is not a bug. I'm probably doing something wrong...what? wll192-250:cpptest gmthor85$ clang++ -O4 -o main main.cpp Out.cpp Operand is null %0 = tail call i32 @__cxa_atexit(void (i8*)* bitcast (void (%class.Out*)* @_ZNSt8ios_base4InitD1Ev to void (i8*)*), , i8* bitcast (i8** @__dso_handle to i8*)) ; [#uses=0] Broken module found, compilation aborted! Stack dump: 0. Running pass 'Function Pass Manager' on module 'ld-temp.o'. 1. Running pass 'Module Verifier' on function '@_GLOBAL__I_a' clang: error: linker command failed due to signal 6 (use -v to see invocation) With the Option -v wll192-250:cpptest gmthor85$ clang++ -v -o main main.cpp Out.cppclang version 2.0 (trunk 104375)Target: x86_64-apple-darwin10 Thread model: posix "/Users/gmthor85/llvm/llvm/Release/bin/clang" -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name main.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -v -resource-dir /Users/gmthor85/llvm/llvm/Release/lib/clang/2.0 -ferror-limit 19 -fmessage-length 221 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/3C/3Cjb8XqLGZ4CudBSDgvEJE+++TI/-Tmp-/cc-jOK31C.o -x c++ main.cpp clang -cc1 version 2.0 based upon llvm 2.8svn hosted on x86_64-apple-darwin10 #include "..." search starts here: #include <...> search starts here: /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 /usr/local/include /Users/gmthor85/llvm/llvm/Release/lib/clang/2.0/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/Users/gmthor85/llvm/llvm/Release/bin/clang" -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name Out.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -v -resource-dir /Users/gmthor85/llvm/llvm/Release/lib/clang/2.0 -ferror-limit 19 -fmessage-length 221 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/3C/3Cjb8XqLGZ4CudBSDgvEJE+++TI/-Tmp-/cc-ekCTgg.o -x c++ Out.cpp clang -cc1 version 2.0 based upon llvm 2.8svn hosted on x86_64-apple-darwin10 #include "..." search starts here: #include <...> search starts here: /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 /usr/local/include /Users/gmthor85/llvm/llvm/Release/lib/clang/2.0/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld" -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o main -lcrt1.10.6.o -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 -L/Users/gmthor85/llvm/llvm/Release/bin/../lib -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../.. /var/folders/3C/3Cjb8XqLGZ4CudBSDgvEJE+++TI/-Tmp-/cc-jOK31C.o /var/folders/3C/3Cjb8XqLGZ4CudBSDgvEJE+++TI/-Tmp-/cc-ekCTgg.o -lstdc++ -lSystem -lgcc -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 08:05:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 08:05:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 7235] New: array initializer must be an initializer list or string literal Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7235 Summary: array initializer must be an initializer list or string literal Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: syntheticpp at gmx.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4935) --> (http://llvm.org/bugs/attachment.cgi?id=4935) reduced test case When compiling Qt it still stops. clang could compile the reduced test case but clang++ not: clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated test-initializer.c:3:8: error: array initializer must be an initializer list or string literal struct inotify_event ^ test-initializer.c:16:26: note: implicit default copy constructor for 'inotify_event' first required here struct inotify_event event = *it; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 26 11:09:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 11:09:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 7059] Exception std::bad_cast thrown by dynamic_cast is not caught correctly. In-Reply-To: References: Message-ID: <20100526160915.4B3083128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7059 Pasi Parviainen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Pasi Parviainen 2010-05-26 11:09:14 CDT --- Seems like duplicate problem report was created afterwords, and this issue has been resolved since revision 103810. *** This bug has been marked as a duplicate of bug 7132 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 11:22:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 11:22:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 4999] llvm.eh.sjlj.longjmp is undocumented In-Reply-To: References: Message-ID: <20100526162220.4700C3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4999 Jim Grosbach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Jim Grosbach 2010-05-26 11:22:19 CDT --- Fixed: r104703 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 15:24:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 15:24:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 7029] Assertion in Sema In-Reply-To: References: Message-ID: <20100526202457.2D8A23128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7029 Fariborz Jahanian changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |fjahanian at apple.com Resolution| |FIXED --- Comment #5 from Fariborz Jahanian 2010-05-26 15:24:56 CDT --- Fixed in TOT: http://llvm.org/viewvc/llvm-project?view=rev&revision=104733 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 15:32:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 15:32:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 7236] New: instcombine broken with arm_aapcscc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7236 Summary: instcombine broken with arm_aapcscc Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu $ cat test.ll define arm_aapcscc double @foo() { entry: ret double 0.0 } define arm_aapcscc i1 @bar() { entry: %t7 = call double @foo() %t8 = fcmp ogt double %t7, 1.000000e-03 ret i1 %t8 } $ opt -instcombine test.ll -o - | llvm-dis ; ModuleID = '' define arm_aapcscc double @foo() { entry: ret double 0.000000e+00 } define arm_aapcscc i1 @bar() { entry: store i1 true, i1* undef ret i1 false } Why the store to undef?!? Removing arm_aapcscc fixes 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 May 26 15:37:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 15:37:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 7237] New: Clang crash on invalid Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7237 Summary: Clang crash on invalid Product: clang Version: trunk Platform: Other OS/Version: FreeBSD Status: NEW Keywords: crash-on-invalid Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hinokind at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4937) --> (http://llvm.org/bugs/attachment.cgi?id=4937) testcase $ clang segv9.cc <...> Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name segv9.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 157 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-qkesfJ.s -x c++ segv9.cc 1. segv9.cc:14:153: current parser token ',' 2. segv9.cc:9:10: parsing struct/union/class body 'wxTimerEvent' 3. segv9.cc:13:63: parsing function body 'wxTimerEvent::CRateLimiter::GetEventHashTable' 4. segv9.cc:13:63: in compound statement ('{}') clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) $ clang --version clang version 2.0 (trunk 104734) Target: x86_64-unknown-freebsd8.0 Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 26 15:46:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 15:46:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 7236] instcombine broken with arm_aapcscc In-Reply-To: References: Message-ID: <20100526204609.BD52D3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7236 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Rafael ?vila de Esp?ndola 2010-05-26 15:46:09 CDT --- Nick noticed the missing arm_aapcscc in the call instruction. Sorry about the noise. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 15:48:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 15:48:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7235] array initializer must be an initializer list or string literal In-Reply-To: References: Message-ID: <20100526204856.A13E23128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7235 Fariborz Jahanian changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |fjahanian at apple.com Resolution| |DUPLICATE --- Comment #2 from Fariborz Jahanian 2010-05-26 15:48:56 CDT --- This is fixed in PR7029. *** This bug has been marked as a duplicate of bug 7029 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 15:51:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 15:51:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 6977] crash (EXC_BAD_ACCESS) in clang::InitializationSequence::Diagnose In-Reply-To: References: Message-ID: <20100526205136.647093128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6977 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Douglas Gregor 2010-05-26 15:51:34 CDT --- This is now fixed in Clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed May 26 16:00:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 16:00:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 7238] New: 'aka' text can make diagnostic unreadable Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7238 Summary: 'aka' text can make diagnostic unreadable Product: clang Version: trunk Platform: PC OS/Version: Linux 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 For example, I got: .../file.cc:100:46: error: no viable conversion from 'iterator' (aka 'dense_hashtable_iterator, std::allocator > const, int>, basic_string, std::allocator >, __gnu_cxx::hash, std::allocator > >, dense_hash_map, std::allocator >, int, __gnu_cxx::hash, std::allocator > >, std::equal_to, std::allocator > >, libc_allocator_with_realloc, std::allocator > const, int> > >::SelectKey, dense_hash_map, std::allocator >, int, __gnu_cxx::hash, std::allocator > >, std::equal_to, std::allocator > >, libc_allocator_with_realloc, std::allocator > const, int> > >::SetKey, std::equal_to, std::allocator > >, libc_allocator_with_realloc, std::allocator > const, int> > >') to 'hash_map::const_iterator' (aka '_Hashtable_const_iterator, std::allocator > const, int>, basic_string, std::allocator >, __gnu_cxx::hash, std::allocator > >, std::_Select1st, std::allocator > const, int> >, std::equal_to, std::allocator > >, std::allocator >') it = item->diagnostics.begin(), end = item->diagnostics.end(); ^ ~~~~~~~~~~~~~~~~~~~~~~~ Unfortunately, I don't have a good suggestion for deciding when to omit the aka text. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 16:47:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 16:47:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 7101] Crash in codegen on local class access to static variable in containing function In-Reply-To: References: Message-ID: <20100526214726.E81C23128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7101 Fariborz Jahanian changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |fjahanian at apple.com Resolution| |FIXED --- Comment #3 from Fariborz Jahanian 2010-05-26 16:47:25 CDT --- Fixed in TOT: http://llvm.org/viewvc/llvm-project?view=rev&revision=104743 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 17:47:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 17:47:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 7026] Loop unroll thinks inline assembly blocks are function calls and does not unroll loops having them In-Reply-To: References: Message-ID: <20100526224754.EFEB03128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7026 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Jakob Stoklund Olesen 2010-05-26 17:47:54 CDT --- Applied in r104780, 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 May 26 19:17:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 19:17:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 3387] ICE in scheduler with ENABLE_EXPENSIVE_CHECKS In-Reply-To: References: Message-ID: <20100527001701.73AC63128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3387 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #9 from Dan Gohman 2010-05-26 19:17:00 CDT --- This is now fixed on trunk in r104718. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 20:46:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 20:46:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7142] Assertion failed: (CurFn->isDeclaration() && "Function already has body?"), function StartFunction, file CodeGenFunction.cpp, line 172. In-Reply-To: References: Message-ID: <20100527014601.BF2393128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7142 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |FIXED --- Comment #7 from John McCall 2010-05-26 20:46:01 CDT --- Fixed in r104796. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 22:19:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 May 2010 22:19:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 3073] Sema::DiagnoseAssignmentResult has broken message logic In-Reply-To: References: Message-ID: <20100527031919.1E0DF3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3073 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |WORKSFORME --- Comment #1 from Eli Friedman 2010-05-26 22:19:18 CDT --- I'm pretty sure this is fixed; current output for the given example: :5:7: error: initializing 'int' with an expression of incompatible type 'struct S' int i = *(struct S*)0; ^ ~~~~~~~~~~~~~ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 27 01:41:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 01:41:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 7199] Assertion ... "Declaration context must already be complete!"' failed In-Reply-To: References: Message-ID: <20100527064127.60F453128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7199 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |FIXED --- Comment #2 from John McCall 2010-05-27 01:41:26 CDT --- Unfortunately, it's quite possible for this particular assertion to come up from a lot of different places, but hopefully r104822 fixes your 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 May 27 04:22:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 04:22:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 6882] clang crashes on spirit.cpp In-Reply-To: References: Message-ID: <20100527092255.187BC3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6882 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |chris at bubblescope.net Resolution| |FIXED --- Comment #1 from Christopher Jefferson 2010-05-27 04:22:54 CDT --- This appears fixed, after the many recent improvements to boost support. Please re-open the bug if you are still having this 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 May 27 05:00:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 05:00:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 5885] clang c++ crash-on-invalid with anonymous union In-Reply-To: References: Message-ID: <20100527100051.C51803128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5885 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #2 from Eli Friedman 2010-05-27 05:00:51 CDT --- Seems fixed for me 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 May 27 05:29:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 05:29:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7239] New: Assertion "ObjectType and scope specifier cannot coexist" with qualified destructor call on template class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7239 Summary: Assertion "ObjectType and scope specifier cannot coexist" with qualified destructor call on template class Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Blocks: 5511 Testcase: template class A { }; class B { void f() { A* x; x->A::~A(); } }; Crashes with: clang: SemaTemplate.cpp:207: void clang::Sema::LookupTemplateName(clang::LookupResult&, clang::Scope*, clang::CXXScopeSpec&, clang::QualType, bool, bool&): Assertion `!SS.isSet() && "ObjectType and scope specifier cannot coexist"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 27 05:38:18 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 05:38:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 3073] Sema::DiagnoseAssignmentResult has broken message logic In-Reply-To: References: Message-ID: <20100527103818.6216D3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3073 Sebastian Redl changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WORKSFORME |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 27 06:01:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 06:01:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 7240] New: The analyser gets the documented pattern for dealing with NSURLConnection wrong. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7240 Summary: The analyser gets the documented pattern for dealing with NSURLConnection wrong. Product: clang Version: unspecified Platform: Macintosh OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: iamleeg at gmail.com CC: llvmbugs at cs.uiuc.edu Summary: Apple document example asynchronous use of NSURLConnections as: - create an NSURLConnection object in one method - when you get a callback indicating completion of the connection, release it. The static analyser (correctly) reports that the NSURLConnection object created in the first method has a retain count of +1 by the end of the method, but in this case we know that the warning is redundant because the object will be released elsewhere. Distasteful solution: an annotation on the variable saying "this local variable should have a retain count of +1 when it goes out of scope" More tasteful solution: an annotation on the class saying "instances of this class are allowed to be created with extra retain counts, as long as they've been given a delegate implementing these methods, where the method releases the parameter passed as self by this class's instance". So on NSURLConnection, it would indicate that -[delegate connectionDidFinishLoading:] and -[delegate connection:didFailWithError:] should release the connection if it was created with an extra retain count. Real solution: you're the experts :-). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 06:04:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 06:04:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 5912] clang++ assertion failed: "Leftover temporaries in function" In-Reply-To: References: Message-ID: <20100527110452.3B0503128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5912 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #9 from Christopher Jefferson 2010-05-27 06:04:51 CDT --- Thanks. In that case I will close the bug. Feel free to reopen it if you feel there is any need to of course! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 10:05:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 10:05:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 7241] New: Missing definitions causes clang++ to crash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7241 Summary: Missing definitions causes clang++ to crash Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mmo at vizrt.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Code, file test.hpp: class A { public: virtual ~A() { } }; class B : public A { public: virtual void test() const {} }; class C : public B { public: C(); ~C(); }; File test.cpp: #include "test.hpp" class D : public C { public: D() {} }; void test() { D d; } Execution: $ clang++ -c test.cpp -v clang version 2.0 (trunk 104832) Target: x86_64-unknown-linux-gnu Thread model: posix "/home/michael/devel/llvm/Debug/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name test.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -resource-dir /home/michael/devel/llvm/Debug/lib/clang/2.0 -ferror-limit 19 -fmessage-length 240 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-nXO2eG.s -x c++ test.cpp clang -cc1 version 2.0 based upon llvm 2.8svn hosted on x86_64-unknown-linux-gnu ... #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.4 /usr/include/c++/4.4/x86_64-linux-gnu /usr/include/c++/4.4/backward /usr/local/include /home/michael/devel/llvm/Debug/lib/clang/2.0/include /usr/include End of search list. clang: CodeGenModule.cpp:831: llvm::Constant* clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef, const llvm::Type*, clang::CodeGen::GlobalDecl): Assertion `DD->isUsed() && "Sema doesn't consider destructor as used."' failed. 0 clang 0x00000000014f6de6 1 clang 0x00000000014f6cbd 2 libpthread.so.0 0x00007f873e7678f0 3 libc.so.6 0x00007f873da57a75 gsignal + 53 4 libc.so.6 0x00007f873da5b5c0 abort + 384 5 libc.so.6 0x00007f873da50941 __assert_fail + 241 6 clang 0x000000000058079d 7 clang 0x00000000005809cf 8 clang 0x0000000000670811 9 clang 0x0000000000670d33 10 clang 0x000000000067124f 11 clang 0x000000000057f3a8 12 clang 0x000000000057db6a 13 clang 0x000000000057c7b9 14 clang 0x0000000000427dfd 15 clang 0x00000000006aa3c2 16 clang 0x0000000000443b08 17 clang 0x0000000000443773 18 clang 0x000000000042e40e 19 clang 0x000000000040933f 20 clang 0x0000000000411f9c main + 357 21 libc.so.6 0x00007f873da42c4d __libc_start_main + 253 22 clang 0x0000000000407cb9 Stack dump: 0. Program arguments: /home/michael/devel/llvm/Debug/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name test.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -resource-dir /home/michael/devel/llvm/Debug/lib/clang/2.0 -ferror-limit 19 -fmessage-length 240 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-nXO2eG.s -x c++ test.cpp 1. parser at end of file 2. Per-file LLVM IR generation clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) Stack trace: #0 0x00007ffff6ebfa75 in *__GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff6ec35c0 in *__GI_abort () at abort.c:92 #2 0x00007ffff6eb8941 in *__GI___assert_fail (assertion=0x154f868 "DD->isUsed() && \"Sema doesn't consider destructor as used.\"", file=, line=831, function=0x1554380 "llvm::Constant* clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef, const llvm::Type*, clang::CodeGen::GlobalDecl)") at assert.c:81 #3 0x000000000058079d in clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction (this=0x231efa0, MangledName=..., Ty=0x233ffa0, D=...) at CodeGenModule.cpp:831 #4 0x00000000005809cf in clang::CodeGen::CodeGenModule::GetAddrOfFunction (this=0x231efa0, GD=..., Ty=0x233ffa0) at CodeGenModule.cpp:862 #5 0x0000000000670811 in clang::CodeGen::CodeGenVTables::CreateVTableInitializer (this=0x231f1f8, RD=0x2333c80, Components=0x234f108, NumComponents=5, VTableThunks=...) at CGVTables.cpp:2955 #6 0x0000000000670d33 in clang::CodeGen::CodeGenVTables::EmitVTableDefinition (this=0x231f1f8, VTable=0x234ee58, Linkage=llvm::GlobalValue::WeakODRLinkage, RD=0x2333c80) at CGVTables.cpp:3052 #7 0x000000000067124f in clang::CodeGen::CodeGenVTables::GenerateClassData (this=0x231f1f8, Linkage=llvm::GlobalValue::WeakODRLinkage, RD=0x2333c80) at CGVTables.cpp:3118 #8 0x000000000057f3a8 in clang::CodeGen::CodeGenModule::EmitDeferred (this=0x231efa0) at CodeGenModule.cpp:509 #9 0x000000000057db6a in clang::CodeGen::CodeGenModule::Release (this=0x231efa0) at CodeGenModule.cpp:94 #10 0x000000000057c7b9 in HandleTranslationUnit (this=0x2301d20, Ctx=...) at ModuleBuilder.cpp:83 #11 0x0000000000427dfd in HandleTranslationUnit (this=0x230a6a0, C=...) at CodeGenAction.cpp:159 #12 0x00000000006aa3c2 in clang::ParseAST (PP=..., Consumer=0x230a6a0, Ctx=..., PrintStats=false, CompleteTranslationUnit=true, CompletionConsumer=0x0) at ParseAST.cpp:108 #13 0x0000000000443b08 in clang::ASTFrontendAction::ExecuteAction (this=0x22f5710) at FrontendAction.cpp:224 #14 0x0000000000443773 in clang::FrontendAction::Execute (this=0x22f5710) at FrontendAction.cpp:150 #15 0x000000000042e40e in clang::CompilerInstance::ExecuteAction (this=0x22efc90, Act=...) at CompilerInstance.cpp:513 #16 0x000000000040933f in cc1_main (ArgBegin=0x7fffffffe1d8, ArgEnd=0x7fffffffe2b8, Argv0=0x7fffffffe54b "/opt/bin/clang", MainAddr=0x411058) at cc1_main.cpp:286 #17 0x0000000000411f9c in main (argc=30, argv=0x7fffffffe1c8) at driver.cpp:186 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 10:26:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 10:26:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7239] Assertion "ObjectType and scope specifier cannot coexist" with qualified destructor call on template class In-Reply-To: References: Message-ID: <20100527152642.11A633128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7239 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-05-27 10:26:41 CDT --- Fixed in r104834. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 13:46:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 13:46:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 5728] Miscompilation with fastcall In-Reply-To: References: Message-ID: <20100527184631.18646312800A@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5728 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Dan Gohman 2010-05-27 13:46:30 CDT --- It appears fast-isel doesn't know about callee-pop yet. With r104866, it now knows it doesn't know about callee-pop yet. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 15:28:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 15:28:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7242] New: Assert on valid code: Constant declref with side-effect?! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7242 Summary: Assert on valid code: Constant declref with side-effect?! 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 Created an attachment (id=4940) --> (http://llvm.org/bugs/attachment.cgi?id=4940) Asserting example The attached code fails with the following assert. This code was reduced from part of libstdc++. t.cc:5:9: warning: division by zero is undefined __max / 0; ^ ~ t.cc:5:9: warning: expression result unused [-Wunused-value] __max / 0; ~~~~~ ^ ~ Assertion failed: (!Result.HasSideEffects && "Constant declref with side-effect?!"), function VisitDeclRefExpr, file CGExprScalar.cpp, line 150. 0 clang 0x000000010100d71a PrintStackTrace(void*) + 38 1 clang 0x000000010100dbfa SignalHandler(int) + 312 2 libSystem.B.dylib 0x00007fff8476180a _sigtramp + 26 3 libSystem.B.dylib 0x00007fff5fbfb430 _sigtramp + 3679034432 4 libSystem.B.dylib 0x00007fff847dcef0 __pthread_markcancel + 0 5 clang 0x00000001001b27e1 (anonymous namespace)::ScalarExprEmitter::VisitDeclRefExpr(clang::DeclRefExpr*) + 153 6 clang 0x00000001001b8374 clang::StmtVisitor<(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 3214 7 clang 0x00000001001b69e9 (anonymous namespace)::ScalarExprEmitter::EmitCastExpr(clang::CastExpr*) + 399 8 clang 0x00000001001b75c3 (anonymous namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) + 87 9 clang 0x00000001001b76e3 clang::StmtVisitor<(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::VisitImplicitCastExpr(clang::ImplicitCastExpr*) + 29 10 clang 0x00000001001b82f7 clang::StmtVisitor<(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 3089 11 clang 0x00000001001bb13e (anonymous namespace)::ScalarExprEmitter::EmitBinOps(clang::BinaryOperator const*) + 58 12 clang 0x00000001001bb1cb (anonymous namespace)::ScalarExprEmitter::VisitBinDiv(clang::BinaryOperator const*) + 33 13 clang 0x00000001001b7846 clang::StmtVisitor<(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 352 14 clang 0x00000001001b8907 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 131 15 clang 0x000000010019278a clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, llvm::Value*, bool, bool, bool) + 76 16 clang 0x00000001001fd174 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 756 17 clang 0x00000001001fe865 clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, llvm::Value*, bool) + 281 18 clang 0x00000001001fea8f clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 179 19 clang 0x00000001001fcece clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 78 20 clang 0x0000000100220d7e clang::CodeGen::CodeGenFunction::EmitFunctionBody(llvm::SmallVector, 16u>&) + 146 21 clang 0x0000000100222148 clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl, llvm::Function*) + 1340 22 clang 0x000000010022b8c2 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl) + 688 23 clang 0x000000010022ba6b clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl) + 277 24 clang 0x000000010022bbf5 clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 309 25 clang 0x000000010022bec2 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 466 26 clang 0x0000000100245690 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 76 27 clang 0x000000010004a95a (anonymous namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 144 28 clang 0x00000001002562e5 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer*) + 440 29 clang 0x000000010006d73e clang::ASTFrontendAction::ExecuteAction() + 256 30 clang 0x000000010006d83b clang::FrontendAction::Execute() + 239 31 clang 0x000000010005041d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 785 32 clang 0x0000000100027891 cc1_main(char const**, char const**, char const*, void*) + 1762 33 clang 0x000000010002ec77 main + 335 34 clang 0x0000000100026710 start + 52 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -mrelax-all -disable-free -main-file-name t.cc -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -resource-dir /usr/local/lib/clang/2.0 -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 1. parser at end of file 2. t.cc:1:5: LLVM IR generation of declaration 'main' 3. t.cc:1:5: Generating code for declaration 'main' 4. t.cc:2:1: LLVM IR generation of compound statement ('{}') clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu May 27 20:42:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 20:42:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 7230] extern "C" global function can't be made a friend of a class in a namespace In-Reply-To: References: Message-ID: <20100528014240.EA5273128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7230 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |FIXED --- Comment #2 from John McCall 2010-05-27 20:42:40 CDT --- Fixed in r104917. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 23:41:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 May 2010 23:41:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 7243] New: clang should be more forgiving of mismatched throw() specifications in -fno-exceptions mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7243 Summary: clang should be more forgiving of mismatched throw() specifications in -fno-exceptions mode Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Blocks: 5511 Testcase: void a() throw(int); void a() throw(); g++ -fno-exceptions accepts this code, but clang -fno-exceptions doesn't. In practice, this affects Firefox, which mismatches the specifications and uses -fno-exceptions. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 01:57:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 01:57:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 6883] diamond in anonymous namespace fails to link In-Reply-To: References: Message-ID: <20100528065741.13DB73128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6883 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |WORKSFORME --- Comment #2 from Eli Friedman 2010-05-28 01:57:40 CDT --- This appears to be working with trunk. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 28 03:21:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 03:21:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 6762] clang++ trigger ADL on va_list In-Reply-To: References: Message-ID: <20100528082103.BE6193128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6762 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |FIXED --- Comment #5 from John McCall 2010-05-28 03:21:02 CDT --- Fixed in r104941. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 03:37:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 03:37:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 7243] clang should be more forgiving of mismatched throw() specifications in -fno-exceptions mode In-Reply-To: References: Message-ID: <20100528083754.4B24A3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7243 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |FIXED --- Comment #1 from John McCall 2010-05-28 03:37:54 CDT --- Fixed in r104942. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 06:54:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 06:54:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 6201] add i64 version of alloca In-Reply-To: References: Message-ID: <20100528115410.A532A3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6201 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |FIXED --- Comment #1 from Benjamin Kramer 2010-05-28 06:54:10 CDT --- Dan removed the i32 restriction in r104911. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 07:32:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 07:32:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 7244] New: Compilation error while using forward declared class in template function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7244 Summary: Compilation error while using forward declared class in template function Product: clang Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ogoffart at kde.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com // Extracted from webkit struct JSCell {}; struct JSValue { JSValue(JSCell *) {} }; struct JSNode; template inline JSValue getDOMNodeWrapper(JSNode* wrapper) { return wrapper; } struct JSNode : JSCell {}; int main() { getDOMNodeWrapper(0); return 0; } /* test.cpp:12:12: error: no viable conversion from 'JSNode *' to 'JSValue' return wrapper; ^~~~~~~ test.cpp:4:8: note: candidate constructor (the implicit copy constructor) not viable: cannot convert argument of incomplete type 'JSNode *' to 'JSValue const &' struct JSValue { ^ test.cpp:5:5: note: candidate constructor not viable: cannot convert argument of incomplete type 'JSNode *' to 'JSCell *' JSValue(JSCell *) {} ^ 1 error generated. */ GCC compiles this code fine. But I think this might be a bug in GCC. In that case, WebKit would need to be fixed instead. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 28 10:00:18 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 10:00:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 7245] New: Should not require copy constructor when binding rvalue to reference Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7245 Summary: Should not require copy constructor when binding rvalue to reference 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: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu, dgregor at apple.com Specifically, struct NonCopyable { NonCopyable(); private: NonCopyable(const NonCopyable&); }; void foo(const NonCopyable&); void bar() { foo(NonCopyable()); } should compile. gcc used to complain about this, but stopped in gcc-4.3 because http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391 convinced them it was a mistake in C++03 (http://gcc.gnu.org/PR44313). Comeau's online compile defaults to allowing it, but gives an error if you disable C++0x extensions. Clang's c++0x mode allows it. And, of course, it's a silly and inconvenient restriction. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 11:02:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 11:02:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 7246] New: clang doesn't handle constructor exception handlers properly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7246 Summary: clang doesn't handle constructor exception handlers properly Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: krisis88 at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4944) --> (http://llvm.org/bugs/attachment.cgi?id=4944) test case in function try blocks for constructors and destructors, the handler should rethrow the currently handled exception at the end, according to the c++ standard. when executing the attached test case, both handlers should be executed, but only the one for the constructor is. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 12:13:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 12:13:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7247] New: Global templates shouldn't make member template functions ambiguous Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7247 Summary: Global templates shouldn't make member template functions ambiguous 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 template struct set{}; template struct trait { typedef const T& type; }; struct Value { template void set(typename trait::type value) { } }; void foo() { Value v; v.set(3.2); } should be valid. As it is, clang complains: test.cc:10:7: error: lookup of 'set' in member access expression is ambiguous v.set(3.2); ^ test.cc:5:10: note: lookup in the object type 'Value' refers here void set(typename trait::type value) { ^ test.cc:1:29: note: lookup from the current scope refers here template struct set{}; ^ That is, clang should ignore the second half of basic.lookup.classref para 1, where, after finding the name the user intended, it's also required to try to find a template the user didn't intend in order to break the compile. Gcc ignores this problem while Comeau only emits a warning. I've filed a national-body comment to try to get this officially fixed in C++0x. A similar problem with destructors was fixed in issue 305: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#305. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 12:26:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 12:26:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7248] New: Assert on "Identifier nested-name-specifier with no prefix or object type" failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7248 Summary: Assert on "Identifier nested-name-specifier with no prefix or object type" failed Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nomura at netapp.com CC: llvmbugs at cs.uiuc.edu r104939 Assertion: clang: /x/eng/build_scratch2/nomura/clang-llvm_100528_0000/llvm/tools/clang/libSema/TreeTransform.h:2026: clang::NestedNameSpecifier* clang::TreeTransform::TransformNestedNameSpecifier(clang::NestedNameSpecifier*, clang::SourceRange, clang::QualType, clang::NamedDecl*) [with Derived = ::TemplateInstantiator]: Assertion `(Prefix || !ObjectType.isNull()) && "Identifier nested-name-specifier with no prefix or object type"' failed._cpumask_t cpumask_t; typedef _0 clang 0x0000000001502cff Reduced testcase (although it's badly mangled, the assert is the same as in the original testcase): //BEGIN TESTCASE typedef struct spinnp_dsid_t { int marshal (int &ops) { } SPINNP_FH_FLAG_NULL, SPINNP_FH_FLAG_STREAMDIR = 0x1, SPINNP_FH_FLAG_SNAPDIR, SPINNP_FH_FLAG_SNAPDIR_ENT, SPINNP_FH_FLAG_EMPTY = 0x8, SPINNP_FH_FLAG_STRIPED = 0x10, SPINNP_FH_FLAG_ONTAPC = 0x20, SPINNP_FH_FLAG_METADATA = 0x40, _SPINNP_MAX_spinnp_fh_flags_t = 0x40, }; namespace Coral { class DsFileTable; class Singleton; class Coral::Singleton { static DsFileTable & dsFileTable (); }; enum FactoryAllocPriority { FACTORY_ALLOC_PRIORITY_0 = 0, FACTORY_ALLOC_PRIORITY_1, FACTORY_ALLOC_PRIORITY_2, FACTORY_ALLOC_PRIORITY_3, FACTORY_ALLOC_PRIORITY_4, FACTORY_ALLOC_PRIORITY_5, FACTORY_ALLOC_PRIORITY_6, FACTORY_ALLOC_PRIORITY_COUNT }; template < typename objectclass > class Coral::LruFactory:public Coral::Factory < objectclass > { } template < typename fte_t > class Coral::FileTable { void kickWaiters (); void release (fte_t * fte); private:typedef LruFactory < fte_t > FteFactory; protected:FteFactory _fteFactory; }; template < typename fte_t > void Coral::FileTable < fte_t >::kickWaiters () { FactoryAllocPriority pri = _maxPriority; fte_t *fte = requestExisting (headWaiter->_dsid, headWaiter->_fileid); fte = _fteFactory.Coral::template Factory < fte_t >::recycle (pri); } template < typename fte_t > void Coral::FileTable < fte_t >::release (fte_t * fte) { kickWaiters (); } struct DsFileTableEntry; class Coral::DsFileTable:public FileTable < DsFileTableEntry > { struct coral_fas_opstate { struct fas_file_info { void coral_fas_opstate::fas_file_info::reset (void) { Coral::Singleton::dsFileTable ().release (this->dsFte); //END TESTCASE Invocation: /x/eng/build2/scratch/nomura/clang-LATEST/bin/clang -x c++ xx.i fatal error: too many errors emitted, stopping now [-ferror-limit=] clang: /x/eng/build_scratch2/nomura/clang-llvm_100528_0000/llvm/tools/clang/libSema/TreeTransform.h:2026: clang::NestedNameSpecifier* clang::TreeTransform::TransformNestedNameSpecifier(clang::NestedNameSpecifier*, clang::SourceRange, clang::QualType, clang::NamedDecl*) [with Derived = ::TemplateInstantiator]: Assertion `(Prefix || !ObjectType.isNull()) && "Identifier nested-name-specifier with no prefix or object type"' failed. 0 clang 0x0000000001502cff 1 clang 0x00000000015038d7 2 libpthread.so.0 0x000000381100e7c0 3 libc.so.6 0x0000003810430265 gsignal + 53 4 libc.so.6 0x0000003810431d10 abort + 272 5 libc.so.6 0x00000038104296e6 __assert_fail + 246 6 clang 0x0000000000861637 7 clang 0x0000000000868d12 8 clang 0x0000000000855144 9 clang 0x0000000000856df9 10 clang 0x00000000008594b9 11 clang 0x000000000085c72b 12 clang 0x0000000000861501 13 clang 0x00000000008669e6 14 clang 0x0000000000848133 15 clang 0x00000000008506a0 16 clang 0x0000000000848dcc 17 clang 0x000000000085189e 18 clang 0x0000000000848d17 19 clang 0x000000000086d4da 20 clang 0x000000000086dba1 21 clang 0x000000000086cf69 22 clang 0x0000000000872ac5 23 clang 0x000000000086ce44 24 clang 0x000000000086dba1 25 clang 0x000000000086cf69 26 clang 0x000000000086e535 27 clang 0x000000000086ca7a 28 clang 0x000000000086dba1 29 clang 0x000000000086cf69 30 clang 0x000000000086e535 31 clang 0x000000000086ca7a 32 clang 0x000000000086dba1 33 clang 0x000000000086cf69 34 clang 0x0000000000875b78 35 clang 0x000000000088252a 36 clang 0x0000000000881e81 37 clang 0x0000000000882995 38 clang 0x0000000000881e81 39 clang 0x000000000069b71e 40 clang 0x0000000000a98c6f 41 clang 0x00000000006988be 42 clang 0x000000000043fe5f 43 clang 0x000000000042d070 44 clang 0x0000000000432ba4 main + 2724 45 libc.so.6 0x000000381041d994 __libc_start_main + 244 46 clang 0x000000000042b209 Stack dump: 0. Program arguments: /x/eng/build_scratch2/nomura/clang-llvm_100528_0000/oot/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name bug.i -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /x/eng/build_scratch2/nomura/clang-llvm_100528_0000/root/lib/clang/2.0 -ferror-limit 19 -fmessage-length 0 -fexceptions -fgnu-runtime -fdiagnostics-show-option -o /tmp/cc-E9MaSJ.s -x c++ bug.i -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 28 12:43:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 12:43:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7249] New: Crash in qualified member call when member function has same name as base class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7249 Summary: Crash in qualified member call when member function has same name as base class 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 I'm not sure if this is valid. Neither gcc nor comeau accept it. dhcp-172-31-155-187:~/tmp$ cat test2.cc namespace hide { template struct base { void bar(double) {} }; struct Value : base { template void base(const T& value) {} }; } void foo() { hide::Value v; v.base::bar(3.2); } dhcp-172-31-155-187:~/tmp$ gdb --args "/Users/jyasskin/src/llvm/clang/obj/Debug/bin/clang" -cc1 -fsyntax-only test2.cc GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries ..... done (gdb) run Starting program: /Users/jyasskin/src/llvm/clang/obj/Debug/bin/clang -cc1 -fsyntax-only test2.cc Reading symbols for shared libraries +++. done Assertion failed: (false && "FIXME: Only type template names supported here"), function ParseOptionalCXXScopeSpecifier, file /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseExprCXX.cpp, line 222. Program received signal SIGABRT, Aborted. 0x96bc7e42 in __kill () (gdb) bt #0 0x96bc7e42 in __kill () #1 0x96bc7e34 in kill$UNIX2003 () #2 0x96c3a23a in raise () #3 0x96c46679 in abort () #4 0x96c3b3db in __assert_rtn () #5 0x0062b969 in clang::Parser::ParseOptionalCXXScopeSpecifier (this=0xbfffecd8, SS=@0xbfffcf84, ObjectType=0x1907bc0, EnteringContext=false, MayBePseudoDestructor=0xbfffcf7f) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseExprCXX.cpp:222 #6 0x00625ea8 in clang::Parser::ParsePostfixExpressionSuffix (this=0xbfffecd8, LHS=@0xbfffd35c) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseExpr.cpp:1024 #7 0x00621da0 in clang::Parser::ParseCastExpression (this=0xbfffecd8, isUnaryExpression=false, isAddressOfOperand=false, NotCastExpr=@0xbfffd817, TypeOfCast=0x0) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseExpr.cpp:668 #8 0x00623ef5 in clang::Parser::ParseCastExpression (this=0xbfffecd8, isUnaryExpression=false, isAddressOfOperand=false, TypeOfCast=0x0) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseExpr.cpp:424 #9 0x00624093 in clang::Parser::ParseAssignmentExpression (this=0xbfffecd8) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseExpr.cpp:231 #10 0x006245ab in clang::Parser::ParseExpression (this=0xbfffecd8) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseExpr.cpp:180 #11 0x006406c2 in clang::Parser::ParseStatementOrDeclaration (this=0xbfffecd8, OnlyStatement=false) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseStmt.cpp:126 #12 0x006450c4 in clang::Parser::ParseCompoundStatementBody (this=0xbfffecd8, isStmtExpr=false) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseStmt.cpp:471 #13 0x00645797 in clang::Parser::ParseFunctionStatementBody (this=0xbfffecd8, Decl={Ptr = 0x19078a0}) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseStmt.cpp:1463 #14 0x0064f39e in clang::Parser::ParseFunctionDefinition (this=0xbfffecd8, D=@0xbfffded0, TemplateInfo=@0xbfffe1cc) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:686 #15 0x0060f731 in clang::Parser::ParseDeclGroup (this=0xbfffecd8, DS=@0xbfffe2ec, Context=0, AllowFunctionDefinitions=true, DeclEnd=0x0) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseDecl.cpp:409 #16 0x0064d80a in clang::Parser::ParseDeclarationOrFunctionDefinition (this=0xbfffecd8, DS=@0xbfffe2ec, Attr=0x0, AS=clang::AS_none) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:587 #17 0x0064d85a in clang::Parser::ParseDeclarationOrFunctionDefinition (this=0xbfffecd8, Attr=0x0, AS=clang::AS_none) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:594 #18 0x0064e63c in clang::Parser::ParseExternalDeclaration (this=0xbfffecd8, Attr={AttrList = 0x0, Range = {B = {ID = 0}, E = {ID = 0}}, HasAttr = false}) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:483 #19 0x0064e77a in clang::Parser::ParseTopLevelDecl (this=0xbfffecd8, Result=@0xbfffeddc) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:355 #20 0x00256b92 in clang::ParseAST (PP=@0x1903640, Consumer=0x1905e50, Ctx=@0x2022e00, PrintStats=false, CompleteTranslationUnit=true, CompletionConsumer=0x0) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Sema/ParseAST.cpp:87 #21 0x0004d05c in clang::ASTFrontendAction::ExecuteAction (this=0x19030f0) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/FrontendAction.cpp:224 #22 0x0004cf4c in clang::FrontendAction::Execute (this=0x19030f0) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/FrontendAction.cpp:150 #23 0x0002d41f in clang::CompilerInstance::ExecuteAction (this=0x19018c0, Act=@0x19030f0) at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/CompilerInstance.cpp:513 #24 0x0000392a in cc1_main (ArgBegin=0xbffff698, ArgEnd=0xbffff6a0, Argv0=0xbffff74c "/Users/jyasskin/src/llvm/clang/obj/Debug/bin/clang", MainAddr=0xa264) at /Users/jyasskin/src/llvm/clang/src/tools/clang/tools/driver/cc1_main.cpp:286 #25 0x0000b054 in main (argc=4, argv=0xbffff690) at /Users/jyasskin/src/llvm/clang/src/tools/clang/tools/driver/driver.cpp:186 (gdb) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 12:48:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 12:48:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 7250] New: Assert/Crash when using arrays of 64k elements or more in structs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7250 Summary: Assert/Crash when using arrays of 64k elements or more in structs Product: new-bugs Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: ddneff at hotmail.com CC: llvmbugs at cs.uiuc.edu Using arrays of 64k or larger overflows the unsigned short SDNode::NumValues variable, and leades to asserts/crashes. Simple test case: ; ModuleID = 'Q' %0 = type { i64, i64, [65536 x double] } @global_subject5747_522547216 = internal hidden global %0 zeroinitializer define internal void @on_1_522492064(i64 %VALUE_0) { entry: store %0 zeroinitializer, %0* @global_subject5747_522547216 ret void } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 28 15:54:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 15:54:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7244] Compilation error while using forward declared class in template function In-Reply-To: References: Message-ID: <20100528205430.3DA3A3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7244 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Douglas Gregor 2010-05-28 15:54:29 CDT --- Clang is allowed to reject this code, because neither "wrapper" nor JSValue are type-dependent. Note that the EDG front end (used by Intel, Comeau, and others) also rejects this code. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 28 18:50:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 18:50:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 7251] New: Clang++ not detecting ambiguous templates Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7251 Summary: Clang++ not detecting ambiguous templates Product: clang Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: wales at physics.usyd.edu.au CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following is accepted by clang++, but rejected by g++ and icpc as an ambiguous reference as both 'int a' and 'template a' are in the global namespace. namespace A { template struct a { }; } using namespace A; int a; /* a should be an ambiguous reference */ a b; clang++ -v clang version 2.0 (trunk 103456) Target: x86_64-apple-darwin10 Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri May 28 20:35:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 May 2010 20:35:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 7193] compiler abort on tail call with regparm In-Reply-To: References: Message-ID: <20100529013541.5E2813128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7193 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Evan Cheng 2010-05-28 20:35:40 CDT --- Fixed: 105092 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 00:08:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 00:08:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 7252] New: clang c++ crash in lookup for ambiguous template base classes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7252 Summary: clang c++ crash in lookup for ambiguous template base classes Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Testcase: namespace A { template struct Base { typedef T t; }; } namespace B { template struct Base { typedef T t; }; } template struct Derived : A::Base, B::Base { typename Derived::Base::t x; }; Crashes with: clang: /home/eli/llvm/tools/clang/lib/Sema/Lookup.h:548: void clang::LookupResult::sanity() const: Assertion `(Paths != __null) == (ResultKind == Ambiguous && (Ambiguity == AmbiguousBaseSubobjectTypes || Ambiguity == AmbiguousBaseSubobjects))' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 01:31:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 01:31:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 7218] Assigning to buf[0] makes buf[1] valid In-Reply-To: References: Message-ID: <20100529063103.B013F3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7218 Zhongxing Xu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |xuzhongxing at gmail.com Resolution| |FIXED --- Comment #1 from Zhongxing Xu 2010-05-29 01:31:03 CDT --- Fixed in r105097. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 01:32:09 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 01:32:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 7217] Crash for accessing too-small malloc'd buffer In-Reply-To: References: Message-ID: <20100529063209.3A8203128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7217 Zhongxing Xu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 01:32:24 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 01:32:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 6123] RFE: check malloc sizes are multiple of access type In-Reply-To: References: Message-ID: <20100529063224.8D71B3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6123 Zhongxing Xu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 01:56:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 01:56:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 7218] Assigning to buf[0] makes buf[1] valid In-Reply-To: References: Message-ID: <20100529065642.053D13128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7218 Zhongxing Xu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #2 from Zhongxing Xu 2010-05-29 01:56:41 CDT --- Discussing another fix. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 03:28:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 03:28:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 7253] New: LLVM creates invalid code on GeodeLX Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7253 Summary: LLVM creates invalid code on GeodeLX Product: clang Version: 2.7 Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: freebsd at nagilum.org CC: llvmbugs at cs.uiuc.edu On a Geode LX system clang attempts to create code for pentium4: $ clang -### -o a16-clang a16.c clang version 1.1 (branches/release_27) Target: i386-portbld-freebsd8.1 Thread model: posix "/usr/local/bin/clang" "-cc1" "-triple" "i386-portbld-freebsd8.1" "-S" "-disable-free" "-main-file-name" "a16.c" "-mrelocation-model" "static" "-mdisable-fp-elim" "-mconstructor-aliases" "-target-cpu" "pentium4" "-resource-dir" "/usr/local/lib/clang/1.1" "-fmessage-length" "80" "-fgnu-runtime" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "/tmp/cc-QQe1uq.s" "-x" "c" "a16.c" "/usr/local/bin/as" "--32" "-o" "/tmp/cc-fveACK.o" "/tmp/cc-QQe1uq.s" "/usr/local/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "-m" "elf_i386_fbsd" "-o" "a16-clang" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "/tmp/cc-fveACK.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" GCC gets it right, but had a similar bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37179): $ gcc45 -### -o a16-clang a16.c Using built-in specs. COLLECT_GCC=gcc45 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/lto-wrapper Target: i386-portbld-freebsd8.1 Configured with: ./../gcc-4.5-20100520/configure --enable-lto=yes --with-libelf=/usr/local --disable-nls --libdir=/usr/local/lib/gcc45 --libexecdir=/usr/local/libexec/gcc45 --program-suffix=45 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc45/include/c++/ --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-system-zlib --disable-rpath --enable-libgcj --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc45 --build=i386-portbld-freebsd8.1 Thread model: posix gcc version 4.5.1 20100520 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-o' 'a16-clang' '-mtune=i386' '-march=i386' "/usr/local/libexec/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/cc1" "-quiet" "a16.c" "-quiet" "-dumpbase" "a16.c" "-mtune=i386" "-march=i386" "-auxbase" "a16" "-o" "/var/tmp//ccosg0Cn.s" COLLECT_GCC_OPTIONS='-o' 'a16-clang' '-mtune=i386' '-march=i386' "/usr/local/bin/as" "-o" "/var/tmp//ccmzk0tQ.o" "/var/tmp//ccosg0Cn.s" COMPILER_PATH=/usr/local/libexec/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/:/usr/local/libexec/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/:/usr/local/libexec/gcc45/gcc/i386-portbld-freebsd8.1/:/usr/local/lib/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/:/usr/local/lib/gcc45/gcc/i386-portbld-freebsd8.1/ LIBRARY_PATH=/usr/local/lib/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/:/usr/local/lib/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 'a16-clang' '-mtune=i386' '-march=i386' "/usr/local/libexec/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/collect2" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "-o" "a16-clang" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/local/lib/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/crtbegin.o" "-L/usr/local/lib/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1" "-L/usr/local/lib/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/../../.." "/var/tmp//ccmzk0tQ.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/local/lib/gcc45/gcc/i386-portbld-freebsd8.1/4.5.1/crtend.o" "/usr/lib/crtn.o" Binaries created by clang will contain invalid code: nagilum at cakebox ~/Projects/C/src/a16 > gdb -c a16-clang-O3.core a16-clang-O3 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `a16-clang-O3'. Program terminated with signal 4, Illegal instruction. Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x08049441 in NextGuess () (gdb) disassemble NextGuess Dump of assembler code for function NextGuess: 0x08049390 : push %ebp 0x08049391 : mov %esp,%ebp 0x08049393 : push %ebx 0x08049394 : push %edi 0x08049395 : push %esi 0x08049396 : sub $0x54c,%esp 0x0804939c : xor %eax,%eax 0x0804939e : lea 0xfffffaf2(%ebp),%ecx 0x080493a4 : mov $0x5,%edx 0x080493a9 : lea 0x0(%esi),%esi 0x080493b0 : xor %esi,%esi 0x080493b2 : lea 0x0(%esi),%esi 0x080493b9 : lea 0x0(%edi),%edi 0x080493c0 : movw $0x0,(%ecx,%esi,2) 0x080493c6 : inc %esi 0x080493c7 : cmp $0x10,%esi 0x080493ca : jne 0x80493c0 0x080493cc : test %edx,%edx 0x080493ce : js 0x80493ee 0x080493d0 : xor %esi,%esi 0x080493d2 : lea 0x0(%esi),%esi 0x080493d9 : lea 0x0(%edi),%edi 0x080493e0 : lea (%eax,%esi,1),%edi 0x080493e3 : mov %di,(%ecx,%esi,2) 0x080493e7 : inc %esi 0x080493e8 : cmp %edx,%esi 0x080493ea : jle 0x80493e0 0x080493ec : add %esi,%eax 0x080493ee : add $0x20,%ecx 0x080493f1 : test %edx,%edx 0x080493f3 : lea 0xffffffff(%edx),%edx 0x080493f6 : jne 0x80493b0 0x080493f8 : mov $0x61a80,%eax 0x080493fd : lea 0x0(%esi),%esi 0x08049400 : mov 0x8(%ebp),%ecx 0x08049403 : xor %edx,%edx 0x08049405 : lea (%ecx,%eax,1),%ecx 0x08049408 : nop ---Type to continue, or q to quit--- 0x08049409 : lea 0x0(%esi),%esi 0x08049410 : movw $0x0,(%ecx,%edx,2) 0x08049416 : inc %edx 0x08049417 : cmp $0x15,%edx 0x0804941a : jne 0x8049410 0x0804941c : add $0x2c,%eax 0x0804941f : cmp $0x493e00,%eax 0x08049424 : jne 0x8049400 0x08049426 : mov 0x8(%ebp),%eax 0x08049429 : pxor %xmm0,%xmm0 0x0804942d : movl $0x1869f,0xfffffad0(%ebp) 0x08049437 : movl $0x186a0,0xfffffacc(%ebp) 0x08049441 : movsd %xmm0,0xfffffad8(%ebp) 0x08049449 : lea 0x61aac(%eax),%ecx 0x0804944f : lea 0x4(%eax),%eax 0x08049452 : mov %ecx,0xfffffabc(%ebp) 0x08049458 : xor %ecx,%ecx 0x0804945a : mov %eax,0xfffffab8(%ebp) 0x08049460 : mov %ecx,0xfffffac8(%ebp) 0x08049466 : mov %ecx,0xfffffad4(%ebp) 0x0804946c : mov %ecx,0xfffffae0(%ebp) 0x08049472 : lea 0x0(%esi),%esi 0x08049479 : lea 0x0(%edi),%edi 0x08049480 : mov 0xfffffae0(%ebp),%eax 0x08049486 : movsd 0xfffffad8(%ebp),%xmm0 0x0804948e : lea 0x1(%eax),%ecx 0x08049491 : addsd 0x80499b8,%xmm0 0x08049499 : mov %eax,0xfffffaec(%ebp) 0x0804949f : mov %ecx,0xfffffae0(%ebp) 0x080494a5 : mov 0x8(%ebp),%ecx 0x080494a8 : movsd %xmm0,0xfffffac0(%ebp) 0x080494b0 : cmpl $0xffffffff,(%ecx,%eax,4) 0x080494b4 : je 0x804957c 0x080494ba : mov 0xfffffad4(%ebp),%ecx 0x080494c0 : mov 0x8(%ebp),%eax 0x080494c3 : cmpl $0x1869f,0xfffffae0(%ebp) 0x080494cd : movw $0x1,0x61aa8(%eax,%ecx,1) 0x080494d7 : jg 0x804957c 0x080494dd : mov 0xfffffac8(%ebp),%eax ---Type to continue, or q to quit--- 0x080494e3 : mov 0x8(%ebp),%ecx 0x080494e6 : mov 0xfffffad4(%ebp),%esi 0x080494ec : mov 0xfffffabc(%ebp),%edi 0x080494f2 : mov 0xfffffab8(%ebp),%ebx 0x080494f8 : lea (%ecx,%eax,1),%edx 0x080494fb : lea (%ecx,%esi,1),%ecx 0x080494fe : lea (%edi,%esi,1),%edi 0x08049501 : lea (%ebx,%eax,1),%ebx 0x08049504 : mov 0xfffffad0(%ebp),%esi 0x0804950a : mov %edx,0xfffffae8(%ebp) 0x08049510 : mov %ecx,0xfffffae4(%ebp) 0x08049516 : lea 0x0(%esi),%esi 0x08049519 : lea 0x0(%edi),%edi 0x08049520 : cmpl $0xffffffff,(%ebx) 0x08049523 : jne 0x8049530 0x08049525 : add $0x4,%ebx 0x08049528 : add $0x2c,%edi 0x0804952b : dec %esi 0x0804952c : jne 0x8049520 0x0804952e : jmp 0x804957c 0x08049530 : mov 0xfffffae8(%ebp),%ecx 0x08049536 : mov %ebx,0x4(%esp) 0x0804953a : mov %ecx,(%esp) 0x0804953d : call 0x8048f50 0x08049542 : mov 0xfffffaec(%ebp),%ecx 0x08049548 : mov 0x8(%ebp),%eax 0x0804954b : mov (%eax,%ecx,4),%eax 0x0804954e : mov 0xfffffae4(%ebp),%ecx 0x08049554 : shr $0x13,%eax 0x08049557 : and $0x1fe,%eax 0x0804955c : movswl 0xfffffaf2(%ebp,%eax,1),%eax 0x08049564 : mov 0x61a80(%ecx,%eax,2),%dx 0x0804956c : inc %dx 0x0804956e : mov %dx,0x61a80(%ecx,%eax,2) 0x08049576 : incw (%edi,%eax,2) 0x0804957a : jmp 0x8049525 0x0804957c : mov 0xfffffaec(%ebp),%ecx 0x08049582 : mov $0x51eb851f,%edx 0x08049587 : mov %ecx,%eax ---Type to continue, or q to quit--- 0x08049589 : imul %edx 0x0804958b : mov %edx,%eax 0x0804958d : sar $0x5,%edx 0x08049590 : shr $0x1f,%eax 0x08049593 : add %eax,%edx 0x08049595 : imul $0x64,%edx,%eax 0x08049598 : sub %eax,%ecx 0x0804959a : jne 0x80495f7 0x0804959c : movsd 0x80499c0,%xmm0 0x080495a4 : cvtsi2sd 0xfffffacc(%ebp),%xmm1 0x080495ac : subsd 0xfffffad8(%ebp),%xmm0 0x080495b4 : mulsd %xmm0,%xmm1 0x080495b8 : movsd 0x80499d0,%xmm0 0x080495c0 : divsd 0x80499c8,%xmm1 0x080495c8 : addsd %xmm0,%xmm1 0x080495cc : divsd %xmm0,%xmm1 0x080495d0 : mulsd 0x80499d8,%xmm1 0x080495d8 : movsd %xmm1,0x4(%esp) 0x080495de : movl $0x8049b40,(%esp) 0x080495e5 : call 0x8048540 <_init+68> 0x080495ea : mov 0x804ae10,%eax 0x080495ef : mov %eax,(%esp) 0x080495f2 : call 0x80485a0 <_init+164> 0x080495f7 : movsd 0xfffffac0(%ebp),%xmm0 0x080495ff : decl 0xfffffacc(%ebp) 0x08049605 : addl $0x2c,0xfffffad4(%ebp) 0x0804960c : addl $0x4,0xfffffac8(%ebp) 0x08049613 : decl 0xfffffad0(%ebp) 0x08049619 : cmpl $0x186a0,0xfffffae0(%ebp) 0x08049623 : movsd %xmm0,0xfffffad8(%ebp) 0x0804962b : jne 0x8049480 0x08049631 : movl $0x8049c83,(%esp) 0x08049638 : call 0x8048600 <_init+260> 0x0804963d : movl $0x186a0,0xfffffae8(%ebp) 0x08049647 : xor %ecx,%ecx 0x08049649 : mov $0xffbcdc80,%eax 0x0804964e : mov %ecx,0xfffffae4(%ebp) 0x08049654 : lea 0x0(%esi),%esi 0x0804965a : lea 0x0(%edi),%edi ---Type to continue, or q to quit--- 0x08049660 : mov 0x8(%ebp),%edx 0x08049663 : cmpl $0xffffffff,(%edx,%ecx,2) 0x08049667 : je 0x80496c8 0x08049669 : mov 0x8(%ebp),%edx 0x0804966c : xor %esi,%esi 0x0804966e : mov %esi,%edi 0x08049670 : lea (%edx,%eax,1),%edx 0x08049673 : lea 0x0(%esi),%esi 0x08049679 : lea 0x0(%edi),%edi 0x08049680 : movzwl 0x493e00(%edx,%edi,2),%ebx 0x08049688 : cmp %ebx,%esi 0x0804968a : cmovle %ebx,%esi 0x0804968d : inc %edi 0x0804968e : cmp $0x15,%edi 0x08049691 : jne 0x8049680 0x08049693 : mov 0xfffffae8(%ebp),%edx 0x08049699 : cmp %edx,%esi 0x0804969b : sete %bl 0x0804969e : cmp %edx,%esi 0x080496a0 : mov 0x8(%ebp),%edx 0x080496a3 : mov %si,0x493e2a(%edx,%eax,1) 0x080496ab : jl 0x80496b8 0x080496ad : movzbl %bl,%esi 0x080496b0 : add %esi,0xfffffae4(%ebp) 0x080496b6 : jmp 0x80496c8 0x080496b8 : movl $0x0,0xfffffae4(%ebp) 0x080496c2 : mov %esi,0xfffffae8(%ebp) 0x080496c8 : add $0x2,%ecx 0x080496cb : add $0x2c,%eax 0x080496ce : jne 0x8049660 0x080496d0 : cmpl $0x0,0xfffffae4(%ebp) 0x080496d7 : jne 0x80496e5 0x080496d9 : movl $0x0,0xfffffaec(%ebp) 0x080496e3 : jmp 0x8049710 0x080496e5 : mov 0xfffffae4(%ebp),%esi 0x080496eb : call 0x8048570 <_init+116> 0x080496f0 : cltd 0x080496f1 : inc %esi 0x080496f2 : idiv %esi ---Type to continue, or q to quit--- 0x080496f4 : movl $0x0,0xfffffaec(%ebp) 0x080496fe : mov %edx,0xfffffae4(%ebp) 0x08049704 : lea 0x0(%esi),%esi 0x0804970a : lea 0x0(%edi),%edi 0x08049710 : mov 0xfffffaec(%ebp),%ecx 0x08049716 : mov 0x8(%ebp),%eax 0x08049719 : mov (%eax,%ecx,4),%eax 0x0804971c : cmp $0xffffffff,%eax 0x0804971f : je 0x80497e6 0x08049725 : mov 0x8(%ebp),%edx 0x08049728 : imul $0x2c,%ecx,%ecx 0x0804972b : movzwl 0x61aaa(%edx,%ecx,1),%ecx 0x08049733 : cmp 0xfffffae8(%ebp),%ecx 0x08049739 : jne 0x80497e6 0x0804973f : cmpl $0x0,0xfffffae4(%ebp) 0x08049746 : jne 0x80497e0 0x0804974c : mov 0xc(%ebp),%ecx 0x0804974f : mov %eax,(%ecx) 0x08049751 : xor %ecx,%ecx 0x08049753 : lea 0x0(%esi),%esi 0x08049759 : lea 0x0(%edi),%edi 0x08049760 : imul $0x2c,0xfffffaec(%ebp),%edx 0x08049767 : add 0x8(%ebp),%edx 0x0804976a : movzwl 0x61a80(%edx,%ecx,2),%edx 0x08049772 : cmp 0xfffffae8(%ebp),%edx 0x08049778 : jne 0x80497d0 0x0804977a : xor %edx,%edx 0x0804977c : lea 0x0(%esi),%esi 0x08049780 : mov $0x5,%esi 0x08049785 : sub %edx,%esi 0x08049787 : js 0x80497c5 0x08049789 : xor %esi,%esi 0x0804978b : nop 0x0804978c : lea 0x0(%esi),%esi 0x08049790 : mov %edx,%edi 0x08049792 : shl $0x4,%edi 0x08049795 : add %esi,%edi 0x08049797 : movswl 0xfffffaf2(%ebp,%edi,2),%ebx 0x0804979f : cmp %ecx,%ebx ---Type to continue, or q to quit--- 0x080497a1 : jne 0x80497b9 0x080497a3 : mov 0xc(%ebp),%edx 0x080497a6 : shl $0x14,%edi 0x080497a9 : and $0xf00fffff,%eax 0x080497ae : or %edi,%eax 0x080497b0 : mov %eax,(%edx) 0x080497b2 : mov $0x5,%edx 0x080497b7 : mov %edx,%esi 0x080497b9 : mov $0x5,%edi 0x080497be : inc %esi 0x080497bf : sub %edx,%edi 0x080497c1 : cmp %edi,%esi 0x080497c5 : inc %edx 0x080497c6 : cmp $0x6,%edx 0x080497c9 : jl 0x8049780 0x080497cb : mov $0x15,%ecx 0x080497d0 : inc %ecx 0x080497d1 : cmp $0x15,%ecx 0x080497d4 : jl 0x8049760 0x080497d6 : movl $0x186a0,0xfffffaec(%ebp) 0x080497e0 : decl 0xfffffae4(%ebp) 0x080497e6 : mov 0xfffffaec(%ebp),%eax 0x080497ec : inc %eax 0x080497ed : mov %eax,0xfffffaec(%ebp) 0x080497f3 : cmp $0x186a0,%eax 0x080497f8 : jl 0x8049710 0x080497fe : add $0x54c,%esp 0x08049804 : pop %esi 0x08049805 : pop %edi 0x08049806 : pop %ebx 0x08049807 : pop %ebp 0x08049808 : ret 0x08049809 : lea 0x0(%esi),%esi End of assembler dump. I used gdb to trace it down to this movsd: 0x0804942d : movl $0x1869f,0xfffffad0(%ebp) 0x08049437 : movl $0x186a0,0xfffffacc(%ebp) 0x08049441 : movsd %xmm0,0xfffffad8(%ebp) 0x08049449 : lea 0x61aac(%eax),%ecx 0x0804944f : lea 0x4(%eax),%eax (gdb) b *0x08049429 Breakpoint 4 at 0x8049429 (gdb) continue Continuing. Breakpoint 4, 0x08049429 in NextGuess () (gdb) stepi 0x0804942d in NextGuess () (gdb) stepi 0x08049437 in NextGuess () (gdb) stepi 0x08049441 in NextGuess () (gdb) stepi Program received signal SIGILL, Illegal instruction. 0x08049441 in NextGuess () -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 05:44:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 05:44:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 7254] New: unrecognized instruction lock Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7254 Summary: unrecognized instruction lock Product: new-bugs Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: niels.pfeffer at googlemail.com CC: llvmbugs at cs.uiuc.edu When trying to compile: static inline void inc(int64_t* atomic) { __asm__ __volatile__ ( "lock incq %0\n" : "=m" (*atomic) : "m" (*atomic) ); } I get: :1:2: error: unrecognized instruction lock incq (%rax) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 09:46:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 09:46:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 7255] New: ADL failing for a template's base. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7255 Summary: ADL failing for a template's base. Product: clang Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dnljms at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In the attached example clang fails to find 'operator>>' by ADL. It looks like something isn't instantiated correctly, as either of the commented out lines fix the problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 12:23:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 12:23:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7256] New: clang++ should provide a fix-it hint for incorrect destructor declarations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7256 Summary: clang++ should provide a fix-it hint for incorrect destructor declarations Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: andersca at mac.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Such as: struct Foo { ~Fo() { }; }; or even struct Foo { ~Bar(); }; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat May 29 20:49:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 May 2010 20:49:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7257] New: clang c++ crash with invalid member function pointer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7257 Summary: clang c++ crash with invalid member function pointer Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Testcase: struct fake_tuple; void (connection::*f)(fake_tuple); Crashes with: clang: Decl.cpp:1053: void clang::FunctionDecl::setParams(clang::ParmVarDecl**, unsigned int): Assertion `NumParams == getNumParams() && "Parameter count mismatch!"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 01:04:07 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 01:04:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 7040] Assertion on reduced boost testcase In-Reply-To: References: Message-ID: <20100530060407.A240C3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7040 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #4 from Eli Friedman 2010-05-30 01:04:06 CDT --- Fixed in r105151. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 05:09:18 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 05:09:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 7258] New: Bogus throw specification error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7258 Summary: Bogus throw specification error Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: luc_j_bourhis at mac.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com ~> clang++ --version clang version 2.0 (trunk 105014) Target: x86_64-apple-darwin10 Thread model: posix ~> cat throw_specs_ok.cpp struct A { virtual ~A() throw() { } }; struct B : A {}; ~> clang++ -c throw_specs_ok.cpp && echo "fine" fine ~> cat throw_specs_fail.cpp template struct A { virtual ~A() throw() { } }; struct B : A {}; ~> clang++ -c throw_specs_fail.cpp throw_specs.cpp:7:8: error: exception specification of overriding function is more lax than base version struct B : A ^ throw_specs.cpp:4:11: note: overridden virtual function is here virtual ~A() throw() { } ^ 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 Sun May 30 05:17:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 05:17:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 7259] New: Derivative class with parent class as template parameter cannot inherit constructor from any class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7259 Summary: Derivative class with parent class as template parameter cannot inherit constructor from any class Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: christian.bugs.2010.05 at juner.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4948) --> (http://llvm.org/bugs/attachment.cgi?id=4948) The source code that fails to compile The file compiles fine with g++ (4.4.3) but does not with clang. I don't know what the C++ standard demands, but given clang tries to be compatible with g++ I think this is an appropriate bug. $ clang clangtest.cpp clangtest.cpp:9:14: error: type 'class Base' is not a direct or virtual base of 'Derived' Derived() : Base() {} ^~~~ 1 diagnostic generated. $ clang --version clang version 1.1 (branches/release_27) Target: x86_64-pc-linux-gnu Thread model: posix The same still happens with clang trunk. $ clang --version clang version 2.0 ($URL$ 1) Target: x86_64-unknown-linux-gnu Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 11:40:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 11:40:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 7260] New: Bogus(?) floating-point overflow Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7260 Summary: Bogus(?) floating-point overflow Product: libraries Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: luc_j_bourhis at mac.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4949) --> (http://llvm.org/bugs/attachment.cgi?id=4949) self-contained source code body to reproduce the problem. LLVM revision 105128 CLANG revision 105014 MacOS 10.6.3 XCode 3.2.2 MacPro 1st generation I attached a self-contained source code to reproduce the problem: (1) make (2) ./tst_eigen: that should result in a floating-point exception (3) ./tst_eigen mask_overflow: the program should enter an infinite loop That shows that a floating-point overflow happens, and it can only be in the function real_symmetric_eigen. The program runs normally if CXXFLAGS does not feature -O3. It also runs fine if g++ is used, even with -O3. The body of that function real_symmetric_eigen is truly a black-box which I have not studied. My motivation to report it is that this is a blocker to enable clang as a compiler for the project this code comes from, the Computational Crystallographic Toolbox (CCTBX). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 14:11:02 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 14:11:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 7262] New: SIGSEGV during compilation of protobuf Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7262 Summary: SIGSEGV during compilation of protobuf Product: clang Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nelchael at gentoo.org CC: llvmbugs at cs.uiuc.edu While compiling protobuf-2.3.0 (homepage: http://code.google.com/p/protobuf/, configured with "./configure CXX='clang++ -v'"): /bin/sh ../libtool --tag=CXX --mode=compile clang++ -v -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -DNDEBUG -MT extension_set.lo -MD -MP -MF .deps/extension_set.Tpo -c -o extension_set.lo `test -f 'google/protobuf/extension_set.cc' || echo './'`google/protobuf/extension_set.cc libtool: compile: clang++ -v -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -DNDEBUG -MT extension_set.lo -MD -MP -MF .deps/extension_set.Tpo -c google/protobuf/extension_set.cc clang version 1.1 (branches/release_27) Target: x86_64-pc-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -S -disable-free -main-file-name extension_set.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -g -resource-dir /usr/lib/clang/1.1 -dependency-file .deps/extension_set.Tpo -sys-header-deps -MP -MT extension_set.lo -DHAVE_CONFIG_H -DNDEBUG -I. -I.. -O2 -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fmessage-length 194 -pthread -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-4ZDueI.s -x c++ google/protobuf/extension_set.cc clang -cc1 version 1.1 based upon llvm 2.7 hosted on x86_64-pc-linux-gnu ignoring nonexistent directory "/usr/include/c++/4.4.3" ignoring nonexistent directory "/usr/include/c++/4.4.3/x86_64-pc-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.4.3/backward" ignoring nonexistent directory "/usr/include/c++/4.4.3" ignoring nonexistent directory "/usr/include/c++/4.4.3/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.4.3/backward" ignoring nonexistent directory "/usr/include/c++/4.4" ignoring nonexistent directory "/usr/include/c++/4.4/x86_64-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.4/backward" ignoring nonexistent directory "/usr/include/c++/4.4" ignoring nonexistent directory "/usr/include/c++/4.4/i486-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.4/backward" ignoring nonexistent directory "/usr/include/c++/4.1.3" ignoring nonexistent directory "/usr/include/c++/4.1.3/i486-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.1.3/backward" ignoring nonexistent directory "/usr/include/c++/4.3.3" ignoring nonexistent directory "/usr/include/c++/4.3.3/x86_64-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.3.3/backward" ignoring nonexistent directory "/usr/include/c++/4.4.1" ignoring nonexistent directory "/usr/include/c++/4.4.1/x86_64-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.4.1/backward" ignoring nonexistent directory "/usr/include/c++/4.1.2" ignoring nonexistent directory "/usr/include/c++/4.1.2/i386-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.1.2/backward" ignoring nonexistent directory "/usr/include/c++/4.3.0" ignoring nonexistent directory "/usr/include/c++/4.3.0/i386-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.3.0/backward" ignoring nonexistent directory "/usr/include/c++/4.3.2" ignoring nonexistent directory "/usr/include/c++/4.3.2/i386-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.3.2/backward" ignoring nonexistent directory "/usr/include/c++/4.3.2" ignoring nonexistent directory "/usr/include/c++/4.3.2/x86_64-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.3.2/backward" ignoring nonexistent directory "/usr/include/c++/4.4.1" ignoring nonexistent directory "/usr/include/c++/4.4.1/i586-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.4.1/backward" ignoring nonexistent directory "/usr/include/c++/4.4.2" ignoring nonexistent directory "/usr/include/c++/4.4.2/i686-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.4.2/backward" ignoring nonexistent directory "/usr/include/c++/4.4.3" ignoring nonexistent directory "/usr/include/c++/4.4.3/i686-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.4.3/backward" ignoring nonexistent directory "/usr/include/c++/4.3" ignoring nonexistent directory "/usr/include/c++/4.3/i586-suse-linux/" ignoring nonexistent directory "/usr/include/c++/4.3/backward" ignoring nonexistent directory "/usr/include/c++/4.3" ignoring nonexistent directory "/usr/include/c++/4.3/x86_64-suse-linux/" ignoring nonexistent directory "/usr/include/c++/4.3/backward" ignoring nonexistent directory "/usr/include/c++/4.4" ignoring nonexistent directory "/usr/include/c++/4.4/i586-suse-linux/" ignoring nonexistent directory "/usr/include/c++/4.4/backward" ignoring nonexistent directory "/usr/include/c++/4.4" ignoring nonexistent directory "/usr/include/c++/4.4/x86_64-suse-linux/" ignoring nonexistent directory "/usr/include/c++/4.4/backward" ignoring nonexistent directory "/usr/include/c++/4.3.1" ignoring nonexistent directory "/usr/include/c++/4.3.1/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.3.1/backward" ignoring nonexistent directory "/usr/include/c++/4.3.1" ignoring nonexistent directory "/usr/include/c++/4.3.1/x86_64-unknown-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.3.1/backward" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/backward" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/backward" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/backward" ignoring nonexistent directory "/usr/include/c++/4.3" ignoring nonexistent directory "/usr/include/c++/4.3/i486-pc-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.3/backward" ignoring nonexistent directory "/usr/include/c++/4.3" ignoring nonexistent directory "/usr/include/c++/4.3/i486-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.3/backward" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/backward" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/x86_64-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/backward" ignoring nonexistent directory "/usr/local/include" #include "..." search starts here: #include <...> search starts here: . .. /usr/lib/clang/1.1/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/x86_64-pc-linux-gnu /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/backward /usr/include End of search list. 0 clang 0x000000000116271f 1 clang 0x0000000001162f9c 2 libpthread.so.0 0x00002ab9cb34d150 3 clang 0x0000000000522e6e 4 clang 0x000000000051e35f 5 clang 0x000000000051e223 6 clang 0x000000000051e347 7 clang 0x000000000051ef11 8 clang 0x0000000000522814 9 clang 0x000000000050d8ae 10 clang 0x00000000005138ca 11 clang 0x0000000000513cfa 12 clang 0x000000000050c141 13 clang 0x0000000000419ab3 14 clang 0x0000000000761fa0 15 clang 0x0000000000761a8d 16 clang 0x00000000005fbfca 17 clang 0x000000000090b2c5 18 clang 0x00000000005f916b 19 clang 0x000000000041ef67 20 clang 0x0000000000412301 21 clang 0x0000000000414e03 main + 1699 22 libc.so.6 0x00002ab9cbf28bbd __libc_start_main + 253 23 clang 0x000000000040fee9 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -S -disable-free -main-file-name extension_set.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -g -resource-dir /usr/lib/clang/1.1 -dependency-file .deps/extension_set.Tpo -sys-header-deps -MP -MT extension_set.lo -DHAVE_CONFIG_H -DNDEBUG -I. -I.. -O2 -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fmessage-length 194 -pthread -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-4ZDueI.s -x c++ google/protobuf/extension_set.cc 1. parser at end of file 2. ./google/protobuf/stubs/map-util.h:62:1: instantiating function definition 'google::protobuf::FindOrNull' 3. ./google/protobuf/stubs/map-util.h:62:1: LLVM IR generation of declaration 'google::protobuf::FindOrNull' 4. ./google/protobuf/stubs/map-util.h:62:1: Mangling declaration 'google::protobuf::FindOrNull' clang: error: compiler command failed due to signal 11 (use -v to see invocation) make[2]: *** [extension_set.lo] Error 1 make[2]: Leaving directory `/home/nelchael/protobuf-2.3.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/nelchael/protobuf-2.3.0' make: *** [all] Error 2 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 15:01:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 15:01:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 7263] New: friend declaration confuses name lookup Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7263 Summary: friend declaration confuses name lookup Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com During building of the pango 1.28.0 port on FreeBSD, we encountered the following fragment of code that gave compile errors with clang, but not with gcc: ======================================== struct LookupSubTable { }; struct Extension { const LookupSubTable& get_subtable (void) const; }; struct ExtensionSubst : Extension { friend struct SubstLookupSubTable; inline const struct SubstLookupSubTable& get_subtable (void) const { return (*(reinterpret_cast((reinterpret_cast(&(Extension::get_subtable ()))) + 0))); } }; ======================================== which produces (with llvm/clang r105165): pangotest.cpp:11:38: error: unknown type name 'SubstLookupSubTable' return (*(reinterpret_cast((reinterpret_cast(&(Extension::get_subtable ()))) + 0))); ^ pangotest.cpp:11:12: error: reference to type 'struct SubstLookupSubTable const' could not bind to an lvalue of type 'char const' return (*(reinterpret_cast((reinterpret_cast(&(Extension::get_subtable ()))) + 0))); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The fragment can be further reduced to (thanks Benjamin): class Bar { friend class Foo; class Foo *test() { return (Foo *)0; } }; giving: friendtest1.cpp:3:31: error: use of undeclared identifier 'Foo' class Foo *test() { return (Foo *)0; } ^ Which compiles fine with gcc 4.2.1 (the FreeBSD default compiler), but also MS VC++ has no problems with it. This issue is similar to, but not exactly the same as bug 6759: the "friend class Foo" line is apparently NOT enough to fully declare class Foo, however the "class Foo *test()" function declaration should be. In fact, this fragment compiles fine: class Bar { class Foo *test() { return (Foo *)0; } }; so adding the "friend class Foo" really seems to change something in the name lookup. It gets even stranger when using a fully specified return type in the member function: class Bar { friend class Foo; class Foo *test() { return (class Foo *)0; } }; resulting in: friendtest2.cpp:3:30: error: cannot initialize return object of type 'class Foo *' with an rvalue of type 'class Foo *' class Foo *test() { return (class Foo *)0; } ^~~~~~~~~~~~~~ which is, though quite funny, a rather confusing error message. :) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 15:28:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 15:28:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 7264] New: [patch] implemented address-of-label feature in JIT Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7264 Summary: [patch] implemented address-of-label feature in JIT Product: libraries Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: enhancement Priority: P Component: Target-Independent JIT AssignedTo: unassignedbugs at nondot.org ReportedBy: yuri at tsoft.com CC: llvmbugs at cs.uiuc.edu This patch fixes this assert: JIT does not support address-of-label yet! It memorizes PC in the BasicBlock structure during the code generation phase. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 15:30:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 15:30:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 6538] Undeclared template names in base class lists cause parse explosions In-Reply-To: References: Message-ID: <20100530203008.8AAD83128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6538 Sean Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 18:00:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 18:00:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 7265] New: Pass 'Simplify well-known library calls' dies on sprintf of union member Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7265 Summary: Pass 'Simplify well-known library calls' dies on sprintf of union member Product: clang Version: trunk Platform: PC OS/Version: All 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 Code fragment reduced from the FreeBSD xkbevd 1.1.0 port (an X11 event daemon program): ======================================== typedef union { int xkb_type; char message[7]; } XkbEvent; void CopyEventArg(XkbEvent *ev) { char *sink; sprintf(sink,"%s",ev->message); } ======================================== results in messages about "Unknown type!", "UNREACHABLE executed", and an abort (ran this on Windows to get a nice stack dump): badsig.c(9) : warning: implicitly declaring C library function 'sprintf' with type 'int (char *, char const *, ...)' sprintf(sink,"%s",ev->message); ^ badsig.c(9) : note: please include the header or explicitly provide a declaration for 'sprintf' Unknown type! UNREACHABLE executed at .\ValueTypes.cpp:190! Stack dump: 0. Program arguments: D:/Home/Dim/Src/llvm/bin/Debug/clang.exe -cc1 -triple i686-pc-win32 -S -disable-free -main-file-name badsig.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -resource-dir D:/Home/Dim/Src/llvm/bin/lib/clang/2.0 -O2 -ferror-limit 19 -fmessage-length 0 -fms-extensions -fgnu-runtime -fdiagnostics-show-option -o D:/Tmp/cc-000000.s -x c badsig.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'badsig.c'. 4. Running pass 'Simplify well-known library calls' on function '@CopyEventArg' 1023C355 (0x0000000A 0xCCCCCCCC 0xCCCCCCCC 0xCCCCCCCC), _get_pgmptr()+0453 bytes(s) 102DEF1D (0x02CDD110 0x02CDD0F8 0x015CD4AA 0x02014BBC), abort()+0045 bytes(s) 0165AFF9 (0x02014BBC 0x02014BA8 0x000000BE 0x02CDD10C), llvm::llvm_unreachable_internal()+0137 bytes(s), d:\home\dim\src\llvm\lib\support\errorhandling.cpp, line 76+0008 byte(s) 015CD4AA (0x02CDD218 0x02E1F128 0x00000000 0x02CDD1F8), llvm::EVT::getEVT()+0106 bytes(s), d:\home\dim\src\llvm\lib\vmcore\valuetypes.cpp, line 191 015784F4 (0x02CDDE84 0x000000B7 0x02CDDEEC 0x00000003), llvm::Intrinsic::getName()+7892 bytes(s), d:\home\dim\src\llvm\lib\vmcore\function.cpp, line 352+0033 byte(s) 01580EC9 (0x02E03F38 0x000000B7 0x02CDDEEC 0x00000003), llvm::Intrinsic::getDeclaration()+0105 bytes(s), d:\home\dim\src\llvm\lib\vmcore\function.cpp, line 396+0051 byte(s) 01372184 (0x02E23DA0 0x02E237D0 0x02E79148 0x00000001), llvm::EmitMemCpy()+0100 bytes(s), d:\home\dim\src\llvm\lib\transforms\utils\buildlibcalls.cpp, line 116+0020 byte(s) 0127EBC6 (0x02E23F98 0x02E2A858 0x02CDE078 0x02CDE018), `anonymous namespace'::SPrintFOpt::CallOptimizer()+1430 bytes(s), d:\home\dim\src\llvm\lib\transforms\scalar\simplifylibcalls.cpp, line 1043+0046 byte(s) 0128069E (0x02E2A858 0x02E324C0 0x02CDE078 0x02CDE10C), `anonymous namespace'::LibCallOptimization::OptimizeCall()+0110 bytes(s), d:\home\dim\src\llvm\lib\transforms\scalar\simplifylibcalls.cpp, line 69+0032 byte(s) 01276EF4 (0x02E21FF0 0x4388D478 0x02CDE194 0x02CDE124), `anonymous namespace'::SimplifyLibCalls::runOnFunction()+0404 bytes(s), d:\home\dim\src\llvm\lib\transforms\scalar\simplifylibcalls.cpp, line 1336+0020 byte(s) 01481A4C (0x02E21FF0 0x4388D4C0 0x02CDE288 0x02CDE1BC), llvm::FPPassManager::runOnFunction()+0332 bytes(s), d:\home\dim\src\llvm\lib\vmcore\passmanager.cpp, line 1428+0023 byte(s) 01385EEB (0x02E36530 0x02CDE2DC 0x02E34240 0x02CDE277), `anonymous namespace'::CGPassManager::RunPassOnSCC()+0507 bytes(s), d:\home\dim\src\llvm\lib\analysis\ipa\callgraphsccpass.cpp, line 145+0016 byte(s) 01386DF2 (0x02CDE2DC 0x02E34240 0x02CDE2CB 0x4388D61C), `anonymous namespace'::CGPassManager::RunAllPassesOnSCC()+0610 bytes(s), d:\home\dim\src\llvm\lib\analysis\ipa\callgraphsccpass.cpp, line 399+0032 byte(s) 013870EC (0x02E03F38 0x4388D124 0x02CDE528 0x02CDE450), `anonymous namespace'::CGPassManager::runOnModule()+0380 bytes(s), d:\home\dim\src\llvm\lib\analysis\ipa\callgraphsccpass.cpp, line 454+0030 byte(s) 01481F6E (0x02E03F38 0x02CDE480 0x7EFDE000 0x00000000), llvm::MPPassManager::runOnModule()+0430 bytes(s), d:\home\dim\src\llvm\lib\vmcore\passmanager.cpp, line 1502+0023 byte(s) 01482524 (0x02E03F38 0x0030EE28 0x02CDE534 0x0044E66C), llvm::PassManagerImpl::run()+0164 bytes(s), d:\home\dim\src\llvm\lib\vmcore\passmanager.cpp, line 1583+0027 byte(s) 01482A4D (0x02E03F38 0x4388D054 0x02CDEE84 0x02CDE53C), llvm::PassManager::run()+0029 bytes(s), d:\home\dim\src\llvm\lib\vmcore\passmanager.cpp, line 1627 0044E66C (0x4388D00C 0x02CDE578 0x02E03E08 0xCCCCCCCC), `anonymous namespace'::BackendConsumer::EmitAssembly()+0604 bytes(s), d:\home\dim\src\llvm\tools\clang\lib\frontend\codegenaction.cpp, line 444 00450685 (0x02DFB570 0x4388DBF0 0x02CDEEFC 0x02CDEEAC), `anonymous namespace'::BackendConsumer::HandleTranslationUnit()+0197 bytes(s), d:\home\dim\src\llvm\tools\clang\lib\frontend\codegenaction.cpp, line 169 007674D8 (0x02DE7948 0x02E03BE8 0x02DFB570 0x00000000), clang::ParseAST()+0744 bytes(s), d:\home\dim\src\llvm\tools\clang\lib\sema\parseast.cpp, line 108+0019 byte(s) 00453C02 (0x4388DA68 0x02CDEF74 0x02CDEF10 0x02CDEEC0), clang::ASTFrontendAction::ExecuteAction()+0226 bytes(s), d:\home\dim\src\llvm\tools\clang\lib\frontend\frontendaction.cpp, line 224+0079 byte(s) 004538DA (0x4388DAE0 0x02CDF75C 0x02CDEF8C 0xCCCCCCCC), clang::FrontendAction::Execute()+0282 bytes(s), d:\home\dim\src\llvm\tools\clang\lib\frontend\frontendaction.cpp, line 150+0015 byte(s) 0042A243 (0x02DE5C78 0x4388C208 0x02CDFF5C 0x00000000), clang::CompilerInstance::ExecuteAction()+0755 bytes(s), d:\home\dim\src\llvm\tools\clang\lib\frontend\compilerinstance.cpp, line 514 0040E944 (0x003060F0 0x00306154 0x00306158 0x004017C1), cc1_main()+2004 bytes(s), d:\home\dim\src\llvm\tools\clang\tools\driver\cc1_main.cpp, line 286+0027 byte(s) 0040321D (0x0000001B 0x003060E8 0x003038C0 0x4388CAD8), main()+0253 bytes(s), d:\home\dim\src\llvm\tools\clang\tools\driver\driver.cpp, line 186+0033 byte(s) 016B1488 (0x02CDFFF0 0x7D4E7D42 0x00000000 0x00000000), __tmainCRTStartup()+0424 bytes(s), f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 586+0025 byte(s) 016B12CF (0x00000000 0x00000000 0x7EFDE000 0x80000003), mainCRTStartup()+0015 bytes(s), f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 403 7D4E7D42 (0x016B12C0 0x00000000 0x000000C8 0x0000017A), BaseProcessInitPostImport()+0141 bytes(s) clang: error: clang frontend command failed due to signal 2147483645 (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 Sun May 30 19:27:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 19:27:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 6431] incorrect significand bits in __builtin_nan In-Reply-To: References: Message-ID: <20100531002721.174163128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6431 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2010-05-30 19:27:20 CDT --- This was fixed in r97383. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 19:55:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 19:55:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 7266] New: Failure to build GMP (5.0.1) without "-no-integrated-as" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7266 Summary: Failure to build GMP (5.0.1) without "-no-integrated-as" Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jens.nockert at gmail.com CC: llvmbugs at cs.uiuc.edu Trying to build GMP without "-no-integrated-as" fails to build with clang revision 105168. /var/folders/fv/fvwDV1MSEYO12oQJ9NbSek+++TI/-Tmp-/cc-jmnuES.s:14:2: warning: ignoring directive for now .size ___gmpn_add_nc,.-___gmpn_add_nc ^ /var/folders/fv/fvwDV1MSEYO12oQJ9NbSek+++TI/-Tmp-/cc-jmnuES.s:82:2: error: unrecognized instruction jrcxz Lend ^ /var/folders/fv/fvwDV1MSEYO12oQJ9NbSek+++TI/-Tmp-/cc-jmnuES.s:86:2: warning: ignoring directive for now .size ___gmpn_add_n,.-___gmpn_add_n ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun May 30 20:25:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 May 2010 20:25:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7218] Assigning to buf[0] makes buf[1] valid In-Reply-To: References: Message-ID: <20100531012501.2A00A3128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7218 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |kremenek at apple.com Resolution| |FIXED --- Comment #3 from Ted Kremenek 2010-05-30 20:25:00 CDT --- I've checked in a different fix here: http://llvm.org/viewvc/llvm-project?view=rev&revision=105195 Please review. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 31 01:16:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 May 2010 01:16:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 7265] Pass 'Simplify well-known library calls' dies on sprintf of union member In-Reply-To: References: Message-ID: <20100531061649.DC9F13128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7265 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nicholas at mxc.ca Resolution| |FIXED --- Comment #2 from Nick Lewycky 2010-05-31 01:16:49 CDT --- Fixed in r105206. Thanks for the excellent reduction! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 31 05:18:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 May 2010 05:18:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 7267] New: Using private types should be allowed as template parametter for explicit instantiation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7267 Summary: Using private types should be allowed as template parametter for explicit instantiation Product: clang Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ogoffart at kde.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com class Foo { class Bar1 {}; class Bar2{}; }; template struct Test {}; template struct Test; //#1 explicit instantiation template<> struct Test {}; //#2 template specialization /* test.cpp:4:27: error: 'Bar1' is a private member of 'Foo' template struct Test; //#1 explicit instantiation ^ test.cpp:5:29: error: 'Bar2' is a private member of 'Foo' template<> struct Test {}; //#2 template specialization ^ */ GCC compiles this code fine. According to the standard: 14.7.2 [temp.explicit] ?8: "The usual access checking rules do not apply to names used to specify explicit instantiations. [Note: In particular, the template arguments and names used in the function declarator (including parameter types, return types and exception specifications) may be private types or objects which would normally not be accessible and the template may be a member template or member function which would not normally be accessible.]" This seems to cover case #1. I'm mostly interested in case #2, which cause compilation failure in Qt (Linguist) even if I have not found an explicit say that this should be allowed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 31 06:35:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 May 2010 06:35:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 7268] New: Convoluted code-generation bug leading to segfault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7268 Summary: Convoluted code-generation bug leading to segfault Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Keywords: miscompilation Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jbytheway+llvm at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=4953) --> (http://llvm.org/bugs/attachment.cgi?id=4953) Source and makefile to reproduce the bug This bug is rather involved. The crux of the matter seems to be a segfault that happens at runtime in the atomic operations used to support boost::shared_ptr. However, in order to make the bug manifest I need a fair bit of quite random-seeming other code around it. I don't know whether this is a clang or llvm issue at heart, but I encountered it through clang, so I'm filing it there. I'm running Gentoo GNU/Linux on amd64. The code uses both standard library and Boost headers. I'm using the gcc 4.4.3 standard library, and Boost 1.42 (headers suffice; the Boost libraries are not necessary, and I doubt the particular code in use has changed significantly in recent Boost versions). If preprocessed source code would be more useful I can certainly provide that. I'm using llvm and clang trunk, revision 105219. I attach a tarball that demonstrates the bug. I did my best to cut it down to a minimal example, but it's still quite messy. Here's the behaviour I see: $ make test clang -O3 -c -o main.o main.cpp clang -O3 -c -o other.o other.cpp clang -o exe main.o other.o -lstdc++ ./exe make: *** [test] Segmentation fault The code doesn't do anything except copy objects around, but of course in the case of shared_ptrs that's non-trivial. Note in particular, all of the following are necessary to make the bug manifest: - The two source files must be compiled to objects separately and then linked, not compiled directly together into an executable. - Optimization must be turned on (level 2 or above suffices). - Many seemingly-irrelevant details of the various structs defined in other.hpp. If I run it in gdb then I get: Program received signal SIGSEGV, Segmentation fault. 0x0000000000400b84 in CF::~CF() () and the instruction at that address is: 0x0000000000400b84 <_ZN2CFD2Ev+36>: lock xadd %eax,0x8(%r14) which I believe is an atomic operation of some kind, and presume must be out of boost::shared_ptr somewhere. Let me know if I can provide any more useful information. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 31 09:02:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 May 2010 09:02:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 7269] New: -Wno-main is not supported Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7269 Summary: -Wno-main is not supported Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: amine.khaldi at reactos.org CC: llvmbugs at cs.uiuc.edu Pretty self-explanatory, -Wno-main isn't supported in clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 31 10:39:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 May 2010 10:39:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 7270] New: DSE wrongly eliminates store, related to byval Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7270 Summary: DSE wrongly eliminates store, related to byval Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4955) --> (http://llvm.org/bugs/attachment.cgi?id=4955) testcase .ll This miscompilation occurs when building LLVM with dragonegg on x86-32. Before running dse, the incoming parameters %arg1 and %arg2 are copied to the locals %CS1 and %CS2, and then %CS1 and %CS2 are passed as the call parameters to _ZN4llvm13AliasAnalysis13getModRefInfoENS_8CallSiteES1_. After running "opt -dse", the copies are no longer made, and the uninitialized values of %CS1 and %CS2 are passed instead. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 31 11:07:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 May 2010 11:07:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 7270] DSE wrongly eliminates store, related to byval In-Reply-To: References: Message-ID: <20100531160755.0D16A3128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7270 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Duncan Sands 2010-05-31 11:07:54 CDT --- The real problem is elsewhere: how this call manages to be marked "tail call" even though it uses some allocas. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 31 12:30:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 May 2010 12:30:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 6623] clang/llvm expands memcpy thus making the resulting code big In-Reply-To: References: Message-ID: <20100531173042.B1CE43128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6623 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |clattner at apple.com Resolution| |FIXED --- Comment #9 from Chris Lattner 2010-05-31 12:30:42 CDT --- Fixed in r105228, please verify. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 31 13:12:18 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 May 2010 13:12:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 7272] New: Bad interaction between byval, -tailcallelim, -inline and -dse Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7272 Summary: Bad interaction between byval, -tailcallelim, -inline and -dse Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Consider the following testcase (note the byval on @bar's parameter): target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" declare void @ext(i32*) define void @bar(i32* byval %x) { call void @ext(i32* %x) ret void } define void @foo(i32* %x) { call void @bar(i32* byval %x) ret void } Running it through "opt -tailcallelim", marks the @bar call as being a tail call: define void @foo(i32* %x) { tail call void @bar(i32* byval %x) ret void } Now run it through "opt -inline -instcombine" (instcombine to clean up a bit): define void @foo(i32* %x) { %x1 = alloca i32, align 4 ; [#uses=2] %1 = load i32* %x, align 1 ; [#uses=1] store i32 %1, i32* %x1 tail call void @ext(i32* %x1) ret void } Now apply "opt -dse": define void @foo(i32* %x) { %x1 = alloca i32, align 4 ; [#uses=1] tail call void @ext(i32* %x1) ret void } Note how an uninitialized variable is now passed in the call to @ext, while originally it was the a variable initialized to whatever value %x points to. This is the cause of a miscompilation of LLVM by dragonegg on x86-32. Personally I think the right thing to do is to not have tailcallelim mark calls as tail calls if they have a byval parameter. That's because byval is equivalent to declaring a stack variable and doing a copy, so amounts to the use of caller's stack (you could argue that logically the copy could be considered to be done in the callees stack; in that case the call to @ext in @bar should not have been marked tail call). However another possibility is to have the inliner clear tail call flags when there is a byval parameter. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon May 31 13:41:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 May 2010 13:41:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 7273] New: error in sse code with _mm_set1_ps Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7273 Summary: error in sse code with _mm_set1_ps Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: scoopr at iki.fi CC: llvmbugs at cs.uiuc.edu Created an attachment (id=4956) --> (http://llvm.org/bugs/attachment.cgi?id=4956) testcase Attached testcase fails in codegen. For reference, this is reduced from Bullet Physics src/BulletDynamics/ConstraintSolver/btSequentialImpulseConstraintSolver.cpp Actually, just __m128 v; __mm_set1_ps(v); Triggers the codegen failure, I don't know if that should even go as far as codegen, I see _mm_set1_ps defined as taking a float argument. But the test-case relies on implicit cast operator to float, and I'm guessing it is choosing the wrong cast. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.