From bugzilla-daemon at llvm.org Fri Jul 1 01:24:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 01:24:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10205] clang++ aborts while compiling In-Reply-To: References: Message-ID: <20110701062401.01B2E2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10205 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from John McCall 2011-07-01 01:24:00 CDT --- Should be fixed in r134227. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 1 02:44:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 02:44:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10237] New: Segfault when dereferencing a forward-declared struct Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10237 Summary: Segfault when dereferencing a forward-declared struct Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: max at duempel.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following snippet makes clang++ svn r134234 crash: struct X crash() { if (X[i]){} } Error message: crash.cpp:1:10: error: incomplete result type 'struct X' in function definition struct X crash() { ^ crash.cpp:1:8: note: forward declaration of 'X' struct X crash() { ^ crash.cpp:2:10: error: expected unqualified-id if (X[i]) {} ^ crash.cpp:2:11: error: use of undeclared identifier 'i' if (X[i]) {} ^ 0 clang 0x00000000018f8d7f 1 clang 0x00000000018f91e9 2 libpthread.so.0 0x00007f6d0f8a0020 3 clang 0x00000000009ab113 clang::Sema::ActOnCXXConditionDeclaration(clang::Scope*, clang::Declarator&) + 19 4 clang 0x00000000008d8182 clang::Parser::ParseCXXCondition(clang::ActionResult&, clang::Decl*&, clang::SourceLocation, bool) + 1058 5 clang 0x0000000000891946 clang::Parser::ParseParenExprOrCondition(clang::ActionResult&, clang::Decl*&, clang::SourceLocation, bool) + 198 6 clang 0x000000000089ac5f clang::Parser::ParseIfStatement(clang::ParsedAttributes&) + 447 7 clang 0x000000000089722d clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 2413 8 clang 0x0000000000894653 clang::Parser::ParseCompoundStatementBody(bool) + 1587 9 clang 0x0000000000894daa clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 138 10 clang 0x00000000008ad3e4 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1044 11 clang 0x00000000008b8dea clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 746 12 clang 0x00000000008a8831 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 145 13 clang 0x00000000008a8db3 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 531 14 clang 0x00000000008ab330 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2752 15 clang 0x00000000008ab864 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 164 16 clang 0x000000000088542d clang::ParseAST(clang::Sema&, bool) + 253 17 clang 0x000000000075e1f3 clang::CodeGenAction::ExecuteAction() + 51 18 clang 0x0000000000673623 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 307 19 clang 0x0000000000653269 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1001 20 clang 0x0000000000648a12 cc1_main(char const**, char const**, char const*, void*) + 706 21 clang 0x0000000000651bf6 main + 678 22 libc.so.6 0x00007f6d0eb85ead __libc_start_main + 253 23 clang 0x00000000006485e9 Stack dump: 0. Program arguments: /usr/local/stow/llvm/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name crash.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.52.20110606 -momit-leaf-frame-pointer -coverage-file crash.o -resource-dir /usr/local/stow/llvm/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 266 -fgnu-runtime -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o crash.o -x c++ crash.cpp 1. crash.cpp:2:13: current parser token ')' 2. crash.cpp:1:18: parsing function body 'crash' 3. crash.cpp:1:18: in compound statement ('{}') clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 1 07:33:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 07:33:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10238] New: False positive with class scope "static const" used with an object Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10238 Summary: False positive with class scope "static const" used with an object Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: geza at bitquad.com CC: llvmbugs at cs.uiuc.edu Hi, this little code gives me an "operand is a garbage value" warning: struct Array { static const int size = 4; }; bool fn(Array &a) { int s = a.size; return s>0; } If I remove the "int s = a.size" line, and change the end to "return a.size>0", I don't get a warning. Or, If I change a.size to Array::size, I don't get a warning 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 Fri Jul 1 07:33:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 07:33:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10239] New: False positive when object is initialized by a member function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10239 Summary: False positive when object is initialized by a member function Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: geza at bitquad.com CC: llvmbugs at cs.uiuc.edu Hi, this little code gives me an "operand is a garbage value" warning: struct Stream { void read(char &b); }; bool fn(Stream &s) { char z; s.read(z); return z==0; } If I remove the class "Stream", and use a global read function instead, I don't a warning. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 1 07:40:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 07:40:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10240] New: Shell scripts generated by llvm-ld load redundant libraries Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10240 Summary: Shell scripts generated by llvm-ld load redundant libraries Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: srk31 at srcf.ucam.org CC: llvmbugs at cs.uiuc.edu When linking in bitcode libraries using -l, llvm-ld still emits "-load=" arguments to lli to load native versions. These are redundant and should not be linked. To reproduce: take any shared library installed on your system, them recompile it as bitcode. Similarly, compile and link a client of that library using llvm, making sure the bitcode library is found first in the library search path (-L). In the output shell script, the native library will be loaded even though the linker linked in the bitcode version. Here's a tarball that demonstrates this with the command below, assuming you have native libssl and libz on your system. I'm doing this on a x86-64 FC13 system, with the 2.9 release of LLVM, compiled Release+Debug+Asserts. $ llvm-ld -v -lpthread -Lout/host/linux-x86/pr/sim/obj/lib/llvm -Lout/host/linux-x86/pr/sim/obj/lib/llvm -L\$ORIGIN/../lib/llvm -Lout/host/linux-x86/pr/sim/obj/lib/llvm out/host/linux-x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/Main.o.bc -l=dvm -l=ssl -l=z -o out/host/linux-x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/LINKED/dalvikvm.bc Adding library pthread to link items Adding library dvm to link items Adding library ssl to link items Adding library z to link items Linking archive file '/usr/lib64/libpthread.a' Linking bitcode file 'out/host/linux-x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/Main.o.bc' Linked in file 'out/host/linux-x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/Main.o.bc' Linking bitcode file 'out/host/linux-x86/pr/sim/obj/lib/llvm/libdvm.so' Linked in file 'out/host/linux-x86/pr/sim/obj/lib/llvm/libdvm.so' Linking bitcode file 'out/host/linux-x86/pr/sim/obj/lib/llvm/libssl.so' Linked in file 'out/host/linux-x86/pr/sim/obj/lib/llvm/libssl.so' Linking bitcode file 'out/host/linux-x86/pr/sim/obj/lib/llvm/libz.so' Linked in file 'out/host/linux-x86/pr/sim/obj/lib/llvm/libz.so' Linking archive file '/usr/lib64/libpthread.a' Generating Bitcode To out/host/linux-x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/LINKED/dalvikvm.bc.bc Emitting Shell Script $ cat out/host/linux-x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/LINKED/dalvikvm.bc #!/bin/sh lli=${LLVMINTERP-lli} exec $lli \ -load=/usr/lib64/libpthread.a \ -load=/usr/lib/libssl.so \ -load=/usr/lib/libz.so \ out/host/linux-x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/LINKED/dalvikvm.bc.bc ${1+"$@"} The second and third -load= lines should not be there. (Also, neither should the first, but that's a separate bug.) This seems to be because the shell script generation code assumes that if an -l request was satisfied by bitcode, then searching for native dynamic libraries will yield nothing, so we can do it anyway. But sometimes both bitcode and native versions can be found in the library path. Instead, if a bitcode library was linked in, it should skip the native equivalent. Here is a quick patch which does mostly the right thing. --- tools/llvm-ld/llvm-ld.cpp +++ tools/llvm-ld/llvm-ld.cpp.patched-1 2011-07-01 13:03:37.000000000 +0100 @@ -449,6 +449,8 @@ // on the command line, so that we don't have to do this manually! for (std::vector::iterator i = Libraries.begin(), e = Libraries.end(); i != e; ++i) { + // we might find a bitcode library; if so, it's already linked in + bool FoundBitcodeLibrary = false; // try explicit -L arguments first: sys::Path FullLibraryPath; for (cl::list::const_iterator P = LibPaths.begin(), @@ -457,16 +459,25 @@ FullLibraryPath.appendComponent("lib" + *i); FullLibraryPath.appendSuffix(sys::Path::GetDLLSuffix()); if (!FullLibraryPath.isEmpty()) { - if (!FullLibraryPath.isDynamicLibrary()) { + if (FullLibraryPath.isBitcodeFile()) { + FoundBitcodeLibrary = true; + break; + } + else if (!FullLibraryPath.isDynamicLibrary()) { // Not a native shared library; mark as invalid FullLibraryPath = sys::Path(); - } else break; + } + else break; } } - if (FullLibraryPath.isEmpty()) - FullLibraryPath = sys::Path::FindLibrary(*i); - if (!FullLibraryPath.isEmpty()) - Out2.os() << " -load=" << FullLibraryPath.str() << " \\\n"; + // only emit -load= lines for native *shared* libraries + if (!FoundBitcodeLibrary) + { + if (FullLibraryPath.isEmpty()) + FullLibraryPath = sys::Path::FindLibrary(*i); + if (!FullLibraryPath.isEmpty()) + Out2.os() << " -load=" << FullLibraryPath.str() << " \\\n"; + } } Out2.os() << " " << BitcodeOutputFilename << " ${1+\"$@\"}\n"; Out2.keep(); Here we're assuming that our walk of the library paths precisely replicates the Linker's, so that iff we found bitcode, so did the linker. A more robust solution would check with the linker what files were actually linked in, and then remove these from the list of Libraries to handle in the shell script. I'm also about to file a related bug triggered in the case where a call to sys::Path::FindLibrary discovers an archive and not a shared object (i.e. the first -load= in the shell script I showed). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 1 08:48:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 08:48:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 10241] New: Shell scripts generated by llvm-ld attempt to dynamically load archives Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10241 Summary: Shell scripts generated by llvm-ld attempt to dynamically load archives Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: srk31 at srcf.ucam.org CC: llvmbugs at cs.uiuc.edu When looking up a library name in sys::Path returns an archive, llvm-ld will happily generate a shell script containing a -load= argument to lli for that archive. This fails at run-time, because archives cannot be dynamically loaded. To reproduce: same as bug 10240 . In general, passing using -l to link any library will trigger the bug if that library's only appearance in the library search path is as an archive. I'm seeing this on an x86-64 FC13 machine, but guess it's an issue for any system that uses archives. The following quick fix seems to sort it out. The problem is that the FindLibrary call can return an archive, but this code only wants shared objects. --- tools/llvm-ld/llvm-ld.cpp +++ tools/llvm-ld/llvm-ld.cpp.patched-3 2011-07-01 14:35:47.000000000 +0100 @@ -465,7 +465,7 @@ } if (FullLibraryPath.isEmpty()) FullLibraryPath = sys::Path::FindLibrary(*i); - if (!FullLibraryPath.isEmpty()) + if (!FullLibraryPath.isEmpty() && FullLibraryPath.isDynamicLibrary()) Out2.os() << " -load=" << FullLibraryPath.str() << " \\\n"; } Out2.os() << " " << BitcodeOutputFilename << " ${1+\"$@\"}\n"; I'm not actually sure why the FindLibrary call is there, since the preceding chunk of code is all about locating the input libraries (and is careful to exclude non-shared-objects). But it might make sense if sys::Path includes some directories that aren't in LibPaths. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 1 10:22:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 10:22:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 8733] AV when reporting diagnostics in some code-completion results In-Reply-To: References: Message-ID: <20110701152245.937742A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8733 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-07-01 10:22:44 CDT --- This is fixed in top-of-tree Clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 1 13:10:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 13:10:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 8992] cout destruction prints garbage In-Reply-To: References: Message-ID: <20110701181010.4A3132A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8992 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #27 from Howard Hinnant 2011-07-01 13:10:07 CDT --- Committed revision 134155. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 1 13:56:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 13:56:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10242] New: Related result types for +class and -class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10242 Summary: Related result types for +class and -class Product: clang Version: unspecified Platform: All 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 The following program should be able to infer which +test method is being called, but Clang currently picks the first one arbitrarily. ////// @interface Base + (Class)class; - (Class)class; @end @interface X : Base + (float)test; @end @interface Y : Base + (char)test; @end int abc () { return [[Y class] test]; } int def (Y *y) { return [[y class] test]; } ////// (We could also extend this to +superclass while we're at 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 Jul 1 14:24:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 14:24:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 10191] compiling libcxx with clang In-Reply-To: References: Message-ID: <20110701192450.9F44A2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10191 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Howard Hinnant 2011-07-01 14:24:49 CDT --- Committed revision 134248. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 1 15:21:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 15:21:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10243] New: [C++] aborts during compilation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10243 Summary: [C++] aborts during compilation Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping at exherbo.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6808) --> (http://llvm.org/bugs/attachment.cgi?id=6808) xz-compressed output of -save-temps video/opengl.cpp from SLIMPlayer[1] fails to compile. pipping at bogus /home/pipping/debug % clang++ -x c++ -c opengl.ii.ok opengl.ii.ok:3:17: error: field has incomplete type 'exception_ptr' exception_ptr _M_ptr; ^ opengl.ii.ok:1:7: note: forward declaration of 'exception_ptr' class exception_ptr; ^ opengl.ii.ok:4:47: warning: defaulted function definition accepted as a C++0x extension [-Wc++0x-extensions] nested_exception(const nested_exception&) = default; ^ clang: SemaLookup.cpp:2151: Sema::SpecialMemberOverloadResult *clang::Sema::LookupSpecialMember(clang::CXXRecordDecl *, clang::Sema::CXXSpecialMember, bool, bool, bool, bool, bool): Assertion `(RD && !RD->isBeingDefined()) && "doing special member lookup into record that isn't fully complete"' failed. 0 libLLVM-3.0svn.so 0x00007fc4327ff78f 1 libLLVM-3.0svn.so 0x00007fc4327ffb81 2 libpthread.so.0 0x00007fc4317daff0 3 libc.so.6 0x00007fc430af8605 gsignal + 53 4 libc.so.6 0x00007fc430af9905 abort + 389 5 libc.so.6 0x00007fc430af1235 __assert_fail + 245 6 clang 0x0000000000dbf5f2 clang::Sema::LookupSpecialMember(clang::CXXRecordDecl*, clang::Sema::CXXSpecialMember, bool, bool, bool, bool, bool) + 2226 7 clang 0x0000000000dbf6f0 clang::Sema::LookupCopyingConstructor(clang::CXXRecordDecl*, unsigned int, bool*) + 64 8 clang 0x0000000000d3b552 clang::Sema::ComputeDefaultedCopyCtorExceptionSpecAndConst(clang::CXXRecordDecl*) + 578 9 clang 0x0000000000d39ff5 clang::Sema::CheckExplicitlyDefaultedCopyConstructor(clang::CXXConstructorDecl*) + 245 10 clang 0x0000000000d398d3 clang::Sema::CheckExplicitlyDefaultedMethods(clang::CXXRecordDecl*) + 323 11 clang 0x0000000000d38a4a clang::Sema::CheckCompletedCXXClass(clang::CXXRecordDecl*) + 1322 12 clang 0x0000000000d3cdbe clang::Sema::ActOnFinishCXXMemberSpecification(clang::Scope*, clang::SourceLocation, clang::Decl*, clang::SourceLocation, clang::SourceLocation, clang::AttributeList*) + 190 13 clang 0x0000000000ca1ed2 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 1442 14 clang 0x0000000000ca1545 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 4965 15 clang 0x0000000000c953f1 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 2225 16 clang 0x0000000000c8c3b9 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 57 17 clang 0x0000000000c8c5fd clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 61 18 clang 0x0000000000c8bf62 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1426 19 clang 0x0000000000c8b9a4 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 212 20 clang 0x0000000000c7505f clang::ParseAST(clang::Sema&, bool) + 303 21 clang 0x0000000000b734df clang::CodeGenAction::ExecuteAction() + 623 22 clang 0x0000000000a968b7 clang::FrontendAction::Execute() + 231 23 clang 0x0000000000a842ea clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 506 24 clang 0x0000000000a4fef0 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 640 25 clang 0x0000000000a460d7 cc1_main(char const**, char const**, char const*, void*) + 647 26 clang 0x0000000000a4c680 main + 368 27 libc.so.6 0x00007fc430ae4c7d __libc_start_main + 253 28 clang 0x0000000000a45d89 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name opengl.ii.ok -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21 -momit-leaf-frame-pointer -coverage-file opengl.ii.o -resource-dir /usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 118 -fgnu-runtime -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o opengl.ii.o -x c++ opengl.ii.ok 1. parser at end of file 2. opengl.ii.ok:2:1: parsing struct/union/class body 'nested_exception' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) pipping at bogus /home/pipping/debug % clang version 3.0, git-35ee32e800145a535f2676898f8f06f7ae6e9b43 [1] https://github.com/Themaister/SLIMPlayer -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 1 17:21:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 17:21:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10244] New: `!Traits::stopLess(b, a) && "Invalid interval"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10244 Summary: `!Traits::stopLess(b, a) && "Invalid interval"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6810) --> (http://llvm.org/bugs/attachment.cgi?id=6810) Preprocessed input Compiling the attached preprocessed input with "clang-O2" for AMD64 triggers 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 Fri Jul 1 17:25:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 17:25:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10245] New: libc++ misses cxxabi when it built by clang + libc++ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10245 Summary: libc++ misses cxxabi when it built by clang + libc++ Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu I was able to successfully build libc++ using CMake with options cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr \ -DCMAKE_C_COMPILER:STRING="/usr/bin/clang" \ -DCMAKE_CXX_COMPILER:STRING="/usr/bin/clang++" \ -DCMAKE_CXX_FLAGS:STRING="-stdlib=libc++" \ ../$_svnmod || return 1 i.e., utilizing C++ Standard Library from libc++ rather than libstdc++. Then, $ ldd -r /usr/lib/libc++.so linux-vdso.so.1 => (0x00007fffc51d8000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f7d7f666000) libc.so.6 => /lib/libc.so.6 (0x00007f7d7f305000) librt.so.1 => /lib/librt.so.1 (0x00007f7d7f0fc000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f7d7eee6000) /lib/ld-linux-x86-64.so.2 (0x00007f7d7fc07000) undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE (/usr/lib/libc++.so) undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE (/usr/lib/libc++.so) undefined symbol: __cxa_pure_virtual (/usr/lib/libc++.so) undefined symbol: _ZTVN10__cxxabiv121__vmi_class_type_infoE (/usr/lib/libc++.so) undefined symbol: __gxx_personality_v0 (/usr/lib/libc++.so) undefined symbol: __cxa_free_exception (/usr/lib/libc++.so) undefined symbol: __cxa_begin_catch (/usr/lib/libc++.so) undefined symbol: __cxa_guard_release (/usr/lib/libc++.so) undefined symbol: __cxa_call_unexpected (/usr/lib/libc++.so) undefined symbol: __cxa_allocate_exception (/usr/lib/libc++.so) undefined symbol: __cxa_throw (/usr/lib/libc++.so) undefined symbol: __cxa_guard_abort (/usr/lib/libc++.so) undefined symbol: __cxa_end_catch (/usr/lib/libc++.so) undefined symbol: __cxa_guard_acquire (/usr/lib/libc++.so) undefined symbol: __cxa_rethrow (/usr/lib/libc++.so) I see libcxxabi in llvm subproject, but I'm not sure how we integrate it into libcxx... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 1 17:31:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 17:31:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 10245] libc++ misses cxxabi when it built by clang + libc++ In-Reply-To: References: Message-ID: <20110701223114.425A72A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10245 Sean Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |scshunt at csclub.uwaterloo.ca Resolution| |INVALID --- Comment #1 from Sean Hunt 2011-07-01 17:31:13 CDT --- This is intentional; libc++ does not include low-level ABI features. libc++abi or libsupc++ (GCC's version of the same) must be compiled separately and linked in to any program that uses libc++. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 1 19:42:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 19:42:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10246] New: Adding new gcc version in ToolChains Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10246 Summary: Adding new gcc version in ToolChains Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu GCC version on ArchLinux is bumped up to 4.6.1. The following patch suffices to keep it compatible. Index: lib/Driver/ToolChains.cpp =================================================================== --- lib/Driver/ToolChains.cpp (revision 134295) +++ lib/Driver/ToolChains.cpp (working copy) @@ -1462,7 +1462,7 @@ ret.append(Version); return ret; } - static const char* GccVersions[] = {"4.6.0", "4.6", + static const char* GccVersions[] = {"4.6.1", "4.6.0", "4.6", "4.5.2", "4.5.1", "4.5", "4.4.5", "4.4.4", "4.4.3", "4.4", "4.3.4", "4.3.3", "4.3.2", "4.3", -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 1 19:51:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 1 Jul 2011 19:51:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10246] Adding new gcc version in ToolChains In-Reply-To: References: Message-ID: <20110702005159.2E6812A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10246 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |chandlerc at gmail.com Resolution| |FIXED --- Comment #1 from Chandler Carruth 2011-07-01 19:51:58 CDT --- Should be fixed in r134299. I also added the 4.6.1 version to the Arch include file search: // Arch Linux gcc 4.6 + AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.6.1", + "i686-pc-linux-gnu", "", "", triple); + AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.6.1", + "x86_64-unknown-linux-gnu", "", "", triple); AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.6.0", "i686-pc-linux-gnu", "", "", triple); AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.6.0", Please let me know if that works, or breaks anything for you. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 2 08:19:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 08:19:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10200] dragonegg svn on FSF gcc 4.6.1 produces unresolved symbols In-Reply-To: References: Message-ID: <20110702131900.593CE2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10200 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Duncan Sands 2011-07-02 08:18:59 CDT --- Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110627/123358.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 2 09:13:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 09:13:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 10248] New: compiling Poco with libc++ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10248 Summary: compiling Poco with libc++ Product: libc++ Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: llvm at niebuhrt.de CC: llvmbugs at cs.uiuc.edu This is probably a problem of Poco (pocoproject.org), but I am not sure about it. When compiling the following program with libc++ (with or without c++0x) //clang++ -c -stdlib=libc++ -I projects/odemx-http.git/install/include/ main.cpp #include #include #include void test(Poco::Data::Statement& s1, Poco::Data::Statement& s2) { std::swap( s1, s2); } ----------------- Statement.h includes so the template swap should be in the namespace std ----------------- I get the following errors: In file included from main.cpp:1: projects/odemx-http.git/install/include//Poco/Data/Statement.h:839:7: error: no function template matches function template specialization 'swap' void swap(Poco::Data::Statement& s1, ^ In file included from main.cpp:1: In file included from projects/odemx-http.git/install/include//Poco/Data/Statement.h:44: In file included from projects/odemx-http.git/install/include//Poco/Data/StatementImpl.h:44: In file included from projects/odemx-http.git/install/include//Poco/Data/AbstractBinding.h:44: In file included from projects/odemx-http.git/install/include//Poco/Data/AbstractBinder.h:44: In file included from projects/odemx-http.git/install/include//Poco/Data/Date.h:44: In file included from projects/odemx-http.git/install/include//Poco/Dynamic/VarHolder.h:54: In file included from /usr/include/c++/v1/vector:261: /usr/include/c++/v1/__bit_reference:26:26: error: no type named '__storage_type' in 'Poco::Data::Statement' typedef typename _C::__storage_type __storage_type; ~~~~~~~~~~~~~^~~~~~~~~~~~~~ main.cpp:5:36: note: in instantiation of template class 'std::__1::__bit_reference' requested here std::swap( s1, s2); ^ In file included from main.cpp:1: In file included from projects/odemx-http.git/install/include//Poco/Data/Statement.h:44: In file included from projects/odemx-http.git/install/include//Poco/Data/StatementImpl.h:44: In file included from projects/odemx-http.git/install/include//Poco/Data/AbstractBinding.h:44: In file included from projects/odemx-http.git/install/include//Poco/Data/AbstractBinder.h:44: In file included from projects/odemx-http.git/install/include//Poco/Data/Date.h:44: In file included from projects/odemx-http.git/install/include//Poco/Dynamic/VarHolder.h:54: In file included from /usr/include/c++/v1/vector:261: /usr/include/c++/v1/__bit_reference:27:26: error: no type named '__storage_pointer' in 'Poco::Data::Statement' typedef typename _C::__storage_pointer __storage_pointer; ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~ /usr/include/c++/v1/__bit_reference:33:25: error: no type named '__self' in 'Poco::Data::Statement' friend typename _C::__self; ~~~~~~~~~~~~~^~~~~~ main.cpp:5:2: error: no matching function for call to 'swap' std::swap( s1, s2); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/v1/memory:3859:1: note: candidate function [with _Tp = Poco::Data::Statement] not viable: no known conversion from 'Poco::Data::Statement' to 'shared_ptr &' for 1st argument swap(shared_ptr<_Tp>& __x, shared_ptr<_Tp>& __y) _NOEXCEPT ^ /usr/include/c++/v1/memory:4040:1: note: candidate function [with _Tp = Poco::Data::Statement] not viable: no known conversion from 'Poco::Data::Statement' to 'weak_ptr &' for 1st argument swap(weak_ptr<_Tp>& __x, weak_ptr<_Tp>& __y) _NOEXCEPT ^ /usr/include/c++/v1/__bit_reference:81:1: note: candidate function [with _C = Poco::Data::Statement] not viable: no known conversion from 'Poco::Data::Statement' to '__bit_reference' for 1st argument swap(__bit_reference<_C> __x, bool& __y) _NOEXCEPT ^ /usr/include/c++/v1/__bit_reference:91:1: note: candidate function [with _C = Poco::Data::Statement] not viable: no known conversion from 'Poco::Data::Statement' to 'bool &' for 1st argument swap(bool& __x, __bit_reference<_C> __y) _NOEXCEPT ^ /usr/include/c++/v1/__mutex_base:276:1: note: candidate function [with _Mutex = Poco::Data::Statement] not viable: no known conversion from 'Poco::Data::Statement' to 'unique_lock &' for 1st argument swap(unique_lock<_Mutex>& __x, unique_lock<_Mutex>& __y) {__x.swap(__y);} ^ /usr/include/c++/v1/__functional_03:1856:1: note: candidate function [with _F = Poco::Data::Statement] not viable: no known conversion from 'Poco::Data::Statement' to 'function &' for 1st argument swap(function<_F>& __x, function<_F>& __y) ^ /usr/include/c++/v1/type_traits:3021:1: note: candidate template ignored: substitution failure [with _Tp = Poco::Data::Statement] swap(_Tp& __x, _Tp& __y) _NOEXCEPT_(is_nothrow_move_constructible<_Tp>::value && ^ /usr/include/c++/v1/utility:183:1: note: candidate template ignored: failed template argument deduction swap(_Tp (&__a)[_N], _Tp (&__b)[_N]) _NOEXCEPT_(__is_nothrow_swappable<_Tp>::value) ^ /usr/include/c++/v1/utility:404:1: note: candidate template ignored: failed template argument deduction swap(pair<_T1, _T2>& __x, pair<_T1, _T2>& __y) ^ /usr/include/c++/v1/memory:2259:1: note: candidate template ignored: failed template argument deduction swap(__compressed_pair<_T1, _T2>& __x, __compressed_pair<_T1, _T2>& __y) ^ /usr/include/c++/v1/memory:2682:1: note: candidate template ignored: failed template argument deduction swap(unique_ptr<_Tp, _Dp>& __x, unique_ptr<_Tp, _Dp>& __y) _NOEXCEPT {__x.swap(__y);} ^ /usr/include/c++/v1/string:3881:1: note: candidate template ignored: failed template argument deduction swap(basic_string<_CharT, _Traits, _Allocator>& __lhs, ^ /usr/include/c++/v1/__bit_reference:71:1: note: candidate template ignored: failed template argument deduction swap(__bit_reference<_C> __x, __bit_reference<_D> __y) _NOEXCEPT ^ /usr/include/c++/v1/__split_buffer:638:1: note: candidate template ignored: failed template argument deduction swap(__split_buffer<_Tp, _Allocator>& __x, __split_buffer<_Tp, _Allocator>& __y) ^ /usr/include/c++/v1/vector:2938:1: note: candidate template ignored: failed template argument deduction swap(vector<_Tp, _Allocator>& __x, vector<_Tp, _Allocator>& __y) ^ /usr/include/c++/v1/deque:2819:1: note: candidate template ignored: failed template argument deduction swap(deque<_Tp, _Allocator>& __x, deque<_Tp, _Allocator>& __y) ^ /usr/include/c++/v1/list:1655:1: note: candidate template ignored: failed template argument deduction swap(list<_Tp, _Alloc>& __x, list<_Tp, _Alloc>& __y) ^ /usr/include/c++/v1/__tree:2281:1: note: candidate template ignored: failed template argument deduction swap(__tree<_Tp, _Compare, _Allocator>& __x, ^ /usr/include/c++/v1/set:672:1: note: candidate template ignored: failed template argument deduction swap(set<_Key, _Compare, _Allocator>& __x, ^ /usr/include/c++/v1/set:1005:1: note: candidate template ignored: failed template argument deduction swap(multiset<_Key, _Compare, _Allocator>& __x, ^ /usr/include/c++/v1/map:1406:1: note: candidate template ignored: failed template argument deduction swap(map<_Key, _Tp, _Compare, _Allocator>& __x, ^ /usr/include/c++/v1/map:1902:1: note: candidate template ignored: failed template argument deduction swap(multimap<_Key, _Tp, _Compare, _Allocator>& __x, ^ /usr/include/c++/v1/sstream:336:1: note: candidate template ignored: failed template argument deduction swap(basic_stringbuf<_CharT, _Traits, _Allocator>& __x, ^ /usr/include/c++/v1/sstream:613:1: note: candidate template ignored: failed template argument deduction swap(basic_istringstream<_CharT, _Traits, _Allocator>& __x, ^ /usr/include/c++/v1/sstream:732:1: note: candidate template ignored: failed template argument deduction swap(basic_ostringstream<_CharT, _Traits, _Allocator>& __x, ^ /usr/include/c++/v1/sstream:851:1: note: candidate template ignored: failed template argument deduction swap(basic_stringstream<_CharT, _Traits, _Allocator>& __x, ^ 5 errors generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 2 10:05:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 10:05:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 10248] compiling Poco with libc++ In-Reply-To: References: Message-ID: <20110702150508.BB3E92A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10248 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Howard Hinnant 2011-07-02 10:05:08 CDT --- The correct way to implement swap is to define it in your own namespace. I note that this project already does that: namespace Poco { namespace Data { inline void swap(Statement& s1, Statement& s2) { s1.swap(s2); } } } The correct way to call swap is: void test(Poco::Data::Statement& s1, Poco::Data::Statement& s2) { swap( s1, s2); } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 2 12:14:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 12:14:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10249] New: Missing functions in string.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10249 Summary: Missing functions in string.cpp Product: libc++ Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: jonathan.sauer at gmx.de CC: llvmbugs at cs.uiuc.edu The following program compiles, but does not link with clang r134322 and libc++ r134322: #include int main(int, char** argv) { std::string s; s.append(argv[0], argv[0] + 1); } clang++ -std=c++0x -stdlib=libc++ clang.cpp Undefined symbols: "__ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6appendIPcEENS_9enable_ifIXsr21__is_forward_iteratorIT_EE5valueERS5_E4typeES9_S9_", referenced from: _main in cc-u2Adwb.o The reason for this is the missing implementation of a few specialized template methods in libc++'s string.cpp file (only the prototypes are there). Commenting the "extern template ..." lines in (lines 3972 to 4020) makes the problem go away (as the compiler simply instanciates the non-specialized template methods). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 2 12:40:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 12:40:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10250] New: __bind in is missing copy constructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10250 Summary: __bind in is missing copy constructor Product: libc++ Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: jonathan.sauer at gmx.de CC: llvmbugs at cs.uiuc.edu __bind in is missing a copy constructor, since according to 12.8p18, the implicit copy assignment operator is defined as deleted if a move copy constructor exists (which is the case in __bind). C.f. bug 10191. Sample program: #include bool foo(int, bool, float); template void bar(F); template void baz(F f) { bar(f); } int main(int, char**) { baz(std::bind(&foo)); } And the error: $ clang++ -std=c++0x -stdlib=libc++ clang.cpp clang.cpp:10:6: error: call to deleted constructor of 'std::__1::__bind' bar(f); ^ clang.cpp:15:2: note: in instantiation of function template specialization 'baz >' requested here baz(std::bind(&foo)); ^ /usr/include/c++/v1/functional:1658:7: note: function has been explicitly marked deleted here class __bind ^ clang.cpp:5:40: note: passing argument to parameter here template static void bar(F); ^ 1 error generated. Commenting __bind's move constructor makes the error go away, as the requirements of 12.8p18 are no longer fulfilled. My clang version: r134322. My libc++ version: r134322. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 2 12:55:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 12:55:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 8045] changes in upcoming gdb 7.2 cause failures in the lookup of C++ functions in clang compiled code In-Reply-To: References: Message-ID: <20110702175550.965102A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8045 Tobias Grosser changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Tobias Grosser 2011-07-02 12:55:48 CDT --- I cannot reproduce this bug anymore with gdb-7.2 and clang/LLVM checkout of today. It probably was solved on the way. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 2 13:22:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 13:22:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 10250] __bind in is missing copy constructor In-Reply-To: References: Message-ID: <20110702182256.3AA972A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10250 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2011-07-02 13:22:55 CDT --- Committed revision 134325. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 2 14:44:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 14:44:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 10251] New: Early tail dup still not as good and duplicating indirectbr in clang Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10251 Summary: Early tail dup still not as good and duplicating indirectbr in clang 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: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6813) --> (http://llvm.org/bugs/attachment.cgi?id=6813) indirect.patch Things got a lot better with the new improvements to the coalescer, but duplicating indirectbr in clang still produces better results. In jsinterp.o, the current trunk produces: 171419 3904 0 0 175323 2acdb And duplicating indirectbr in clang produces: 117275 3904 0 0 121179 1d95b -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 2 15:06:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 15:06:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10252] New: -strong-phi-elim crash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10252 Summary: -strong-phi-elim crash 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: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6815) --> (http://llvm.org/bugs/attachment.cgi?id=6815) bugpoint-reduced-simplified.bc llc -strong-phi-elim bugpoint-reduced-simplified.bc Assertion failed: (SrcVNI), function InsertCopiesForPHI, file /Users/espindola/llvm/llvm/lib/CodeGen/StrongPHIElimination.cpp, line 677. 0 llc 0x00000001008b32e2 PrintStackTrace(void*) + 34 1 llc 0x00000001008b38d9 SignalHandler(int) + 777 2 libSystem.B.dylib 0x00007fff88ee11ba _sigtramp + 26 3 libSystem.B.dylib 0xffffffffffffffff _sigtramp + 1997663839 4 llc 0x00000001008b3526 abort + 22 5 llc 0x00000001008b34e7 __assert_rtn + 55 6 llc 0x000000010064d1ae (anonymous namespace)::StrongPHIElimination::runOnMachineFunction(llvm::MachineFunction&) + 9790 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 2 16:07:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 16:07:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 10253] New: cannot compile large Boost.Test testsuites and gives cryptic output (regression) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10253 Summary: cannot compile large Boost.Test testsuites and gives cryptic output (regression) Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pogonyshev at gmx.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6816) --> (http://llvm.org/bugs/attachment.cgi?id=6816) file demonstrating the bug The attached file requires Boost.Test to compile. It is a large test suite of empty templated tests. When compiled and run with GCC or Clang 2.7 it produces the expected output: "Running 700 test cases... *** No errors detected". However, with Clang 2.9 compilation/linkage fails with errors: /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 0 has invalid symbol index 11 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 1 has invalid symbol index 12 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 2 has invalid symbol index 2 ... Compilation/linkage line is as follows: $CC -DBOOST_TEST_DYN_LINK test.cpp -o test -lboost_unit_test_framework with $CC replaced by compiler name. Additionally, when you remove or comment out last (I guess any) 10 templated test cases and run the result, Clang 2.9 suddenly works fine, producing "Running 600 test cases... *** No errors detected" (here 600 is expected, as 100 tests are gone). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 2 16:25:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 16:25:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10249] Missing functions in string.cpp In-Reply-To: References: Message-ID: <20110702212520.928B32A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10249 jonathan.sauer at gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #5 from jonathan.sauer at gmx.de 2011-07-02 16:25:20 CDT --- Well, it seems that I compiled libc++ with an older version of clang, r133996 to be precise. That resulted in the following symbol in libc++.1.dylib (for string::append(ForwardIterator, ForwardIterator)): __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6appendIPcEENS_9enable_ifIXsrNS_21__is_forward_iteratorIT_EE5valueERS5_E4typeESA_SA_ Now, clang r134322 mangles this as (note the missing "NS" after "ifXsr" and the differing suffix): __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6appendIPcEENS_9enable_ifIXsr21__is_forward_iteratorIT_EE5valueERS5_E4typeES9_S9_ This, of course, resulted in a linker error. And I misread the explicit instanciation of methods in string.cpp for declarations. The reason for the change in name mangling seems to be revision 134227: http://llvm.org/viewvc/llvm-project?view=rev&revision=134227 So, all-clear for libc++. I'm sorry for the noise, and I hope I did not cause too much work for all involved! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 2 21:47:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 21:47:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 10242] Related result types for +class and -class In-Reply-To: References: Message-ID: <20110703024725.967892A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10242 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Chris Lattner 2011-07-02 21:47:25 CDT --- We track objective-c language changes internally to apple, since that is where the decision makers are. The current policy is that we only do this for a specific set of methods. We are kicking around the idea of making this generally extensible to arbitrary methods. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 2 21:49:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 21:49:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10252] -strong-phi-elim crash In-Reply-To: References: Message-ID: <20110703024906.94F892A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10252 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Chris Lattner 2011-07-02 21:49:06 CDT --- strong-phi-elim is still experimental, it doesn't make sense to track individual bugs in it until someone decides to make it real. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 2 21:58:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 21:58:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10252] -strong-phi-elim crash In-Reply-To: References: Message-ID: <20110703025812.BBA232A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10252 Cameron Zwarich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|LATER | --- Comment #2 from Cameron Zwarich 2011-07-02 21:58:12 CDT --- Chris, I told him to file the bug so I could at least see why it doesn't work on his test case. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 2 22:24:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 2 Jul 2011 22:24:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 10254] New: Phi with identical arguments not optimized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10254 Summary: Phi with identical arguments not optimized Product: libraries Version: trunk Platform: PC OS/Version: All 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 Created an attachment (id=6818) --> (http://llvm.org/bugs/attachment.cgi?id=6818) test.ll I was curious why early tail dup in CodeGen was seeing trivial bb like foo: jmp bar since I would expect simplifycfg to handle them. One case I found is attached. We have code that looks like: ---------------------------- bb0: ; preds = %for.body7.i %gep0 = getelementptr inbounds i8* %call.i.i.i.i, i64 8 %cast0 = bitcast i8* %gep0 to %"class.llvm::MallocAllocator"** br label %bb2 bb1: ; preds = %for.body7.i %second.i.i.i.i.i = getelementptr inbounds i8* %call.i.i.i.i, i64 8 %cast1 = bitcast i8* %second.i.i.i.i.i to %"class.llvm::MallocAllocator"** Use of cast1 br label %bb2 bb2: ; preds = %bb1, %bb0 %.pre-phi.i.i.i = phi %"class.llvm::MallocAllocator"** [ %cast0, %bb0 ], [ %cast1, %bb1 ] ---------------------------- codegenprepare will move gep0 and cast0, making bb0 empty, but that is too late for simplifycfg. One way to optimize this early would be to move both the gep and cast to for.body7.i and remove the phi. After that simplifycfg would remove bb0. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 3 09:10:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Jul 2011 09:10:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 10255] New: Build of llvm-gcc trunk fails on PPC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10255 Summary: Build of llvm-gcc trunk fails on PPC Product: tools Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: annulen at yandex.ru CC: llvmbugs at cs.uiuc.edu Here is error output: /Volumes/Development/projects/svn/obj/./gcc/xgcc -B/Volumes/Development/projects/svn/obj/./gcc/ -B/Volumes/Development/projects/svn/obj/../install/powerpc-apple-darwin9/bin/ -B/Volumes/Development/projects/svn/obj/../install/powerpc-apple-darwin9/lib/ -isystem /Volumes/Development/projects/svn/obj/../install/powerpc-apple-darwin9/include -isystem /Volumes/Development/projects/svn/obj/../install/powerpc-apple-darwin9/sys-include -mmacosx-version-min=10.4 -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Wa,-force_cpusubtype_ALL -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../llvm-gcc/gcc -I../../llvm-gcc/gcc/. -I../../llvm-gcc/gcc/../include -I./../intl -I../../llvm-gcc/gcc/../libcpp/include -I../../llvm-gcc/gcc/../libdecnumber -I../libdecnumber -I/Volumes/Development/projects/svn/obj/../../git/llvm-build/include -I/Volumes/Development/projects/git/llvm/include -isysroot/Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -DL_multc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../llvm-gcc/gcc/libgcc2.c -o libgcc/./_multc3.o Unhandled reg in PPCRegisterInfo::getRegisterNumbering! UNREACHABLE executed at /Volumes/Development/projects/git/llvm/lib/Target/PowerPC/PPCRegisterInfo.cpp:111! ../../llvm-gcc/gcc/libgcc2.c:1914: internal compiler error: Abort trap -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 3 15:37:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Jul 2011 15:37:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 10256] New: Assertion failed: (!Call.isInvalid() && "Call to __builtin_memcpy cannot fail!"), function DefineImplicitCopyAssignment Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10256 Summary: Assertion failed: (!Call.isInvalid() && "Call to __builtin_memcpy cannot fail!"), function DefineImplicitCopyAssignment Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: i.galic at brainsware.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com When trying to build this test case: struct A { unsigned int i; volatile int buff[2]; }; int main(int argc, char** argv) { A a1, a2; a1 = a2; return 0; } I'll get this error: igalic at tynix ~/src % /opt/llvm-trunk/bin/clang++ foo.cc foo.cc:1:8: error: cannot initialize a parameter of type 'void *' with an rvalue of type 'volatile int (*)[2]' struct A { ^ foo.cc:8:5: note: implicit default copy assignment operator for 'A' first required here a1 = a2; ^ 1 error generated. igalic at tynix ~/src % Here's the same build with Asserts enabled: Assertion failed: (!Call.isInvalid() && "Call to __builtin_memcpy cannot fail!"), function DefineImplicitCopyAssignment, file SemaDeclCXX.cpp, line 7011. 0 clang 0x00000001019215f2 PrintStackTrace(void*) + 34 1 clang 0x0000000101922443 SignalHandler(int) + 707 2 libSystem.B.dylib 0x00007fff80f0d1ba _sigtramp + 26 3 libSystem.B.dylib 0x0000000c030469f0 _sigtramp + 2182322256 4 clang 0x000000010001b102 __assert_rtn + 66 5 clang 0x000000010048edd8 clang::Sema::DefineImplicitCopyAssignment(clang::SourceLocation, clang::CXXMethodDecl*) + 9336 6 clang 0x00000001004de018 clang::Sema::MarkDeclarationReferenced(clang::SourceLocation, clang::Decl*) + 2216 7 clang 0x00000001005dc311 clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int, clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*) + 4433 8 clang 0x00000001005306f1 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 241 9 clang 0x0000000100530a17 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 455 10 clang 0x0000000100358bf2 clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) + 594 11 clang 0x0000000100357c27 clang::Parser::ParseAssignmentExpression() + 87 12 clang 0x0000000100359901 clang::Parser::ParseExpression() + 17 13 clang 0x0000000100381019 clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 73 14 clang 0x000000010037d042 clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 2130 15 clang 0x000000010037e056 clang::Parser::ParseCompoundStatementBody(bool) + 1526 16 clang 0x000000010037e609 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 201 17 clang 0x0000000100396bca clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1130 18 clang 0x0000000100336abc clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2860 19 clang 0x0000000100397e48 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 168 20 clang 0x00000001003982ce clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 478 21 clang 0x0000000100398ec3 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2931 22 clang 0x00000001003995ca clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 554 23 clang 0x00000001003295fb clang::ParseAST(clang::Sema&, bool) + 299 24 clang 0x00000001002f41cc clang::CodeGenAction::ExecuteAction() + 60 25 clang 0x000000010005a521 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 433 26 clang 0x00000001000258f7 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1527 27 clang 0x000000010001c421 cc1_main(char const**, char const**, char const*, void*) + 577 28 clang 0x000000010002472e main + 4526 29 clang 0x000000010001b854 start + 52 Stack dump: 0. Program arguments: /Users/thakis/src/llvm-rw/Release+Asserts/bin/clang -cc1 -triple x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -main-file-name test.cc -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17 -coverage-file test.o -resource-dir /Users/thakis/src/llvm-rw/Release+Asserts/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 141 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++ test.cc 1. test.cc:8:10: current parser token ';' 2. test.cc:6:33: parsing function body 'main' 3. test.cc:6:33: in compound statement ('{}') clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 3 16:14:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Jul 2011 16:14:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 5137] clang --print-file-name prints library for the wrong architecture In-Reply-To: References: Message-ID: <20110703211406.1AEF62A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5137 Carl-Daniel Hailfinger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Carl-Daniel Hailfinger 2011-07-03 16:14:05 CDT --- "clang --print-file-name" now works as expected. T?r?k Edwin: Can you please open a separate bug for -print-multi-os-directory which you mentioned in comment #1? That issue is still unfixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 3 17:07:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Jul 2011 17:07:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10257] New: clang -arch FOO is ignored Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10257 Summary: clang -arch FOO is ignored Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: c-d.hailfinger.devel.2006 at gmx.net CC: llvmbugs at cs.uiuc.edu compiler at p35:> clang -arch ppc test.c clang-3: warning: argument unused during compilation: '-arch ppc' As mentioned in the clang man page and in http://clang.llvm.org/docs/DriverInternals.html, "clang -arch FOO" should allow specifying the target architecture. More info: compiler at p35:> clang -ccc-print-options -arch ppc test.c Option 0 - Name: "-ccc-print-options", Values: {} Option 1 - Name: "-arch", Values: {"ppc"} Option 2 - Name: "", Values: {"test.c"} compiler at p35:> clang -ccc-print-bindings -arch ppc test.c # "i386-pc-linux-gnu" - "clang", inputs: ["test.c"], output: "/tmp/cc-aluQvo.o" # "i386-pc-linux-gnu" - "linux::Link", inputs: ["/tmp/cc-aluQvo.o"], output: "a.out" clang-3: warning: argument unused during compilation: '-arch ppc' compiler at p35:> clang --version SUSE Linux clang version 3.0 (trunk 132667) (based on LLVM 3.0) 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 Sun Jul 3 18:13:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Jul 2011 18:13:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10258] New: "cannot select" on ARM with variable-index insertelement Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10258 Summary: "cannot select" on ARM with variable-index insertelement Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu define <8 x i16> @f(<8 x i16> %a, i16 %b, i32 %c) nounwind readnone { entry: %r = insertelement <8 x i16> %a, i16 %b, i32 %c ret <8 x i16> %r } $ llc -march=arm -mcpu=cortex-a9 test.ll LLVM ERROR: Cannot select: 0x101831710: v8i16 = insert_vector_elt 0x101831010, 0x101831310, 0x101831510 [ORD=1] [ID=24] 0x101831010: v8i16 = bitcast 0x101833110 [ORD=1] [ID=23] 0x101833110: v2f64 = ARMISD::BUILD_VECTOR 0x10182fc10, 0x101830110 [ID=22] 0x10182fc10: f64 = ARMISD::VMOVDRR 0x10182f910, 0x10182fb10 [ORD=1] [ID=20] 0x10182f910: i32,ch = CopyFromReg 0x10141a6f8, 0x10182f810 [ORD=1] [ID=14] 0x10182f810: i32 = Register %vreg0 [ORD=1] [ID=1] 0x10182fb10: i32,ch = CopyFromReg 0x10141a6f8, 0x10182fa10 [ORD=1] [ID=15] 0x10182fa10: i32 = Register %vreg1 [ORD=1] [ID=2] 0x101830110: f64 = ARMISD::VMOVDRR 0x10182fe10, 0x101830010 [ORD=1] [ID=21] 0x10182fe10: i32,ch = CopyFromReg 0x10141a6f8, 0x10182fd10 [ORD=1] [ID=16] 0x10182fd10: i32 = Register %vreg2 [ORD=1] [ID=3] 0x101830010: i32,ch = CopyFromReg 0x10141a6f8, 0x10182ff10 [ORD=1] [ID=17] 0x10182ff10: i32 = Register %vreg3 [ORD=1] [ID=4] 0x101831310: i32,ch = load 0x10141a6f8, 0x101831110, 0x101831210 [ID=18] 0x101831110: i32 = FrameIndex<-1> [ORD=1] [ID=7] 0x101831210: i32 = undef [ORD=1] [ID=8] 0x101831510: i32,ch = load 0x10141a6f8, 0x101831410, 0x101831210 [ORD=1] [ID=19] 0x101831410: i32 = FrameIndex<-2> [ORD=1] [ID=9] 0x101831210: i32 = undef [ORD=1] [ID=8] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 3 19:06:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 3 Jul 2011 19:06:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 10244] `!Traits::stopLess(b, a) && "Invalid interval"' failed. In-Reply-To: References: Message-ID: <20110704000621.0D5F92A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10244 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Jakob Stoklund Olesen 2011-07-03 19:06:20 CDT --- r134369 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 00:14:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 00:14:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 10259] New: Fake ambiguity between scoped redeclaration of class found via inline anonymous namespace Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10259 Summary: Fake ambiguity between scoped redeclaration of class found via inline anonymous namespace Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com // scoped declaration fails (correctly: [namespace.qual]p7) if namespace isn't inline // works if namespace isn't anonymous inline namespace { class A; } // if not scoped, ambiguity is real, no bug class ::A {}; A a; daysthatwere:trunk glamr$ clang -std=c++0x /tmp/red3.cpp /tmp/red3.cpp:5:1: error: reference to 'A' is ambiguous A a; ^ /tmp/red3.cpp:4:9: note: candidate found by name lookup is 'A' class ::A {}; ^ /tmp/red3.cpp:2:9: note: candidate found by name lookup is '::A' class A; ^ /tmp/red3.cpp:5:3: error: variable has incomplete type '::A' A a; ^ /tmp/red3.cpp:2:9: note: forward declaration of '::A' class A; ^ 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 Mon Jul 4 00:44:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 00:44:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10260] New: IRgen assert from instantiating initializer pack expansion with empty pack Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10260 Summary: IRgen assert from instantiating initializer pack expansion with empty pack Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com struct A {}; struct B : public A {}; template static void foo(T &&...ts) { A *printerArray[sizeof...(T) ? sizeof...(T) : 1] = { (&ts)... }; } void test() { foo(); } daysthatwere:trunk glamr$ clang -std=c++0x /tmp/red3.cpp Assertion failed: (E && hasAggregateLLVMType(E->getType()) && "Invalid aggregate expression to emit"), function EmitAggExpr, file CGExprAgg.cpp, line 904. 0 clang 0x0000000102025835 PrintStackTrace(void*) + 53 1 clang 0x0000000102025dfb SignalHandler(int) + 379 2 libSystem.B.dylib 0x00007fff8718a66a _sigtramp + 26 3 libSystem.B.dylib 0x0000000000000014 _sigtramp + 2028427716 4 clang 0x000000010004252b raise + 27 5 clang 0x00000001000425ea abort + 26 6 clang 0x00000001000425c4 __assert_rtn + 132 7 clang 0x00000001003127f8 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) + 184 8 clang 0x00000001002eaec6 clang::CodeGen::CodeGenFunction::EmitExprAsInit(clang::Expr const*, clang::ValueDecl const*, clang::CodeGen::LValue, bool) + 1190 9 clang 0x00000001002e9a00 clang::CodeGen::CodeGenFunction::EmitAutoVarInit(clang::CodeGen::CodeGenFunction::AutoVarEmission const&) + 880 10 clang 0x00000001002e6cca clang::CodeGen::CodeGenFunction::EmitAutoVarDecl(clang::VarDecl const&) + 58 11 clang 0x00000001002e6bc8 clang::CodeGen::CodeGenFunction::EmitVarDecl(clang::VarDecl const&) + 120 12 clang 0x00000001002e6a0b clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl const&) + 219 13 clang 0x00000001003bb62f clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) + 143 14 clang 0x00000001003b5ba2 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 290 15 clang 0x00000001003b54a1 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 113 16 clang 0x00000001003bb37d clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 445 17 clang 0x00000001003b5b80 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 256 18 clang 0x00000001003b54a1 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 113 19 clang 0x00000001003f2e2c clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&) + 172 20 clang 0x00000001003f3205 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 965 21 clang 0x00000001003fdf11 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl) + 1297 22 clang 0x00000001003fba76 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 678 23 clang 0x00000001003f8b35 clang::CodeGen::CodeGenModule::EmitDeferred() + 565 24 clang 0x00000001003f8799 clang::CodeGen::CodeGenModule::Release() + 25 25 clang 0x0000000100420d51 (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) + 161 26 clang 0x00000001003f022b clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 139 27 clang 0x0000000100430992 clang::ParseAST(clang::Sema&, bool) + 850 28 clang 0x00000001000ebd0c clang::ASTFrontendAction::ExecuteAction() + 284 29 clang 0x00000001003eed62 clang::CodeGenAction::ExecuteAction() + 1250 30 clang 0x00000001000eb8c8 clang::FrontendAction::Execute() + 360 31 clang 0x00000001000c5ab6 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1078 32 clang 0x0000000100059e7c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1132 33 clang 0x0000000100045d64 cc1_main(char const**, char const**, char const*, void*) + 1252 34 clang 0x00000001000533ad main + 701 35 clang 0x0000000100045874 start + 52 36 clang 0x0000000000000026 start + 4294682598 Stack dump: 0. Program arguments: /Volumes/Data/llvm/Debug+Asserts/bin/clang -cc1 -triple x86_64-apple-macosx10.6.7 -emit-obj -mrelax-all -disable-free -main-file-name red3.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17 -resource-dir /Volumes/Data/llvm/Debug+Asserts/bin/../lib/clang/3.0 -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 85 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/s9/s96FsWmjFfOmejEGjQKJMU+++TI/-Tmp-/cc-rTiryX.o -x c++ /tmp/red3.cpp 1. parser at end of file 2. Per-file LLVM IR generation 3. /tmp/red3.cpp:4:35: Generating code for declaration 'foo' 4. /tmp/red3.cpp:4:50: LLVM IR generation of compound statement ('{}') clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 4 01:12:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 01:12:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10261] New: tblgen assert when building clang from trunk Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10261 Summary: tblgen assert when building clang from trunk Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: TableGen AssignedTo: unassignedbugs at nondot.org ReportedBy: oyvind.harboe at zylin.com CC: llvmbugs at cs.uiuc.edu ../llvm/configure --enable-optimized make (tried without optimized too) => llvm[5]: Building Clang attribute classes with tblgen tblgen: /home/oyvind/llvm/llvm/utils/TableGen/ClangAttrEmitter.cpp:479: virtual void llvm::ClangAttrClassEmitter::run(llvm::raw_ostream&): Assertion `Arg' failed. 0 tblgen 0x000000000054fb7f 1 tblgen 0x000000000055095c 2 libpthread.so.0 0x00002b2ad611ec60 3 libc.so.6 0x00002b2ad6d07d05 gsignal + 53 4 libc.so.6 0x00002b2ad6d0bab6 abort + 390 5 libc.so.6 0x00002b2ad6d007c5 __assert_fail + 245 6 tblgen 0x000000000043e8df 7 tblgen 0x0000000000528a9f 8 libc.so.6 0x00002b2ad6cf2eff __libc_start_main + 255 9 tblgen 0x0000000000406349 Stack dump: 0. Program arguments: /home/oyvind/llvm/build/Release+Asserts/bin/tblgen -I /home/oyvind/llvm/llvm/tools/clang/include/clang/AST -I /home/oyvind/llvm/llvm/include -I /home/oyvind/llvm/llvm/include -I /home/oyvind/llvm/llvm/lib/Target -gen-clang-attr-classes -o /home/oyvind/llvm/build/tools/clang/include/clang/AST/Release+Asserts/Attrs.inc.tmp -I /home/oyvind/llvm/llvm/tools/clang/include/clang/AST/../../ /home/oyvind/llvm/llvm/tools/clang/include/clang/AST/../Basic/Attr.td -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 02:50:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 02:50:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 10263] New: Wrong definition of ftrunc. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10263 Summary: Wrong definition of ftrunc. Product: tools Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: hranac.bz at email.cz CC: llvmbugs at cs.uiuc.edu Node ftrunc is defined as such: def SDTFPUnaryOp: SDTypeProfile<1, 1, [ SDTCisSameAs<0, 1>, SDTCisFP<0> ]>; def ftrunc: SDNode<"ISD::FTRUNC", SDTFPUnaryOp>; Because of this, ftrunc is unuseable (which is probably the reason why no official backends use this node). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 05:14:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 05:14:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10264] New: Rejects-valid and sometimes a crash with defining fixed enums out of scope Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10264 Summary: Rejects-valid and sometimes a crash with defining fixed enums out of scope Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In my original test case, this didn't crash, but it still rejected what I believe is valid code. This is probably just a matter of protecting colons when parsing nested names on enum specifiers. However, it also suggests that we aren't handling incomplete enums safely when they're the base of a nested name; i.e. ns::A::foo should not lead to crashes when A is an incomplete unscoped enum. daysthatwere:trunk clang$ cat /tmp/red3.cpp namespace ns { typedef unsigned type; enum A : ns::type; } enum ns::A : ns::type { X }; daysthatwere:trunk clang$ clang -std=c++0x /tmp/red3.cpp /tmp/red3.cpp:6:12: error: unexpected ':' in nested name specifier enum ns::A : ns::type { ^ :: Assertion failed: ((!isa(LookupCtx) || LookupCtx->isDependentContext() || cast(LookupCtx)->isDefinition() || Context.getTypeDeclType(cast(LookupCtx))->getAs() ->isBeingDefined()) && "Declaration context must already be complete!"), function LookupQualifiedName, file SemaLookup.cpp, line 1334. 0 clang 0x0000000102025835 PrintStackTrace(void*) + 53 1 clang 0x0000000102025dfb SignalHandler(int) + 379 2 libSystem.B.dylib 0x00007fff8718a66a _sigtramp + 26 3 clang 0x0000000100fb99ce clang::EnumType::classof(clang::TagType const*) + 30 4 clang 0x000000010004252b raise + 27 5 clang 0x00000001000425ea abort + 26 6 clang 0x00000001000425c4 __assert_rtn + 132 7 clang 0x00000001006fbc3f clang::Sema::LookupQualifiedName(clang::LookupResult&, clang::DeclContext*, bool) + 495 8 clang 0x00000001004fd999 clang::Sema::BuildCXXNestedNameSpecifier(clang::Scope*, clang::IdentifierInfo&, clang::SourceLocation, clang::SourceLocation, clang::QualType, bool, clang::CXXScopeSpec&, clang::NamedDecl*, bool) + 937 9 clang 0x00000001004ff2f7 clang::Sema::ActOnCXXNestedNameSpecifier(clang::Scope*, clang::IdentifierInfo&, clang::SourceLocation, clang::SourceLocation, clang::OpaquePtr, bool, clang::CXXScopeSpec&) + 263 10 clang 0x000000010046c040 clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&, clang::OpaquePtr, bool, bool*, bool) + 4896 11 clang 0x000000010043f04e clang::Parser::ParseEnumSpecifier(clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier) + 382 12 clang 0x000000010043c296 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 10534 13 clang 0x00000001004a8e69 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 137 14 clang 0x00000001004a93a0 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 96 15 clang 0x00000001004a84d1 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 3681 16 clang 0x00000001004a7623 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 451 17 clang 0x00000001004307cc clang::ParseAST(clang::Sema&, bool) + 396 18 clang 0x00000001000ebd0c clang::ASTFrontendAction::ExecuteAction() + 284 19 clang 0x00000001003eed62 clang::CodeGenAction::ExecuteAction() + 1250 20 clang 0x00000001000eb8c8 clang::FrontendAction::Execute() + 360 21 clang 0x00000001000c5ab6 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1078 22 clang 0x0000000100059e7c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1132 23 clang 0x0000000100045d64 cc1_main(char const**, char const**, char const*, void*) + 1252 24 clang 0x00000001000533ad main + 701 25 clang 0x0000000100045874 start + 52 26 clang 0x0000000000000026 start + 4294682598 Stack dump: 0. Program arguments: /Volumes/Data/llvm/Debug+Asserts/bin/clang -cc1 -triple x86_64-apple-macosx10.6.7 -emit-obj -mrelax-all -disable-free -main-file-name red3.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17 -resource-dir /Volumes/Data/llvm/Debug+Asserts/bin/../lib/clang/3.0 -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 85 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/s9/s96FsWmjFfOmejEGjQKJMU+++TI/-Tmp-/cc-8cHSPp.o -x c++ /tmp/red3.cpp 1. /tmp/red3.cpp:6:18: current parser token 'type' clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 4 07:31:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 07:31:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10265] New: variable 's_rand_seed' is uninitialized when used within its own initialization Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10265 Summary: variable 's_rand_seed' is uninitialized when used within its own initialization Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: i.galic at brainsware.org CC: llvmbugs at cs.uiuc.edu lib/ts/ink_auth_api.cc|30 col 39| error: variable 's_rand_seed' is uninitialized when used within its own initialization [-Werror,-Wuninitialized] || static int s_rand_seed = time(NULL) + s_rand_seed; || ~~~~~~~~~~~ ^~~~~~~~~~~ || 1 error generated. This is a bogus warning, not because the code isn't terrible, but because variables with static storage duration are zero-initialized prior to dynamic initialization. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 07:34:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 07:34:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10266] New: MC does not recognise hyphenated VIA instructions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10266 Summary: MC does not recognise hyphenated VIA instructions Product: libraries Version: trunk Platform: Other OS/Version: OpenBSD Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: jsg at openbsd.org CC: llvmbugs at cs.uiuc.edu binutils has the VIA instructions in both the hyphenated form as used in the VIA documentation and without. It seems LLVM only has the form without the hyphens. xstore-rng xcrypt-ecb xcrypt-cbc xcrypt-ctr xcrypt-cfb xcrypt-ofb These instructions are used in both the kernel and userland (OpenSSL) of at least OpenBSD. So it shows when using clang with the builtin assembler: /usr/src/lib/libssl/crypto/../src/crypto/engine/hw_cryptodev.c:637:19: error: invalid instruction mnemonic 'xcrypt' __asm __volatile("rep xcrypt-cbc" : ^ :1:6: note: instantiated into assembly here rep xcrypt-cbc ^ Is it possible to add aliases so both sets of names can co-exist? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 14:38:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 14:38:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10267] New: instcombine deoptimizes testcase Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10267 Summary: instcombine deoptimizes testcase Product: libraries Version: trunk Platform: PC OS/Version: All 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 In the attached testcase, instcombine converts %tmp2 = ptrtoint %struct.Shape* %tmp9 to i64 %and = and i64 %tmp2, -2 %tmp5 = inttoptr i64 %and to %struct.Shape* %tobool = icmp ne %struct.Shape* %tmp5, null br i1 %tobool, label %land.lhs.true, label %if.end land.lhs.true: ; preds = %entry %propid = getelementptr inbounds %struct.Shape* %tmp5, i32 0, i32 2 to %tobool = icmp ugt %struct.Shape* %tmp9, inttoptr (i64 1 to %struct.Shape*) br i1 %tobool, label %land.lhs.true, label %if.end land.lhs.true: ; preds = %entry %tmp2 = ptrtoint %struct.Shape* %tmp9 to i64 %and = and i64 %tmp2, -2 %tmp5 = inttoptr i64 %and to %struct.Shape* %propid = getelementptr inbounds %struct.Shape* %tmp5, i64 0, i32 2 The first one produces: movq (%rcx,%rax,8), %rdx andq $-2, %rdx je LBB0_3 ## BB#1: ## %land.lhs.true cmpq %rdi, 8(%rdx) jne LBB0_3 The second one produces movq (%rcx,%rax,8), %rdx cmpq $2, %rdx jb LBB0_3 ## BB#1: ## %land.lhs.true andq $-2, %rdx cmpq %rdi, 8(%rdx) jne LBB0_3 Note the extra "cmpq $2, %rdx" -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 15:15:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 15:15:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 10268] New: poor location for type mismatch diagnostic Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10268 Summary: poor location for type mismatch diagnostic Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I got this today: LinkModules.cpp:419:11: error: no matching function for call to 'LinkAppendingVars' if (LinkAppendingVars(DGV, SGV, ValueMap, Error)) return true; ^~~~~~~~~~~~~~~~~ LinkModules.cpp:278:13: note: candidate function not viable: cannot convert from base class pointer 'llvm::GlobalValue *' to derived class pointer 'llvm::GlobalVariable *' for 1st argument static bool LinkAppendingVars(GlobalVariable *DstGV, GlobalVariable *SrcGV, ^ Why is it pointing to and underlining "LinkAppendingVars"? It should point to the function and underline the "1st argument". Likewise, the note should point to the first argument (DstGV) as well. -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 4 15:17:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 15:17:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10267] instcombine deoptimizes testcase In-Reply-To: References: Message-ID: <20110704201739.85E212A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10267 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |FIXED --- Comment #2 from Benjamin Kramer 2011-07-04 15:17:39 CDT --- r134379 should help, thanks for finding 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 Jul 4 16:06:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 16:06:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10269] New: "PCMULQDQ" not disassembled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10269 Summary: "PCMULQDQ" not disassembled Product: tools Version: 2.9 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: llvm-as AssignedTo: unassignedbugs at nondot.org ReportedBy: kkhoo at perfwizard.com CC: llvmbugs at cs.uiuc.edu According to the "Intel? 64 and IA-32 Architectures Software Developer?s Manual Volume 2 (2A & 2B): Instruction Set Reference, A-Z", p. 4-75: 66 0F 3A 44 /r ib PCLMULQDQ $ echo '0x66 0x0f 0x3a 0x44 0xc8 0x01'| ./llvm-mc -disassemble -triple="x86_64" :1:1: warning: invalid instruction encoding 0x66 0x0f 0x3a 0x44 0xc8 0x01 ^ :1:21: warning: invalid instruction encoding 0x66 0x0f 0x3a 0x44 0xc8 0x01 ^ :1:26: warning: invalid instruction encoding 0x66 0x0f 0x3a 0x44 0xc8 0x01 ^ $ ./llvm-mc -version Low Level Virtual Machine (http://llvm.org/): llvm version 2.9 Optimized build. Built Jun 20 2011 (12:11:38). Host: i386-apple-darwin10 Host CPU: corei7 Registered Targets: alpha - Alpha [experimental] arm - ARM bfin - Analog Devices Blackfin [experimental] c - C backend cellspu - STI CBEA Cell SPU [experimental] cpp - C++ backend mblaze - MBlaze mips - Mips mipsel - Mipsel msp430 - MSP430 [experimental] ppc32 - PowerPC 32 ppc64 - PowerPC 64 ptx - PTX sparc - Sparc sparcv9 - Sparc V9 systemz - SystemZ thumb - Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 xcore - XCore -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 16:47:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 16:47:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10270] New: [C++] aborts during compilation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10270 Summary: [C++] aborts during compilation Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping at exherbo.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6824) --> (http://llvm.org/bugs/attachment.cgi?id=6824) xz-compressed output of -save-temps During compilation of "single.cpp" from eigen-3.0.1 pipping at bogus /home/pipping % clang++ -c single.ii clang: SemaOverload.cpp:8753: ExprResult clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int, const clang::UnresolvedSetImpl &, clang::Expr *, clang::Expr *): Assertion `Result.isInvalid() && "C++ binary operator overloading is missing candidates!"' failed. 0 libLLVM-3.0svn.so 0x00007f69a56bc78f 1 libLLVM-3.0svn.so 0x00007f69a56bcb81 2 libpthread.so.0 0x00007f69a4697ff0 3 libc.so.6 0x00007f69a39b5605 gsignal + 53 4 libc.so.6 0x00007f69a39b6905 abort + 389 5 libc.so.6 0x00007f69a39ae235 __assert_fail + 245 6 clang 0x0000000000de0d82 7 clang 0x0000000000d7502c clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 300 8 clang 0x0000000000e6060f 9 clang 0x0000000000e5a740 10 clang 0x0000000000e5a3d1 11 clang 0x0000000000e66407 12 clang 0x0000000000e5a037 13 clang 0x0000000000e6a7ac 14 clang 0x0000000000e5a0cb 15 clang 0x0000000000e66407 16 clang 0x0000000000e5a037 17 clang 0x0000000000e6aae7 18 clang 0x0000000000e5a115 19 clang 0x0000000000e66407 20 clang 0x0000000000e5a037 21 clang 0x0000000000e6aae7 22 clang 0x0000000000e5a115 23 clang 0x0000000000e66407 24 clang 0x0000000000e5a037 25 clang 0x0000000000e59f0e clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) + 94 26 clang 0x0000000000e7b182 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 1570 27 clang 0x0000000000e7bce4 clang::Sema::PerformPendingInstantiations(bool) + 388 28 clang 0x0000000000cbbf8f clang::Sema::ActOnEndOfTranslationUnit() + 239 29 clang 0x0000000000c8b966 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 150 30 clang 0x0000000000c7505f clang::ParseAST(clang::Sema&, bool) + 303 31 clang 0x0000000000b734df clang::CodeGenAction::ExecuteAction() + 623 32 clang 0x0000000000a968b7 clang::FrontendAction::Execute() + 231 33 clang 0x0000000000a842ea clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 506 34 clang 0x0000000000a4fef0 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 640 35 clang 0x0000000000a460d7 cc1_main(char const**, char const**, char const*, void*) + 647 36 clang 0x0000000000a4c680 main + 368 37 libc.so.6 0x00007f69a39a1c7d __libc_start_main + 253 38 clang 0x0000000000a45d89 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name single.ii -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21 -momit-leaf-frame-pointer -coverage-file single.o -resource-dir /usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 238 -fgnu-runtime -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o single.o -x c++-cpp-output single.ii 1. parser at end of file 2. /home/pipping/eigen-3.0.1/Eigen/src/Jacobi/Jacobi.h:306:6: instantiating function definition 'apply_rotation_in_the_plane' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) pipping at bogus /home/pipping % -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 20:35:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 20:35:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 10271] New: Add contains() to ImmutableList Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10271 Summary: Add contains() to ImmutableList Product: new-bugs Version: trunk Platform: Macintosh OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: rpaulo at apple.com CC: llvmbugs at cs.uiuc.edu I would like to have a contains() method in ImmutableList so I can use it in clang: GRStateTrail / PthreadLockChecker. Attached is a patch. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 23:55:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 23:55:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10272] New: attribute in method in template class doesn't survive instantiation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10272 Summary: attribute in method in template class doesn't survive instantiation Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Given: template struct Vector { void growStorageBy(); }; template __attribute__((noinline)) void Vector::growStorageBy() { } void foo() { Vector strs; strs.growStorageBy(); } clang produces: define linkonce_odr void @_ZN6VectorIiE13growStorageByEv(%struct.Vector* %this) nounwind align 2 { Note that the noinline is missing. Adding for (DeclContext::decl_iterator I = Tmpl->getDeclContext()->decls_begin(), E = Tmpl->getDeclContext()->decls_end(); I != E; ++I) { Decl *D = *I; for (AttrVec::const_iterator i = D->attr_begin(), e = D->attr_end(); i != e; ++i) { const Attr *TmplAttr = *i; if (TmplAttr->getKind() == clang::attr::NoInline) { assert(0 && "foo"); } } } to Sema::InstantiateAttrs hits the assert, so the attribute is available in a redeclaration. Now, I don't know if the attribute should have been merged at this point or if Sema::InstantiateAttrs should walk redeclations. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 4 23:58:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 4 Jul 2011 23:58:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 10273] New: clang++ asserts when including Boost.Spirit header Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10273 Summary: clang++ asserts when including Boost.Spirit header Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tziltzal at y7mail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com compiling: #include int main() { } by issuing: /usr/local/bin/clang++ -o CMakeFiles/test.dir/test.cpp.o -c /home/user/Sources/test/test.cpp (through cmake finding boost 1.44) produced: clang: /usr/src/llvm/tools/clang/lib/AST/Decl.cpp:1683: void clang::FunctionDecl::setParams(clang::ASTContext&, clang::ParmVarDecl**, unsigned int): Assertion `NumParams == getNumParams() && "Parameter count mismatch!"' failed. 0 clang 0x0000000001bc97ff 1 clang 0x0000000001bca33a 2 libpthread.so.0 0x000000370780eeb0 3 libc.so.6 0x0000003706c330c5 gsignal + 53 4 libc.so.6 0x0000003706c34a76 abort + 390 5 libc.so.6 0x0000003706c2b905 __assert_fail + 245 6 clang 0x0000000000f39acc 7 clang 0x0000000000bfcce4 clang::TemplateDeclInstantiator::VisitFunctionDecl(clang::FunctionDecl*, clang::TemplateParameterList*) + 1076 8 clang 0x0000000000bfbfad clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 125 9 clang 0x0000000000bc9d1c clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*) + 2636 10 clang 0x0000000000bcb589 clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, clang::Expr**, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 1065 11 clang 0x0000000000b369a9 clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::TemplateArgumentListInfo*, clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool) + 393 12 clang 0x0000000000b4295b clang::Sema::AddOverloadedCallCandidates(clang::UnresolvedLookupExpr*, clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool) + 219 13 clang 0x0000000000b42c20 clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation, clang::Expr*) + 208 14 clang 0x0000000000abd87a clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, clang::ASTMultiPtr, clang::SourceLocation, clang::Expr*) + 778 15 clang 0x00000000009744bc clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) + 2332 16 clang 0x000000000096e75b clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 203 17 clang 0x0000000000970bfe clang::Parser::ParseCastExpression(bool, bool, bool) + 46 18 clang 0x000000000096fb81 clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 5361 19 clang 0x0000000000970bfe clang::Parser::ParseCastExpression(bool, bool, bool) + 46 20 clang 0x00000000009716a2 clang::Parser::ParseAssignmentExpression() + 34 21 clang 0x0000000000972389 clang::Parser::ParseExpression() + 9 22 clang 0x0000000000970fb2 clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) + 882 23 clang 0x00000000009716b2 clang::Parser::ParseAssignmentExpression() + 50 24 clang 0x0000000000972389 clang::Parser::ParseExpression() + 9 25 clang 0x00000000009288b0 clang::Parser::ParseReturnStatement(clang::ParsedAttributes&) + 176 26 clang 0x000000000092d9e8 clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 520 27 clang 0x000000000092b2fa clang::Parser::ParseCompoundStatementBody(bool) + 1626 28 clang 0x000000000092baa5 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 149 29 clang 0x00000000009479b3 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 2067 30 clang 0x0000000000954f30 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1472 31 clang 0x00000000009424f1 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 145 32 clang 0x0000000000942ae3 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 531 33 clang 0x0000000000944e90 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 3184 34 clang 0x00000000009660d9 clang::Parser::ParseInnerNamespace(std::vector >&, std::vector >&, std::vector >&, unsigned int, clang::SourceLocation&, clang::SourceLocation&, clang::ParsedAttributes&, clang::SourceLocation&) + 377 35 clang 0x000000000096c116 clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) + 3734 36 clang 0x000000000095aa77 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 567 37 clang 0x0000000000944480 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 608 38 clang 0x00000000009660d9 clang::Parser::ParseInnerNamespace(std::vector >&, std::vector >&, std::vector >&, unsigned int, clang::SourceLocation&, clang::SourceLocation&, clang::ParsedAttributes&, clang::SourceLocation&) + 377 39 clang 0x000000000096c116 clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) + 3734 40 clang 0x000000000095aa77 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 567 41 clang 0x0000000000944480 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 608 42 clang 0x00000000009660d9 clang::Parser::ParseInnerNamespace(std::vector >&, std::vector >&, std::vector >&, unsigned int, clang::SourceLocation&, clang::SourceLocation&, clang::ParsedAttributes&, clang::SourceLocation&) + 377 43 clang 0x000000000096c116 clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) + 3734 44 clang 0x000000000095aa77 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 567 45 clang 0x0000000000944480 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 608 46 clang 0x000000000094515c clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 156 47 clang 0x000000000091a51d clang::ParseAST(clang::Sema&, bool) + 189 48 clang 0x00000000007bacd4 clang::CodeGenAction::ExecuteAction() + 68 49 clang 0x00000000006b0653 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371 50 clang 0x0000000000688bcd clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1181 51 clang 0x000000000067d66b cc1_main(char const**, char const**, char const*, void*) + 779 52 clang 0x0000000000687b43 main + 7283 53 libc.so.6 0x0000003706c1ee5d __libc_start_main + 253 54 clang 0x000000000067d179 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name test.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51.0.7 -momit-leaf-frame-pointer -coverage-file CMakeFiles/test.dir/test.cpp.o -resource-dir /usr/local/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 237 -fgnu-runtime -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o CMakeFiles/test.dir/test.cpp.o -x c++ /home/user/Sources/test/test.cpp 1. /usr/include/boost/spirit/home/qi/numeric/detail/real_impl.hpp:82:50: current parser token ')' 2. /usr/include/boost/spirit/home/qi/numeric/detail/real_impl.hpp:31:1: parsing namespace 'boost' 3. /usr/include/boost/spirit/home/qi/numeric/detail/real_impl.hpp:31:19: parsing namespace 'spirit' 4. /usr/include/boost/spirit/home/qi/numeric/detail/real_impl.hpp:31:38: parsing namespace 'traits' 5. /usr/include/boost/spirit/home/qi/numeric/detail/real_impl.hpp:81:5: parsing function body 'negate' 6. /usr/include/boost/spirit/home/qi/numeric/detail/real_impl.hpp:81:5: in compound statement ('{}') clang: error: unable to execute command: Aborted (core dumped) clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) clang++ --version outputs: clang version 3.0 (trunk 134402) Target: x86_64-unknown-linux-gnu Thread model: posix llvm & clang were compiled together with --enabled-optimize. uname -a outputs: Linux fedora-host 2.6.35.13-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011 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 Tue Jul 5 01:10:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 01:10:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 10274] New: format function attribute with the NSString archetype yields no compiler warnings Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10274 Summary: format function attribute with the NSString archetype yields no compiler warnings Product: clang Version: 2.9 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: macbavarious at gmail.com CC: llvmbugs at cs.uiuc.edu The following code: #import extern void test0(const char *format, ...) __attribute__((format(__printf__, 1, 2))); extern void test1(NSString *format, ...) __attribute__((format(__NSString__, 1, 2))); void function(void) { test0("%d"); test0("%d", "foo"); test1(@"%d"); test1(@"%d", "foo"); } yields warnings for test0() calls only: $ clang -c -Wformat bug0.m bug0.m:7:13: warning: more '%' conversions than data arguments [-Wformat] test0("%d"); ~^ bug0.m:8:13: warning: conversion specifies type 'int' but the argument has type 'char *' [-Wformat] test0("%d", "foo"); ~^ ~~~~~ %s 2 warnings generated. so it seems that the __NSString__ archetype doesn't yield compiler warnings when there's a mismatch between the format NSString and the arguments. This has been tested with: $ clang --version Apple clang version 2.0 (tags/Apple/clang-137) (based on LLVM 2.9svn) 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 Tue Jul 5 01:15:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 01:15:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10275] New: format function attribute isn't checked in Objective-C methods Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10275 Summary: format function attribute isn't checked in Objective-C methods Product: clang Version: 2.9 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: macbavarious at gmail.com CC: llvmbugs at cs.uiuc.edu The following code: #import @interface Test + (void)test2:(NSString *)format, ... __attribute__((format(__NSString__, 1, 2))); + (void)test3:(const char *)format, ... __attribute__((format(__printf__, 1, 2))); - (void)test4:(NSString *)format, ... __attribute__((format(__NSString__, 1, 2))); - (void)test5:(const char *)format, ... __attribute__((format(__printf__, 1, 2))); @end void function(void) { [Test test2:@"%d"]; [Test test2:@"%d", "foo"]; [Test test3:"%d"]; [Test test3:"%d", "foo"]; Test *t; [t test4:@"%d"]; [t test4:@"%d", "foo"]; [t test5:"%d"]; [t test5:"%d", "foo"]; } which uses both the __printf__ and the __NSString__ archetypes in the format function attribute, doesn't yield any compiler warnings even though there's a mismatch in the number of arguments and the argument types: $ clang -c -Wformat bug1.m $ This has been tested with: $ clang --version Apple clang version 2.0 (tags/Apple/clang-137) (based on LLVM 2.9svn) 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 Tue Jul 5 02:22:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 02:22:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 10276] New: Problems with zlib Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10276 Summary: Problems with zlib Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: cullmann at absint.de CC: llvmbugs at cs.uiuc.edu Hi, I use zlib 1.2.5 in the following style: I have a FILE *stream from fopen. Then I do: int fileNumber = fileno (stream); m_gzFile = z_gzdopen (Ur::dup(fileNumber), "rb"); (This is done to allow multiple backends, normally I would read the header myself from the stream and then choose, but the bug occurs with just that sequence above) Now, my program hangs, inside read, always: read (state=, buf=, len=, have=) at /usr/include/bits/unistd.h:37 37 if (__bos0 (__buf) != (size_t) -1) (gdb) bt #0 read (state=, buf=, len=, have=) at /usr/include/bits/unistd.h:37 #1 gz_load (state=, buf=, len=, have=) at /local/cullmann/build/llvm.default.release/libur/3rdparty/zlib/gzread.c:31 #2 0x00000000004342e2 in gz_avail (state=) at /local/cullmann/build/llvm.default.release/libur/3rdparty/zlib/gzread.c:58 #3 0x0000000000433dad in gz_head (state=) at /local/cullmann/build/llvm.default.release/libur/3rdparty/zlib/gzread.c:143 #4 0x0000000000433758 in gz_make (state=) at /local/cullmann/build/llvm.default.release/libur/3rdparty/zlib/gzread.c:310 #5 0x000000000043361d in z_gzread (file=, buf=, len=Unhandled dwarf expression opcode 0x0 ) at /local/cullmann/build/llvm.default.release/libur/3rdparty/zlib/gzread.c:418 #6 0x0000000000421e27 in Ur::FileStreamInZLib::read (this=, data=, size=) at /local/cullmann/build/llvm.default.release/libur/src/filestream_internal.h:518 #7 0x000000000042020d in Ur::FileStreamIn::read (this=Unhandled dwarf expression opcode 0x0 ) at /local/cullmann/build/llvm.default.release/libur/src/filestream.cpp:225 #8 0x000000000042025a in Ur::FileStreamIn::read (this=Unhandled dwarf expression opcode 0xef ) at /local/cullmann/build/llvm.default.release/libur/src/filestream.cpp:248 #9 0x000000000041e8c0 in copy_compress_uncompress(char const*, char const*, Ur::FileStreamOut::CompressionMode) () at /local/cullmann/build/llvm.default.release/libur/bin/ur-compress.h:60 #10 0x00007ffff7a66eff in __libc_start_main (main=0x41e6a0 , argc=3, ubp_av=0x7fffffffde38, init=, fini=, rtld_fini=, stack_end=0x7fffffffde28) at libc-start.c:226 #11 0x000000000041e5a9 in _start () This only occurs with clang/clang++ (without any compiler warnings/errors) but works perfectly well with GCC (on both linux + macos) and MSVC on win32/64. Any ideas? Tried to debug this but really see no 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 Tue Jul 5 04:32:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 04:32:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 10277] New: After r134372, segfault in InlineSpiller::analyzeSiblingValues() Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10277 Summary: After r134372, segfault in InlineSpiller::analyzeSiblingValues() Product: new-bugs Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6829) --> (http://llvm.org/bugs/attachment.cgi?id=6829) Crashes InlineSpiller::analyzeSiblingValues() if compiled with -O2 After r134372, I started getting segfaults in MipsFrameLowering.cpp, while self-hosting on FreeBSD/i386: gmake[3]: Entering directory `/home/dim/obj/llvm-2/lib/Target/Mips' llvm[3]: Compiling MipsFrameLowering.cpp for Release+Asserts build if /home/dim/llvm/134372M-gcc-rel-1/bin/clang++ -I/home/dim/obj/llvm-2/include -I/home/dim/obj/llvm-2/lib/Target/Mips -I/home/dim/src/llvm/trunk/include -I/home/dim/src/llvm/trunk/lib/Target/Mips -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-exceptions -fno-rtti -fPIC -Woverloaded-virtual -Wcast-qual -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -c -MMD -MP -MF "/home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.d.tmp" -MT "/home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.o" -MT "/home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.d" /home/dim/src/llvm/trunk/lib/Target/Mips/MipsFrameLowering.cpp -o /home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.o ; \ then /bin/mv -f "/home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.d.tmp" "/home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.d"; else /bin/rm "/home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.d.tmp"; exit 1; fi Stack dump: 0. Program arguments: /home/dim/llvm/134372M-gcc-rel-1/bin/clang -cc1 -triple i386-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name MipsFrameLowering.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -target-linker-version 2.17.50 -momit-leaf-frame-pointer -coverage-file /home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.o -resource-dir /home/dim/llvm/134372M-gcc-rel-1/bin/../lib/clang/3.0 -dependency-file /home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.d.tmp -MP -MT /home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.o -MT /home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.d -D _DEBUG -D _GNU_SOURCE -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I /home/dim/obj/llvm-2/include -I /home/dim/obj/llvm-2/lib/Target/Mips -I /home/dim/src/llvm/trunk/include -I /home/dim/src/llvm/trunk/lib/Target/Mips -O2 -Woverloaded-virtual -Wcast-qual -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -fconst-strings -fdeprecated-macro -ferror-limit 19 -fmessage-length 237 -fno-rtti -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /home/dim/obj/llvm-2/lib/Target/Mips/Release+Asserts/MipsFrameLowering.o -x c++ /home/dim/src/llvm/trunk/lib/Target/Mips/MipsFrameLowering.cpp 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/home/dim/src/llvm/trunk/lib/Target/Mips/MipsFrameLowering.cpp'. 4. Running pass 'Greedy Register Allocator' on function '@_ZNK4llvm17MipsFrameLowering12emitPrologueERNS_15MachineFunctionE' clang: error: unable to execute command: Segmentation fault: 11 (core dumped) clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) Running this in gdb gives the following backtrace: #0 0x0967a0d3 in (anonymous namespace)::InlineSpiller::analyzeSiblingValues () #1 0x0967fcf7 in (anonymous namespace)::InlineSpiller::spill () #2 0x095a7a48 in (anonymous namespace)::RAGreedy::selectOrSplit () #3 0x096c8600 in llvm::RegAllocBase::allocatePhysRegs () #4 0x095a13d5 in (anonymous namespace)::RAGreedy::runOnMachineFunction () #5 0x0954f471 in llvm::MachineFunctionPass::runOnFunction () #6 0x09a68054 in llvm::FPPassManager::runOnFunction () #7 0x09a68117 in llvm::FPPassManager::runOnModule () #8 0x09a67bef in llvm::MPPassManager::runOnModule () #9 0x09a67d2b in llvm::PassManagerImpl::run () #10 0x09a67dd7 in llvm::PassManager::run () #11 0x0848f533 in clang::EmitBackendOutput () Adding a few debug printfs to InlineSpiller::analyzeSiblingValues() reveals that in this function, OrigLI.getVNInfoAt(VNI->def) returns NULL sometimes, leading to the segfault in the next if() statement: void InlineSpiller::analyzeSiblingValues() { ... if (VNI->isPHIDef() || VNI->getCopy()) { VNInfo *OrigVNI = OrigLI.getVNInfoAt(VNI->def); fprintf(stderr, "DBG: OrigVNI=%p, VNI=%p\n", OrigVNI, VNI); if (OrigVNI->def != VNI->def) { I have attached the reduced testcase I generated from MipsFrameLowering.cpp. Compile this with "clang -O2" to reproduce the segfault. Note, for some reason, the segfault only occurs on i386, *not* on x86_64... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 5 04:38:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 04:38:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10278] New: Problem with Custom Allocator Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10278 Summary: Problem with Custom Allocator Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: cullmann at absint.de CC: llvmbugs at cs.uiuc.edu Hi, given the following allocator: /** * Generic Pool Allocator Template */ template class PoolAllocator { public: /** * Size */ typedef size_t size_type; /** * Pointer difference */ typedef ptrdiff_t difference_type; /** * Pointer */ typedef T* pointer; /** * Const Pointer */ typedef const T* const_pointer; /** * Reference */ typedef T& reference; /** * Const Reference */ typedef const T& const_reference; /** * Value */ typedef T value_type; /** * Rebind */ template struct rebind { /** * Rebind implementation */ typedef PoolAllocator other; }; /** * Constructor */ PoolAllocator() { } /** * Copy-Constructor * @param other other allocator */ template PoolAllocator (const PoolAllocator &other) { (void) other; } /** * Give address * @param x reference * @return address for reference */ pointer address(reference x) const { return &x; } /** * Give address (const) * @param x reference * @return address for reference */ const_pointer address(const_reference x) const { return &x; } /** * Allocate memory for given count of elements * @param size number of elements to allocate * @param hint optimizer hint * @return allocated memory or 0 */ pointer allocate(size_type size, PoolAllocator::const_pointer hint = 0) { (void) hint; return static_cast (poolAllocate(size*sizeof(T))); } /** * Deallocate given memory with given number of elements * @param p pointer to deallocate * @param size number of elements allocated there */ void deallocate(pointer p, size_type size) { poolDeallocate(p, size*sizeof(T)); } /** * Maximal amount allocatable * @return maximal number of elements allocatable */ size_type max_size() const throw() { return size_t(-1) / sizeof(value_type); } /** * Construct object * @param p pointer where to construct */ void construct(pointer p) { new(p) T(); } /** * Construct object * @param p pointer where to construct * @param val value */ void construct(pointer p, const T& val) { new(p) T(val); } /** * Deconstruct object * @param p pointer where to deconstruct */ void destroy(pointer p) { p->~T(); } }; I get this error message that no usable construct function is available: /local/cullmann/build/llvm.default.release/usr/include/c++/v1/memory:1530:18: error: no matching member function for call to 'construct' {__a.construct(__p, _VSTD::forward<_Args>(__args)...);} ~~~~^~~~~~~~~ /local/cullmann/build/llvm.default.release/usr/include/c++/v1/memory:1468:14: note: in instantiation of function template specialization 'std::__1::allocator_traits, void *> > >::__construct' requested here {__construct(__has_construct(), ^ /local/cullmann/build/llvm.default.release/usr/include/c++/v1/map:1228:20: note: in instantiation of function template specialization 'std::__1::allocator_traits, void *> > >::construct' requested here __node_traits::construct(__na, _VSTD::addressof(__h->__value_.second), _VSTD::forward<_Args>(__args)...); ^ /local/cullmann/build/llvm.default.release/usr/include/c++/v1/map:1279:29: note: in instantiation of function template specialization 'std::__1::map > >::__construct_node' requested here __node_holder __h = __construct_node(_VSTD::move(__k)); ^ /local/cullmann/build/llvm.default.release/libtf14net/src/to_string.cpp:730:17: note: in instantiation of member function 'std::__1::map > >::operator[]' requested here topo[type->cast_TypeNamed()->name()] = level; ^ /local/cullmann/build/llvm.default.release/usr/include/ur/poolallocator.h:231:14: note: candidate function not viable: no known conversion from 'int *' to 'pointer' (aka 'std::__1::__tree_node, void *> *') for 1st argument void construct(pointer p) ^ /local/cullmann/build/llvm.default.release/usr/include/ur/poolallocator.h:241:14: note: candidate function not viable: requires 2 arguments, but 1 was provided void construct(pointer p, const T& val) ^ Only wait to get this compiling is introducing ambigious function void construct(pointer p, const T& val = T ()) in addition to void construct(pointer p) The allocator works well with gcc stl and MSVC stl. Is this a problem with libc++ or with clang not finding the correct overloaded variant? Or dumb error on my side? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 5 05:35:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 05:35:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10279] New: lli barfs with "pseudo instructions should be removed before code emission" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10279 Summary: lli barfs with "pseudo instructions should be removed before code emission" Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: srk31 at srcf.ucam.org CC: llvmbugs at cs.uiuc.edu I'm getting the following strange error from lli. $ lli out/host/linux-x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/LINKED/dalvikvm.bc.bc pseudo instructions should be removed before code emission UNREACHABLE executed at X86CodeEmitter.cpp:720! 0 lli 0x0000000000e3b2ff 1 lli 0x0000000000e3bd63 2 libpthread.so.0 0x0000003b7f60f4a0 3 libc.so.6 0x0000003b7ea328f5 gsignal + 53 4 libc.so.6 0x0000003b7ea340d5 abort + 373 5 lli 0x0000000000e1e3ac 6 lli 0x000000000067f482 7 lli 0x00000000006809a5 8 lli 0x0000000000dadec7 llvm::FPPassManager::runOnFunction(llvm::Function&) + 567 9 lli 0x0000000000dadffb llvm::FunctionPassManagerImpl::run(llvm::Function&) + 139 10 lli 0x0000000000dae169 llvm::FunctionPassManager::run(llvm::Function&) + 105 11 lli 0x00000000008f09be llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 46 12 lli 0x00000000008f35ec llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 28 13 lli 0x00000000008f3870 llvm::JIT::getPointerToFunction(llvm::Function*) + 272 14 lli 0x00000000008f1fa4 llvm::JIT::runFunction(llvm::Function*, std::__debug::vector > const&) + 52 15 lli 0x0000000000c7b42d llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::__debug::vector > const&, char const* const*) + 1757 16 lli 0x0000000000617dfc main + 1612 17 libc.so.6 0x0000003b7ea1ec5d __libc_start_main + 253 18 lli 0x000000000061f1ad Stack dump: 0. Program arguments: lli out/host/linux-x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/LINKED/dalvikvm.bc.bc 1. Running pass 'X86 Machine Code Emitter' on function '@main' Aborted (core dumped) This is with a Release+Debug+Asserts+Checks build of the 2.9 release, on a FC13 x86-64 machine. You can probably reproduce with the following bitcode file: . (I was expecting it to need external bitcode libraries that I built alongside it, but it gets at least as far as the bug without them. Maybe they're already linked in -- I don't yet understand bitcode linkage enough to say.) To investigate further, I hacked X86CodeEmitter.cpp as follows: --- lib/Target/X86/X86CodeEmitter.cpp 2010-10-09 00:59:27.000000000 +0100 +++ lib/Target/X86/X86CodeEmitter-hacked.cpp 2011-07-04 16:10:44.000000000 +0100 @@ -715,6 +715,7 @@ // base address. switch (Opcode) { default: + dbgs() << MI; llvm_unreachable("pseudo instructions should be removed before code" " emission"); break; which prints DBG_VALUE 0, 0, !"needExtra"; dbg:Main.c:149 and the relevant bit of Main.c looks like this: 148 int optionCount, curOpt, i, argIdx; 149 int needExtra = JNI_FALSE; 150 int result = 1; ... i.e. nothing out of the ordinary. The disassembly looks normal too, although I wouldn't really know. Here's a (carefully snipped) log showing how make built the bitcode file: -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 5 07:18:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 07:18:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10280] New: undefined reference error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10280 Summary: undefined reference error Product: dragonegg Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: New Bugs AssignedTo: baldrick at free.fr ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu I've got the link failure only when dragonegg is used. Since the linking through the regular gcc goes well without an error I think it's a dragonegg bug. Linking CXX executable bin/OcelotConfig lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_lock_error::what() const' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_wait_error::~__concurrence_wait_error()' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_wait_error::what() const' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_lock_error::~__concurrence_lock_error()' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_unlock_error::~__concurrence_unlock_error()' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_broadcast_error::what() const' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_unlock_error::what() const' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_wait_error::~__concurrence_wait_error()' lib/libocelot.so: undefined reference to `boost::assign::assignment_exception::what() const' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_unlock_error::~__concurrence_unlock_error()' lib/libocelot.so: undefined reference to `boost::assign::assignment_exception::~assignment_exception()' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_lock_error::~__concurrence_lock_error()' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_broadcast_error::~__concurrence_broadcast_error()' lib/libocelot.so: undefined reference to `boost::assign::assignment_exception::~assignment_exception()' lib/libocelot.so: undefined reference to `__gnu_cxx::__concurrence_broadcast_error::~__concurrence_broadcast_error()' $ ldd -r ./lib/libocelot.so linux-vdso.so.1 => (0x00007fff2954e000) libdl.so.2 => /lib/libdl.so.2 (0x00007fc8bbe00000) librt.so.1 => /lib/librt.so.1 (0x00007fc8bbbf8000) libboost_thread-mt.so.1.46.1 => /usr/lib/libboost_thread-mt.so.1.46.1 (0x00007fc8bb9de000) libboost_system-mt.so.1.46.1 => /usr/lib/libboost_system-mt.so.1.46.1 (0x00007fc8bb7db000) libLLVMX86CodeGen.so => /usr/lib/libLLVMX86CodeGen.so (0x00007fc8bb41e000) libLLVMSelectionDAG.so => /usr/lib/libLLVMSelectionDAG.so (0x00007fc8bb007000) libLLVMAsmPrinter.so => /usr/lib/libLLVMAsmPrinter.so (0x00007fc8badae000) libLLVMMCParser.so => /usr/lib/libLLVMMCParser.so (0x00007fc8bab8c000) libLLVMX86AsmPrinter.so => /usr/lib/libLLVMX86AsmPrinter.so (0x00007fc8ba951000) libLLVMX86Utils.so => /usr/lib/libLLVMX86Utils.so (0x00007fc8ba74e000) libLLVMX86Info.so => /usr/lib/libLLVMX86Info.so (0x00007fc8ba54c000) libLLVMAsmParser.so => /usr/lib/libLLVMAsmParser.so (0x00007fc8ba313000) libLLVMJIT.so => /usr/lib/libLLVMJIT.so (0x00007fc8ba0e2000) libLLVMExecutionEngine.so => /usr/lib/libLLVMExecutionEngine.so (0x00007fc8b9ec8000) libLLVMCodeGen.so => /usr/lib/libLLVMCodeGen.so (0x00007fc8b99e9000) libLLVMScalarOpts.so => /usr/lib/libLLVMScalarOpts.so (0x00007fc8b96bd000) libLLVMInstCombine.so => /usr/lib/libLLVMInstCombine.so (0x00007fc8b9421000) libLLVMTransformUtils.so => /usr/lib/libLLVMTransformUtils.so (0x00007fc8b915f000) libLLVMipa.so => /usr/lib/libLLVMipa.so (0x00007fc8b8f3f000) libLLVMAnalysis.so => /usr/lib/libLLVMAnalysis.so (0x00007fc8b8b7c000) libLLVMTarget.so => /usr/lib/libLLVMTarget.so (0x00007fc8b8953000) libLLVMMC.so => /usr/lib/libLLVMMC.so (0x00007fc8b86be000) libLLVMCore.so => /usr/lib/libLLVMCore.so (0x00007fc8b8307000) libLLVMSupport.so => /usr/lib/libLLVMSupport.so (0x00007fc8b8051000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fc8b7d47000) libm.so.6 => /lib/libm.so.6 (0x00007fc8b7ac5000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fc8b78ae000) libc.so.6 => /lib/libc.so.6 (0x00007fc8b754d000) /lib/ld-linux-x86-64.so.2 (0x00007fc8bc620000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc8b7330000) undefined symbol: _ZN5boost6assign20assignment_exceptionD2Ev (./lib/libocelot.so) undefined symbol: _ZN5boost6assign20assignment_exceptionD0Ev (./lib/libocelot.so) undefined symbol: _ZNK5boost6assign20assignment_exception4whatEv (./lib/libocelot.so) undefined symbol: _ZN9__gnu_cxx24__concurrence_lock_errorD2Ev (./lib/libocelot.so) undefined symbol: _ZN9__gnu_cxx24__concurrence_lock_errorD0Ev (./lib/libocelot.so) undefined symbol: _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv (./lib/libocelot.so) undefined symbol: _ZN9__gnu_cxx26__concurrence_unlock_errorD2Ev (./lib/libocelot.so) undefined symbol: _ZN9__gnu_cxx26__concurrence_unlock_errorD0Ev (./lib/libocelot.so) undefined symbol: _ZNK9__gnu_cxx26__concurrence_unlock_error4whatEv (./lib/libocelot.so) undefined symbol: _ZN9__gnu_cxx29__concurrence_broadcast_errorD2Ev (./lib/libocelot.so) undefined symbol: _ZN9__gnu_cxx29__concurrence_broadcast_errorD0Ev (./lib/libocelot.so) undefined symbol: _ZNK9__gnu_cxx29__concurrence_broadcast_error4whatEv (./lib/libocelot.so) undefined symbol: _ZN9__gnu_cxx24__concurrence_wait_errorD2Ev (./lib/libocelot.so) undefined symbol: _ZN9__gnu_cxx24__concurrence_wait_errorD0Ev (./lib/libocelot.so) undefined symbol: _ZNK9__gnu_cxx24__concurrence_wait_error4whatEv (./lib/libocelot.so) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 5 09:14:58 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 09:14:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 10278] Problem with Custom Allocator In-Reply-To: References: Message-ID: <20110705141459.3D9732A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10278 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Howard Hinnant 2011-07-05 09:14:58 CDT --- You found a bug, thanks! Fix Committed revision 134405. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 5 09:36:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 09:36:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10276] Problems with zlib In-Reply-To: References: Message-ID: <20110705143630.C462B2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10276 Christoph Cullmann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #4 from Christoph Cullmann 2011-07-05 09:36:30 CDT --- Works now, seemed to have been issue with corrupted heap because of bug 10278. *** This bug has been marked as a duplicate of bug 10278 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 5 09:52:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 09:52:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10276] Problems with zlib In-Reply-To: References: Message-ID: <20110705145207.4B1BE2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10276 Christoph Cullmann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE | --- Comment #5 from Christoph Cullmann 2011-07-05 09:52:06 CDT --- And open again, seems that is only broken with -O2, otherwise it works. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 5 11:16:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 11:16:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10270] [C++] aborts during compilation In-Reply-To: References: Message-ID: <20110705161648.CF9CC2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10270 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2011-07-05 11:16:48 CDT --- I've committed Hans' patch as Clang r134416. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 5 11:50:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 11:50:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 10277] After r134372, segfault in InlineSpiller::analyzeSiblingValues() In-Reply-To: References: Message-ID: <20110705165002.F2E622A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10277 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Jakob Stoklund Olesen 2011-07-05 11:50:02 CDT --- Fixed in r134413. Rafael, if you found a different issue, please open a new PR. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 5 12:25:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 12:25:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 10222] llc -O0 crash somehow due to debug info In-Reply-To: References: Message-ID: <20110705172516.CE1BB2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10222 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Devang Patel 2011-07-05 12:25:16 CDT --- I am not able to reproduce this using r134418. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 5 13:30:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 13:30:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10273] clang++ asserts when including Boost.Spirit header In-Reply-To: References: Message-ID: <20110705183041.0D2D22A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10273 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2011-07-05 13:30:40 CDT --- Fixed in Clang r134426. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 5 16:15:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 16:15:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 10237] Segfault when dereferencing a forward-declared struct In-Reply-To: References: Message-ID: <20110705211556.ACA402A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10237 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-07-05 16:15:56 CDT --- I think r134416 fixed this; please reopen if you still see the issue 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 Tue Jul 5 16:30:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 16:30:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 10281] New: Clang cannot compile on centos with gcc 4.4 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10281 Summary: Clang cannot compile on centos with gcc 4.4 Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: Pidgeot18 at gmail.com CC: llvmbugs at cs.uiuc.edu This package of gcc apparently uses x86_64-redhat-linux6E instead of x86_64-redhat-linux to store the files, which renders using the C++ STL impossible. Running clang++ -I/usr/include/c++/4.4.4/x86_64-redhat-linux6E/ gets it to 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 Jul 5 17:22:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 17:22:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10270] [C++] aborts during compilation In-Reply-To: References: Message-ID: <20110705222200.1BB462A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10270 Elias Pipping changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 5 20:35:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 5 Jul 2011 20:35:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 6992] Unfortunate code placement for PHI lowering In-Reply-To: References: Message-ID: <20110706013510.14B8A2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6992 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |evan.cheng at apple.com Resolution| |FIXED --- Comment #2 from Evan Cheng 2011-07-05 20:35:09 CDT --- Yep. Fixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 6 01:58:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 01:58:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10264] Rejects-valid and sometimes a crash with defining fixed enums out of scope In-Reply-To: References: Message-ID: <20110706065839.9FC3E2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10264 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from John McCall 2011-07-06 01:58:38 CDT --- Fixed in r134468 and r134479. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 03:02:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 03:02:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10260] IRgen assert from instantiating initializer pack expansion with empty pack In-Reply-To: References: Message-ID: <20110706080218.1A4882A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10260 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from John McCall 2011-07-06 03:02:17 CDT --- Fixed in r134483. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 06:05:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 06:05:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10282] New: [SPARC] Assertion in Tail Duplication Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10282 Summary: [SPARC] Assertion in Tail Duplication Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6837) --> (http://llvm.org/bugs/attachment.cgi?id=6837) Test case Attached byte code triggers the assertion in r134437. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 08:16:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 08:16:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10283] New: Spell checking triggers "correction has not been looked up" assertion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10283 Summary: Spell checking triggers "correction has not been looked up" assertion Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hans at chromium.org CC: llvmbugs at cs.uiuc.edu Spell checking triggers "correction has not been looked up" assertion when a typo result is an overloaded function, e.g. for code such as this: void sin(int); void sin(void); void f() { min(5); } or template void sin(); void f() { min(); } This seems to have regressed when namespace-aware typo checking was landed in r134007. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 08:17:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 08:17:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10270] [C++] aborts during compilation In-Reply-To: References: Message-ID: <20110706131759.AE3A42A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10270 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #6 from Hans Wennborg 2011-07-06 08:17:58 CDT --- (In reply to comment #5) > Created an attachment (id=6835) --> (http://llvm.org/bugs/attachment.cgi?id=6835) [details] > new reduction > > Good news and bad news. > > Good news: now with clang 3.0 git-9a30c9946e898e595eb71f23dc9a60303428998b the > reduced sample indeed no longer makes clang++ crash. Great :) > > Bad news: The Original sample (single.ii) still does! So here's another > reduction that still managed to make clang++ crash. Thanks. I've filed Bug 10283 for that since it's a different 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 Jul 6 09:30:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 09:30:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10284] New: False positives for null pointer dereferences with glib/gtk+ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10284 Summary: False positives for null pointer dereferences with glib/gtk+ Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: kjartan.maraas at gmail.com CC: llvmbugs at cs.uiuc.edu I'm seeing a huge amount of false positives here when building gtk+ One assumption within glib/gtk+ that the analyzer doesn't pick up is that priv pointers can never be NULL. They are set early on in the various _init functions for the different widgets and then not set again. It also looks like the analyzer doesn't understand the parameter checking in glib with functions like this generating warnings: void 1837 _gtk_tree_menu_set_row_span_column (GtkTreeMenu *menu, 1838 gint row_span) 1839 { 1840 GtkTreeMenuPrivate *priv; 1841 1842 g_return_if_fail (GTK_IS_TREE_MENU (menu)); 1843 1844 priv = menu->priv; Access to field 'priv' results in a dereference of a null pointer (loaded from variable 'menu') 1845 the function will return in g_return_if_fail() if menu is NULL. Also as mentioned above menu->priv should never be NULL, and the only way to make it be so is to intentionally abuse the API and feed NULL pointers to the public functions. This is not something that the glib/gtk+ developers feel is worth spending resources on fixing just to silence the clang-analyzer. Is there a way to mark certain functions / patterns as excluded like there is for valgrind with supression files? Or will this have to be fixed in the analyzer itself? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 6 10:46:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 10:46:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 10272] attribute in method in template class doesn't survive instantiation In-Reply-To: References: Message-ID: <20110706154647.40E312A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10272 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Rafael ?vila de Esp?ndola 2011-07-06 10:46:46 CDT --- Fixed in 134491. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 10:59:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 10:59:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 10285] New: Improper assignment operator overload resolution Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10285 Summary: Improper assignment operator overload resolution Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hhinnant at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Apple clang version 3.0 (trunk 134483) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.0.0 Thread model: posix $ clang++ -std=c++0x test.cpp class A { public: A() {} template explicit A(_F&& __f); A(A&&) {} A& operator=(A&&) {return *this;} }; template void sort(T t) { A a; a = A(t); } int main() { sort(4); } test.cpp:18:7: error: overload resolution selected deleted operator '=' a = A(t); ~ ^ ~~~~ test.cpp:2:7: note: candidate function (the implicit copy assignment operator) has been explicitly deleted class A ^ test.cpp:11:8: note: candidate function not viable: no known conversion from 'A' to 'A &&' for 1st argument A& operator=(A&&) {return *this;} ^ 1 error generated. I expect it to compile, selecting the move assignment 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 Jul 6 11:22:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 11:22:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10286] New: Compiling code using labels as pointers produces s in disassembly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10286 Summary: Compiling code using labels as pointers produces s in disassembly Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: max99x at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6840) --> (http://llvm.org/bugs/attachment.cgi?id=6840) C source and resulting bytecode disassembly When compiling the attached program with clang -c -emit-llvm -m32, then disassembling the result with llvm-dis -show-annotations, the produced LL (also attached) contains instead of labels. Compiling straight away without -emit-llvm and disassembling produces a valid program. This happens on both 2.9 (from Arch Linux repositories) and trunk (built manually). Trunk configured with: ../llvm/configure --disable-debug-symbols --enable-optimized --disable-debug-runtime --disable-assertions --enable-multilib --with-cxx-include-32bit-dir=/usr/lib32 -with-cxx-include-32bit-dir=/usr/lib Works fine on llvm-gcc. The code comes from the emscripten test suite (https://github.com/kripken/emscripten), whose maintainer could not reproduce the issue. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 6 13:15:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 13:15:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 10232] Assertion failed: (isa(Val) && "cast() argument of incompatible type!"), function cast, file llvm/include/llvm/Support/Casting.h, line 194 In-Reply-To: References: Message-ID: <20110706181503.D385E2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10232 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2011-07-06 13:15:02 CDT --- Fixed in Clang r134515. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 13:30:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 13:30:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 10287] New: Unnecessary testl Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10287 Summary: Unnecessary testl Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu given double foobar(double x, int y) { unsigned n = y; double p = 1; while (true) { n >>= 1; if (n == 0) return p; } } gcc produces: __Z6foobardi: shrl %edi jne __Z6foobardi movsd 0x00000004(%rip),%xmm0 re clang produces: __Z6foobardi: shrl %edi testl %edi,%edi jne __Z6foobardi movsd 0x00000002(%rip),%xmm0 ret -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 6 13:41:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 13:41:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 10288] New: Clang rejects string literal initializer for char array that has no explicit size Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10288 Summary: Clang rejects string literal initializer for char array that has no explicit size Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang rejects "#1" and accepts "#2" char x[]("hello"); // #1 char x[6]("hello"); // #2 The example in clause 8.5.2 makes it clear that deducing the size of the initialized array is not dependent on enclosing braces, showing this example char x[] = "hello"; // no braces around the initializer This is accepted by clang. The existence of parentheses (not braces) around the initializer expression should not make a difference for non-class types, see 8.5p11. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 13:52:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 13:52:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10289] New: Clang incorrectly takes an unnamed bitfield as a member Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10289 Summary: Clang incorrectly takes an unnamed bitfield as a member Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following is valid C++03 code, as far as I can see struct A { private: int : 0; }; A a = { }; "A" is an aggregate, but clang complains main1.cpp:6:3: error: non-aggregate type 'A' cannot be initialized with an initializer list A a = { }; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 6 15:05:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 15:05:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 10290] New: Crash in LLVM VMCore Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10290 Summary: Crash in LLVM VMCore 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: rtrieu at google.com CC: llvmbugs at cs.uiuc.edu Testing some template code when LLVM crashed. Details below. ~/clang/test$ cat logical_constant2.cc template struct ei_are_flags_consistent { int ret = (Flags&5 && Flags&7); }; int main(int argc, char** argv) { ei_are_flags_consistent<4> foo; return 0; } ~/clang/test$ clang logical_constant2.cc logical_constant2.cc:3:11: warning: in-class initialization of non-static data member accepted as a C++0x extension [-Wc++0x-extensions] int ret = (Flags&5 && Flags&7); ^ logical_constant2.cc:3:22: warning: use of logical && with constant operand; switch to bitwise & or remove constant [-Wconstant-logical-operand] int ret = (Flags&5 && Flags&7); ^ ~~~~~~~ logical_constant2.cc:7:30: note: in instantiation of template class 'ei_are_flags_consistent<4>' requested here ei_are_flags_consistent<4> foo; ^ clang-3.0: llvm/lib/VMCore/Instructions.cpp:968: 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: llvm/llvm_build/bin/clang-3.0 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name logical_constant2.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -resource-dir llvm/llvm_build/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 80 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-wLc9E0.o -x c++ logical_constant2.cc 1. parser at end of file 2. Per-file LLVM IR generation 3. logical_constant2.cc:1:37: Generating code for declaration 'ei_are_flags_consistent<4>::ei_are_flags_consistent' clang-3: error: unable to execute command: Aborted clang-3: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 6 15:42:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 15:42:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 9696] compilation failure with gcc >=4.5 In-Reply-To: References: Message-ID: <20110706204242.6025E2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9696 Ryuta Suzuki changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Ryuta Suzuki 2011-07-06 15:42:41 CDT --- I haven't used gcc to build libcxx for a while but as of r134405 I was able to successfully build libcxx by gcc-4.6.1. Though I haven't tested gcc-4.5.3 I would deem this bug is fixed for the most recent versions of gcc. (In reply to comment #1) > Thanks for the report. For various reasons I can not test on anything beyond > gcc-4.4, and so am unable to reproduce this symptom. If you can recommend a > patch I'll review 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 Jul 6 17:04:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 17:04:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10142] Exception mistakenly moved from In-Reply-To: References: Message-ID: <20110706220432.185362A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10142 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2011-07-06 17:04:31 CDT --- Fixed in Clang r134548. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 17:29:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 17:29:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10220] Crash in scheduler on x86-64 with very wide addition In-Reply-To: References: Message-ID: <20110706222949.EB7132A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10220 Lang Hames changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Lang Hames 2011-07-06 17:29:49 CDT --- Looks like this is fixed in r134525. Thanks Evan. I'll submit a testcase shortly. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 19:43:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 19:43:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10263] Wrong definition of ftrunc. In-Reply-To: References: Message-ID: <20110707004328.2180F2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10263 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Chris Lattner 2011-07-06 19:43:27 CDT --- These look 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 Wed Jul 6 19:43:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 19:43:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10271] Add contains() to ImmutableList In-Reply-To: References: Message-ID: <20110707004349.C3BF92A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10271 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2011-07-06 19:43:49 CDT --- This got applied. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 21:20:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 21:20:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10290] [irgen] clang crash In-Reply-To: References: Message-ID: <20110707022029.C974B2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10290 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Nick Lewycky 2011-07-06 21:20:29 CDT --- Fixed in r134583. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 22:52:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 22:52:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10291] New: clang asserts when comparing different types inside a throw inside a class template Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10291 Summary: clang asserts when comparing different types inside a throw inside a class template Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tziltzal at y7mail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com ... pretty weird situation, but the following example causes clang to assert on comparing different types: template class X { public: X() : i(0) { } void foo() { throw i == 0u ? // this causes the assertion 5 : 6; } private: int i; }; int main() { X x; } the output is: clang: /usr/src/llvm/tools/clang/lib/Sema/SemaChecking.cpp:2810: void::AnalyzeComparison(clang::Sema&, clang::BinaryOperator*): Assertion `S.Context.hasSameUnqualifiedType(T, E->getRHS()->getType()) && "comparison with mismatched types"' failed. 0 clang 0x0000000001bd4f3f 1 clang 0x0000000001bd5a7a 2 libpthread.so.0 0x000000370780eeb0 3 libc.so.6 0x0000003706c330c5 gsignal + 53 4 libc.so.6 0x0000003706c34a76 abort + 390 5 libc.so.6 0x0000003706c2b905 __assert_fail + 245 6 clang 0x00000000009d753e 7 clang 0x00000000009d7611 8 clang 0x00000000009d709e 9 clang 0x00000000009d6f7a 10 clang 0x0000000000ad38d0 clang::Sema::ActOnFinishFullExpr(clang::Expr*) + 144 11 clang 0x0000000000932c91 clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 129 12 clang 0x000000000092f00b clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 2875 13 clang 0x000000000092c23e clang::Parser::ParseCompoundStatementBody(bool) + 1742 14 clang 0x000000000092c9e8 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 168 15 clang 0x000000000094b249 clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 457 16 clang 0x000000000094afe9 clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 137 17 clang 0x00000000009699d4 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 2404 18 clang 0x000000000096ade0 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 4432 19 clang 0x0000000000957240 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 1408 20 clang 0x0000000000933b4d clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 765 21 clang 0x00000000009372d2 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 706 22 clang 0x000000000095bb8a clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 522 23 clang 0x000000000094581b clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 603 24 clang 0x00000000009464ec clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 156 25 clang 0x000000000091b33d clang::ParseAST(clang::Sema&, bool) + 205 26 clang 0x00000000007bc534 clang::CodeGenAction::ExecuteAction() + 68 27 clang 0x00000000006b0d43 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371 28 clang 0x000000000068923d clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1181 29 clang 0x000000000067dc7b cc1_main(char const**, char const**, char const*, void*) + 779 30 clang 0x00000000006881b3 main + 7347 31 libc.so.6 0x0000003706c1ee5d __libc_start_main + 253 32 clang 0x000000000067d789 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name test.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51.0.7 -momit-leaf-frame-pointer -coverage-file CMakeFiles/test.dir/test.cpp.o -resource-dir /usr/local/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 237 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o CMakeFiles/test.dir/test.cpp.o -x c++ /home/user/Sources/test/test.cpp 1. /home/user/Sources/test/test.cpp:13:5: current parser token '}' 2. /home/user/Sources/test/test.cpp:2:1: parsing struct/union/class body 'X' 3. /home/user/Sources/test/test.cpp:9:5: parsing function body 'foo' 4. /home/user/Sources/test/test.cpp:9:5: in compound statement ('{}') clang: error: unable to execute command: Aborted (core dumped) clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) if X isn't a template class, or you change 'throw' to be a different expression (e.g. int x = ) or make sure that == compares identical types, it will compile fine... uname -a returns: Linux fedora-host 2.6.35.13-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux clang --version returns: clang version 3.0 (trunk 134577) Target: x86_64-unknown-linux-gnu Thread model: posix clang/llvm were compiled with --enable-optimized. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 6 23:37:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Jul 2011 23:37:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 10186] Infinite loop in llc on ARMv7 (LLVM HEAD from June 17) In-Reply-To: References: Message-ID: <20110707043754.4A31E2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10186 Lang Hames changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |lhames at gmail.com Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 7 01:13:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 01:13:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 10292] New: redundant load not removed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10292 Summary: redundant load not removed Product: libraries Version: trunk Platform: PC OS/Version: All 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 In the following example, tmp5 could be removed. %zed = type { i8* } define void @test(%zed** %bar) { %tmp1 = alloca i8, align 8 %tmp2 = load %zed** %bar, align 8 %tmp3 = getelementptr inbounds %zed* %tmp2, i64 0, i32 0 %tmp4 = load i8** %tmp3, align 8 call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp1, i8* %tmp4, i64 24, i32 8, i1 false) %tmp5 = load i8** %tmp3, align 8 call void @foobar(i8* %tmp1) call void @foobar(i8* %tmp5) ret void } declare void @foobar(i8*) declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture, i64, i32, i1) 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 Jul 7 06:46:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 06:46:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10293] New: Load not hoisted out of loop with multiple exits Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10293 Summary: Load not hoisted out of loop with multiple exits Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: benny.kra at gmail.com CC: llvmbugs at cs.uiuc.edu We compile this C code: === bool foo(const char *CurPtr) { for (unsigned i = 1; i != 7; ++i) if (CurPtr[i] != CurPtr[0]) return false; return true; } === into === define zeroext i1 @foo(i8* nocapture %CurPtr) nounwind readonly ssp { entry: br label %for.cond for.cond: ; preds = %for.inc, %entry %indvar = phi i32 [ %phitmp, %for.inc ], [ 1, %entry ] %cmp = icmp eq i32 %indvar, 7 br i1 %cmp, label %return, label %for.body for.body: ; preds = %for.cond %arrayidx = getelementptr i8* %CurPtr, i32 %indvar %tmp3 = load i8* %arrayidx, align 1, !tbaa !0 %tmp6 = load i8* %CurPtr, align 1, !tbaa !0 %cmp8 = icmp eq i8 %tmp3, %tmp6 br i1 %cmp8, label %for.inc, label %return for.inc: ; preds = %for.body %phitmp = add i32 %indvar, 1 br label %for.cond return: ; preds = %for.cond, %for.body %retval.0 = phi i1 [ false, %for.body ], [ true, %for.cond ] ret i1 %retval.0 } === The load of CurPtr[0] should be moved out of the loop. Recent versions of GCC seem to be able to do 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 Thu Jul 7 07:17:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 07:17:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 10294] New: Release tarballs are signed with a key that is nowhere to be found Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10294 Summary: Release tarballs are signed with a key that is nowhere to be found Product: Website Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: General Website AssignedTo: unassignedbugs at nondot.org ReportedBy: sliedes at cc.hut.fi CC: llvmbugs at cs.uiuc.edu To reproduce: 1. Download http://llvm.org/releases/2.9/llvm-2.9.tgz 2. Download http://llvm.org/releases/2.9/llvm-2.9.tgz.sig 3. Run gpg --verify llvm-2.9.tgz.sig [gpg indicates key E95C63DC is unknown] 4. Run gpg --recv-key E95C63DC [gpg indicates the key cannot be found on the public keyserver] 5. Google for E95C63DC [cannot find the key with Google either] Actual result: The key used to sign llvm-2.9.tgz is nowhere to be found. Hence the signature cannot be verified. Hence the .sig files are rather useless. Expected result: The key should be available on the public keyservers and/or on the LLVM website. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 07:52:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 07:52:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10295] New: Problem with preprocessor with keep comments Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10295 Summary: Problem with preprocessor with keep comments Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: cullmann at absint.de CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6846) --> (http://llvm.org/bugs/attachment.cgi?id=6846) Test Case If you use clang -E -CC test.c on the following snippet as test.c, you get this error: # 1 "/home/step/c-files/bug_8438.c" # 1 "/home/step/c-files/bug_8438.c" 1 # 1 "" 1 # 1 "" 3 # 132 "" 3 # 1 "" 1 # 1 "" 2 # 1 "/home/step/c-files/bug_8438.c" 2 /* hurz *//home/step/c-files/bug_8438.c:3:47: error: token is not a valid binary operator in a preprocessor subexpression #if defined __LCC__ /* Compiler = LCC ~~~~~~~~~~~~~~~~~~~~~~~ ^ main() { return 1; } 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 Jul 7 08:42:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 08:42:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10296] New: clang doesn't honor LIBRARY_PATH Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10296 Summary: clang doesn't honor LIBRARY_PATH 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: howarth at nitro.med.uc.edu CC: llvmbugs at cs.uiuc.edu The clang compiler doesn't honor LIBRARY_PATH during linkage. For example, when building guile 1.8.8 using clang against libgmp in /sw/lib... setenv LIBRARY_PATH /sw/lib allows both gcc and ifort to find libgmp in /sw/lib without explicitly passing -L/sw/lib on the compiler options... [MacPro:guile18-1.8.8-3/guile-1.8.8/build] root# gcc -o conftest -g -O2 -Dmacosx conftest.c -lgmp -lm -lltdl however this same configure test fails to link under clang... [MacPro:guile18-1.8.8-3/guile-1.8.8/build] root# clang -o conftest -g -O2 -Dmacosx conftest.c -lgmp -lm -lltdl ld: library not found for -lgmp clang: error: linker command failed with exit code 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 7 10:38:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 10:38:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 10297] New: clang doesn't honor CPATH Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10297 Summary: clang doesn't honor CPATH 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: howarth at nitro.med.uc.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6848) --> (http://llvm.org/bugs/attachment.cgi?id=6848) test case The clang compiler doesn't honor the CPATH environmental such that the attached test case fails... [MacPro:~/clang_bug2] howarth% ./show_bug.sh #!/bin/sh -ev export CPATHH=./local gcc cpath_bug.c clang cpath_bug.c cpath_bug.c:4:10: fatal error: 'test.h' file not found #include ^ 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 Jul 7 11:16:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 11:16:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10298] New: cpp preprocessing yields different results than gcc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10298 Summary: cpp preprocessing yields different results than gcc Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joel.sherrill at oarcorp.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6849) --> (http://llvm.org/bugs/attachment.cgi?id=6849) Test Case RTEMS uses preprocessed assembly files (.S). I have a small test case which compiles with i386 gcc and not with clang from the svn head. $ clang -c set_asm.S /tmp/cc-Y6Q2YB.s:14:24: error: unexpected token in assignment .set HEIRCONTEXT_ARG, 8_label: It is running the label inside a macro on a subsequent line with the value on the RHS of the .set. This is a cut down and if I simplify it much more, it works. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 7 12:27:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 12:27:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10299] New: clang does not know FP registers gcc does Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10299 Summary: clang does not know FP registers gcc does Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joel.sherrill at oarcorp.com CC: llvmbugs at cs.uiuc.edu In RTEMS, we use some inline assembly to assist in FPU context switches. clang has trouble with the two attached test cases. I think we use two registers clang does not know about yet. This can likely be reduced but I thought it better to stick with two real examples so when this is addressed, it is more likely to let this code in RTEMS compile. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 7 12:32:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 12:32:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10300] New: newlib using warning pragma clang does not know Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10300 Summary: newlib using warning pragma clang does not know Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joel.sherrill at oarcorp.com CC: llvmbugs at cs.uiuc.edu Another bit from the RTEMS clang effort. One line test case from newlib attached which uses the warning pragma. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 12:37:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 12:37:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 10301] New: Link errors: C++ new operators with MSVC C++ Linker Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10301 Summary: Link errors: C++ new operators with MSVC C++ Linker Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: art.oriented at gmail.com CC: llvmbugs at cs.uiuc.edu Windows, LLVM and clang For the following simple C++ code: ////////////////////////////// class DUMMY { public: DUMMY() { val1 = 0, val2 = 0.f; } int val1; float val2; }; int main() { int* a = new int[10]; DUMMY* b = new DUMMY(); return a[0] + b->val1; } ////////////////////////////// clang and linking with MSVC C++ linker gives link errors: new.o : error LNK2019: unresolved external symbol __Znaj referenced in function _main new.o : error LNK2019: unresolved external symbol __Znwj referenced in function _main LINK : error LNK2001: unresolved external symbol _mainCRTStartup new.exe : fatal error LNK1120: 3 unresolved externals After simple searching, this is due to clang or LLVM didn't correctly emit some C++ operator functions. Of course, linking with g++ (MinGW) is okay. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 14:16:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 14:16:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10302] New: unrestricted unions don't delete destructor when required Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10302 Summary: unrestricted unions don't delete destructor when required Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: oneill+llvmbugs at cs.hmc.edu CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6852) --> (http://llvm.org/bugs/attachment.cgi?id=6852) unionbug.cpp ? small example to show the bug When an unrestricted union has a member with nontrivial destructor and no explicit destructor is provided, the destrutor should be deleted, but clang does not do so: > clang++ -v clang version 3.0 (trunk 133502) Target: x86_64-apple-darwin10.8.0 Thread model: posix > clang++ -Wall -std=c++0x -c unionbug.cpp [no errors] c.f. > g++-mp-4.6 -std=c++0x -c unionbug.cpp unionbug.cpp: In function 'int main()': unionbug.cpp:16:39: error: use of deleted function 'NonTrivialDestructorInUnion::~NonTrivialDestructorInUnion()' unionbug.cpp:8:7: error: 'NonTrivialDestructorInUnion::~NonTrivialDestructorInUnion()' is implicitly deleted because the default definition would be ill-formed: unionbug.cpp:11:29: error: union member 'NonTrivialDestructorInUnion::annoy' with non-trivial 'HasNonTrivialDestructor::~HasNonTrivialDestructor()' -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 14:23:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 14:23:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 10301] Link errors: C++ new operators with MSVC C++ Linker In-Reply-To: References: Message-ID: <20110707192336.2791C2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10301 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |LATER --- Comment #1 from Eli Friedman 2011-07-07 14:23:35 CDT --- You can activate the experimental Microsoft C++ ABI support with "-Xclang -cxx-abi -Xclang microsoft"; otherwise, we use a MinGW compatible C++ ABI. It's impossible to generate code that supports both at the same time. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 7 14:55:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 14:55:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 10303] New: CMake build updates cmake/modules/LLVMLibDeps.cmake Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10303 Summary: CMake build updates cmake/modules/LLVMLibDeps.cmake Product: Build scripts Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: cmake AssignedTo: unassignedbugs at nondot.org ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu, ofv at wanadoo.es The CMake build sometimes makes changes to cmake/modules/LLVMLibDeps.cmake. This is really bad as it should be able to function completely out-of-tree. Worse, this in-tree change is to a checked-in file. As a direct result of this, the file needs to be reset occasionally in order to perform an update via git. The CMake build should never modify files in-tree. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 15:25:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 15:25:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10233] extern keyword for inline definition should trigger function emission In-Reply-To: References: Message-ID: <20110707202529.E1F332A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10233 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Nick Lewycky 2011-07-07 15:25:29 CDT --- Fixed in r134634. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 16:38:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 16:38:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10304] New: unrestricted unions call *all* constructors/destructors for member types Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10304 Summary: unrestricted unions call *all* constructors/destructors for member types Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: oneill+llvmbugs at cs.hmc.edu CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6853) --> (http://llvm.org/bugs/attachment.cgi?id=6853) unionbad.cpp ? example of unrestricted union bug When a union is constructed, generated code calls default constructors for *all* member types. Likewise when a union is destroyed, generated code calls *all* destructors. Back when unions only had POD types (and thus constructors/destructors were all do-nothing actions, this was harmless, but currently clang allows non-POD types in unions in c++0x mode, with extremely surprising results.) > clang++ -std=c++0x -Wall -o unionbad unionbad.cpp > ./unionbad Foo at 0x7fff5fbff218 created Bar at 0x7fff5fbff218 created FooBar (union) at 0x7fff5fbff218 created FooBar (union) at 0x7fff5fbff218 destroyed Bar at 0x7fff5fbff218 destroyed Foo at 0x7fff5fbff218 destroyed c.f. > g++-mp-4.6 -std=c++0x -Wall -o unionbad unionbad.cpp > ./unionbad FooBar (union) at 0x7fff5fbff21f created FooBar (union) at 0x7fff5fbff21f destroyed P.S. I realize (now) that unrestricted unions aren't officially supported yet (despite coppro's comment at r131432), but I think that miscompiling unsupported c++0x code can lead to subtle and suprising bugs for the unwary. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 17:30:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 17:30:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 10149] __asm__ segfaults In-Reply-To: References: Message-ID: <20110707223002.EE33F2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10149 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Eric Christopher 2011-07-07 17:30:01 CDT --- Fixed thusly: [yendi:Data/sources/llvm] echristo% git svn dcommit Committing to https://llvm.org/svn/llvm-project/llvm/trunk ... M lib/CodeGen/SelectionDAG/TargetLowering.cpp Committed r134647 M lib/Target/Mips/MipsInstrInfo.td r134645 = 58b4edbef426064b00087bcff639cb6f7ef5b25e (refs/remotes/origin/master) M lib/CodeGen/SelectionDAG/TargetLowering.cpp r134647 = 3e7ceca1d7bd2b91a3bfd6b9290f0485694fb174 (refs/remotes/origin/master) W: 5ede211a754d87a5a1df91b48b2a4d5f51cb3d2c and refs/remotes/origin/master differ, using rebase: :040000 040000 1fe39b7d8ec289bf48340a71916997214f1258a0 05d4f8e7a535d4315320f0043258c8ed9dabf676 M lib First, rewinding head to replay your work on top of it... Applying: Add support for the X86 'l' constraint. M lib/Target/X86/X86ISelLowering.cpp M test/CodeGen/X86/inline-asm.ll Committed r134648 M test/CodeGen/X86/inline-asm.ll M lib/Target/X86/X86ISelLowering.cpp r134648 = 1f7667c1972413f09d50ecdb729b2621b7b487e5 (refs/remotes/origin/master) No changes between current HEAD and refs/remotes/origin/master Resetting to the latest refs/remotes/origin/master -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 17:30:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 17:30:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10305] New: error LNK2019: unresolved external symbol ___umoddi3 referenced in function _main Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10305 Summary: error LNK2019: unresolved external symbol ___umoddi3 referenced in function _main Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jlerouge at apple.com CC: llvmbugs at cs.uiuc.edu On windows, using clang built with msvc (following http://clang.llvm.org/get_started.html), the following code doesn't link: int main(int argc, char **argv) { unsigned long long i = argc; unsigned long long j = argc + (int) argv; return i % j; } c:\> clang -o t.exe t.c cc-524958.o : error LNK2019: unresolved external symbol ___umoddi3 referenced in function _main t.exe : fatal error LNK1120: 1 unresolved externals Is this expected ? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 7 17:53:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 17:53:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10306] New: Missing fixit for ternary precedence warning near macros Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10306 Summary: Missing fixit for ternary precedence warning near macros Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matthewbg at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com $ cat testcases/ternary-precedence-fixit.cc #include #define COUT std::cout void f() { std::cout << "n = " << true ? 1 : 0; COUT << "n = " << true ? 1 : 0; } $ clang -fsyntax-only -Wparentheses testcases/ternary-precedence-fixit.cc testcases/ternary-precedence-fixit.cc:4:31: warning: operator '?:' has lower precedence than '<<'; '<<' will be evaluated first [-Wparentheses] std::cout << "n = " << true ? 1 : 0; ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ternary-precedence-fixit.cc:4:31: note: place parentheses around the '<<' expression to silence this warning std::cout << "n = " << true ? 1 : 0; ^ ( ) testcases/ternary-precedence-fixit.cc:4:31: note: place parentheses around the '?:' expression to evaluate it first std::cout << "n = " << true ? 1 : 0; ^ ( ) testcases/ternary-precedence-fixit.cc:5:26: warning: operator '?:' has lower precedence than '<<'; '<<' will be evaluated first [-Wparentheses] COUT << "n = " << true ? 1 : 0; ~~~~~~~~~~~~~~~~~~~~~~ ^ testcases/ternary-precedence-fixit.cc:5:26: note: place parentheses around the '<<' expression to silence this warning COUT << "n = " << true ? 1 : 0; ~~~~~~~~~~~~~~~~~~~~~~ ^ testcases/ternary-precedence-fixit.cc:5:26: note: place parentheses around the '?:' expression to evaluate it first COUT << "n = " << true ? 1 : 0; ^ ( ) Introducing a macro somehow causes us to lose the fixits for the first note. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 17:57:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 17:57:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10299] clang does not know FP registers gcc does In-Reply-To: References: Message-ID: <20110707225748.904132A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10299 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Eric Christopher 2011-07-07 17:57:48 CDT --- Fixed thusly: [yendi:Data/sources/llvm] echristo% git svn dcommit Committing to https://llvm.org/svn/llvm-project/llvm/trunk ... M lib/Target/X86/X86MCAsmInfo.cpp Committed r134653 M lib/Target/X86/X86MCAsmInfo.cpp r134653 = 675819a2a75c0e4669f45bce42b0c2ad23da5d4c (refs/remotes/origin/master) and for clang: M lib/Basic/Targets.cpp r134654 = bb851ee5ad7e4ab99d0d68ca8c3809d7f01410c6 (refs/remotes/origin/master) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 18:57:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 18:57:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10214] Macro expansion stack fails to list bottom most macro for errors in arguments In-Reply-To: References: Message-ID: <20110707235717.796452A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10214 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chandler Carruth 2011-07-07 18:57:16 CDT --- Fixed by submitting an updated form of this patch in r134660. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 18:57:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 18:57:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 10215] Location of argument to function style macro not correctly tracked In-Reply-To: References: Message-ID: <20110707235726.2807A2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10215 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chandler Carruth 2011-07-07 18:57:25 CDT --- Fixed by submitting an updated form of this patch in r134660. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 19:05:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 19:05:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 9675] Calling __sync_sub_and_fetch with -mno-sse and -O0 crashes clang In-Reply-To: References: Message-ID: <20110708000548.9D8612A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9675 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Eric Christopher 2011-07-07 19:05:48 CDT --- Should be fixed thusly: [yendi:Data/sources/llvm-svn] echristo% svn ci Sending lib/Target/X86/X86ISelLowering.cpp Adding test/CodeGen/X86/membarrier.ll Transmitting file data .. Committed revision 134664. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 7 21:14:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Jul 2011 21:14:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 10307] New: Add Contains() to GRStateTrait's specialization of ImmutableList Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10307 Summary: Add Contains() to GRStateTrait's specialization of ImmutableList Product: clang Version: trunk Platform: Macintosh OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rpaulo at apple.com CC: llvmbugs at cs.uiuc.edu Now that we ImmutableList has a contains() method, we can add 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 Jul 8 06:23:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 06:23:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10183] [-Wuninitialized] Large bottleneck observed for certain PostgreSQL TUs In-Reply-To: References: Message-ID: <20110708112319.1516A2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10183 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #12 from Chandler Carruth 2011-07-08 06:23:17 CDT --- This should be fixed in r134697. It brings the compile time for this file from 80 seconds to 1 second for me. Ted, please review just to make sure this doesn't pessimize some other case. I've tried as hard as I can to find any such, but you've seen a lot more of these issues. =D -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 8 07:09:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 07:09:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 10308] New: using libc++ with -O4 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10308 Summary: using libc++ with -O4 Product: new-bugs Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm at niebuhrt.de CC: llvmbugs at cs.uiuc.edu Compiling the following small program with link time optimization results in errors. --------------- test.cpp----------------- #include int main() { int data; std::shared_ptr px(&data); std::weak_ptr ppx(px); return 0; } ---------------test.cpp------------------ Everything is compiled from trunk. /usr/lib/libLTO.dylib is linked to the libLTO.dylib from the compiled trunk clang++ -v -O4 test.cpp -std=c++0x -stdlib=libc++ -U__STRICT_ANSI__ clang version 3.0 (trunk 134695) Target: x86_64-apple-darwin10.8.0 Thread model: posix "/Users/niebuhr/projects/llvm/Release+Asserts/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.8 -emit-llvm-bc -disable-free -main-file-name test.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 123.2 -v -resource-dir /Users/niebuhr/projects/llvm/Release+Asserts/bin/../lib/clang/3.0 -U __STRICT_ANSI__ -stdlib=libc++ -O3 -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/i1/i1WwOXILFa8QNqJQnuxxd++++TI/-Tmp-/cc-JvMCW6.o -x c++ test.cpp clang -cc1 version 3.0 based upon llvm 3.0svn hosted on x86_64-apple-darwin10.8.0 #include "..." search starts here: #include <...> search starts here: /usr/include/c++/v1 /usr/local/include /Users/niebuhr/projects/llvm/Release+Asserts/bin/../lib/clang/3.0/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin10/4.2.1/ld" -demangle -object_path_lto /var/folders/i1/i1WwOXILFa8QNqJQnuxxd++++TI/-Tmp-/cc-5v0a2o.o -dynamic -arch x86_64 -macosx_version_min 10.6.8 -o a.out -lcrt1.10.6.o /var/folders/i1/i1WwOXILFa8QNqJQnuxxd++++TI/-Tmp-/cc-JvMCW6.o -lc++ -lSystem Undefined symbols for architecture x86_64: "typeinfo name for std::__1::__shared_weak_count", referenced from: "typeinfo name for std::__1::__shared_count", referenced from: ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 8 08:46:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 08:46:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 10309] New: Can't override a virtual function and return a more specific ObjC type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10309 Summary: Can't override a virtual function and return a more specific ObjC type 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: alee at mimsoftware.com CC: llvmbugs at cs.uiuc.edu #import @interface Test : NSObject @end @interface TestX : Test @end class Top { virtual Test* getTest(); }; class Bottom: public Top { virtual TestX* getTest(); //Error generated on this line }; LLVM outputs the following error: virtual function 'getTest' has a different return type ('TestX *') than the function it overrides (which has return type 'Test *') TestX is a subclass of Test in this scenario so there should be no error here (legitimately narrowing the return type). Using the Apple LLVM compiler 3.0 in Xcode 4.2 Build 4D58. It's worth noting that this same code compiles cleanly under GCC 4.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 Fri Jul 8 10:02:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 10:02:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10310] New: function-within-namespace lookup bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10310 Summary: function-within-namespace lookup bug Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ps at kr.tuwien.ac.at CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6857) --> (http://llvm.org/bugs/attachment.cgi?id=6857) the good input attached there are two .cpp files which differ only in the way a function is declared to be in the namespace. *** good.E.cpp 2011-07-08 17:00:23.249503002 +0200 --- bad.E.cpp 2011-07-08 16:59:58.649503000 +0200 *************** *** 104707,104720 **** }; } ! namespace LitDep ! { ! inline FormulaNode* new_clone(const FormulaNode& a) { (void)a; return 0; } - } # 24 "/home/ps/Documents/potassco/trunk/gringo/libgringo/src/aggrlit.cpp" 2 # 1 "/home/ps/Documents/potassco/trunk/gringo/libgringo/./gringo/exceptions.h" 1 # 22 "/home/ps/Documents/potassco/trunk/gringo/libgringo/./gringo/exceptions.h" --- 104707,104717 ---- }; } ! inline LitDep::FormulaNode* new_clone(const LitDep::FormulaNode& a) { (void)a; return 0; } # 24 "/home/ps/Documents/potassco/trunk/gringo/libgringo/src/aggrlit.cpp" 2 # 1 "/home/ps/Documents/potassco/trunk/gringo/libgringo/./gringo/exceptions.h" 1 # 22 "/home/ps/Documents/potassco/trunk/gringo/libgringo/./gringo/exceptions.h" The "good" file compiles with clang 2.9 and trunk from tonight. The "bad" complains as follows (using trunk) In file included from /home/ps/Documents/potassco/trunk/gringo/libgringo/src/aggrlit.cpp:1: In file included from /home/ps/Documents/potassco/trunk/gringo/libgringo/src/aggrlit.cpp:18: In file included from /home/ps/Documents/potassco/trunk/gringo/libgringo/./gringo/aggrlit.h:20: In file included from /home/ps/Documents/potassco/trunk/gringo/libgringo/./gringo/gringo.h:24: /home/ps/Documents/potassco/trunk/gringo/libgringo/./gringo/clone_ptr.h:54:21: error: call to function 'new_clone' that is neither visible in the template definition nor found by argument-dependent lookup : ptr_(ptr.get() ? new_clone(*ptr.get()) : 0) ^ /home/ps/Documents/potassco/trunk/gringo/libgringo/./gringo/formula.h:23:7: note: in instantiation of member function 'clone_ptr::clone_ptr' requested here class Formula : public Locateable ^ /home/ps/Documents/potassco/trunk/gringo/libgringo/./gringo/litdep.h:78:29: note: 'new_clone' should be declared prior to the call site or in namespace 'LitDep' inline LitDep::FormulaNode* new_clone(const LitDep::FormulaNode& a) ^ 1 warning and 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 Fri Jul 8 10:09:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 10:09:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10310] function-within-namespace lookup bug In-Reply-To: References: Message-ID: <20110708150949.93E232A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10310 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Douglas Gregor 2011-07-08 10:09:48 CDT --- Clang is behaving correctly, because your new_clone function is neither visible in the template definition nor found through ADL. This is a common compatibility issue (because other compilers get it wrong), documented here: http://clang.llvm.org/compatibility.html#dep_lookup Besides, the error Clang is providing describes *exactly* what the code is doing wrong, and the note specifies how to 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 Jul 8 10:50:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 10:50:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10285] Improper assignment operator overload resolution In-Reply-To: References: Message-ID: <20110708155059.C2E892A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10285 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-07-08 10:50:59 CDT --- Fixed in Clang r134700. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 8 11:30:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 11:30:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10309] Can't override a virtual function and return a more specific ObjC type In-Reply-To: References: Message-ID: <20110708163040.EADC92A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10309 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Chris Lattner 2011-07-08 11:30:40 CDT --- Please file this bug against bugreporter.apple.com, 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 Jul 8 12:22:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 12:22:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10311] New: Dangling reference problem Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10311 Summary: Dangling reference problem Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: release blocker Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dave at boostpro.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6859) --> (http://llvm.org/bugs/attachment.cgi?id=6859) patch that fixes the bug See attached patch -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 8 12:38:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 12:38:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 10312] New: Test Failure on MSVC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10312 Summary: Test Failure on MSVC Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: release blocker Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dave at boostpro.com CC: llvmbugs at cs.uiuc.edu This appears to be an upstream bug rather than anything in our fork: 'vcbuild_test.bat' in dir c:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\build\tools\clang\test (timeout 1200 secs) watching logfiles {} argv: ['vcbuild_test.bat'] environment: ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\buildslave\AppData\Roaming COMMONPROGRAMFILES=C:\Program Files\Common Files COMMONPROGRAMFILES(X86)=C:\Program Files (x86)\Common Files COMMONPROGRAMW6432=C:\Program Files\Common Files COMPUTERNAME=WIN08X64 COMSPEC=C:\Windows\system32\cmd.exe FP_NO_HOST_CHECK=NO LLVM_LIT_TOOLS_DIR=c:\gnuwin32\bin LOCALAPPDATA=C:\Users\buildslave\AppData\Local NUMBER_OF_PROCESSORS=2 OS=Windows_NT PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\CMake 2.8\bin;C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin;C:\gnuwin32\bin PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 23 Stepping 10, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=170a PROGRAMDATA=C:\ProgramData PROGRAMFILES=C:\Program Files PROGRAMFILES(X86)=C:\Program Files (x86) PROGRAMW6432=C:\Program Files PSMODULEPATH=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public PWD=c:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\build\tools\clang\test SYSTEMDRIVE=C: SYSTEMROOT=C:\Windows TEMP=C:\Users\BUILDS~1\AppData\Local\Temp TMP=C:\Users\BUILDS~1\AppData\Local\Temp USERDOMAIN=WIN08X64 USERNAME=buildslave USERPROFILE=C:\Users\buildslave VS100COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\ VS71COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Common7\Tools\ VS80COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\ VS90COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\ WINDIR=C:\Windows closing stdin using PTY: False c:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\build\tools\clang\test>"c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\..\..\VC\VCPackages\vcbuild.exe" "clang-test.vcproj" "Debug|Win32" Microsoft (R) Visual C++ Project Builder - Command Line Version 9.00.21022 Copyright (C) Microsoft Corporation. All rights reserved. Build started: Project: clang-test, Configuration: Debug|Win32 Running Clang regression tests -- Testing: 3687 tests, 2 threads -- FAIL: Clang :: ARCMT/with-working-dir.m (23 of 3687) ******************** TEST 'Clang :: ARCMT/with-working-dir.m' FAILED ******************** Script: -- C:/Users/buildslave/bot/xjag-win64-clang-llvm-work/llvm/build/bin/Debug/clang.EXE -cc1 -triple x86_64-apple-darwin10 -fobjc-nonfragile-abi -fsyntax-only -fobjc-arc -x objective-c C:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\tools\clang\test\ARCMT\with-working-dir.m.result arcmt-test --args -triple x86_64-apple-macosx10.6 -fobjc-nonfragile-abi -working-directory C:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\tools\clang\test\ARCMT with-working-dir.m > C:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\build\tools\clang\test\ARCMT\Output\with-working-dir.m.tmp diff C:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\build\tools\clang\test\ARCMT\Output\with-working-dir.m.tmp C:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\tools\clang\test\ARCMT\with-working-dir.m.result -- Exit Code: 1 Command Output (stdout): -- Command 0: "C:/Users/buildslave/bot/xjag-win64-clang-llvm-work/llvm/build/bin/Debug/clang.EXE" "-cc1" "-triple" "x86_64-apple-darwin10" "-fobjc-nonfragile-abi" "-fsyntax-only" "-fobjc-arc" "-x" "objective-c" "C:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\tools\clang\test\ARCMT\with-working-dir.m.result" Command 0 Result: 0 Command 0 Output: Command 0 Stderr: Command 1: "arcmt-test" "--args" "-triple" "x86_64-apple-macosx10.6" "-fobjc-nonfragile-abi" "-working-directory" "C:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\tools\clang\test\ARCMT" "with-working-dir.m" Command 1 Result: 0 Command 1 Output: None Command 1 Stderr: Command 2: "diff" "C:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\build\tools\clang\test\ARCMT\Output\with-working-dir.m.tmp" "C:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\tools\clang\test\ARCMT\with-working-dir.m.result" Command 2 Result: 1 Command 2 Output: 31d30 < __IMPL_ARCMT_REMOVED_EXPR__; 33,34d31 < if (obj) < __IMPL_ARCMT_REMOVED_EXPR__; 43d39 < __IMPL_ARCMT_REMOVED_EXPR__; Command 2 Stderr: -- ******************** Testing Time: 790.32s ******************** Failing Tests (1): Clang :: ARCMT/with-working-dir.m Expected Passes : 3492 Expected Failures : 167 Unsupported Tests : 27 Unexpected Failures: 1 lit.py: LitConfig.py:99: warning: Unable to find 'bash.exe'. lit.py: lit.cfg:182: note: using clang: 'C:/Users/buildslave/bot/xjag-win64-clang-llvm-work/llvm/build/bin/Debug/clang.EXE' lit.py: lit.cfg:191: note: using ast-test: 'C:/Users/buildslave/bot/xjag-win64-clang-llvm-work/llvm/build/bin/Debug\\ast-test.EXE' lit.py: main.py:298: warning: test suite 'Clang-Unit' contained no tests 2 warning(s) in tests. Project : error PRJ0019: A tool returned an error code from "Running Clang regression tests" Build log was saved at "file://c:\Users\buildslave\bot\xjag-win64-clang-llvm-work\llvm\build\tools\clang\test\clang-test.dir\Debug\BuildLog.htm" clang-test - 1 error(s), 0 warning(s) program finished with exit code 1 elapsedTime=795.865000 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 8 13:04:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 13:04:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 10311] Dangling reference problem In-Reply-To: References: Message-ID: <20110708180436.962F02A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10311 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Evan Cheng 2011-07-08 13:04:36 CDT --- I've applied the patch. Thanks Dave. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 8 16:41:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 16:41:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 10305] error LNK2019: unresolved external symbol ___umoddi3 referenced in function _main In-Reply-To: References: Message-ID: <20110708214115.AE6A72A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10305 Julien Lerouge changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #10 from Julien Lerouge 2011-07-08 16:41:15 CDT --- Sending lib/Target/X86/X86ISelLowering.cpp Adding test/CodeGen/X86/allrem-moddi3.ll Transmitting file data .. Committed revision 134744. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 8 17:51:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 17:51:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10313] New: Segfault when compiling 2005-02-20-BrokenReferenceTest.cpp from llvm test suite Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10313 Summary: Segfault when compiling 2005-02-20-BrokenReferenceTest.cpp from llvm test suite Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sreekumar.v.kodakara at intel.com CC: llvmbugs at cs.uiuc.edu I got a segfault when compiling a test from FrontendC++ directory in llvm test-suite. I have given the details below. OS: Ubuntu 11.04, 32 bit Clang/LLVM version : 2.9 release Test Name: 2005-02-20-BrokenReferenceTest.cpp Test Source: // RUN: %llvmgxx %s -S -o /dev/null void test(unsigned char *b, int rb) { typedef unsigned char imgfoo[10][rb]; imgfoo &br = *(imgfoo *)b; br[0][0] = 1; rb = br[0][0]; } Compile Output: $ clang++ 2005-02-20-BrokenReferenceTest.cpp -c -o 2005-02-20-BrokenReferenceTest.o -v clang version 2.9 (tags/RELEASE_29/final) Target: i386-pc-linux-gnu Thread model: posix "/home/user/software/llvm/llvm-install/bin/clang" -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name 2005-02-20-BrokenReferenceTest.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.21.0.20110327 -momit-leaf-frame-pointer -v -resource-dir /home/user/software/llvm/llvm-install/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 128 -fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o 2005-02-20-BrokenReferenceTest.o -x c++ 2005-02-20-BrokenReferenceTest.cpp clang -cc1 version 2.9 based upon llvm 2.9 hosted on i386-pc-linux-gnu ignoring nonexistent directory "/usr/include/c++/4.4" ignoring nonexistent directory "/usr/include/c++/4.4/i686-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/x86_64-linux-gnu/32" 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.4" ignoring nonexistent directory "/usr/include/c++/4.4/arm-linux-gnueabi/" ignoring nonexistent directory "/usr/include/c++/4.4/backward" ignoring nonexistent directory "/usr/include/c++/4.3" ignoring nonexistent directory "/usr/include/c++/4.3/x86_64-linux-gnu/32" 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/include/c++/4.3" ignoring nonexistent directory "/usr/include/c++/4.3/arm-linux-gnueabi/" ignoring nonexistent directory "/usr/include/c++/4.3/backward" ignoring nonexistent directory "/usr/include/c++/4.2" ignoring nonexistent directory "/usr/include/c++/4.2/x86_64-linux-gnu/32" ignoring nonexistent directory "/usr/include/c++/4.2/backward" ignoring nonexistent directory "/usr/include/c++/4.2" ignoring nonexistent directory "/usr/include/c++/4.2/i486-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.2/backward" ignoring nonexistent directory "/usr/include/c++/4.1" ignoring nonexistent directory "/usr/include/c++/4.1/x86_64-linux-gnu/32" ignoring nonexistent directory "/usr/include/c++/4.1/backward" ignoring nonexistent directory "/usr/include/c++/4.1" ignoring nonexistent directory "/usr/include/c++/4.1/i486-linux-gnu/" ignoring nonexistent directory "/usr/include/c++/4.1/backward" ignoring nonexistent directory "/usr/include/c++/4.5.1" ignoring nonexistent directory "/usr/include/c++/4.5.1/x86_64-redhat-linux/32" ignoring nonexistent directory "/usr/include/c++/4.5.1/backward" ignoring nonexistent directory "/usr/include/c++/4.5.1" ignoring nonexistent directory "/usr/include/c++/4.5.1/i686-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.5.1/backward" ignoring nonexistent directory "/usr/include/c++/4.4.4" ignoring nonexistent directory "/usr/include/c++/4.4.4/x86_64-redhat-linux/32" ignoring nonexistent directory "/usr/include/c++/4.4.4/backward" ignoring nonexistent directory "/usr/include/c++/4.4.4" ignoring nonexistent directory "/usr/include/c++/4.4.4/i686-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.4.4/backward" ignoring nonexistent directory "/usr/include/c++/4.4.3" ignoring nonexistent directory "/usr/include/c++/4.4.3/x86_64-redhat-linux/32" 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-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.4.3/backward" ignoring nonexistent directory "/usr/include/c++/4.4.2" ignoring nonexistent directory "/usr/include/c++/4.4.2/x86_64-redhat-linux/32" ignoring nonexistent directory "/usr/include/c++/4.4.2/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.1" ignoring nonexistent directory "/usr/include/c++/4.4.1/x86_64-redhat-linux/32" ignoring nonexistent directory "/usr/include/c++/4.4.1/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.3.2" ignoring nonexistent directory "/usr/include/c++/4.3.2/x86_64-redhat-linux/32" 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/i386-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.3.2/backward" ignoring nonexistent directory "/usr/include/c++/4.3.0" ignoring nonexistent directory "/usr/include/c++/4.3.0/x86_64-redhat-linux/32" ignoring nonexistent directory "/usr/include/c++/4.3.0/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.1.2" ignoring nonexistent directory "/usr/include/c++/4.1.2/x86_64-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.1.2/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.4.3" ignoring nonexistent directory "/usr/include/c++/4.4.3/x86_64-pc-linux-gnu/32" 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.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/32" 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.5/i586-suse-linux/" ignoring nonexistent directory "/usr/include/c++/4.5/x86_64-suse-linux/" 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.5.2/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include/g++-v4/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include/g++-v4/backward" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4/backward" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.4/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.4/include/g++-v4/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.4/include/g++-v4/backward" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/g++-v4/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/g++-v4/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/lib/llvm-gcc-4.2-9999/include/c++/4.2.1" ignoring nonexistent directory "/usr/lib/llvm-gcc-4.2-9999/include/c++/4.2.1/i686-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/llvm-gcc-4.2-9999/include/c++/4.2.1/backward" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/x86_64-pc-linux-gnu/32" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/backward" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/x86_64-pc-linux-gnu/32" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/backward" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/include/g++-v4/x86_64-pc-linux-gnu/32" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/include/g++-v4/backward" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/x86_64-pc-linux-gnu/32" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/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/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/x86_64-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/llvm-gcc-4.2-9999/include/c++/4.2.1" ignoring nonexistent directory "/usr/lib/llvm-gcc-4.2-9999/include/c++/4.2.1/x86_64-pc-linux-gnu/" ignoring nonexistent directory "/usr/lib/llvm-gcc-4.2-9999/include/c++/4.2.1/backward" ignoring duplicate directory "/usr/include/c++/4.5" ignoring duplicate directory "/usr/include/c++/4.5/backward" ignoring duplicate directory "/usr/include/c++/4.5" ignoring duplicate directory "/usr/include/c++/4.5/backward" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.5 /usr/include/c++/4.5/i686-linux-gnu /usr/include/c++/4.5/backward /usr/local/include /home/user/software/llvm/llvm-install/bin/../lib/clang/2.9/include /usr/include End of search list. 0 clang 0x09485c38 Stack dump: 0. Program arguments: /home/user/software/llvm/llvm-install/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name 2005-02-20-BrokenReferenceTest.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.21.0.20110327 -momit-leaf-frame-pointer -v -resource-dir /home/user/software/llvm/llvm-install/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 128 -fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o 2005-02-20-BrokenReferenceTest.o -x c++ 2005-02-20-BrokenReferenceTest.cpp 1. parser at end of file 2. 2005-02-20-BrokenReferenceTest.cpp:3:6: LLVM IR generation of declaration 'test' 3. 2005-02-20-BrokenReferenceTest.cpp:3:6: Generating code for declaration 'test' 4. 2005-02-20-BrokenReferenceTest.cpp:3:37: LLVM IR generation of compound statement ('{}') clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 8 18:12:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 18:12:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 10269] "PCLMULQDQ" not disassembled In-Reply-To: References: Message-ID: <20110708231225.382EF2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10269 Kay Tiong Khoo changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Kay Tiong Khoo 2011-07-08 18:12:24 CDT --- Looks like this is fixed in trunk, rev 134732. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 8 20:16:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Jul 2011 20:16:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 9602] couldn't allocate input reg for constraint 'q'! In-Reply-To: References: Message-ID: <20110709011645.3D7262A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9602 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Nick Lewycky 2011-07-08 20:16:44 CDT --- This is fixed 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 Sat Jul 9 00:39:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 00:39:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 10313] Segfault when compiling 2005-02-20-BrokenReferenceTest.cpp from llvm test suite In-Reply-To: References: Message-ID: <20110709053956.D146D2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10313 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |FIXED --- Comment #1 from John McCall 2011-07-09 00:39:56 CDT --- This has been 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 Sat Jul 9 04:42:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 04:42:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10314] New: "bitset::operator[](size_t) const" does not return bool Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10314 Summary: "bitset::operator[](size_t) const" does not return bool Product: libc++ Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: jonathan.sauer at gmx.de CC: llvmbugs at cs.uiuc.edu The following program does not compile with clang r134322 and libc++ r134357: #include template struct Foo; template <> struct Foo { static const bool value = true; }; template static void bar(B) { Foo::value; } int main(int, char**) { std::bitset<32> const bits; bar(bits[0]); } This results in: $ clang -std=c++0x -stdlib=libc++ clang.cpp clang.cpp:13:2: error: implicit instantiation of undefined template 'Foo > >' Foo::value; ^ clang.cpp:20:2: note: in instantiation of function template specialization 'bar > >' requested here bar(bits[0]); ^ clang.cpp:4:8: note: template is declared here struct Foo; ^ 1 error generated. According to 20.5p1, the signature of "operator[](std::size_t) const" is: constexpr bool operator[](size_t pos) const; libc++'s bitset's current implementation's signature is: const_reference operator[](size_t) const, where "const_reference" is equal to "__bit_const_reference<...>". While it is implicitely convertible to bool, it is not a bool itself and thus creates problems when used as a template parameter as in the code above. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 9 09:02:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 09:02:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10315] New: [C++0x] "Call to deleted constructor" with move assignment operator Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10315 Summary: [C++0x] "Call to deleted constructor" with move assignment operator Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Keywords: compile-fail Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matti.niemenmaa+llvmbugs at iki.fi CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang++ 2.9 and g++ 4.6.1 accept the code below (reduced from "#include " with Boost 1.46.1), but clang++ trunk (r134813) doesn't. My guess is that trunk is the one getting it wrong here: $ cat foo.cc struct shared_ptr { shared_ptr& operator=(shared_ptr&&) { return *this; } }; struct tss_data_node { shared_ptr sp; tss_data_node(shared_ptr p) : sp(p) {} }; $ g++ -std=c++0x -fsyntax-only foo.cc $ clang++ -std=c++0x -fsyntax-only foo.cc $ bin/clang++ -std=c++0x -fsyntax-only foo.cc foo.cc:6:32: error: call to deleted constructor of 'shared_ptr' tss_data_node(shared_ptr p) : sp(p) {} ^ ~ foo.cc:1:8: note: function has been explicitly marked deleted here struct shared_ptr { ^ 1 error generated. $ g++ --version g++ (GCC) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ clang++ --version clang version 2.9 (tags/RELEASE_29/final) Target: x86_64-unknown-linux-gnu Thread model: posix $ bin/clang++ --version clang version 3.0 () 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 Sat Jul 9 10:57:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 10:57:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10316] New: Incorrect function calls in the tutorials for building the fadd, fmul, and fsub operations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10316 Summary: Incorrect function calls in the tutorials for building the fadd, fmul, and fsub operations Product: Documentation Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: damien.schoof at gmail.com CC: llvmbugs at cs.uiuc.edu Depends on: 10016,10025 Created an attachment (id=6863) --> (http://llvm.org/bugs/attachment.cgi?id=6863) Calls the correct functions to build arithmetic operators +++ This bug was initially created as a clone of Bug #10025 +++ In the Kaleidoscope tutorials, Codegen.ml specifies that creating the add, sub and mul operators involves a call to build_add, build_sub, and build_mul. However, the language being created only has a double type, and therefore the above functions do not work correctly. There is no useful error message for this, and therefore it is not possible to tell what is going wrong. I have created a patch for this, which uses the correct function call in the tutorial. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 9 11:52:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 11:52:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10317] New: Thumb 2 : Overflow intrinsic generates horrible code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10317 Summary: Thumb 2 : Overflow intrinsic generates horrible code Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: xocotl at gmail.com CC: llvmbugs at cs.uiuc.edu This test: ; ModuleID = 'test.c' target datalayout = "e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:32-n32" target triple = "thumb-none--eabi" declare {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b) define i32 @add32_test(i32 %a, i32 %b) nounwind readnone { %res = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b) %1 = extractvalue {i32, i1} %res, 0 %2 = extractvalue {i32, i1} %res, 1 %. = select i1 %2, i32 4294967295, i32 %1 ret i32 %. } generates this: add32_test: @ BB#0: push {r4, r5, r7, lr} movs r2, #1 movs r3, #0 cmp r1, #0 mov r4, r2 bge .LBB0_2 @ BB#1: mov r4, r3 .LBB0_2: cmp r0, #0 mov r5, r2 bge .LBB0_4 @ BB#3: mov r5, r3 .LBB0_4: cmp r5, r4 mov r4, r2 beq .LBB0_6 @ BB#5: mov r4, r3 .LBB0_6: adds r1, r0, r1 cmp r1, #0 mov r0, r2 bge .LBB0_8 @ BB#7: mov r0, r3 .LBB0_8: cmp r5, r0 bne .LBB0_10 @ BB#9: mov r2, r3 .LBB0_10: mvns r0, r3 tst r4, r2 bne .LBB0_12 @ BB#11: mov r0, r1 .LBB0_12: pop {r4, r5, r7, pc} It could just check the overflow flag. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 9 14:00:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 14:00:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 10318] New: namespace error message doesn't make sense Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10318 Summary: namespace error message doesn't make sense Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I got this: Callgraph.ii:76782:3: error: no template named 'GraphWriter' in namespace 'llvm'; did you mean 'llvm::GraphWriter'? GraphWriter W(llvm::errs(), *this); ^~~~~~~~~~~ llvm::GraphWriter Saying "no template named 'GraphWriter' in namespace 'llvm'" doesn't make sense, because there is one, and that is what I wanted to use. nice fixit 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 Jul 9 15:01:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 15:01:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 10312] Test Failure on MSVC In-Reply-To: References: Message-ID: <20110709200153.BC0122A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10312 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Argyrios Kyrtzidis 2011-07-09 15:01:52 CDT --- Removed the test at r134845. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 9 16:09:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 16:09:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10319] New: Use 'leave' instruction in prologues Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10319 Summary: Use 'leave' instruction in prologues Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: jmuizelaar at mozilla.com CC: llvmbugs at cs.uiuc.edu llvm currently uses a sequence like: 000000000000003b addq $0x10,%rsp 000000000000003f popq %rbp 0000000000000040 ret instead of the shorter: 000000000000003b leave 000000000000003c ret that gcc usees. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 9 16:13:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 16:13:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 10221] Poor register allocation In-Reply-To: References: Message-ID: <20110709211326.A80FE2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10221 Jeff Muizelaar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Jeff Muizelaar 2011-07-09 16:13:26 CDT --- Fixed by revision: 134776 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 9 19:49:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Jul 2011 19:49:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10320] New: LLVMX86CodeGen.lib can't be created on 64-bit Visual Studio solution. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10320 Summary: LLVMX86CodeGen.lib can't be created on 64-bit Visual Studio solution. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: art.oriented at gmail.com CC: llvmbugs at cs.uiuc.edu It's an old problem, and confirmed that it's still there. I don't know whether there is already a solution (I was unable to find it). - Download the source code. - Create Visual Studio 2010 Win64 solution via CMake. - Open the LLVM.sln, and you will see x64 projects. Problem: Visual Studio can't load LLVMX86CodeGen project. So, building LLVMX86CodeGen.lib will be 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 Jul 10 00:31:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 00:31:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10315] [C++0x] "Call to deleted constructor" with move assignment operator In-Reply-To: References: Message-ID: <20110710053144.5B75B2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10315 Sean Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |scshunt at csclub.uwaterloo.ca Resolution| |INVALID --- Comment #1 from Sean Hunt 2011-07-10 00:31:43 CDT --- This is correct behavior, although the diagnostic is quite lacking. The C++0x draft says that in the presence of a user-declared move constructor or move assignment operator, the implicit copy constructor and copy assignment operator are defined as deleted. Clang only recently implemented this, and I guess GCC 4.6.1 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 Sun Jul 10 14:44:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 14:44:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10321] New: lib/VMCore/Instructions.cpp:191: void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10321 Summary: lib/VMCore/Instructions.cpp:191: void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6867) --> (http://llvm.org/bugs/attachment.cgi?id=6867) Failing input Compile the attached preprocessed input with clang -c to get 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 Sun Jul 10 15:15:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 15:15:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10322] New: -instcombine can deoptimize testcase? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10322 Summary: -instcombine can deoptimize testcase? Product: libraries Version: trunk Platform: PC OS/Version: All 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 In %struct.Value = type { i8* } define void @f1(%struct.Value* %foo, %struct.Value* %bar) { entry: %arrayidx8 = getelementptr inbounds %struct.Value* %foo, i64 -2 call void @f2(%struct.Value* %arrayidx8) nounwind call void @f2(%struct.Value* %bar) nounwind call void @f2(%struct.Value* %arrayidx8) nounwind call void @f2(%struct.Value* %bar) nounwind br label %if.then18 if.then18: %tmp2 = getelementptr inbounds %struct.Value* %arrayidx8, i64 0, i32 0 %tmp3 = load i8** %tmp2, align 8 call void @f3(i8* %tmp3) nounwind ret void } declare void @f2(%struct.Value*) declare void @f3(i8*) instcombine can transform the second gep in %tmp2 = getelementptr inbounds %struct.Value* %foo, i64 -2, i32 0 The original codegens to movq %rsi, %r14 movq %rdi, %rbx addq $-16, %rbx movq %rbx, %rdi callq _f2 movq %r14, %rdi callq _f2 movq %rbx, %rdi callq _f2 movq %r14, %rdi callq _f2 movq (%rbx), %rdi callq _f3 And the new one codegens to movq %rsi, %r15 movq %rdi, %r14 leaq -16(%r14), %rbx movq %rbx, %rdi callq _f2 movq %r15, %rdi callq _f2 movq %rbx, %rdi callq _f2 movq %r15, %rdi callq _f2 movq -16(%r14), %rdi callq _f3 Note that we need an extra register. This can be fixed by adding a hasOneUse to the optimization, but in this case that doesn't look like the right solution. The right solution might be to do this "gep propagation" at the machine code level too and produce movq %rsi, %r15 movq %rdi, %r14 leaq -16(%r14), %rdi callq _f2 movq %r15, %rdi callq _f2 leaq -16(%r14), %rdi callq _f2 movq %r15, %rdi callq _f2 movq -16(%r14), %rdi callq _f3 Yet another option is to disable the optimization if all the new indices are 0, since in that case the two values are the "same", they just have a different type. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 10 16:07:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 16:07:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10323] New: Incomplete support for -fplan9-extensions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10323 Summary: Incomplete support for -fplan9-extensions Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tim.nieradzik at gmx.de CC: llvmbugs at cs.uiuc.edu There are currently two issues with Clang's implementation of the Plan9 extensions: - It must imply -fms-extensions so that a structure declared in a different scope can be used like an unnamed structure. - When passing the pointer of a structure to another function, Clang doesn't select the correct member. See also http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html #include struct s1 { int b; }; struct s2 { int a; struct s1; }; void f0(void *p) { printf("a=%p\n", p); } void f1(struct s1 *p) { printf("b=%p\n", &p->b); } void f2(struct s2 *p) { printf("a=%p b=%p\n", &p->a, &p->b); f0(p); f1(p); } int main(void) { struct s2 s; f2(&s); 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 Sun Jul 10 16:20:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 16:20:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 10324] New: -fms-extensions doesn't set __STDC__ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10324 Summary: -fms-extensions doesn't set __STDC__ Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tim.nieradzik at gmx.de CC: llvmbugs at cs.uiuc.edu GCC sets __STDC__ even when compiling with -fms-extensions. As __STDC__ is required by some system headers, it should be set in Clang as well. For instance, this program miscompiles: #include int main(void) { printf("Hello World.\n"); return 0; } /usr/include/sys/cdefs.h:32:3: error: #error "You need a ISO C conforming compiler to use the glibc headers" >From cdefs.h: /* The GNU libc does not support any K&R compilers or the traditional mode of ISO C compilers anymore. Check for some of the combinations not anymore supported. */ #if defined __GNUC__ && !defined __STDC__ # error "You need a ISO C conforming compiler to use the glibc headers" #endif -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 10 16:47:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 16:47:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10325] New: clang++ craches when compiling certain code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10325 Summary: clang++ craches when compiling certain code 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: llvm at niebuhrt.de CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6868) --> (http://llvm.org/bugs/attachment.cgi?id=6868) ucFiber.cpp the attached code was compiled with libc++ clang++ -c ucFiber.cpp -std=c++0x -U__STRICT_ANSI__ -stdlib=libc++ It used to compile an run with previous revisions. The revision that resulted in this error must be between Jul 5 and Jul 10. clang++ -c ucFiber.cpp -std=c++0x -U__STRICT_ANSI__ -stdlib=libc++ Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file Instructions.cpp, line 191. 0 clang 0x00000001018f4602 PrintStackTrace(void*) + 34 1 clang 0x00000001018f5583 SignalHandler(int) + 707 2 libSystem.B.dylib 0x00007fff877951ba _sigtramp + 26 3 libSystem.B.dylib 0x00007fff5fbf99a0 _sigtramp + 3628484608 4 clang 0x00000001018f4a82 __assert_rtn + 66 5 clang 0x0000000101803a64 llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int) + 292 6 clang 0x0000000101652c84 llvm::CallInst::CallInst(llvm::Value*, llvm::Value**, llvm::Value**, llvm::Twine const&, llvm::Instruction*) + 164 7 clang 0x00000001001ae366 clang::CodeGen::CodeGenFunction::EmitCall(clang::CodeGen::CGFunctionInfo const&, llvm::Value*, clang::CodeGen::ReturnValueSlot, clang::CodeGen::CallArgList const&, clang::Decl const*, llvm::Instruction**) + 5286 8 clang 0x00000001001f04e7 clang::CodeGen::CodeGenFunction::EmitCall(clang::QualType, llvm::Value*, clang::CodeGen::ReturnValueSlot, clang::ConstExprIterator, clang::ConstExprIterator, clang::Decl const*) + 519 9 clang 0x00000001001fb8cb clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) + 1003 10 clang 0x0000000100226582 (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) + 82 11 clang 0x00000001002311eb clang::StmtVisitorBase::Visit(clang::Stmt*) + 3947 12 clang 0x000000010023227d clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 141 13 clang 0x00000001001f27e0 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) + 80 14 clang 0x00000001002001b5 clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 53 15 clang 0x00000001002a48fc clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 1356 16 clang 0x00000001002a78bb clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 283 17 clang 0x00000001002a7c89 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 505 18 clang 0x00000001002a43e0 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48 19 clang 0x00000001002a75c1 clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&) + 529 20 clang 0x00000001002a47dd clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 1069 21 clang 0x00000001002a78bb clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 283 22 clang 0x00000001002a7c89 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 505 23 clang 0x00000001002a43e0 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48 24 clang 0x00000001001bbbb2 clang::CodeGen::CodeGenFunction::EmitConstructorBody(clang::CodeGen::FunctionArgList&) + 210 25 clang 0x00000001002d09b6 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 646 26 clang 0x00000001001a16ee clang::CodeGen::CodeGenModule::EmitCXXConstructor(clang::CXXConstructorDecl const*, clang::CXXCtorType) + 270 27 clang 0x00000001002dbe2f clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 287 28 clang 0x00000001002dc00a clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 154 29 clang 0x00000001002dd029 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 1129 30 clang 0x00000001002dce9b clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 731 31 clang 0x00000001002dce9b clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 731 32 clang 0x00000001002ef80f (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 63 33 clang 0x00000001002cbefb clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 155 34 clang 0x00000001002fd4a2 clang::ParseAST(clang::Sema&, bool) + 338 35 clang 0x00000001002ca3dc clang::CodeGenAction::ExecuteAction() + 60 36 clang 0x000000010002bd01 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 433 37 clang 0x000000010000ac4b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1547 38 clang 0x000000010000154c cc1_main(char const**, char const**, char const*, void*) + 652 39 clang 0x0000000100009a6e main + 4526 40 clang 0x0000000100000934 start + 52 41 clang 0x000000000000002b start + 4294965035 Stack dump: 0. Program arguments: /Users/niebuhr/projects/llvm/Release+Asserts/bin/clang -cc1 -triple x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -main-file-name ucFiber.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 123.2 -coverage-file ucFiber.o -resource-dir /Users/niebuhr/projects/llvm/Release+Asserts/bin/../lib/clang/3.0 -U __STRICT_ANSI__ -stdlib=libc++ -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 151 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o ucFiber.o -x c++ ucFiber.cpp 1. parser at end of file 2. ../odemx-http.git/src/coroutine/ucFiber.cpp:34:11: LLVM IR generation of declaration 'odemx' 3. ../odemx-http.git/src/coroutine/ucFiber.cpp:48:10: Generating code for declaration 'odemx::coroutine::ucFiber::ucFiber' 4. ../odemx-http.git/src/coroutine/ucFiber.cpp:52:1: LLVM IR generation of compound statement ('{}') 5. ../odemx-http.git/src/coroutine/ucFiber.cpp:61:27: LLVM IR generation of compound statement ('{}') clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 10 17:23:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 17:23:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 9168] Wrong source location for CXXMemberCallExpr In-Reply-To: References: Message-ID: <20110710222335.EDBB02A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9168 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |chandlerc at gmail.com Resolution| |FIXED --- Comment #7 from Chandler Carruth 2011-07-10 17:23:34 CDT --- (In reply to comment #6) > I have synced to 127127 now. I see the same issue with CXXOperatorCallExpr. > > obj->method(arg) > ^ > getLocStart() for CXXOperatorCallExpr > > > obj->method(arg) > ^ getLocStart() for MemberExpr > > Thus the start location of sub expression is before the start location of the > encompassing expression. Sorry for the very late response, but I tried this morning (r134880) to reproduce this using the AST dump feature of Clang (as it prints Stmt::getSourceRange for each expression node) and the behavior looks correct: % cat x.cc struct X { struct Y { void operator ()(int) {} } y; }; struct S { X* operator->() { return new X; } }; void test(S s) { s->y(42); } % ./bin/clang -cc1 -ast-dump x.cc void test(S s) (CompoundStmt 0x54021c8 (CXXOperatorCallExpr 0x5402160 'void' (ImplicitCastExpr 0x5402148 <> 'void (*)(int)' (DeclRefExpr 0x54020f8 <> 'void (int)' lvalue CXXMethod 0x53fe8b0 'operator()' 'void (int)')) (MemberExpr 0x5402098 'struct Y':'struct X::Y' lvalue ->y 0x53fe9a0 (CXXOperatorCallExpr 0x5402060 'struct X *' (ImplicitCastExpr 0x5402048 <> 'struct X *(*)(void)' (DeclRefExpr 0x5401ff8 <> 'struct X *(void)' lvalue CXXMethod 0x53fece0 'operator->' 'struct X *(void)')) (DeclRefExpr 0x5401fa0 'struct S' lvalue ParmVar 0x5401e40 's' 'struct S'))) (IntegerLiteral 0x54020d0 'int' 42))) Specifically, CXXOperatorCallExpr starts on column 3, as does the MemberExpr, and the inner CXXOperatorCallExpr (for the -> operator). Please open a new bug if you see further inconsistencies in source locations, and include the sample code and ast dump that hightlights it (if possible to see the problem in ast dump). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 10 17:25:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 17:25:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 5304] Warning about attribude __cdecl__ being ignored in prototype In-Reply-To: References: Message-ID: <20110710222514.EDDE22A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5304 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |WORKSFORME --- Comment #2 from Eli Friedman 2011-07-10 17:25:14 CDT --- This is working now, and I believe it's been working for a while. Please reopen if there are still issues here. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 10 18:09:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 18:09:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10326] New: Unfortunate error message for incorrect operator precedence between 'new' and '->' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10326 Summary: Unfortunate error message for incorrect operator precedence between 'new' and '->' Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu The following program is clearly invalid, but I think we could do better diagnosing it: % cat x.cc struct S { S* foo(int) { return this; } }; S* test() { return new S()->foo(42); } % ./bin/clang -fsyntax-only x.cc x.cc:6:17: error: expected ';' after return statement return new S()->foo(42); ^ ; 1 error generated. It seems like it would be better to say in the error that the new operator has lower precedence than '->', and thus the new expression must be explicitly grouped. Then we could recover and continue parsing the rest of the expression as if that grouping had been performed. This seems reasonable to do for most of the postfix expressions which form a suffix but could not reasonable be part of a new-type-id: '->', '--', '++', and even '(...)' when the parentheses are not parsed as part of the new-initializer. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 10 21:17:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 21:17:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10327] New: unnecessary mov Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10327 Summary: unnecessary mov 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: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu We codegen define void @zed(i8* %cx) nounwind uwtable ssp { entry: tail call void @foo(i8* %cx) nounwind tail call void @bar(i8* %cx) nounwind ret void } declare void @foo(i8*) declare void @bar(i8*) into pushq %rbx movq %rdi, %rbx movq %rbx, %rdi callq __Z3fooPv movq %rbx, %rdi popq %rbx jmp __Z3barPv note the funny rdi -> rbx -> rdi moves. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 10 21:42:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 21:42:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10328] New: Inefficient code for 64 bit shift and compare Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10328 Summary: Inefficient code for 64 bit shift and compare Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu given int foo(unsigned long l) { return (l>> 47) == 1; } we produce %shr.mask = and i64 %l, -140737488355328 %cmp = icmp eq i64 %shr.mask, 140737488355328 %conv = zext i1 %cmp to i32 ret i32 %conv which codegens to movq $0xffff800000000000,%rax andq %rdi,%rax movq $0x0000800000000000,%rcx cmpq %rcx,%rax sete %al movzbl %al,%eax ret gcc produces shrq $0x2f,%rdi xorl %eax,%eax cmpq $0x01,%rdi sete %al 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 Sun Jul 10 22:45:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Jul 2011 22:45:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10322] -instcombine can deoptimize testcase? In-Reply-To: References: Message-ID: <20110711034511.266402A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10322 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Rafael ?vila de Esp?ndola 2011-07-10 22:45:10 CDT --- Fixed in 134883. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 07:25:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 07:25:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10329] New: assertion failure on invalid combination of late-specified return type and 'new'. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10329 Summary: assertion failure on invalid combination of late-specified return type and 'new'. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com $ echo 'void f() { new (auto()->int); }' | clang -cc1 -x c++ -std=c++0x clang: lib/Frontend/TextDiagnosticPrinter.cpp:130: void clang::TextDiagnosticPrinter::HighlightRange(const clang::CharSourceRange&, const clang::SourceManager&, unsigned int, clang::FileID, std::string&, const std::string&): Assertion `StartColNo <= EndColNo && "Invalid range!"' failed. 0 clang 0x0000000001a7313f 1 clang 0x0000000001a753b2 2 libpthread.so.0 0x00007fc912426b40 3 libc.so.6 0x00007fc911724ba5 gsignal + 53 4 libc.so.6 0x00007fc9117286b0 abort + 384 5 libc.so.6 0x00007fc91171da71 __assert_fail + 241 6 clang 0x00000000006b2fc2 clang::TextDiagnosticPrinter::HighlightRange(clang::CharSourceRange const&, clang::SourceManager const&, unsigned int, clang::FileID, std::string&, std::string const&) + 1362 7 clang 0x00000000006b4145 clang::TextDiagnosticPrinter::EmitCaretDiagnostic(clang::SourceLocation, clang::CharSourceRange*, unsigned int, clang::SourceManager const&, clang::FixItHint const*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) + 4069 8 clang 0x00000000006b62ea clang::TextDiagnosticPrinter::HandleDiagnostic(clang::Diagnostic::Level, clang::DiagnosticInfo const&) + 4730 9 clang 0x0000000000fc9355 clang::DiagnosticIDs::ProcessDiag(clang::Diagnostic&) const + 565 10 clang 0x0000000000fc29b1 clang::DiagnosticBuilder::Emit() + 33 11 clang 0x0000000000950bf8 clang::Sema::SemaDiagnosticBuilder::~SemaDiagnosticBuilder() + 248 12 clang 0x0000000000a76f1c clang::Sema::CheckAllocatedType(clang::QualType, clang::SourceLocation, clang::SourceRange) + 444 13 clang 0x0000000000a866d2 clang::Sema::BuildCXXNew(clang::SourceLocation, bool, clang::SourceLocation, clang::ASTMultiPtr, clang::SourceLocation, clang::SourceRange, clang::QualType, clang::TypeSourceInfo*, clang::Expr*, clang::SourceLocation, clang::ASTMultiPtr, clang::SourceLocation, bool) + 274 14 clang 0x0000000000a87cac clang::Sema::ActOnCXXNew(clang::SourceLocation, bool, clang::SourceLocation, clang::ASTMultiPtr, clang::SourceLocation, clang::SourceRange, clang::Declarator&, clang::SourceLocation, clang::ASTMultiPtr, clang::SourceLocation) + 364 15 clang 0x000000000093da2d clang::Parser::ParseCXXNewExpression(bool, clang::SourceLocation) + 2141 16 clang 0x00000000009329fa clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 2362 17 clang 0x000000000093300e clang::Parser::ParseCastExpression(bool, bool, bool) + 46 18 clang 0x0000000000933072 clang::Parser::ParseAssignmentExpression() + 34 19 clang 0x0000000000930779 clang::Parser::ParseExpression() + 9 20 clang 0x00000000008fa573 clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 83 21 clang 0x00000000008f7ef3 clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 2355 22 clang 0x00000000008f5935 clang::Parser::ParseCompoundStatementBody(bool) + 1605 23 clang 0x00000000008f5ef8 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 168 24 clang 0x000000000090b895 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1909 25 clang 0x0000000000918ed8 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1992 26 clang 0x0000000000909229 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 153 27 clang 0x00000000009096b2 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 530 28 clang 0x000000000090d005 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2229 29 clang 0x000000000090d3ac clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 156 30 clang 0x00000000008e888d clang::ParseAST(clang::Sema&, bool) + 285 31 clang 0x000000000068a873 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371 32 clang 0x00000000006726d7 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1319 33 clang 0x0000000000668558 cc1_main(char const**, char const**, char const*, void*) + 760 34 clang 0x00000000006714f1 main + 7121 35 libc.so.6 0x00007fc91170fd8e __libc_start_main + 254 36 clang 0x0000000000667739 Stack dump: 0. Program arguments: clang -cc1 -x c++ -std=c++0x 1. :1:29: current parser token ';' 2. :1:10: parsing function body 'f' 3. :1:10: in compound statement ('{}') zsh: done echo 'void f() { new (auto()->int); }' | zsh: abort clang -cc1 -x c++ -std=c++0x -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 10:15:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:15:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 6482] llvm-link asserts with "Type mismatch in constant table!" depending on linking order In-Reply-To: References: Message-ID: <20110711151512.1E7C02A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6482 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #13 from Chris Lattner 2011-07-11 10:15:10 CDT --- The linker got completely rewritten with the type system rewrite. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 10:17:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:17:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 4155] [driver] in -O4 (LTO) try to use llvm-ld instead of gcc for linking In-Reply-To: References: Message-ID: <20110711151743.109E92A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4155 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Chris Lattner 2011-07-11 10:17:42 CDT --- We don't want clang to depend on llvm-ld. It does not support all of the native linker flags etc. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 11 10:20:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:20:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 7154] Nightly test failures for -O0 -g In-Reply-To: References: Message-ID: <20110711152043.C4CD62A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7154 Chris Lattner 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 Mon Jul 11 10:23:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:23:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 2742] [meta] cases where we mishandle functions with weak linkage In-Reply-To: References: Message-ID: <20110711152313.0A3F52A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2742 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #2 from Chris Lattner 2011-07-11 10:23:12 CDT --- We don't need a metabug to track one other 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 Mon Jul 11 10:24:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:24:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 3283] module verifier allows unsized types that crash llc / llvm-as accepts invalid .ll In-Reply-To: References: Message-ID: <20110711152435.E4AD82A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3283 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2011-07-11 10:24:34 CDT --- Fixed by the type system rewrite. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 10:26:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:26:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 6355] llvm-ld exponentially slow In-Reply-To: References: Message-ID: <20110711152657.49E6A2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6355 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2011-07-11 10:26:56 CDT --- This is fixed by the type system rewrite. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 10:27:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:27:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 6925] "Aliasee not linked" assertion failed In-Reply-To: References: Message-ID: <20110711152747.A1DC32A6C133@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6925 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-07-11 10:27:46 CDT --- I rewrote all this code, so this is either fixed or broken a different way. :) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 11 10:32:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:32:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 4943] llvm-ld crashing when linking FreeBSD kernel In-Reply-To: References: Message-ID: <20110711153204.7621A2A6C136@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4943 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |DUPLICATE --- Comment #11 from Chris Lattner 2011-07-11 10:32:04 CDT --- *** This bug has been marked as a duplicate of bug 4496 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 10:32:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:32:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 4496] linker/lto: assertion fails when linking FreeBSD kernel In-Reply-To: References: Message-ID: <20110711153239.932F22A6C13B@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4496 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-07-11 10:32:38 CDT --- I strongly suspect that this is fixed. Please verify with mainline and file a new bug if required. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 11 10:47:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 10:47:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10330] New: SILK codec inline assembly bug with llvm-gcc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10330 Summary: SILK codec inline assembly bug with llvm-gcc Product: new-bugs Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: jcherukuri_necc at yahoo.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6870) --> (http://llvm.org/bugs/attachment.cgi?id=6870) LLVM GCC 4.2.1 bug compiling SILK codec for ARM architectures Hi , I am trying to compile Skype's SILK codec code using "llvm-gcc compiler" (arm-apple-darwin10-llvm-gcc-4.2) for ARM architecture and am getting an error compiling inline assembly code in src/SKP_Silk_inner_prod_aligned.c error: invalid operand in inline asm: 'smlal ${0:Q}, ${0:R}, $2, $3' make: *** [src/SKP_Silk_inner_prod_aligned.o] Error 1 The same code works fine if I build it with arm-apple-darwin10-gcc-4.2.1 compiler instead Please see the attached text file for all the info. I would appreciate if you could please look into this issue and respond to me at the earliest. Thanks in advance Best Regards Jyotshna Cherukuri -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 11:10:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 11:10:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10331] New: [Win32] clang cannot handle -I foo/bar/ with trailing slash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10331 Summary: [Win32] clang cannot handle -I foo/bar/ with trailing slash Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu I met this in test/Frontend/dependency-gen.c on msys-mingw. eg. $ mkdir -p a/b $ touch a/b/x.h $ echo '#include ' > foo.c $ clang -fsyntax-only -I a/b foo.c (passes) $ clang -fsyntax-only -I a/b/ foo.c foo.c:1:10: fatal error: 'x.h' file not found #include ^ 1 error generated. I have not investigated the root cause, llvm/Support/Path or clang frontend... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 12:58:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 12:58:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10332] New: Compiler crashes when parser overflows the stack, instead of providing a nice report Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10332 Summary: Compiler crashes when parser overflows the stack, instead of providing a nice report Product: clang Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: seth.cantrell at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6871) --> (http://llvm.org/bugs/attachment.cgi?id=6871) A simple case to make parser overflow stack When compiling the attached file the parser overflows the stack. Then the code to catch crashes and print out a stack trace is called and another crash occurs, presenting the user (on Windows 7) with the 'close program'/'debug program' dialog. For comparison, Microsoft's cl.exe gives the following output when compiling the attached file: tail.cpp(2) : fatal error C1026: parser stack overflow, program too complex -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 13:01:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 13:01:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10330] SILK codec inline assembly bug with llvm-gcc In-Reply-To: References: Message-ID: <20110711180155.0DA4A2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10330 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #1 from Eli Friedman 2011-07-11 13:01:54 CDT --- Two issues: 1. You didn't provide enough information to reproduce; please provide a preprocessed version of the failing file. 2. Don't file bugs against the iOS SDK here; please file at bugreport.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 Mon Jul 11 16:46:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 16:46:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 10201] clang does not warn on va_arg(args, float) In-Reply-To: References: Message-ID: <20110711214614.4CCAD2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10201 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #2 from Eli Friedman 2011-07-11 16:46:13 CDT --- r134926. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 11 17:18:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 17:18:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10333] New: llvm-3.0svn build failure with gcc-4.6 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10333 Summary: llvm-3.0svn build failure with gcc-4.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: vlee at vmware.com CC: llvmbugs at cs.uiuc.edu llvm: llvm-3.0svn r134929 gcc: 4:4.6.0-3ubuntu1 $ make [...] make[1]: Entering directory `llvm/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td pure virtual method called terminate called without an active exception make[1]: *** [llvm/lib/VMCore/Release+Asserts/Intrinsics.gen.tmp] Segmentation fault (core dumped) make[1]: *** Deleting file `llvm/lib/VMCore/Release+Asserts/Intrinsics.gen.tmp' make[1]: Leaving directory `llvm/lib/VMCore' make: *** [all] Error 1 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 11 18:28:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 18:28:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10333] llvm-3.0svn build failure with gcc-4.6 In-Reply-To: References: Message-ID: <20110711232817.C2EEF2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10333 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-07-11 18:28:17 CDT --- Try r134936 or 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 Mon Jul 11 20:41:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 20:41:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 10334] New: PowerPC code generator generates $stub function calls for non-Darwin targets Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10334 Summary: PowerPC code generator generates $stub function calls for non-Darwin targets Product: libraries Version: trunk Platform: Macintosh OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Backend: PowerPC AssignedTo: unassignedbugs at nondot.org ReportedBy: chmeeedalf+llvm at gmail.com CC: llvmbugs at cs.uiuc.edu Subject says it all. ELF systems don't need $stub functions, and this prevents proper linking on FreeBSD/ppc (and probably all other ELF PowerPC targets). Something similar to how X86/X86_64 ELF works would probably do the trick for fixing 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 Mon Jul 11 20:47:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 20:47:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10335] New: crash with callbacks passed to vaarg functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10335 Summary: crash with callbacks passed to vaarg functions Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu clang crashes on: typedef void (* JSErrorCallback)(void); void js_GetErrorMessage(void); void JS_ReportErrorNumber(JSErrorCallback errorCallback, ...); void Interpret() { JS_ReportErrorNumber(js_GetErrorMessage, 0); } clang: /home/espindola/llvm/llvm/lib/VMCore/Instructions.cpp:191: void llvm::CallInst::init(llvm::Value *, llvm::Value *const *, unsigned int): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"' 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 Jul 11 23:36:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 23:36:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 10336] New: Assertion `unsignedRange.NonNegative && "unsigned range includes negative?"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10336 Summary: Assertion `unsignedRange.NonNegative && "unsigned range includes negative?"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu [regehr at gamow tmp039]$ clang -v clang version 3.0 (trunk 134918) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp039]$ cat small.c int * g_610; static func_57 (long p_62) { unsigned **l_499; *g_610 == (**l_499 ^= p_62); } main (void) { return 0; } [regehr at gamow tmp039]$ clang -O0 small.c small.c:4:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] func_57 (long p_62) ^ clang: SemaChecking.cpp:2865: void::AnalyzeComparison(clang::Sema&, clang::BinaryOperator*): Assertion `unsignedRange.NonNegative && "unsigned range includes negative?"' failed. 0 clang 0x0000000001a7097f 1 clang 0x0000000001a72bf2 2 libpthread.so.0 0x00007ffff7bcf8f0 3 libc.so.6 0x00007ffff6ebea75 gsignal + 53 4 libc.so.6 0x00007ffff6ec25c0 abort + 384 5 libc.so.6 0x00007ffff6eb7941 __assert_fail + 241 6 clang 0x0000000000997d69 7 clang 0x0000000000a96ed0 clang::Sema::ActOnFinishFullExpr(clang::Expr*) + 128 8 clang 0x000000000091a429 clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 137 9 clang 0x0000000000917da3 clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 2355 10 clang 0x00000000009157e5 clang::Parser::ParseCompoundStatementBody(bool) + 1605 11 clang 0x0000000000915da8 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 168 12 clang 0x000000000092b755 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1909 13 clang 0x0000000000938da8 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1992 14 clang 0x00000000009290e9 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 153 15 clang 0x0000000000929572 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 530 16 clang 0x000000000092cec5 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2229 17 clang 0x000000000092d26c clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 156 18 clang 0x000000000090873d clang::ParseAST(clang::Sema&, bool) + 285 19 clang 0x00000000007c6b54 clang::CodeGenAction::ExecuteAction() + 68 20 clang 0x00000000006abb73 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371 21 clang 0x0000000000693970 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1328 22 clang 0x0000000000689738 cc1_main(char const**, char const**, char const*, void*) + 840 23 clang 0x00000000006927bb main + 7131 24 libc.so.6 0x00007ffff6ea9c4d __libc_start_main + 253 25 clang 0x00000000006888c9 Stack dump: 0. Program arguments: /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r134918-install/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -momit-leaf-frame-pointer -resource-dir /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r134918-install/bin/../lib/clang/3.0 -O0 -ferror-limit 19 -fmessage-length 80 -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-6LjbVZ.o -x c small.c 1. small.c:8:1: current parser token '}' 2. small.c:5:1: parsing function body 'func_57' 3. small.c:5:1: in compound statement ('{}') clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 11 23:53:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Jul 2011 23:53:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 10335] crash with callbacks passed to vaarg functions In-Reply-To: References: Message-ID: <20110712045353.D8E942A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10335 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2011-07-11 23:53:53 CDT --- Fixed in r134966, thanks for the great 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 Tue Jul 12 00:00:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 00:00:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10321] lib/VMCore/Instructions.cpp:191: void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"' failed. In-Reply-To: References: Message-ID: <20110712050012.27ED22A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10321 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-07-12 00:00:11 CDT --- Fixed in r134966. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 00:03:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 00:03:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10334] PowerPC code generator generates $stub function calls for non-Darwin targets In-Reply-To: References: Message-ID: <20110712050314.00F122A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10334 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Chris Lattner 2011-07-12 00:03:13 CDT --- The PPC backend hasn't really been ported to other architectures. Because it is half-way there, it doesn't make sense to track individual bugs. Patches welcome on llvm-commits 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 Tue Jul 12 04:21:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 04:21:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10337] New: lib/VMCore/Instructions.cpp:968: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10337 Summary: lib/VMCore/Instructions.cpp:968: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElemen tType() && "Ptr must be a pointer to Val type!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: clattner at apple.com ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6873) --> (http://llvm.org/bugs/attachment.cgi?id=6873) Failing input Failing input is attached. clang -c hits the assertions. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 06:50:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 06:50:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10325] clang++ craches when compiling certain code In-Reply-To: References: Message-ID: <20110712115005.B2BB22A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10325 Toralf Niebuhr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Toralf Niebuhr 2011-07-12 06:50:04 CDT --- (In reply to comment #2) > Fixed in r134966, please verify though because your testcase doesn't build for > me. Works now. 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 Jul 12 08:34:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 08:34:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 10338] New: __attribute__((noreturn)) not matching functions in clang++ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10338 Summary: __attribute__((noreturn)) not matching functions in clang++ Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: howarth at nitro.med.uc.edu CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The plotutils 2.6 package built with clang/clang++ against png 1.5 exposes a bug in clang++. The same z_write.c source file is compiled first with clang as c in libplot and then with clang++ as c++ in libplotter. The c compilation compiles without error under clang but under clang++ the compilation fails with... /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I./../include -I/sw/include -DLIBPLOT -DLIBPLOTTER -I/sw/include -O2 -MT z_write.lo -MD -MP -MF .deps/z_write.Tpo -c -o z_write.lo z_write.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I./../include -I/sw/include -DLIBPLOT -DLIBPLOTTER -I/sw/include -O2 -MT z_write.lo -MD -MP -MF .deps/z_write.Tpo -c z_write.cc -fno-common -DPIC -o .libs/z_write.o z_write.cc:167:15: error: no matching function for call to 'png_set_longjmp_fn' if (setjmp (png_jmpbuf (png_ptr))) ^~~~~~~~~~~~~~~~~~~~ In file included from z_write.cc:43: /sw/include/png.h:988:9: note: instantiated from: (*png_set_longjmp_fn((png_ptr), longjmp, sizeof (jmp_buf))) ^~~~~~~~~~~~~~~~~~ /sw/include/png.h:985:1: note: candidate function not viable: no known conversion from 'void (int *, int)' to 'png_longjmp_ptr' (aka 'void (*)(int *, int) __attribute__((noreturn))') for 2nd argument PNG_EXPORT(8, jmp_buf*, png_set_longjmp_fn, (png_structp png_ptr, ^ /sw/include/pngconf.h:319:4: note: instantiated from: PNG_EXPORTA(ordinal, type, name, args, PNG_EMPTY) ^ /sw/include/pngconf.h:309:7: note: instantiated from: PNG_FUNCTION(PNG_EXPORT_TYPE(type),(PNGAPI name),PNGARG(args), \ ^ /sw/include/png.h:985:1: note: instantiated from: PNG_EXPORT(8, jmp_buf*, png_set_longjmp_fn, (png_structp png_ptr, ^ /sw/include/pngconf.h:319:4: note: instantiated from: PNG_EXPORTA(ordinal, type, name, args, PNG_EMPTY) ^ /sw/include/png.h:985:1: note: instantiated from: PNG_EXPORT(8, jmp_buf*, png_set_longjmp_fn, (png_structp png_ptr, ^ /sw/include/png.h:985:25: note: instantiated from: PNG_EXPORT(8, jmp_buf*, png_set_longjmp_fn, (png_structp png_ptr, ^ 1 error generated. Steps to Reproduce: The attached no return_bug.tar.bz2 compressed archive contains the preprocessed sources for the two compilations of z_write.c as z_write.i from clang and z_write.ii from clang++. The bug can be demonstrated with... clang -c z_write.i -fno-common -o z_write.o clang++ -c z_write.ii -fno-common -o z_write.o Expected Results: I expected the z_write.ii preprocessed source to compile without error as it does with llvm-gcc-4.2... [MacPro:~/noreturn_bug] howarth% g++ -c z_write.ii -fno-common -o z_write.o [MacPro:~/noreturn_bug] howarth% Actual Results: [MacPro:~/noreturn_bug] howarth% clang++ -c z_write.ii -fno-common -o z_write.o In file included from z_write.cc:1: z_write.cc:167:17: error: no matching function for call to 'png_set_longjmp_fn' if (setjmp ((*png_set_longjmp_fn((png_ptr), longjmp, sizeof (jmp_buf))))) ^~~~~~~~~~~~~~~~~~ /sw/include/png.h:985:19: note: candidate function not viable: no known conversion from 'void (int *, int)' to 'png_longjmp_ptr' (aka 'void (*)(int *, int) __attribute__((noreturn))') for 2nd argument extern jmp_buf* ( png_set_longjmp_fn) (png_structp png_ptr, png_longjmp_ptr longjmp_fn, size_t jmp_buf_size); ^ 1 error generated. Also filed as radr://9757022 . -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 09:40:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 09:40:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10338] __attribute__((noreturn)) not matching functions in clang++ In-Reply-To: References: Message-ID: <20110712144017.E4AFF2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10338 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Douglas Gregor 2011-07-12 09:40:17 CDT --- Clang is actually behaving correctly here. It is unsafe to pass a pointer to a function that my return to a parameter that expects a 'noreturn' function pointer, since the callee could have been optimized on the assumption that calling that function pointer won't return. GCC doesn't actually enforce these type-safety constraints on noreturn function pointers. The fix is relatively simple: explicitly cast from the function pointer type to the 'noreturn' function pointer type, e.g., if (setjmp ((*png_set_longjmp_fn((png_ptr), (png_longjmp_ptr)longjmp, sizeof (jmp_buf))))) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 10:47:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 10:47:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10283] Spell checking triggers "correction has not been looked up" assertion In-Reply-To: References: Message-ID: <20110712154706.2F96B2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10283 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Hans Wennborg 2011-07-12 10:47:05 CDT --- Fixed in r134976. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 11:16:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 11:16:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10339] New: TOT clang crashes building Boost 1.47.0 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10339 Summary: TOT clang crashes building Boost 1.47.0 Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mclow at qualcomm.com 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 Tue Jul 12 12:20:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 12:20:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10340] New: Segmentation fault in simple template testcase Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10340 Summary: Segmentation fault in simple template testcase Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang -cc1 -emit-llvm-bc -w nsRenderingContext.ii crashes on template struct BaseRect { T x, y, width, height; }; struct gfxRect : public BaseRect { }; gfxRect Transform(const gfxRect& rect); gfxRect *foo; void FillRect() { Transform(*foo); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 12 13:14:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 13:14:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 9860] Clang "no viable conversion" bug with operator overload In-Reply-To: References: Message-ID: <20110712181403.4CE232A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9860 d235j.1 at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #3 from d235j.1 at gmail.com 2011-07-12 13:14:03 CDT --- *** This bug has been marked as a duplicate of bug 8800 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 15:59:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 15:59:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10341] New: ::delete acts like regular delete for classes with virtual destructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10341 Summary: ::delete acts like regular delete for classes with virtual destructor Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ppelletier at oblong.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6876) --> (http://llvm.org/bugs/attachment.cgi?id=6876) delete-test.C Although c++ is a complex language and I could easily be wrong about what the correct behavior should be, I believe I have found a bug in clang. In any case, clang behaves differently for my testcase (which I have attached to this bug) than gcc and Visual C++, and I got a reply to my query on the mailing list which suggests this is indeed a clang bug: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-July/016070.html The bug is that I would expect "::delete" to call "::operator delete" after running the class's destructor. For classes without a virtual destructor, this is indeed what happens. However, for classes with a virtual destructor, after clang calls the destructor, it calls the class's operator delete, rather than the global one. In other words, "::delete" seems to act like "delete" if the class has a virtual destructor. This is different than how gcc and Visual C++ behave; they both call the global operator delete when "::delete" is used, regardless of whether the class has a virtual destructor or not. ppelletier at pumpkin:~/misc$ uname -a Linux pumpkin 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux ppelletier at pumpkin:~/misc$ /home/ppelletier/src/asan/asan_clang_Linux/bin/clang++ --version clang version 3.0 (trunk 133511) Target: x86_64-unknown-linux-gnu Thread model: posix ppelletier at pumpkin:~/misc$ g++ --version g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ppelletier at pumpkin:~/misc$ /home/ppelletier/src/asan/asan_clang_Linux/bin/clang++ -O3 -Wall -o delete-test-clang delete-test.C ppelletier at pumpkin:~/misc$ g++ -O3 -Wall -o delete-test-gcc delete-test.C ppelletier at pumpkin:~/misc$ ./delete-test-clang destructor for 1 [1] I would expect this to be printed (and it is) destructor for 2 [2] I would not expect this to be printed (gcc doesn't, clang does) destructor for 3 ppelletier at pumpkin:~/misc$ ./delete-test-gcc destructor for 1 [1] I would expect this to be printed (and it is) destructor for 2 destructor for 3 ppelletier at pumpkin:~/misc$ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 16:41:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 16:41:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10342] New: apparent wrong code bug at -O0 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10342 Summary: apparent wrong code bug at -O0 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: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu I believe the correct result of the program below is "0" because the unsigned bit field is promoted to signed int before comparison. In fact, Clang prints 0 if the comma operator is removed. I think that clinches it. [regehr at gamow ~]$ clang -v clang version 3.0 (trunk 134918) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow ~]$ clang -O0 small.c small.c:11:17: warning: expression result unused [-Wunused-value] int y = x >= (0, s.f1); ^ 1 warning generated. [regehr at gamow ~]$ ./a.out 1 [regehr at gamow ~]$ cat small.c #include struct S0 { unsigned f1:1; }; struct S0 s; int main (void) { int x = -3; int y = x >= (0, s.f1); printf ("%d\n", y); return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 12 16:51:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 16:51:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 10343] New: Segmentation fault with svn r134996 of llvm/clang on c++ code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10343 Summary: Segmentation fault with svn r134996 of llvm/clang on c++ code 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: dane at dbsgeo.com CC: llvmbugs at cs.uiuc.edu My first bug here. Let me know what else I can provide to help track down the issue. 
$  clang++ -o src/cairo_renderer.os -c -arch i386 -arch x86_64
-Iosx/sources/include -Iosx/sources/include/freetype2 -DHAVE_JPEG -ansi -Wall
-Wno-unused-function -Wno-uninitialized -Wno-array-bounds -Wno-parentheses
-Wno-char-subscripts -ftemplate-depth-200 -DDARWIN -DBOOST_SPIRIT_THREADSAFE
-DMAPNIK_THREADSAFE -O3 -finline-functions -Wno-inline -DNDEBUG -DHAVE_CAIRO
-fPIC -Iagg/include -I. -Iinclude -Iosx/sources/include/freetype2
-Iosx/sources/include -I/Library/Frameworks/SQLite3.framework/unix/include
-I/Library/Frameworks/UnixImageIO.framework/unix/include
-I/Library/Frameworks/PROJ.framework/unix/include
-I/Library/Frameworks/GDAL.framework/Versions/1.8/Headers
-I/usr/local/pgsql/include -I/usr/include -I/usr/include/libxml2
-Iosx/sources/include/cairomm-1.0 -Iosx/sources/lib/cairomm-1.0/include
-Iosx/sources/include/cairo -Iosx/sources/include/sigc++-2.0
-Iosx/sources/lib/sigc++-2.0/include -Iosx/sources/include/pixman-1
-I/Library/Frameworks/UnixImageIO.framework/unix/include/libpng14
src/cairo_renderer.cpp
0  clang             0x00000001018f7d22
llvm::SmallVectorTemplateBase::grow(unsigned long) +
754
1  clang             0x00000001018f8b73
llvm::SmallVectorTemplateBase::grow(unsigned long) +
4419
2  libSystem.B.dylib 0x00007fff85a3b1ba _sigtramp + 26
3  libSystem.B.dylib 0x000000013042f410 _sigtramp + 2862563952
4  clang             0x0000000100313701 clang::CodeGenerator::~CodeGenerator()
+ 43617
5  clang             0x0000000100315b6f clang::CodeGenerator::~CodeGenerator()
+ 52943
6  clang             0x00000001001bc28b llvm::cast_retty::ret_type llvm::cast(clang::CXXDestructorDecl const* const&) + 8059
7  clang             0x00000001001bfa3d llvm::cast_retty::ret_type llvm::cast(clang::CXXDestructorDecl const* const&) +
22317
8  clang             0x00000001001bfb32 llvm::cast_retty::ret_type llvm::cast(clang::CXXDestructorDecl const* const&) +
22562
9  clang             0x00000001002fdc42 llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 12178
10 clang             0x00000001002efa83 llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 20899
11 clang             0x00000001002112fc llvm::IRBuilder
>::CreateBitCast(llvm::Value*, llvm::Type const*, llvm::Twine const&) + 37324
12 clang             0x00000001002119a5 llvm::IRBuilder
>::CreateBitCast(llvm::Value*, llvm::Type const*, llvm::Twine const&) + 39029
13 clang             0x0000000100212e7c llvm::IRBuilder
>::CreateBitCast(llvm::Value*, llvm::Type const*, llvm::Twine const&) + 44364
14 clang             0x0000000100250d36
clang::CodeGen::CGRecordLayout::getVirtualBaseIndex(clang::CXXRecordDecl
const*) const + 73126
15 clang             0x00000001002497e3
clang::CodeGen::CGRecordLayout::getVirtualBaseIndex(clang::CXXRecordDecl
const*) const + 43091
16 clang             0x000000010024a73d
clang::CodeGen::CGRecordLayout::getVirtualBaseIndex(clang::CXXRecordDecl
const*) const + 47021
17 clang             0x0000000100213df6 llvm::IRBuilder
>::CreateBitCast(llvm::Value*, llvm::Type const*, llvm::Twine const&) + 48326
18 clang             0x000000010023f9f2
clang::CodeGen::CGRecordLayout::getVirtualBaseIndex(clang::CXXRecordDecl
const*) const + 2658
19 clang             0x00000001002496cb
clang::CodeGen::CGRecordLayout::getVirtualBaseIndex(clang::CXXRecordDecl
const*) const + 42811
20 clang             0x000000010024a73d
clang::CodeGen::CGRecordLayout::getVirtualBaseIndex(clang::CXXRecordDecl
const*) const + 47021
21 clang             0x000000010020af50 llvm::IRBuilder
>::CreateBitCast(llvm::Value*, llvm::Type const*, llvm::Twine const&) + 11808
22 clang             0x0000000100218915 llvm::IRBuilder
>::CreateBitCast(llvm::Value*, llvm::Type const*, llvm::Twine const&) + 67557
23 clang             0x00000001002bc7ac llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 31804
24 clang             0x00000001002bc07e llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 29966
25 clang             0x00000001002bc674 llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 31492
26 clang             0x00000001002bf61b llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 43691
27 clang             0x00000001002bf9e9 llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 44665
28 clang             0x00000001002bc290 llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 30496
29 clang             0x00000001002e88bd
clang::BackendConsumer::InlineAsmDiagHandler(llvm::SMDiagnostic const&, void*,
unsigned int) + 18285
30 clang             0x00000001002f153e llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 27742
31 clang             0x00000001002f3d4b llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 37995
32 clang             0x00000001002f59ee llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 45326
33 clang             0x00000001002f5a33 llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 45395
34 clang             0x00000001002e3ada
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 106
35 clang             0x0000000100316694 llvm::IRBuilder
>::CreateGEP(llvm::Value*, llvm::Value*, llvm::Twine const&) + 804
36 clang             0x00000001002e228c llvm::DenseMap, llvm::DenseMapInfo
>::grow(unsigned int) + 2204
37 clang             0x00000001000433d1 llvm::DenseMap,
llvm::DenseMapInfo >::grow(unsigned int) + 8081
38 clang             0x0000000100024f8b llvm::raw_ostream::operator<<(char
const*) + 1707
39 clang             0x000000010001b8dc
std::vector
>::_M_insert_aux(__gnu_cxx::__normal_iterator > >,
llvm::PassRegistrationListener* const&) + 9116
40 clang             0x0000000100023dae std::vector
>::_M_insert_aux(__gnu_cxx::__normal_iterator > >, std::string const&) +
13582
41 clang             0x000000010001acc4
std::vector
>::_M_insert_aux(__gnu_cxx::__normal_iterator > >,
llvm::PassRegistrationListener* const&) + 6020
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-apple-macosx10.6.8 -emit-obj -disable-free -main-file-name
cairo_renderer.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 95.2.12 -coverage-file
/var/folders/vC/vCkzLwkoGlO6b78KTUPPWE+++TI/-Tmp-/cc-nodwi2.o -resource-dir
/usr/local/bin/../lib/clang/3.0 -D HAVE_JPEG -D DARWIN -D
BOOST_SPIRIT_THREADSAFE -D MAPNIK_THREADSAFE -D NDEBUG -D HAVE_CAIRO -I
osx/sources/include -I osx/sources/include/freetype2 -I agg/include -I . -I
include -I osx/sources/include/freetype2 -I osx/sources/include -I
/Library/Frameworks/SQLite3.framework/unix/include -I
/Library/Frameworks/UnixImageIO.framework/unix/include -I
/Library/Frameworks/PROJ.framework/unix/include -I
/Library/Frameworks/GDAL.framework/Versions/1.8/Headers -I
/usr/local/pgsql/include -I /usr/include -I /usr/include/libxml2 -I
osx/sources/include/cairomm-1.0 -I osx/sources/lib/cairomm-1.0/include -I
osx/sources/include/cairo -I osx/sources/include/sigc++-2.0 -I
osx/sources/lib/sigc++-2.0/include -I osx/sources/include/pixman-1 -I
/Library/Frameworks/UnixImageIO.framework/unix/include/libpng14 -O3 -Wall
-Wno-unused-function -Wno-uninitialized -Wno-array-bounds -Wno-parentheses
-Wno-char-subscripts -Wno-inline -std=c++98 -fdeprecated-macro -ftemplate-depth
200 -ferror-limit 19 -fmessage-length 194 -stack-protector 1 -fblocks
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/vC/vCkzLwkoGlO6b78KTUPPWE+++TI/-Tmp-/cc-nodwi2.o -x c++
src/cairo_renderer.cpp 
1.     parser at end of file
2.    Per-file LLVM IR generation
3.    /usr/include/c++/4.2.1/bits/stl_algo.h:2416:5: Generating code for
declaration 'std::__unguarded_insertion_sort'
4.    /usr/include/c++/4.2.1/bits/stl_algo.h:2418:5: LLVM IR generation of
compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
-- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 12 17:06:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 17:06:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 10344] New: Incorrect disassembly for "0x49 0x90" on x86-64 ("xchg %r8, %rax") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10344 Summary: Incorrect disassembly for "0x49 0x90" on x86-64 ("xchg %r8, %rax") Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu $ echo "0x49 0x90" | llvm-mc -disassemble nop This instruction is actually "xchg %r8, %rax", not a nop. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 17:08:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 17:08:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10345] New: Incorrect assembly of "xchg %eax, %eax" on x86-64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10345 Summary: Incorrect assembly of "xchg %eax, %eax" on x86-64 Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu $ echo "xchg %eax, %eax" | llvm-mc -show-encoding xchgl %eax, %eax ## encoding: [0x90] The correct encoding is "0x87 0xc0"; the given encoding, "0x90", is a nop. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 19:25:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 19:25:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10340] Segmentation fault in simple template testcase In-Reply-To: References: Message-ID: <20110713002552.91F902A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10340 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2011-07-12 19:25:52 CDT --- This is working with r134987. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 19:26:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 19:26:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10346] New: Future won't compile with exceptions disabled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10346 Summary: Future won't compile with exceptions disabled Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu std::future will attempt to throw errors even with exceptions diabled, and as a result fails to compile. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 12 19:58:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 19:58:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 10341] ::delete acts like regular delete for classes with virtual destructor In-Reply-To: References: Message-ID: <20110713005823.8D9152A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10341 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-07-12 19:58:23 CDT --- Fixed in Clang r135021. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 20:28:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 20:28:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 10347] New: Clang permits implicit conversion to 'noreturn' function pointer in C Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10347 Summary: Clang permits implicit conversion to 'noreturn' function pointer in C Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Keywords: accepts-invalid Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu Clang accepts this code in C mode: int add(int); void f0(__attribute__((noreturn)) int (*)(int)); void f1() { f0(&add); } but it should not, since it is unsafe to treat a pointer to a possibly-returning function pointer as a function pointer that is known not to return. We properly diagnose this in C++ mode. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 21:13:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 21:13:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 10342] apparent wrong code bug at -O0 In-Reply-To: References: Message-ID: <20110713021350.6A4E42A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10342 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |FIXED --- Comment #1 from Benjamin Kramer 2011-07-12 21:13:50 CDT --- Eli fixed this in r135026. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 21:16:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 21:16:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 9683] Assert generated when clang GEP's into nested unnamed structs In-Reply-To: References: Message-ID: <20110713021651.69A732A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9683 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2011-07-12 21:16:50 CDT --- Fixed in Clang r135027. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 22:29:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 22:29:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10339] TOT clang crashes building Boost 1.47.0 In-Reply-To: References: Message-ID: <20110713032958.0261D2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10339 Marshall Clow (work) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Marshall Clow (work) 2011-07-12 22:29:57 CDT --- The crash no longer occurs with clang built with r135024 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 12 22:59:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Jul 2011 22:59:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10337] lib/VMCore/Instructions.cpp:968: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed. In-Reply-To: References: Message-ID: <20110713035942.CE6342A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10337 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-07-12 22:59:42 CDT --- Fixed in r135030, 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 Jul 13 01:36:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 01:36:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10336] Assertion `unsignedRange.NonNegative && "unsigned range includes negative?"' failed. In-Reply-To: References: Message-ID: <20110713063632.BB6A62A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10336 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from John McCall 2011-07-13 01:36:32 CDT --- This has nothing to do with anything I've done recently; it seems to just be a longstanding oversight in the integer-range analysis that feeds (e.g.) -Wsign-compare. Fixed in r135034. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 03:17:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 03:17:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10348] New: clang 2.9 can't support chinese path in Windows Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10348 Summary: clang 2.9 can't support chinese path in Windows Product: clang Version: 2.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tunixer at gmail.com CC: llvmbugs at cs.uiuc.edu clang 2.9 can't support chinese path i have a source file named "???.c" but clang can't build it ,it always say "no in put file" i hope the team can improve the support of chinese 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 Jul 13 04:22:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 04:22:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10349] New: clang crashes when using template return type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10349 Summary: clang crashes when using template return type 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: llvm at niebuhrt.de CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6878) --> (http://llvm.org/bugs/attachment.cgi?id=6878) file crashing clang When compiling the attached code, clang crashes with a stack trace. The code is probably wrong, but clang should produce an error. clang++ -std=c++0x -stdlib=libc++ -U__STRICT_ANSI__ template_foo.cpp -o main Assertion failed: (isa(D) && "declaration not instantiated in this scope"), function findInstantiationOf, file SemaTemplateInstantiate.cpp, line 2324. 0 clang 0x00000001018f9b82 PrintStackTrace(void*) + 34 1 clang 0x00000001018fab03 SignalHandler(int) + 707 2 libSystem.B.dylib 0x00007fff877951ba _sigtramp + 26 3 libSystem.B.dylib 0x000001320000012a _sigtramp + 2022092682 4 clang 0x00000001018fa002 __assert_rtn + 66 5 clang 0x000000010066fe25 clang::LocalInstantiationScope::findInstantiationOf(clang::Decl const*) + 421 6 clang 0x00000001006ab908 clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&) + 104 7 clang 0x000000010069553b (anonymous namespace)::TemplateInstantiator::TransformTemplateParmRefExpr(clang::DeclRefExpr*, clang::NonTypeTemplateParmDecl*) + 603 8 clang 0x000000010067bf68 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 4152 9 clang 0x00000001006840ea clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&) + 1690 10 clang 0x00000001006891da bool clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArguments >(clang::(anonymous namespace)::TemplateArgumentLocContainerIterator, clang::(anonymous namespace)::TemplateArgumentLocContainerIterator, clang::TemplateArgumentListInfo&) + 1850 11 clang 0x000000010068a49a clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) + 186 12 clang 0x000000010068d68d clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc) + 189 13 clang 0x00000001006805e9 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) + 889 14 clang 0x0000000100683991 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) + 401 15 clang 0x0000000100692119 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::QualType) + 121 16 clang 0x0000000100694f94 clang::Sema::SubstType(clang::QualType, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) + 68 17 clang 0x00000001006abca4 clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&) + 1028 18 clang 0x00000001006748ca (anonymous namespace)::TemplateInstantiator::TransformDecl(clang::SourceLocation, clang::Decl*) + 122 19 clang 0x000000010067a29f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformInjectedClassNameType(clang::TypeLocBuilder&, clang::InjectedClassNameTypeLoc) + 79 20 clang 0x0000000100680580 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) + 784 21 clang 0x0000000100683991 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) + 401 22 clang 0x0000000100692119 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::QualType) + 121 23 clang 0x00000001006941be clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDeclarationNameInfo(clang::DeclarationNameInfo const&) + 622 24 clang 0x0000000100694f3d clang::Sema::SubstDeclarationNameInfo(clang::DeclarationNameInfo const&, clang::MultiLevelTemplateArgumentList const&) + 45 25 clang 0x00000001006ac85f clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*, clang::TemplateParameterList*) + 767 26 clang 0x00000001006a4d92 clang::DeclVisitor::Visit(clang::Decl*) + 2290 27 clang 0x000000010069c6cc clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 1740 28 clang 0x000000010069de73 clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 2371 29 clang 0x00000001006d0219 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 937 30 clang 0x00000001004b7d91 clang::Sema::CheckCallReturnType(clang::QualType, clang::SourceLocation, clang::CallExpr*, clang::FunctionDecl*) + 3137 31 clang 0x00000001005105b6 clang::Sema::BuildResolvedCallExpr(clang::Expr*, clang::NamedDecl*, clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation, clang::Expr*) + 230 32 clang 0x00000001005ad170 clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation, clang::Expr*) + 2000 33 clang 0x00000001005122b1 clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, clang::ASTMultiPtr, clang::SourceLocation, clang::Expr*) + 1489 34 clang 0x0000000100330977 clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) + 1271 35 clang 0x000000010032adbb clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 1195 36 clang 0x000000010032cf7a clang::Parser::ParseAssignmentExpression() + 58 37 clang 0x000000010032ec71 clang::Parser::ParseExpression() + 17 38 clang 0x000000010031ba56 clang::Parser::ParseDecltypeSpecifier(clang::DeclSpec&) + 310 39 clang 0x000000010030e351 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 6641 40 clang 0x00000001003184c8 clang::Parser::ParseSimpleDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, bool, clang::Parser::ForRangeInit*) + 600 41 clang 0x00000001003186d5 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 133 42 clang 0x00000001003529c4 clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 3316 43 clang 0x0000000100353546 clang::Parser::ParseCompoundStatementBody(bool) + 1526 44 clang 0x0000000100353af9 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 201 45 clang 0x000000010036c04a clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1130 46 clang 0x0000000100317cdc clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2844 47 clang 0x000000010036d2c8 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 168 48 clang 0x000000010036d74e clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 478 49 clang 0x000000010036e343 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2931 50 clang 0x000000010036ea4a clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 554 51 clang 0x00000001002ff42b clang::ParseAST(clang::Sema&, bool) + 315 52 clang 0x00000001002cc1fc clang::CodeGenAction::ExecuteAction() + 60 53 clang 0x000000010002bec1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 433 54 clang 0x000000010000adfb clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1547 55 clang 0x000000010000174c cc1_main(char const**, char const**, char const*, void*) + 652 56 clang 0x0000000100009c1e main + 4526 57 clang 0x0000000100000b34 start + 52 Stack dump: 0. Program arguments: /Users/niebuhr/projects/llvm/Release+Asserts/bin/clang -cc1 -triple x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -main-file-name template_foo.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 123.2 -resource-dir /Users/niebuhr/projects/llvm/Release+Asserts/bin/../lib/clang/3.0 -U __STRICT_ANSI__ -stdlib=libc++ -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 151 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/i1/i1WwOXILFa8QNqJQnuxxd++++TI/-Tmp-/cc-6U5LKY.o -x c++ template_foo.cpp 1. template_foo.cpp:31:41: current parser token ')' 2. template_foo.cpp:29:13: parsing function body 'main' 3. template_foo.cpp:29:13: in compound statement ('{}') clang: error: unable to execute command: Illegal instruction -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 13 04:38:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 04:38:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10350] New: Forward declared protocols + inherited protocol conformance results in protocol conformance warnings Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10350 Summary: Forward declared protocols + inherited protocol conformance results in protocol conformance warnings 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: keith at realmacsoftware.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6879) --> (http://llvm.org/bugs/attachment.cgi?id=6879) Test case, compile options detailed in description Summary: I make heavy use of protocols and inheritance in one of my projects. My subclasses often define a more specific delegate protocol than their superclass, and make their own delegate protocol conform to the protocols of the superclass' delegate. When a project compiled with clang imports one of these header chains, the compiler complains that the declaration of the subclass' delegate property is incompatible with the superclass' declaration. I have noted that this only occurs when the protocols are forward declared using @protocol, and later defined. I like to forward declare my @protocols and define them after my @interface declaration. Example Warning Given: warning: property type 'id' is incompatible with type 'id' inherited from 'AFNetworkConnectionLayer' [3] Expected Results: Don't warn about property type incompatibilities when basing the warning on a forward declared @protocol, the compiler should read ahead to the @protocol definition before issuing a warning. Workaround: Define the @protocol before the class that uses the declaration in it's property list, using @class to forward declare the class if necessary. Example Project: Attached is an archive with two files. To demonstrate the warning illustrated above, compile with no additional defines: `clang clang_protocol_conformance.m -framework Foundation` and receive the following warning: clang_protocol_conformance.m:19:35: warning: property type 'id' is incompatible with type 'id' inherited from 'Parent' @property (assign) id delegate; ^ 1 warning generated. To workaround the problem, define RM_FORWARD_DEFINE_PROTOCOLS, which moves the #import above the @interface declarations, and fixes the warnings. Compile with: `clang clang_protocol_conformance.m -framework Foundation -DRM_FORWARD_DEFINE_PROTOCOLS` and no warnings are generated. Clang Version: Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.0.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 Jul 13 07:02:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 07:02:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 10351] New: NULL pointer dereference in clang::CodeGen::CodeGenFunction::destroyCXXObject Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10351 Summary: NULL pointer dereference in clang::CodeGen::CodeGenFunction::destroyCXXObject Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6880) --> (http://llvm.org/bugs/attachment.cgi?id=6880) Failing input Start of the backtrace: 0 clang 0x000000000285ccd9 1 clang 0x000000000285cad5 2 libpthread.so.0 0x00007f4a44006c60 3 clang 0x00000000012a474c clang::FunctionDecl::isTrivial() const + 12 4 clang 0x000000000130de12 clang::CodeGen::CodeGenFunction::destroyCXXObject(clang::CodeGen::CodeGenFunction&, llvm::Value*, clang::QualType) + 104 5 clang 0x000000000133786a clang::CodeGen::CodeGenFunction::emitArrayDestroy(llvm::Value*, llvm::Value*, clang::QualType, void (&)(clang::CodeGen::CodeGenFunction&, llvm::Value*, clang::QualType), bool, bool) + 668 6 clang 0x0000000001337b13 7 clang 0x0000000001337bc8 8 clang 0x0000000001316aed 9 clang 0x0000000001318178 clang::CodeGen::CodeGenFunction::PopCleanupBlock(bool) + 5390 10 clang 0x0000000001316682 clang::CodeGen::CodeGenFunction::PopCleanupBlocks(clang::CodeGen::EHScopeStack::stable_iterator) + 164 11 clang 0x0000000001313993 clang::CodeGen::CodeGenFunction::RunCleanupsScope::~RunCleanupsScope() + 71 1 The dtor variable in destroyCXXObject is NULL. Preprocessed source is attached. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 13 10:19:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 10:19:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 9613] clang doesn't handle -MG properly In-Reply-To: References: Message-ID: <20110713151907.31FF32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9613 Peter Collingbourne changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |peter at pcc.me.uk Resolution| |FIXED --- Comment #1 from Peter Collingbourne 2011-07-13 10:19:06 CDT --- Implemented in r134996. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 11:01:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 11:01:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 10346] Future won't compile with exceptions disabled In-Reply-To: References: Message-ID: <20110713160104.948842A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10346 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2011-07-13 11:01:04 CDT --- Committed revision 135045. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 11:58:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 11:58:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10243] [C++] aborts during compilation In-Reply-To: References: Message-ID: <20110713165819.84CA52A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10243 Enea Zaffanella changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Enea Zaffanella 2011-07-13 11:58:18 CDT --- Fixed in http://llvm.org/viewvc/llvm-project?view=rev&revision=134892 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 13:27:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 13:27:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10228] Crash on -dealloc in category with ARC enabled In-Reply-To: References: Message-ID: <20110713182713.A27D42A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10228 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |FIXED --- Comment #1 from John McCall 2011-07-13 13:27:12 CDT --- Thanks for finding this! Fixed in r135054. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 15:13:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 15:13:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10351] NULL pointer dereference in clang::CodeGen::CodeGenFunction::destroyCXXObject In-Reply-To: References: Message-ID: <20110713201312.E66FC2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10351 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |FIXED --- Comment #1 from John McCall 2011-07-13 15:13:12 CDT --- Fixed in r135073. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 15:44:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 15:44:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 7565] LTO failed due to signal 11 In-Reply-To: References: Message-ID: <20110713204411.4C3FB2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7565 Toralf Niebuhr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |llvm at niebuhrt.de Resolution| |FIXED --- Comment #13 from Toralf Niebuhr 2011-07-13 15:44:10 CDT --- works with the currently shipped developer kit from apple -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 17:20:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 17:20:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10318] namespace error message doesn't make sense In-Reply-To: References: Message-ID: <20110713222057.E971A2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10318 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #6 from Eli Friedman 2011-07-13 17:20:57 CDT --- r135086. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 19:59:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 19:59:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10352] New: inline asm can't tie bool to "q" constraint Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10352 Summary: inline asm can't tie bool to "q" constraint Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, echristo at gmail.com Consider this code: template inline void test(T desired) { __asm__ __volatile__("foo %0" : : "q" (desired)); } void helper() { bool v; // char, short, float, double, unsigned long long all work test(v); } Note that the failure about "foo" not being a valid mnemonic is not a problem. The problem is: $ clang z.cc fatal error: error in backend: Couldn't allocate input reg for constraint 'q'! GCC thinks this is fine: $ gcc z.cc z.cc: Assembler messages: z.cc:3: Error: no such instruction: `foo %al' -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 20:22:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 20:22:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10353] New: Definitions of operator new do not have exception specification Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10353 Summary: Definitions of operator new do not have exception specification Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu The definitions of operator new in src/new.cpp do not feature an exception specification which causes an error in C++03 mode. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 20:34:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 20:34:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10353] Definitions of operator new do not have exception specification In-Reply-To: References: Message-ID: <20110714013457.83F772A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10353 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2011-07-13 20:34:57 CDT --- Committed revision 135125. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 21:39:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 21:39:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10354] New: Assertion failed: (LoopToAliasSetMap.empty() && "Didn't free loop alias sets") running scalar-evolution early Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10354 Summary: Assertion failed: (LoopToAliasSetMap.empty() && "Didn't free loop alias sets") running scalar-evolution early Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6882) --> (http://llvm.org/bugs/attachment.cgi?id=6882) Testcase Assertion failed: (LoopToAliasSetMap.empty() && "Didn't free loop alias sets"), function doFinalization, file /Volumes/storage/llvm/lib/Transforms/Scalar/LICM.cpp, line 90. Reproduces with "opt bugpoint-reduced-simplified.bc -scalar-evolution -loop-rotate -licm -indvars -loop-unroll". Note that explicitly specifying -scalar-evolution is necessary because otherwise, we end up with two loop pass managers. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 13 22:07:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 22:07:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 10355] New: crash after typo correction of template-id to templated function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10355 Summary: crash after typo correction of template-id to templated function Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This testcase: template void template_id1() { template_id2<> t; } crashes: nlewycky at ducttape:~$ llvm/Debug+Asserts/bin/clang -cc1 reduced.cc reduced.cc:3:3: error: use of undeclared identifier 'template_id2'; did you mean 'template_id1'? template_id2<> t; ^~~~~~~~~~~~ template_id1 0 clang 0x00000000027d2e31 1 clang 0x00000000027d2c24 2 libpthread.so.0 0x00007fb42ec148f0 3 clang 0x000000000104beda clang::Decl::getLocation() const + 12 4 clang 0x00000000013ea351 clang::Sema::ClassifyName(clang::Scope*, clang::CXXScopeSpec&, clang::IdentifierInfo*&, clang::SourceLocation, clang::Token const&) + 3221 5 clang 0x00000000013275cc clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 844 6 clang 0x0000000001329ae3 clang::Parser::ParseCompoundStatementBody(bool) + 1113 7 clang 0x000000000132d75d clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 245 8 clang 0x000000000133d272 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 2518 9 clang 0x000000000132fe2e clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 1322 10 clang 0x000000000132f8b6 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 996 11 clang 0x000000000132f43b clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 175 12 clang 0x00000000013482c3 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 193 13 clang 0x000000000133bcb6 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1494 14 clang 0x000000000133b631 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 309 15 clang 0x000000000131a026 clang::ParseAST(clang::Sema&, bool) + 455 16 clang 0x000000000104b95d clang::ASTFrontendAction::ExecuteAction() + 263 17 clang 0x000000000104b5ae clang::FrontendAction::Execute() + 326 18 clang 0x0000000001031031 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 751 19 clang 0x0000000001005033 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 912 20 clang 0x0000000000ff625c cc1_main(char const**, char const**, char const*, void*) + 987 21 clang 0x00000000010006ea main + 499 22 libc.so.6 0x00007fb42deeec4d __libc_start_main + 253 23 clang 0x0000000000ff58f9 Stack dump: 0. Program arguments: llvm/Debug+Asserts/bin/clang -cc1 reduced.cc 1. reduced.cc:3:3: current parser token 'template_id2' 2. reduced.cc:2:1: parsing function body 'template_id1' 3. reduced.cc:2:1: in compound statement ('{}') 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 Jul 13 22:25:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Jul 2011 22:25:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10356] New: LICM doesn't preserve scalar-evolution correctly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10356 Summary: LICM doesn't preserve scalar-evolution correctly Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Per summary; moving an instruction out of a loop while preserving SCEV requires a call to ScalarEvolution::forgetValue(), but LICM doesn't call it at the moment. Noting here so I don't forget about 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 Jul 14 04:12:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 04:12:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 8800] conversion function not viable if conversion-type-id is reference to incomplete type In-Reply-To: References: Message-ID: <20110714091203.1DE9A2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8800 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Richard Smith 2011-07-14 04:12:02 CDT --- Fixed in r135101. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 07:14:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 07:14:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10357] New: Compilation failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10357 Summary: Compilation failed Product: dragonegg Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: New Bugs AssignedTo: baldrick at free.fr ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu I think we need an update in dragonegg: Compiling Backend.cpp /home/ryuta/devel/dragonegg/src/dragonegg/src/Backend.cpp: In function ?void CreateStructorsList(std::vector >&, const char*)?: /home/ryuta/devel/dragonegg/src/dragonegg/src/Backend.cpp:693:56: error: no matching function for call to ?llvm::FunctionType::get(llvm::Type*, std::vector, bool)? /home/ryuta/devel/dragonegg/src/dragonegg/src/Backend.cpp:693:56: note: candidates are: /usr/include/llvm/DerivedTypes.h:105:24: note: static llvm::FunctionType* llvm::FunctionType::get(const llvm::Type*, llvm::ArrayRef, bool) /usr/include/llvm/DerivedTypes.h:105:24: note: no known conversion for argument 2 from ?std::vector? to ?llvm::ArrayRef? /usr/include/llvm/DerivedTypes.h:110:24: note: static llvm::FunctionType* llvm::FunctionType::get(const llvm::Type*, bool) /usr/include/llvm/DerivedTypes.h:110:24: note: candidate expects 2 arguments, 3 provided make: *** [Backend.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 Thu Jul 14 12:41:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 12:41:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 10358] New: -Wuninitialized false negative for use inside a loop Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10358 Summary: -Wuninitialized false negative for use inside a loop Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matthewbg at google.com CC: llvmbugs at cs.uiuc.edu void f(int i); void g() { int j; for (int k = 0; k < 10; ++k) f(j); } Clang doesn't warn about the uninitialized use of 'j'. GCC (4.4.3) says "may be used uninitialized" at -O0 and "is used uninitialized" at -O2. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 14:03:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 14:03:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10359] New: Allows declarators after a class template declaration Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10359 Summary: Allows declarators after a class template declaration Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang accepts this code template struct A { static A a; } A::a; It should reject it, because when a template-declaration declares a class template, no declarators are permitted to appear in the init-declarator section of the simple-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 Thu Jul 14 14:48:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 14:48:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 10360] New: Building LLVM-GCC Front-end 4.2-2.9 on Sparc Solaris Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10360 Summary: Building LLVM-GCC Front-end 4.2-2.9 on Sparc Solaris Product: Build scripts Version: 2.9 Platform: Sun OS/Version: Solaris Status: NEW Keywords: build-problem Severity: normal Priority: P Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: javpicorel at gmail.com CC: llvmbugs at cs.uiuc.edu Platform: - Sun4U Sparc Solaris (Solaris 2.10) Status: - llvm-2.9 (not SVN) succesfully builded - llvm-gcc-4.2-2.9.source extracted - in llvm-gcc-4.2-2.9.source/ --> mkdir obj - cd obj - ../configure --prefix=/../llvm-gcc/ --program-prefix=llvm- --enable-llvm=/../llvm-2.9/obj/ --enable-languages=c,c++ - make ENABLE_OPTIMIZED=1 When building I receive: /export/home/picorel/filesCloud9/llvm-gcc4.2-2.6.source/obj/./gcc/xgcc -B/export/home/picorel/filesCloud9/llvm-gcc4.2-2.6.source/obj/./gcc/ -B/export/home/picorel/programs/llvm-gcc//sparc-sun-solaris2.10/bin/ -B/export/home/picorel/programs/llvm-gcc//sparc-sun-solaris2.10/lib/ -isystem /export/home/picorel/programs/llvm-gcc//sparc-sun-solaris2.10/include -isystem /export/home/picorel/programs/llvm-gcc//sparc-sun-solaris2.10/sys-include -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -I/export/home/picorel/filesCloud9/llvm-2.6/obj//include -I/export/home/picorel/filesCloud9/llvm-2.6/include \ -c ../../gcc/config/sparc/gmon-sol2.c -o gmon.o Assertion failed: Traits::getNext(NodePtr) != 0 && "Dereferencing end()!", file /export/home/picorel/filesCloud9/llvm-2.6/include/llvm/ADT/ilist.h, line 197 ../../gcc/config/sparc/gmon-sol2.c:423: internal compiler error: Abort Please submit a full bug report, with preprocessed source if appropriate. See for instructions. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 14 15:15:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 15:15:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 10352] inline asm can't tie bool to "q" constraint In-Reply-To: References: Message-ID: <20110714201531.06C452A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10352 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Eric Christopher 2011-07-14 15:15:30 CDT --- Fixed thusly: [ghostwheel:~/sources/llvm-git] echristo% git svn dcommit Committing to https://llvm.org/svn/llvm-project/llvm/trunk ... Authentication realm: LLVM Subversion repository Password for 'echristo': M lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp M lib/CodeGen/SelectionDAG/TargetLowering.cpp M lib/Target/X86/X86ISelLowering.cpp M test/CodeGen/X86/inline-asm.ll Committed r135180 M test/CodeGen/X86/inline-asm.ll M lib/Target/X86/X86ISelLowering.cpp M lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp M lib/CodeGen/SelectionDAG/TargetLowering.cpp r135180 = 288d8c56b953b1ede3ee5ca7ff5d8d4bc6869969 (refs/remotes/origin/master) No changes between current HEAD and refs/remotes/origin/master Resetting to the latest refs/remotes/origin/master -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 15:15:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 15:15:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 10360] Building LLVM-GCC Front-end 4.2-2.9 on Sparc Solaris In-Reply-To: References: Message-ID: <20110714201547.52B102A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10360 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-07-14 15:15:46 CDT --- Worry, but llvm-gcc has reached its end of life. Please try clang or dragonegg. Neither of them have been fully ported to sparc as far as I know. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 15:41:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 15:41:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 10361] New: Ambiguity with name lookup into namespace with inline namespaces not detected Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10361 Summary: Ambiguity with name lookup into namespace with inline namespaces not detected Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This ambiguity is not detected by clang. Apparently it stops looking into 'A' when it finds the direct declaration of 'f' in A, and doesn't look into the inline namespace. The FDIS says that name lookup for A::f yields both A::f and A::B::f. namespace A { inline namespace B { template struct f { }; } template struct f { }; } int main() { A::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 Thu Jul 14 16:36:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 16:36:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10359] Allows declarators after a class template declaration In-Reply-To: References: Message-ID: <20110714213611.60CD72A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10359 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution| |FIXED --- Comment #1 from Richard Smith 2011-07-14 16:36:11 CDT --- Fixed in r135195. We even accepted cases like this: template struct A {} 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 Thu Jul 14 17:51:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 17:51:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 10363] New: crash if structure field is used in initialization expression Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10363 Summary: crash if structure field is used in initialization expression Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This crashes clang in c++ mode: struct SharedFields { unsigned regnum; }; SharedFields sharedFields; unsigned r = { sharedFields.regnum }; -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 17:58:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 17:58:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10363] crash if structure field is used in initialization expression In-Reply-To: References: Message-ID: <20110714225859.76D872A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10363 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Rafael ?vila de Esp?ndola 2011-07-14 17:58:59 CDT --- Fixed in 135210 by reverting 135177. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 18:02:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 18:02:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10364] New: ptrdiff_t and size_t used unqualified Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10364 Summary: ptrdiff_t and size_t used unqualified Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Support Libraries AssignedTo: unassignedbugs at nondot.org ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu We use ptrdiff_t and size_t frequently without qualifying them, which won't work on a C++ library that does not declare them in the global namespace. Probably the best approach is just to import them into the llvm namespace, but we could also go qualifying them everywhere. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 18:42:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 18:42:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 10365] New: missing support for %cc in inline asm Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10365 Summary: missing support for %cc in 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: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu gcc accepts void f() { __asm__ ( "" : : : "%cc"); } but clang rejects it with: unknown register name '%cc' in asm -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 18:44:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 18:44:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10358] -Wuninitialized false negative for use inside a loop In-Reply-To: References: Message-ID: <20110714234435.CE5992A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10358 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #5 from Ted Kremenek 2011-07-14 18:44:35 CDT --- (In reply to comment #2) > Created an attachment (id=6883) --> (http://llvm.org/bugs/attachment.cgi?id=6883) [details] > Don't ever mark uninitialized variables as Initialized > > Here's a patch to mark uninitialized variables as Unknown instead of > Initialized when trying to just avoid cascaded warnings. This way > isUninitialized() will still return false but variables don't accidentally get > marked as maybe uninitialized when they are clearly uninitialized. I've also > mailed it to cfe-commits. Applied in r135217. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 18:58:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 18:58:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10366] New: path problem on ubuntu 11.04 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10366 Summary: path problem on ubuntu 11.04 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: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu I know this is a known issue, but couldn't find it in the bugzilla. Anything I can help do to fix this? Seems like it must be a hardcoded path somewhere... regehr at home:~$ clang small.c -w /usr/bin/ld.bfd.real: cannot find crtbegin.o: No such file or directory /usr/bin/ld.bfd.real: cannot find -lgcc /usr/bin/ld.bfd.real: cannot find -lgcc_s clang: error: linker command failed with exit code 1 (use -v to see invocation) regehr at home:~$ clang -v clang version 3.0 (trunk 135196) 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 Thu Jul 14 19:00:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 19:00:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10356] LICM doesn't preserve scalar-evolution correctly In-Reply-To: References: Message-ID: <20110715000044.29E622A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10356 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Eli Friedman 2011-07-14 19:00:43 CDT --- Yeah, this is just me not really thinking things through. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 14 22:33:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Jul 2011 22:33:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10307] Add Contains() to GRStateTrait's specialization of ImmutableList In-Reply-To: References: Message-ID: <20110715033318.69E002A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10307 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Ted Kremenek 2011-07-14 22:33:18 CDT --- Applied in r135241. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 00:23:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 00:23:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 1823] 'noalias' attribute lost when compiling with optimization In-Reply-To: References: Message-ID: <20110715052310.2B9242A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=1823 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Chris Lattner 2011-07-15 00:23:09 CDT --- Clang gets this right, llvm-gcc is retired. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 00:24:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 00:24:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 6751] bug in release 2.7 In-Reply-To: References: Message-ID: <20110715052411.6C7BB2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6751 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #3 from Chris Lattner 2011-07-15 00:24:10 CDT --- A long dead bug, closing as not having enough info. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 15 00:24:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 00:24:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 6867] Unexpected linkage decl In-Reply-To: References: Message-ID: <20110715052436.B5E4F2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6867 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #2 from Chris Lattner 2011-07-15 00:24:35 CDT --- We don't have enough info to do anything with 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 Jul 15 00:25:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 00:25:07 -0500 (CDT) Subject: [LLVMbugs] =?utf-8?q?=5BBug_6966=5D_llvm/include/llvm/Support/All?= =?utf-8?b?b2NhdG9yLmg6MTAzOjE4OiBub3RlOiAg4oCYbGx2bSA6OkJ1bXBQdHJBbGxv?= =?utf-8?q?cator=3A=3A_Allocator=E2=80=99_should_be_initialized?= In-Reply-To: References: Message-ID: <20110715052507.AB5822A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6966 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Chris Lattner 2011-07-15 00:25:06 CDT --- Seems like a bug in the host 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 Fri Jul 15 00:25:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 00:25:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 7203] Cast kind 7 not handled In-Reply-To: References: Message-ID: <20110715052546.0C8E72A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7203 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Chris Lattner 2011-07-15 00:25:45 CDT --- There is no attached 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 Fri Jul 15 00:26:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 00:26:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 7340] Analyzer++ crash due to unsupported statement In-Reply-To: References: Message-ID: <20110715052628.6276A2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7340 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Chris Lattner 2011-07-15 00:26:27 CDT --- Works 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 Fri Jul 15 00:28:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 00:28:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 8132] signal 11 while analyzing a file with clang from 2.8 branch In-Reply-To: References: Message-ID: <20110715052824.C66CB2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8132 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Chris Lattner 2011-07-15 00:28:24 CDT --- 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 Jul 15 00:34:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 00:34:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 10263] Wrong definition of ftrunc. In-Reply-To: References: Message-ID: <20110715053438.646DB2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10263 Jan Hranac changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #3 from Jan Hranac 2011-07-15 00:34:38 CDT --- OK, let me be more specific: this definition says that the input and the output are same - but how can it possibly be same when the operation is float truncation?! In short, specification in the tablegen differs from the one in 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 Fri Jul 15 01:06:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 01:06:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10263] Wrong definition of ftrunc. In-Reply-To: References: Message-ID: <20110715060629.CF8E32A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10263 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2011-07-15 01:06:29 CDT --- This doesn't implement the IR truncation operation, it implements the libm truncation operation. do "man trunc" or "man truncf". -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 01:25:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 01:25:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10367] New: Fix the design of GlobalAlias to not require dest type to match source type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10367 Summary: Fix the design of GlobalAlias to not require dest type to match source type Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu Global alias is currently defined to have its own type, and then have an initializer of the same type. The initializer is a "Constant*" which is either a) a global value, b) a constant expr bitcast, c) a constantexpr gep with all zero indices, d) null (which isn't valid, but transiently happens). This doesn't make sense for a number of reasons. Instead, the initializer of a GlobalAlias should be required to be a GlobalValue, but the type of the source and dest of the alias should not be required to be the same, they should just be completely decoupled. -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 15 01:32:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 01:32:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10368] New: Redesign ConstantExpr's Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10368 Summary: Redesign ConstantExpr's Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu We currently allow ConstantExprs occur for any side-effect free LLVM IR instruction, and use ConstantExpr::get as the primitive constant folding API in LLVM. This doesn't make sense for a number of reasons: a) code generators can't codegen arbitrary constant exprs at arbitrary places, causing global variable initializers to explode in funny ways if the optimizer gets creative. b) constant expressions like divides canTrap() which is a common source of bugs. c) optimizers typically treat constants as cheap or free, but a ConstantExpr can have arbitrary cost. d) optimizers try to handle both instructions and constantexprs equally well in many cases, leading to complexity in PatternMatch.h and to the existence of the Operator classes, which are gross. e) we have no way to represent target-specific relocations that don't conveniently map to ConstantExprs. Instead, I propose that we implement the following plan: 1. Switch everything off using ConstantExpr::get as constant folding API, onto the InstSimplify APIs, which are more general and powerful anyway. 2. Move all of the constant folding logic out of ConstantExpr::get into InstSimplify so that ConstantExpr::get *just* creates them. 3. Remove the canTrap() constant exprs, simplifying the world and cleaning up tons of stuff. 4. Introduce new ConstantExprs for target specific things that we currently need like darwin_symbol_difference. 5. Remove various extraneous constantexprs other than GEP and bitcast. 6. Introduce a new ConstantExpr "base_offset" node which takes a constant pointer and integer and adds them together, returning a new pointer. Teach the optimizer to optimize them as well as ConstantExpr GEP's are right now. 7. Remove the gep constantexpr, leaving us with the target specific ones, bitcast, and base_offset. 8. Profit! -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 15 05:48:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 05:48:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10369] New: __builtin___NSStringMakeConstantString() always uses Mac runtime Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10369 Summary: __builtin___NSStringMakeConstantString() always uses Mac runtime 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: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu Clang is crashing in .c files calling __builtin___NSStringMakeConstantString() because it trying to create an instance of CGObjCMac (not sure why this crashes - it should at least just do the wrong thing). The problem seems to be related to recent improvements in the driver, so the NeXTRuntime flag is always being set, because -fgnu-runtime is not being passed to the frontend if the language is not Objective-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 Fri Jul 15 06:51:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 06:51:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10370] New: [MC assembler] after r134501, again incorrect reloc type for push of a label argument (on x86_64) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10370 Summary: [MC assembler] after r134501, again incorrect reloc type for push of a label argument (on x86_64) Product: new-bugs Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu After r134501, bug 8798 reappears, but since the regression test was also amended in r134511, there were no test failures. Again, the reasoning is that this x85_64 assembly: pushq $foo foo: should result in the following opcodes: 0000000000000000 : 0: 68 00 00 00 00 pushq $0x0 and the following relocation: Offset Info Type Sym. Value Sym. Name + Addend 000000000001 00020000000b R_X86_64_32S 0000000000000000 .text + 5 After r134501 however, the opcodes become: 0000000000000000 : 0: 6a 00 pushq $0x0 and the relocation becomes: Offset Info Type Sym. Value Sym. Name + Addend 000000000001 00020000000e R_X86_64_8 0000000000000000 .text + 2 A pushq of a label should never be shortened to an 8 bit operand. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 11:51:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 11:51:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 10371] New: Spurious -Wunused-[x] warning within erroneous function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10371 Summary: Spurious -Wunused-[x] warning within erroneous function Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matthieu.monrocq at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com When a function does not parse correctly, there is a risk that some arguments/identifiers be reported as unused; probably if they only appear in expressions whose evaluation has been short-circuited. Using the following short program: struct A; void sink(A,int); void func(A const& a, int x, int y) { sink(a + x, y); } Clang will correctly report an error, but it will accompany it by an incorrect warning: $ clang -fsyntax-only -Wunused-parameter unused_parameter.cpp unused_parameter.cpp:15:11: error: invalid operands to binary expression ('const A' and 'int') sink(a + x, y); ~ ^ ~ unused_parameter.cpp:14:34: warning: unused parameter 'y' [-Wunused-parameter] void func(A const& a, int x, int y) { ^ 1 warning and 1 error generated. For reference: $ clang --version clang version 3.0 (trunk 132889) Target: i686-pc-mingw32 Thread model: posix The warning is probably emitted because of the incomplete parse of the function, meaning that the point of use is "hidden" by the error. >From Ted: We should probably not emit a -Wunused-[x] warning in cases where a function doesn't fully parse correctly. Please file a bug. Here it is :) -- Matthieu -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 12:44:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 12:44:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10372] New: clang++ crashed when analyzing a function with returntype int, when it contains a return __null statement Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10372 Summary: clang++ crashed when analyzing a function with returntype int, when it contains a return __null statement Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: bastianra at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6884) --> (http://llvm.org/bugs/attachment.cgi?id=6884) Test case that triggers the bug and and scan-build output. Hi, I am using a version compiled from URL: http://llvm.org/svn/llvm-project/cfe/trunk Repository Root: http://llvm.org/svn/llvm-project Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8 Revision: 135213 running scan-build -o . -v -v -v g++ main.cpp on a file containing int main(int argc, char * argv[]) { return __null; } will crash clang++. I have attached the output directory generated by scan-build including the failure report. Best, Bastian -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 14:16:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 14:16:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 10373] New: Inlining non-virtual thunks causes code bloat Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10373 Summary: Inlining non-virtual thunks causes code bloat Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: jmuizelaar at mozilla.com CC: llvmbugs at cs.uiuc.edu The following example compiles to two separate functions: class nsSVGElement { virtual void PrependLocalTransformTo() const; }; class nsIDOMSVGAnimatedPathData { virtual unsigned int GetPathSegList(void **aPathSegList) = 0; }; class nsSVGPathElement : public nsSVGElement, public nsIDOMSVGAnimatedPathData { public: unsigned int virtual GetPathSegList(void **aPathSegList); }; void *GetDOMWrapper(void *aList,void *aElement, bool aIsAnimValList); void *GetBaseValKey(); unsigned int nsSVGPathElement::GetPathSegList(void * *aPathSegList) { void *key = GetBaseValKey(); *aPathSegList = GetDOMWrapper(key, this, false); return *aPathSegList ? 0 : 0x8007000e; } GCC compiles the thunk an 'add' and 'jmp'. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 15:03:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 15:03:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10316] Incorrect function calls in the tutorials for building the fadd, fmul, and fsub operations In-Reply-To: References: Message-ID: <20110715200352.1BEB93128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10316 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-07-15 15:03:51 CDT --- r135293. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 15:04:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 15:04:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10025] Missing line in OCaml Kaleidoscope tutorial Chapter 3 In-Reply-To: References: Message-ID: <20110715200429.6D1BF3128034@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10025 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #2 from Eli Friedman 2011-07-15 15:04:28 CDT --- r135293. (And in the future, please send patches to llvm-commits; they are more likely to be seen there.) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 15 15:18:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 15:18:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 10374] New: lib/Target/TargetData.cpp:460: unsigned int llvm::TargetData::getAlignment(const llvm::Type*, bool) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10374 Summary: lib/Target/TargetData.cpp:460: unsigned int llvm::TargetData::getAlignment(const llvm::Type*, bool) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6885) --> (http://llvm.org/bugs/attachment.cgi?id=6885) Failing input Attached input hits the assertion for AMD64/Linux and AMD64/NetBSD. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 15:21:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 15:21:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 6048] ms crt8 64bit release misses _byteswap_ushort and friends In-Reply-To: References: Message-ID: <20110715202101.9A9E72A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6048 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #1 from Eli Friedman 2011-07-15 15:21:01 CDT --- It's unclear what exactly this bug is about. If you are having issues building LLVM, please reopen and specify how exactly you are building LLVM, and include the error output. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 15 15:29:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 15:29:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10372] clang++ crashed when analyzing a function with returntype int, when it contains a return __null statement In-Reply-To: References: Message-ID: <20110715202933.415A32A6C131@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10372 Jordy Rose changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jediknil at belkadan.com Resolution| |FIXED --- Comment #1 from Jordy Rose 2011-07-15 15:29:32 CDT --- The analyzer is treating __null as a pointer, but it's actually implemented as a pointer-sized integer. int main(int argc, char *argv[]) (CompoundStmt 0x1060439d8 (ReturnStmt 0x1060439b8 (ImplicitCastExpr 0x1060439a0 'int' (GNUNullExpr 0x106043988 'long')))) I can't find a GNU spec for __null, so I'm going with our own docs and behavior and changing ExprEngine to use a pointer-sized NonLoc. Should be fixed in r135294. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 16:02:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 16:02:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 7993] LegalizeOp produces illegal type In-Reply-To: References: Message-ID: <20110715210216.7FCA33128018@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7993 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Eli Friedman 2011-07-15 16:02:15 CDT --- I'm going to call this fixed; not worth tracking down exactly what fixed 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 Jul 15 16:05:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 16:05:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10374] lib/Target/TargetData.cpp:460: unsigned int llvm::TargetData::getAlignment(const llvm::Type*, bool) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed. In-Reply-To: References: Message-ID: <20110715210552.D43773128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10374 J?rg Sonnenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from J?rg Sonnenberger 2011-07-15 16:05:52 CDT --- Fixed in the mean 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 Jul 15 16:29:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 16:29:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 10370] [MC assembler] after r134501, again incorrect reloc type for push of a label argument (on x86_64) In-Reply-To: References: Message-ID: <20110715212904.9DE343128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10370 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Eli Friedman 2011-07-15 16:29:04 CDT --- r135303. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 15 16:42:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 16:42:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 7635] [MC] Inline assembly in C++ source fails to link In-Reply-To: References: Message-ID: <20110715214226.C6E933128026@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7635 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #7 from Eli Friedman 2011-07-15 16:42:25 CDT --- The original issue as reported seems to be fixed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 15 16:49:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 16:49:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10375] New: warning on delete object of incomplete type missing -W flag Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10375 Summary: warning on delete object of incomplete type missing -W flag Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu This warning needs a flag to control it: $ cat del.cc class Foo; void test(Foo *foo) { delete foo; } $ llvm/Debug+Asserts/bin/clang del.cc -Werror del.cc:4:3: error: deleting pointer to incomplete type 'Foo' may cause undefined behaviour [-Werror] delete foo; ^ ~~~ del.cc:1:7: note: forward declaration of 'Foo' class 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 Fri Jul 15 17:35:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Jul 2011 17:35:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10376] New: Autoreleased return value results in sub-optimal path diagnostics Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10376 Summary: Autoreleased return value results in sub-optimal path diagnostics Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Keywords: quality-of-implementation Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: jediknil at belkadan.com CC: llvmbugs at cs.uiuc.edu In the code below (or any code that returns an autoreleased object and causes a bug report), the emitted messages look something like this (locations omitted): warning: Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected note: Method returns an Objective-C object with a +1 retain count note: Object sent -autorelease message note: Object returned to caller as an owning reference (single retain count transferred to caller) note: Object returned to caller with a +0 retain count note: Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected Note the two "returned to caller" lines. This happens because we process autorelease counts after deciding that a value is returned. Ideally we'd just skip the first line. @interface NSObject + (id)alloc; - (id)init; - (id)retain; - (void)release; - (void)autorelease; @end @implementation NSObject (Copying) - (id)copy { id result = [[NSObject alloc] init]; [result autorelease]; return result; } @end -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 16 01:37:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 16 Jul 2011 01:37:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 10377] New: Missed optimizations with indirectbr terminators Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10377 Summary: Missed optimizations with indirectbr terminators Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm-bugzilla at cafxx.strayorange.com CC: llvmbugs at cs.uiuc.edu Consider this IR fragment produced by opt -O3: > %7: > %8 = phi i8* [ blockaddress(@0, %19), %19 ], [ %12, %11 ] > %9 = phi i32 [ %20, %19 ], [ 0, %11 ] > indirectbr i8* %8, [label %4, label %19] > > %19: > %20 = add nsw i32 %9, 1 > %21 = icmp eq i32 %9, 9999 > br i1 %21, label %16, label %7 the br in %19 should be optimized to branch directly to itself rather than going back to %7 (note that the arg %8 to the indirectbr will always be the address of %19 when coming from %19). While this might or might not be so big of a problem per-se, notice how %19 is a loop body that simply adds 1 to the same variable at each iteration. Because the br is still pointing to %7 instead of %18, other passes are not able to recognize that the loop has a constant iteration count and could therefore be replaced entirely by a > %20 = add nsw i32 %9, 10000 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 16 11:47:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 16 Jul 2011 11:47:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10378] New: ASTContext.cpp assertion failure Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10378 Summary: ASTContext.cpp assertion failure Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ejtttje at gmail.com CC: llvmbugs at cs.uiuc.edu Using svn-bisect, I have determined that revision 131365 introduced an assertion which is failing on one of my Objective-C++ source files. (The failure occurs at both that revision and through to the current trunk.) Clang was built as Release+Asserts You can view the file in question here: http://cvs.tekkotsu.org/viewvc/Tekkotsu/local/DataSources/CameraSourceQTKit.mm?view=markup I will append the assertion failure report from clang below, let me know if there is anything else I can provide to help resolve this, thanks! Assertion failed: (!FieldOrBaseOffsets[layout.getVBaseClassOffsetInBits(base)]), function getObjCEncodingForStructureImpl, file ASTContext.cpp, line 4474. 0 clang 0x00000001016ef862 llvm::SmallVectorTemplateBase::grow(unsigned long) + 818 1 clang 0x00000001016f07e3 llvm::SmallVectorTemplateBase::grow(unsigned long) + 4787 2 libSystem.B.dylib 0x00007fff879bd1ba _sigtramp + 26 3 libSystem.B.dylib 0x00007fff5fbfb1a0 _sigtramp + 3626229760 4 clang 0x00000001016efce2 llvm::SmallVectorTemplateBase::grow(unsigned long) + 1970 5 clang 0x0000000100868a33 clang::ASTConsumer::~ASTConsumer() + 71699 6 clang 0x000000010086a495 clang::ASTConsumer::~ASTConsumer() + 78453 7 clang 0x0000000100869188 clang::ASTConsumer::~ASTConsumer() + 73576 8 clang 0x00000001008760de clang::ASTConsumer::~ASTConsumer() + 126654 9 clang 0x000000010025b816 llvm::IRBuilder >::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 24726 10 clang 0x000000010026949c llvm::IRBuilder >::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 81180 11 clang 0x00000001002777cf llvm::IRBuilder >::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 139343 12 clang 0x000000010027877a llvm::IRBuilder >::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 143354 13 clang 0x00000001002cd9c9 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 46393 14 clang 0x00000001002e00ff llvm::IRBuilder >::CreateExtractValue(llvm::Value*, unsigned int, llvm::Twine const&) + 3231 15 clang 0x00000001002bbe3b clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 155 16 clang 0x00000001002ecc72 llvm::IRBuilder >::CreateAdd(llvm::Value*, llvm::Value*, llvm::Twine const&, bool, bool) + 674 17 clang 0x00000001002ba34c llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 2188 18 clang 0x0000000100041ff1 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 8945 19 clang 0x000000010000a4c5 std::_Rb_tree, std::less, std::allocator >::_M_insert_unique(std::string const&) + 1893 20 clang 0x0000000100001718 21 clang 0x0000000100009682 std::vector >::operator=(std::vector > const&) + 12962 22 clang 0x0000000100000b34 Stack dump: 0. Program arguments: /usr/local/clang/bin/clang -cc1 -triple x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -main-file-name CameraSourceQTKit.mm -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 123.2 -g -coverage-file /Users/ejt/todo/Tekkotsu/project/build/Make.build/Clang/tekkotsu-Chiara.build/Objects-normal/x86_64/CameraSourceQTKit.o -resource-dir /usr/local/clang/bin/../lib/clang/3.0 -iquote /Users/ejt/todo/Tekkotsu/project/build/Make.build/Clang/tekkotsu-Chiara.build/tekkotsu-CHIARA-generated-files.hmap -iquote /Users/ejt/todo/Tekkotsu/project/build/Make.build/Clang/tekkotsu-Chiara.build/tekkotsu-CHIARA-project-headers.hmap -include-pch /var/folders/yD/yDuH0ZKwH2eve2V192DILE+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/common-fpwetdlsyucehhcfiphrusldwvxi/common.h.pth -D DEBUG -D HAVE_READDIR_R -D NO_LIBTEKKOTSU -D PLATFORM_LOCAL -D TGT_CHIARA -I /Users/ejt/todo/Tekkotsu/project/build/Make.build/Clang/tekkotsu-Chiara.build/tekkotsu-CHIARA-own-target-headers.hmap -I /Users/ejt/todo/Tekkotsu/project/build/Make.build/Clang/tekkotsu-Chiara.build/tekkotsu-CHIARA-all-target-headers.hmap -I /Users/ejt/todo/Tekkotsu/project/build/Clang/include -I /Users/ejt/todo/Tekkotsu/project/build/Make.build/DerivedSources -I /Users/ejt/todo/Tekkotsu -I /opt/local/include -I /usr/include/libxml2 -I /Users/ejt/todo/Tekkotsu/project/build/Make.build/Clang/tekkotsu-Chiara.build/DerivedSources/x86_64 -I /Users/ejt/todo/Tekkotsu/project/build/Make.build/Clang/tekkotsu-Chiara.build/DerivedSources -F/Users/ejt/todo/Tekkotsu/project/build/Clang -O0 -Wno-trigraphs -Wmissing-field-initializers -Wreturn-type -Wnon-virtual-dtor -Woverloaded-virtual -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wunused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wsign-compare -Wnewline-eof -Wall -Wpointer-arith -Wcast-qual -Woverloaded-virtual -Wdeprecated -Wno-mismatched-tags -Wno-tautological-compare -Wno-shadow -Wno-mismatched-tags -Wno-tautological-compare -fdeprecated-macro -ferror-limit 19 -fmessage-length 0 -fvisibility hidden -fvisibility-inlines-hidden -fdiagnostics-print-source-range-info -fdiagnostics-parseable-fixits -stack-protector 1 -fblocks -fobjc-exceptions -fcxx-exceptions -fexceptions -fobjc-nonfragile-abi -fobjc-dispatch-method=mixed -fpascal-strings -fdiagnostics-show-option -fdiagnostics-show-category id -o /Users/ejt/todo/Tekkotsu/project/build/Make.build/Clang/tekkotsu-Chiara.build/Objects-normal/x86_64/CameraSourceQTKit.o -x objective-c++ /Users/ejt/todo/Tekkotsu/local/DataSources/CameraSourceQTKit.mm 1. parser at end of file 2. /Users/ejt/todo/Tekkotsu/local/DataSources/CameraSourceQTKit.mm:494:1: LLVM IR generation of declaration 'CameraSourceQTKitDelegate' clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 16 14:06:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 16 Jul 2011 14:06:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10379] New: Infinite loop when compiling with -Wall Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10379 Summary: Infinite loop when compiling with -Wall 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: niclas.zeising at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6887) --> (http://llvm.org/bugs/attachment.cgi?id=6887) preprocessed test case to trigger bug Clang goes into an infinite loop when compiling attached preprocessed reduced test case with -Wall. Any other warning flags works, it seems, including -Wextra -pedantic. As soon as -Wall is added, the infinite loop occurs. The code is originally from libX11 1.3.6. -Wall can be added by itself or together with other warning flags, it does not matter. This is with clang/llvm r135344 and confirmed on FreeBSD and Linux (Ubuntu 10.04). Clang has to be killed with either ^C or a signal. When sending the abort signal it displays the following on FreeBSD: Stack dump: 0. Program arguments: /usr/home/llvm-build/build/obj-llvm.3/Release+Asserts/bin/clang -cc1 -triple x86_64-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name imRmAttr.changed.2.i -pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu core2 -target-linker-version 2.17.50 -momit-leaf-frame-pointer -coverage-file imRmAttr.o -resource-dir /usr/home/llvm-build/build/obj-llvm.3/Release+Asserts/bin/../lib/clang/3.0 -O2 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wbad-function-cast -Wformat=2 -Wold-style-definition -Wdeclaration-after-statement -ferror-limit 19 -fmessage-length 130 -fdiagnostics-show-option -fcolor-diagnostics -o imRmAttr.o -x cpp-output imRmAttr.testcase.i 1. parser at end of file 2. imRmAttr.changed.2.i:72:1: parsing function body '_XimMakeICAttrIDList' and then hangs again with 100% CPU usage. A second abort signal then terminates clang. On Linux it prints the same message when sent the abort signal as well as a more elaborate stack trace: 0 clang 0x000000000186f35f 1 clang 0x000000000186f8c9 2 libpthread.so.0 0x00007fbfb6bfd8f0 3 clang 0x0000000000c6cbc8 void std::__rotate(clang::CFGBlock const**, clang::CFGBlock const**, clang::CFGBlock const**, std::random_access_iterator_tag) + 136 4 clang 0x0000000000c6a4da clang::runUninitializedVariablesAnalysis(clang::DeclContext const&, clang::CFG const&, clang::AnalysisContext&, clang::UninitVariablesHandler&, clang::UninitVariablesAnalysisStats&) + 1146 5 clang 0x0000000000b7a60c clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy, clang::sema::FunctionScopeInfo*, clang::Decl const*, clang::BlockExpr const*) + 3516 6 clang 0x0000000000904088 clang::Sema::PopFunctionOrBlockScope(clang::sema::AnalysisBasedWarnings::Policy const*, clang::Decl const*, clang::BlockExpr const*) + 88 7 clang 0x00000000009a0af9 clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 1177 8 clang 0x00000000008bbe57 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 247 9 clang 0x00000000008c75be clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1854 10 clang 0x00000000008d185f clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 975 11 clang 0x00000000008c69b3 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 675 12 clang 0x00000000008c6b7c clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 380 13 clang 0x00000000008c60dc clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2508 14 clang 0x00000000008c5694 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 244 15 clang 0x00000000008ae45e clang::ParseAST(clang::Sema&, bool) + 318 16 clang 0x000000000079cad4 clang::CodeGenAction::ExecuteAction() + 804 17 clang 0x0000000000699817 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 983 18 clang 0x0000000000685a77 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2743 19 clang 0x000000000067d702 cc1_main(char const**, char const**, char const*, void*) + 5970 20 clang 0x0000000000681ce4 main + 772 21 libc.so.6 0x00007fbfb5ed7c4d __libc_start_main + 253 22 clang 0x000000000067bee9 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 16 14:40:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 16 Jul 2011 14:40:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10380] New: Static analyzer flags results of dynamic_cast as garbage Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10380 Summary: Static analyzer flags results of dynamic_cast as garbage Product: clang Version: 2.9 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: uwe at familie-hees.de CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6888) --> (http://llvm.org/bugs/attachment.cgi?id=6888) Test Case The static analyzer flags the result of a dynamic_cast as garbage. Analyze the test case and you will see... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 16 16:20:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 16 Jul 2011 16:20:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 9875] getVisualStudioDir() brokes system environment In-Reply-To: References: Message-ID: <20110716212013.89E322A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9875 Francois Pichet changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |pichet2000 at gmail.com Resolution| |FIXED --- Comment #1 from Francois Pichet 2011-07-16 16:20:13 CDT --- Fixed in r135356 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 16 17:29:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 16 Jul 2011 17:29:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10379] Infinite loop when compiling with -Wall In-Reply-To: References: Message-ID: <20110716222901.BCD322A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10379 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chandler Carruth 2011-07-16 17:29:00 CDT --- Fixed in r135359 by reverting r135217, we'll have to use a different fix. Sorry for the fallout. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 16 17:30:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 16 Jul 2011 17:30:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10358] -Wuninitialized false negative for use inside a loop In-Reply-To: References: Message-ID: <20110716223011.B603F2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10358 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |chandlerc at gmail.com Resolution|FIXED | --- Comment #6 from Chandler Carruth 2011-07-16 17:30:11 CDT --- This patch was reverted in r135359 to fix PR10379. Looking at the underlying issue with that bug, I don't think marking as 'Unknown' is necessarily the right step here. I'm looking into a new fix for this one. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 17 00:58:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 17 Jul 2011 00:58:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 10377] Missed optimizations with indirectbr terminators In-Reply-To: References: Message-ID: <20110717055808.8ECEF2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10377 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |REMIND --- Comment #2 from Chris Lattner 2011-07-17 00:58:08 CDT --- Please reopen when you have additional information, such as a testcase, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 17 06:31:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 17 Jul 2011 06:31:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10377] Missed optimizations with indirectbr terminators In-Reply-To: References: Message-ID: <20110717113100.107E52A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10377 Carlo Alberto Ferraris changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|REMIND | --- Comment #5 from Carlo Alberto Ferraris 2011-07-17 06:30:59 CDT --- Here you go. (I know that the unoptimized code is overly verbose and redundant, that will be fixed eventually) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 17 12:32:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 17 Jul 2011 12:32:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 5324] Clang needs a nice "nested functions not supported in ISO C" diagnostic In-Reply-To: References: Message-ID: <20110717173253.CDEEB2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5324 Elias Pipping changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |pipping at exherbo.org Resolution| |DUPLICATE --- Comment #3 from Elias Pipping 2011-07-17 12:32:53 CDT --- *** This bug has been marked as a duplicate of bug 4296 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 17 13:26:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 17 Jul 2011 13:26:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10383] New: Assertion `isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant!"' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10383 Summary: Assertion `isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant!"' Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Global Analyses AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6893) --> (http://llvm.org/bugs/attachment.cgi?id=6893) Failing input Attached test case fails with "clang -ccc-host-triple x86_64-linux -c delta.i -O2" (revision 135294) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 17 13:28:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 17 Jul 2011 13:28:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 10384] New: Assertion `Ty && "GEP indices invalid!"' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10384 Summary: Assertion `Ty && "GEP indices invalid!"' Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6894) --> (http://llvm.org/bugs/attachment.cgi?id=6894) Failing input Attached input fails with "clang -ccc-host-triple x86_64-linux -c main.ii" running r135294 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 17 13:28:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 17 Jul 2011 13:28:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 10385] New: clang prints invisible black text on black background terminal Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10385 Summary: clang prints invisible black text on black background terminal Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: davezarzycki at gmail.com CC: llvmbugs at cs.uiuc.edu The compiler prints the text "note:" in black on my white-text-on-black-background terminal: /tmp $ cat v.c void g(void *); void f(void) { void *volatile x; g(&x); } /tmp $ clang -Wall -Wextra -Os -c v.c v.c:2:36: warning: passing 'void *volatile *' to parameter of type 'void *' discards qualifiers void f(void) { void *volatile x; g(&x); } ^~ v.c:1:14: note: passing argument to parameter here void g(void *); ^ 1 warning generated. /tmp $ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 17 14:32:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 17 Jul 2011 14:32:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 10386] New: Assertion `!isa(Preds[i]->getTerminator()) && "Cannot split an edge from an IndirectBrInst" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10386 Summary: Assertion `!isa(Preds[i]->getTerminator()) && "Cannot split an edge from an IndirectBrInst" Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Transformation Utilities AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6895) --> (http://llvm.org/bugs/attachment.cgi?id=6895) Reduced test case Seen in r135294. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 17 15:53:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 17 Jul 2011 15:53:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10387] New: Assertion failed: (VNI && "Early-clobber tied value not available") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10387 Summary: Assertion failed: (VNI && "Early-clobber tied value not available") Product: new-bugs Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: pawel.worach at gmail.com CC: llvmbugs at cs.uiuc.edu Building ffmpeg's motion_est.c with llvm/clang r135360. % llc motion_est.bc Assertion failed: (VNI && "Early-clobber tied value not available"), function shrinkToUses, file /data/buildslave/freebsd-clang-amd64/src-llvm/lib/CodeGen/LiveIntervalAnalysis.cpp, line 771. Stack dump: 0. Program arguments: llc motion_est.bc 1. Running pass 'Function Pass Manager' on module 'motion_est.bc'. 2. Running pass 'Greedy Register Allocator' on function '@hpel_motion_search' Abort (core dumped) The bitcode is pretty huge and bugpoint dies on it too, you can find it here. http://llvm-amd64.freebsd.your.org/tmp/motion_est.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 Sun Jul 17 16:25:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 17 Jul 2011 16:25:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10388] New: bugpoint UNREACHABLE executed at BitcodeWriter.cpp:914! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10388 Summary: bugpoint UNREACHABLE executed at BitcodeWriter.cpp:914! Product: new-bugs Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: pawel.worach at gmail.com CC: llvmbugs at cs.uiuc.edu bugpoint crashes on the following bitcode file: http://llvm-amd64.freebsd.your.org/tmp/motion_est.bc llvm/clang r135360. % bugpoint -run-llc motion_est.bc Read input file : 'motion_est.bc' *** All input ok Initializing execution environment: Found gcc: /usr/bin/gcc Running the code generator to test for a crash: Error running tool: /usr/local/llvm/bin/llc -o bugpoint-test-program.bc.llc.s bugpoint-test-program.bc Stack dump: 0. Program arguments: /usr/local/llvm/bin/llc -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 'Greedy Register Allocator' on function '@ff_epzs_motion_search' *** Debugging code generator crash! Checking to see if we can delete global inits: define internal void @zero_hpel(i8* nocapture %a, i8* nocapture %b, i32 %stride, i32 %h) nounwind uwtable readnone { entry: tail call void @llvm.dbg.value(metadata !{i8* %a}, i64 0, metadata !3302), !dbg !3772 tail call void @llvm.dbg.value(metadata !{i8* %b}, i64 0, metadata !3303), !dbg !3773 tail call void @llvm.dbg.value(metadata !{i32 %stride}, i64 0, metadata !3304), !dbg !3774 tail call void @llvm.dbg.value(metadata !{i32 %h}, i64 0, metadata !3305), !dbg !3775 ret void, !dbg !3776 } Unknown constant! UNREACHABLE executed at /data/buildslave/freebsd-clang-amd64/src-llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:914! Stack dump: 0. Program arguments: bugpoint -run-llc motion_est.bc 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 Mon Jul 18 00:33:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 00:33:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10387] Assertion failed: (VNI && "Early-clobber tied value not available") In-Reply-To: References: Message-ID: <20110718053319.9CDB22A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10387 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Jakob Stoklund Olesen 2011-07-18 00:33:19 CDT --- Fixed in r135378. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 18 05:16:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 05:16:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 10389] New: [MC assembler] dot symbol used with leal interpreted differently from GNU as Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10389 Summary: [MC assembler] dot symbol used with leal interpreted differently from GNU as 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 When OpenSSL generates its crypto/des/crypt586.s file, it uses the following construction for PIC setup: call .L000PIC_me_up .L000PIC_me_up: popl %edx leal _GLOBAL_OFFSET_TABLE_+[.-.L000PIC_me_up](%edx),%edx GNU as produces the following for this fragment: 0: e8 00 00 00 00 call 0x5 5: 5a pop %edx 6: 8d 92 03 00 00 00 lea 0x3(%edx),%edx So when gas processes the . symbol, it apparently considers the 'current address' to be just after the initial opcode bytes for leal, e.g. at offset 0x8. Thus the addend becomes 0x8-0x5 = 0x3. Clang's integrated assember, however, produces the following: 0: e8 00 00 00 00 call 0x5 5: 5a pop %edx 6: 8d 92 01 00 00 00 lea 0x1(%edx),%edx E.g. it considers the current address for the . symbol to be at offset 0x6, and the addend becomes 0x1 instead. This makes the function crash with a segfault at runtime. All similar assembly functions in OpenSSL are generated by the same 'picmeup' Perl subroutine, so all of them suffer the same 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 Mon Jul 18 05:56:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 05:56:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 10390] New: Define std::getline in , not Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10390 Summary: Define std::getline in , not Product: libc++ Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: pyry.jahkola at iki.fi CC: llvmbugs at cs.uiuc.edu By ? 20.3 of the C++0x FDIS, the definitions for the free functions std::getline(is, str[, delim]) should be defined in the header, but trunk libc++ defines them in the header. I tried to compile Boost.Filesystem against clang and libc++ but got compiler errors from boost/filesystem/v2/path.hpp correctly trying to call std::getline without including . Adding "#include " to the file removed the error, but the right fix would be to move said template function definitions to their right place, i.e. to the header. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 18 10:52:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 10:52:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10390] Define std::getline in , not In-Reply-To: References: Message-ID: <20110718155209.8AC8D2A6C131@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10390 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Howard Hinnant 2011-07-18 10:52:09 CDT --- Committed revision 135393. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 18 11:38:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 11:38:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 10391] New: 'nullptr' in C++03 mode is a macro that violates assumptions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10391 Summary: 'nullptr' in C++03 mode is a macro that violates assumptions Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu When compiler 'nullptr' support is not available, 'nullptr' is defined as a macro, and this is visible in user code. As a consequence, this makes valid use of 'nullptr' illegal as well as violating a few critical assumptions since it doesn't behave as a true 'nullptr_t' would. In particular, 'reinterpret_cast(nullptr)' does not work, and a test for this behavior fails as a result. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 18 12:49:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 12:49:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 10392] New: _Pragma's argument gets incorrect macro expansion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10392 Summary: _Pragma's argument gets incorrect macro expansion Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Consider the following input: #define push(foo) xxxxxxxxxxxxxxxxxxxxxxx _Pragma("GCC visibility push(default)"); The current implementation of _Pragma expands the push() inside the string if compiled directly and operates correctly when using e.g. -save-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 Mon Jul 18 12:57:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 12:57:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10393] New: clang things lookup is ambiguous, gcc and edg don't Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10393 Summary: clang things lookup is ambiguous, gcc and edg don't Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com gcc and edg accept: namespace mozilla { struct Proxy; } using mozilla::Proxy; struct Proxy { }; Proxy mProxy; clang rejects: error: reference to 'Proxy' is ambiguous That code looks really strange, but both gcc and edg accept it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 18 13:20:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 13:20:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 10394] New: Assertion failed compiling while loop with continue in the guard Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10394 Summary: Assertion failed compiling while loop with continue in the guard Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bagnara at cs.unipr.it CC: llvmbugs at cs.uiuc.edu $ cat q.c int main() { do { while (({ continue; 1; })) { return 1; } } while (0); return 0; } $ clang q.c clang: /home/roberto/deps/build/llvm-r135343/lib/VMCore/Value.cpp:285: void llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `New != this && "this->replaceAllUsesWith(this) is NOT valid!"' failed. 0 libLLVM-3.0svn.so 0x00007fb094e96f59 1 libLLVM-3.0svn.so 0x00007fb094e96d55 2 libc.so.6 0x00007fb092cc8d80 3 libc.so.6 0x00007fb092cc8d05 gsignal + 53 4 libc.so.6 0x00007fb092cccab6 abort + 390 5 libc.so.6 0x00007fb092cc17c5 __assert_fail + 245 6 libLLVM-3.0svn.so 0x00007fb094a8789c llvm::Value::replaceAllUsesWith(llvm::Value*) + 98 7 clang 0x0000000000d56642 clang::CodeGen::CodeGenFunction::SimplifyForwardingBlocks(llvm::BasicBlock*) + 150 8 clang 0x0000000000d574e7 clang::CodeGen::CodeGenFunction::EmitWhileStmt(clang::WhileStmt const&) + 1011 9 clang 0x0000000000d55ef2 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 638 10 clang 0x0000000000d563fa clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 306 11 clang 0x0000000000d561b3 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 217 12 clang 0x0000000000d55cbf clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 75 13 clang 0x0000000000d5766b clang::CodeGen::CodeGenFunction::EmitDoStmt(clang::DoStmt const&) + 371 14 clang 0x0000000000d55f15 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 673 15 clang 0x0000000000d563fa clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 306 16 clang 0x0000000000d561b3 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 217 17 clang 0x0000000000d55cbf clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 75 18 clang 0x0000000000d876fc clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&) + 154 19 clang 0x0000000000d87aaa clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 664 20 clang 0x0000000000c40327 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl) + 917 21 clang 0x0000000000c3e0a5 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 503 22 clang 0x0000000000c3dd19 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 773 23 clang 0x0000000000c42ae8 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 310 24 clang 0x0000000000c36f73 25 clang 0x0000000000c36386 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 158 26 clang 0x0000000000da831f clang::ParseAST(clang::Sema&, bool) + 436 27 clang 0x0000000000aef6d3 clang::ASTFrontendAction::ExecuteAction() + 263 28 clang 0x0000000000c359df clang::CodeGenAction::ExecuteAction() + 957 29 clang 0x0000000000aef32f clang::FrontendAction::Execute() + 325 30 clang 0x0000000000ad51c3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 741 31 clang 0x0000000000aa9f88 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 909 32 clang 0x0000000000a9b29f cc1_main(char const**, char const**, char const*, void*) + 983 33 clang 0x0000000000aa5600 main + 496 34 libc.so.6 0x00007fb092cb3eff __libc_start_main + 255 35 clang 0x0000000000a9a949 Stack dump: 0. Program arguments: /home/roberto/deps/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name q.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.0.20110327 -momit-leaf-frame-pointer -resource-dir /home/roberto/deps/bin/../lib/clang/3.0 -ferror-limit 19 -fmessage-length 80 -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-M7P3ut.o -x c q.c 1. parser at end of file 2. q.c:1:5: LLVM IR generation of declaration 'main' 3. q.c:1:5: Generating code for declaration 'main' 4. q.c:1:12: LLVM IR generation of compound statement ('{}') 5. q.c:2:6: LLVM IR generation of compound statement ('{}') clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 18 13:48:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 13:48:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10395] New: Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10395 Summary: Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElemen tType() && "Ptr must be a pointer to Val type!"' Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6900) --> (http://llvm.org/bugs/attachment.cgi?id=6900) Failing input Attached test case triggers the assertion with "clang -ccc-host-triple x86_64-linux fluid_menus.ii -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 Mon Jul 18 15:15:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 15:15:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10396] New: clang crashes during name mangling with as non-type template parameter Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10396 Summary: clang crashes during name mangling with as non-type template parameter Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jonathan.sauer at gmx.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6902) --> (http://llvm.org/bugs/attachment.cgi?id=6902) Complete crash log The following program crashes clang r135379: template void bar(); int main(int, char**) { bar(); } This results in (full crash log attached): clang -std=c++0x clang.cpp 0 clang 0x0000000101903bc2 PrintStackTrace(void*) + 34 1 clang 0x0000000101904a13 SignalHandler(int) + 707 2 libSystem.B.dylib 0x00007fff84b2866a _sigtramp + 26 3 libSystem.B.dylib 000000000000000000 _sigtramp + 2068674992 4 clang 0x0000000100b3e14f clang::TemplateArgument::isInstantiationDependent() const + 223 5 clang 0x0000000100b00d99 (anonymous namespace)::CXXNameMangler::mangleTemplateArg(clang::NamedDecl const*, clang::TemplateArgument) + 57 6 clang 0x0000000100b017ed (anonymous namespace)::CXXNameMangler::mangleTemplateArgs(clang::TemplateParameterList const&, clang::TemplateArgumentList const&) + 173 7 clang 0x0000000100affe1f (anonymous namespace)::CXXNameMangler::mangleName(clang::NamedDecl const*) + 399 [...] -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 18 15:31:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 15:31:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 10397] New: X86 Disassembler Gives Wrong Sign for short JMP Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10397 Summary: X86 Disassembler Gives Wrong Sign for short JMP Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: lally.singh at gmail.com CC: llvmbugs at cs.uiuc.edu I'm disassembling an executable, but the MCInst for a JMP instruction seems to have the wrong offset (or rather, doesn't preserve the original sign). The original assembly (from gcc -S): .file "hello.c" .section .rodata .LC0: .string "Hello!" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 movq %rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 subq $16, %rsp movl %edi, -4(%rbp) movq %rsi, -16(%rbp) .L2: movl $.LC0, %edi call puts jmp .L2 ; <<<<<< THIS ONE .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3" .section .note.GNU-stack,"", at progbits Main disassembles to: Seeking to offset 1316 for executable's 27 bytes. 55 48 89 e5 48 83 ec 10 89 7d fc 48 89 75 f0 bf 2c 06 40 00 e8 db fe ff ff eb f4 0 [1899]: pushq %rbp 1 [1302]: movq %rsp, %rbp 4 [2311]: subq $16, %rsp 8 [1275]: movl %edi, -4(%rbp) 11 [1291]: movq %rsi, -16(%rbp) 15 [1280]: movl $4195884, %edi 20 [275]: callq -293 25 [936]: jmp 244 ; <<<< BAD! The 244 as the argument to JMP seems to be the 2's complement inverse of what it should be. Linux 64-bit 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 Mon Jul 18 15:38:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 15:38:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 10398] New: Clang won't accept a null pointer constant as a non-type template argument Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10398 Summary: Clang won't accept a null pointer constant as a non-type template argument Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang does not accept the following: template struct foo; template <> struct foo <0> {}; This is probably a regression; it was discovered while investigating bug 10396. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 18 15:53:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 15:53:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10399] New: Make lit a separate project Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10399 Summary: Make lit a separate project Product: Test Suite Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: lit AssignedTo: unassignedbugs at nondot.org ReportedBy: pipping at exherbo.org CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org libc++ can use lit. even if you have llvm and clang installed, you do not have lit installed, though. There is no install-lit target, neither is lit distributed separately. It would nice if there were releases of lit along with llvm/clang/etc. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 18 16:05:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 16:05:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10399] Make lit a separate project In-Reply-To: References: Message-ID: <20110718210558.022E32A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10399 Tobias Grosser changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |grosser at fim.uni-passau.de Resolution| |FIXED --- Comment #1 from Tobias Grosser 2011-07-18 16:05:57 CDT --- Lit is available in the python package repository. As far as I know, this is the offical way to install it for external projects. http://pypi.python.org/pypi/lit Please reopen, if this does not solve 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 Mon Jul 18 16:31:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 16:31:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10401] New: error: ran out of registers during register allocation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10401 Summary: error: ran out of registers during register allocation 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: js-llvm-bugzilla at webkeks.org CC: llvmbugs at cs.uiuc.edu When trying to compile an ObjC file, I get: error: ran out of registers during register allocation OS X 10.5.8/PowerPC Preprocessed file attached. Compilation flags: -fblocks (Actually, a lot more, but that's enough flags 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 Mon Jul 18 18:27:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 18:27:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 8949] [MC] Redefining a weak symbol crashes with integrated as In-Reply-To: References: Message-ID: <20110718232759.B7AE62A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8949 J?rg Sonnenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from J?rg Sonnenberger 2011-07-18 18:27:59 CDT --- Now creates: fatal error: error in backend: 'foo' label emitted multiple times to assembly file -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 18 18:48:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 18:48:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10402] New: [C++] aborts during compilation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10402 Summary: [C++] aborts during compilation Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping at exherbo.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6905) --> (http://llvm.org/bugs/attachment.cgi?id=6905) delta-reduced input (not valid code but manages to make clang++ crash) The following happens when colour_pretty_printer.cc is compiled with `clang++ -std=c++0x` and headers from libc++: clang: DeclSpec.cpp:511: bool clang::DeclSpec::SetTypeSpecType(TST, clang::SourceLocation, clang::SourceLocation, const char *&, unsigned int &, ParsedType): Assertion `Rep && "no type provided!"' failed. 0 libLLVM-3.0svn.so 0x00007f1518ded8af 1 libLLVM-3.0svn.so 0x00007f1518dedc21 2 libpthread.so.0 0x00007f1517846ff0 3 libc.so.6 0x00007f1516b64605 gsignal + 53 4 libc.so.6 0x00007f1516b65905 abort + 389 5 libc.so.6 0x00007f1516b5d235 __assert_fail + 245 6 clang 0x0000000000cb3881 7 clang 0x0000000000c9beba clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 5002 8 clang 0x0000000000c90215 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 2245 9 clang 0x0000000000c9d4b5 clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject*) + 1221 10 clang 0x0000000000c9c6ee clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 1246 11 clang 0x0000000000c9be1a clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 4842 12 clang 0x0000000000c90215 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 2245 13 clang 0x0000000000c9d4b5 clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject*) + 1221 14 clang 0x0000000000c7f069 clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 73 15 clang 0x0000000000c7ee28 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 680 16 clang 0x0000000000c7eaf0 clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 112 17 clang 0x0000000000c9d31a clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject*) + 810 18 clang 0x0000000000c9c6ee clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 1246 19 clang 0x0000000000c9be1a clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 4842 20 clang 0x0000000000c90215 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 2245 21 clang 0x0000000000c7f11a clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 250 22 clang 0x0000000000c7ee28 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 680 23 clang 0x0000000000c7eaf0 clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 112 24 clang 0x0000000000c8f74c clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 252 25 clang 0x0000000000c86c77 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1239 26 clang 0x0000000000c86774 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 212 27 clang 0x0000000000c6feaf clang::ParseAST(clang::Sema&, bool) + 335 28 clang 0x0000000000b6ce71 clang::CodeGenAction::ExecuteAction() + 641 29 clang 0x0000000000a89d07 clang::FrontendAction::Execute() + 231 30 clang 0x0000000000a773aa clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 506 31 clang 0x0000000000a599e0 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 640 32 clang 0x0000000000a4fa81 cc1_main(char const**, char const**, char const*, void*) + 657 33 clang 0x0000000000a56180 main + 368 34 libc.so.6 0x00007f1516b50c7d __libc_start_main + 253 35 clang 0x0000000000a4f729 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name colour_pretty_printer.1.ii -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.1 -momit-leaf-frame-pointer -coverage-file colour_pretty_printer.1.o -resource-dir /usr/bin/../lib/clang/3.0 -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 238 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o colour_pretty_printer.1.o -x c++-cpp-output colour_pretty_printer.1.ii 1. colour_pretty_printer.1.ii:7:31: current parser token ';' 2. colour_pretty_printer.1.ii:2:1: parsing struct/union/class body 'basic_string' 3. colour_pretty_printer.1.ii:6:27: parsing struct/union/class body 'bitset' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) As a result of running multidelta, the attached file is not valid C++ code. This is with clang version 3.0 git-1fba8281b9fab5bf11c4083e88f31047413f94f2. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 18 18:48:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 18:48:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10403] New: [C++] aborts during compilation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10403 Summary: [C++] aborts during compilation Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping at exherbo.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6906) --> (http://llvm.org/bugs/attachment.cgi?id=6906) delta-reduced input (not valid code but manages to make clang++ crash) The following happens when colour_pretty_printer.cc is compiled with `clang++ -std=c++0x` and headers from libc++: clang: SemaInit.cpp:3951: ExprResult clang::InitializationSequence::Perform(clang::Sema &, const clang::InitializedEntity &, const clang::InitializationKind &, MultiExprArg, clang::QualType *): Assertion `Kind.getKind() == InitializationKind::IK_Copy || Kind.isExplicitCast()' failed. 0 libLLVM-3.0svn.so 0x00007f6fdcf218af 1 libLLVM-3.0svn.so 0x00007f6fdcf21c21 2 libpthread.so.0 0x00007f6fdb97aff0 3 libc.so.6 0x00007f6fdac98605 gsignal + 53 4 libc.so.6 0x00007f6fdac99905 abort + 389 5 libc.so.6 0x00007f6fdac91235 __assert_fail + 245 6 clang 0x0000000000db32ce clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, clang::ASTMultiPtr, clang::QualType*) + 7758 7 clang 0x0000000000d0ee95 clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) + 1797 8 clang 0x0000000000c91d1e clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&) + 1614 9 clang 0x0000000000c9145a clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 714 10 clang 0x0000000000c8f921 clang::Parser::ParseSimpleDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, bool, clang::Parser::ForRangeInit*) + 289 11 clang 0x0000000000c8f70b clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 187 12 clang 0x0000000000c793f4 clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 804 13 clang 0x0000000000c7ccd3 clang::Parser::ParseCompoundStatementBody(bool) + 867 14 clang 0x0000000000c7d6e7 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 151 15 clang 0x0000000000c87bb5 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1493 16 clang 0x0000000000c7f30d clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 749 17 clang 0x0000000000c7ee28 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 680 18 clang 0x0000000000c7eaf0 clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 112 19 clang 0x0000000000c8f74c clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 252 20 clang 0x0000000000c86c77 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1239 21 clang 0x0000000000c993b2 clang::Parser::ParseInnerNamespace(std::vector >&, std::vector >&, std::vector >&, unsigned int, clang::SourceLocation&, clang::SourceLocation&, clang::ParsedAttributes&, clang::SourceLocation&) + 130 22 clang 0x0000000000c990c4 clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) + 2324 23 clang 0x0000000000c8f7c5 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 373 24 clang 0x0000000000c86c77 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1239 25 clang 0x0000000000c86774 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 212 26 clang 0x0000000000c6feaf clang::ParseAST(clang::Sema&, bool) + 335 27 clang 0x0000000000b6ce71 clang::CodeGenAction::ExecuteAction() + 641 28 clang 0x0000000000a89d07 clang::FrontendAction::Execute() + 231 29 clang 0x0000000000a773aa clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 506 30 clang 0x0000000000a599e0 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 640 31 clang 0x0000000000a4fa81 cc1_main(char const**, char const**, char const*, void*) + 657 32 clang 0x0000000000a56180 main + 368 33 libc.so.6 0x00007f6fdac84c7d __libc_start_main + 253 34 clang 0x0000000000a4f729 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name colour_pretty_printer.2.ii -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.1 -momit-leaf-frame-pointer -coverage-file colour_pretty_printer.2.o -resource-dir /usr/bin/../lib/clang/3.0 -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 238 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o colour_pretty_printer.2.o -x c++-cpp-output colour_pretty_printer.2.ii 1. colour_pretty_printer.2.ii:10:68: current parser token ';' 2. colour_pretty_printer.2.ii:1:1: parsing namespace 'std' 3. colour_pretty_printer.2.ii:8:3: parsing function body 'operator<<' 4. colour_pretty_printer.2.ii:8:3: in compound statement ('{}') clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) As a result of running multidelta, the attached file is not valid C++ code. This is with clang version 3.0 git-1fba8281b9fab5bf11c4083e88f31047413f94f2. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 18 19:39:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 18 Jul 2011 19:39:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10398] Clang won't accept a null pointer constant as a non-type template argument In-Reply-To: References: Message-ID: <20110719003906.AC3812A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10398 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Douglas Gregor 2011-07-18 19:39:06 CDT --- This is a C++0x feature that hasn't been implemented yet. *** This bug has been marked as a duplicate of bug 9700 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 04:37:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 04:37:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10405] New: Missing actual type in error message when using decltype as a template parameter Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10405 Summary: Missing actual type in error message when using decltype as a template parameter Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Keywords: quality-of-implementation Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jonathan.sauer at gmx.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following program intentionally does not compile: template struct Foo { }; template auto foo(T t, U u) -> Foo; int main(int, char**) { int i = foo(1, 2); } With clang r135379, this results in the following message: $ clang -std=c++0x clang.cpp clang.cpp:9:6: error: no viable conversion from 'Foo' to 'int' int i = foo(1, 2); ^ ~~~~~~~~~ 1 error generated. It would be helpful, if clang displayed the actual type here, just as it does with template parameters in many other situations. In this case, the message should read: no viable conversion from 'Foo' (aka 'Foo') 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 Tue Jul 19 07:56:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 07:56:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 10406] New: [PATCH] _MIPS_SIM builtin macro Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10406 Summary: [PATCH] _MIPS_SIM builtin macro Product: clang Version: trunk Platform: PC OS/Version: other Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rmh at gnu.org CC: llvmbugs at cs.uiuc.edu Hi, Please could you define the _MIPS_SIM builtin macro on MIPS platforms? It is defined in recent versions of GCC. Since software out there may rely on this macro, it would be useful if Clang defined it for compatibility. 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 Jul 19 11:26:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 11:26:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10407] New: fatal error: error in backend: Cannot yet select: ... Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10407 Summary: fatal error: error in backend: Cannot yet select: ... Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu Hardware: Intel Core i5 (64-bit) O.S.: Linux Fedora Core 15 (64-bit) When trying to compile a large program, all I get is: fatal error: error in backend: Cannot yet select: 0x1c56e10: f64 = ConstantFP<3.000000e+00> [ID=11] Since I have no clue as to which line, I have no idea as to what the compiler is dying on. Command line options to clang: -std=c99 -fmath-errno -O0 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 19 11:33:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 11:33:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10408] New: integer from floating-point done wrong Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10408 Summary: integer from floating-point done wrong Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu The C99 program: http://www.tybor.com/tflt2int.c fails because the compiler's code generation for conversions from floating-point (FP) to integer is wrong. In some cases, some FP exception flags are raised when no FP exceptions should happen. In other cases, FP exception flags are not being raised when they should happen. Command line options: -std=c99 -fmath-errno -O0 -lm -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 11:49:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 11:49:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 10409] New: -O0 not turn off all "optimizations" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10409 Summary: -O0 not turn off all "optimizations" Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu It appears, that even with -O0, some "optimizations" are being done. These optimizations change the semantics (meaning) of the code and do the wrong thing. One such item is constant folding. #include #include #pragma STDC FENV_ACCESS ON int main(void){ double x; int i; feclearexcept(FE_ALL_EXCEPT); x = 1.0; x /= 3.0; /* should raise inexact; value computed depends upon rounding direction */ i = fetestexcept(FE_ALL_EXCEPT); if( FE_INEXACT != i ){ printf("missing inexact (got %i), x=%g\n", i, x); } return 0; ] If I add 'volatile' to the declaration of x, then the code works. The same kind of problem happens for: x=1.0; x /= 0.0; /* divide by zero */ x=0.0; x /= 0.0; /* invalid */ x=DBL_MAX; x *= DBL_MAX; /* overflow */ x=DBL_MIN; x *= DBL_MIN; /* underflow */ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 11:55:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 11:55:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10410] New: Hex floating-point converted wrong Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10410 Summary: Hex floating-point converted wrong Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu Hexadecimal floating-point constants similar to: 0x1p+99999 0x1p-99999 0x1p-2147483648 0x1p+2147483648 convert to the wrong 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 Tue Jul 19 11:56:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 11:56:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10408] integer from floating-point done wrong In-Reply-To: References: Message-ID: <20110719165617.2AAA22A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10408 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2011-07-19 11:56:16 CDT --- Clang does not support the FP pragmas yet. *** This bug has been marked as a duplicate of bug 10409 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 11:57:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 11:57:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 10410] Hex floating-point converted wrong In-Reply-To: References: Message-ID: <20110719165703.467422A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10410 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2011-07-19 11:57:03 CDT --- What values do you expect? These are overflow conditions and are thus have undefined values. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 11:57:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 11:57:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10407] fatal error: error in backend: Cannot yet select: ... In-Reply-To: References: Message-ID: <20110719165719.01D042A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10407 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |WORKSFORME --- Comment #1 from Benjamin Kramer 2011-07-19 11:57:18 CDT --- Can you retry with a more recent version of LLVM? 2.8 is ancient and has known problems with newer CPUs. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 13:57:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 13:57:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10411] New: assertion when using exception and ARC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10411 Summary: assertion when using exception and ARC Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: devlists at shadowlab.org CC: llvmbugs at cs.uiuc.edu Clang (trunk 135497) failed to compile code that throw exception when ARC is enabled. It reaches an assertion in ActOnFinishFunctionBody(). For instance the following code failed to compile: ------- test.m @interface NSException + (id)exception; @end void test() { @throw [NSException exception]; } ------------ % clang -fobjc-arc -c test.m Assertion failed: (!ExprNeedsCleanups && "Unaccounted cleanups in function"), function ActOnFinishFunctionBody, file SemaDecl.cpp, line 6536. 0 clang 0x000000010ec97842 _ZL15PrintStackTracePv + 34 ? 5 clang 0x000000010ec97a45 __assert_rtn + 53 6 clang 0x000000010df12d23 clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 1347 7 clang 0x000000010de570c4 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 244 8 clang 0x000000010de6212d clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1885 9 clang 0x000000010de267ab clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 907 ? 18 clang 0x000000010dbff68a cc1_main(char const**, char const**, char const*, void*) + 5450 19 clang 0x000000010dc033d2 main + 706 20 clang 0x000000010dbfe134 start + 52 21 clang 0x000000000000002b start + 18446744069183905579 Stack dump: 0. Program arguments: /Users/jddupas/Projects/OpenSource/llvm/release/Release+Asserts/bin/clang -cc1 -triple x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all -disable-free -main-file-name test.m -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 123.2.1 -coverage-file test.o -resource-dir /Users/jddupas/Projects/OpenSource/llvm/release/Release+Asserts/bin/../lib/clang/3.0 -ferror-limit 19 -fmessage-length 170 -stack-protector 1 -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-nonfragile-abi -fobjc-dispatch-method=mixed -fobjc-arc -fobjc-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x objective-c test.m 1. parser at end of file 2. test.m:5:13: parsing function body 'test' clang: error: unable to execute command: Illegal instruction: 4 clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 19 15:28:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 15:28:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10412] New: clang accepts extra qualifier Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10412 Summary: clang accepts extra qualifier Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang compiles ----------------- struct A { A(); }; A* f() { return new A::A(); } ---------------- gcc complains: test.cc: In function ?A* f()?: test.cc:6:14: error: expected type-specifier test.cc:6:14: error: cannot convert ?int*? to ?A*? in return test.cc:6:14: error: expected ?;? test.cc:6:19: error: cannot call constructor ?A::A? directly [-fpermissive] test.cc:6:19: error: for a function-style cast, remove the redundant ?::A? [-fpermissive] edg rejects it 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 Tue Jul 19 17:44:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 17:44:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 10413] New: Race condition in unix signal handling Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10413 Summary: Race condition in unix signal handling Product: new-bugs Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: rolfbjarne at gmail.com CC: llvmbugs at cs.uiuc.edu There is a race condition in the code that registers signal handlers and handles signals here: llvm/lib/Support/Unix/Signals.inc The problem is if two signals are raised in quick succession, you'll handle the first one in your signal handler, and then restore the signal handler to the previous one. If the second signal is raised before you've restored the previous handler, the process will exit (since you specify SA_RESETHAND when registering your signal handler, there is a small window of time where the default signal handler is in effect). This is a problem for mono, we already use a few of the signals you handle (SIGFPE, SIGUSR1, SIGUSR2). It means that in a few rare cases an application will randomly just exit without any diagnostic message at all (which is somewhat ironic, given that you add signal handlers only to provide more/better information when crashes occur). I think the fix would be to just remove the SA_NODEFER|SA_RESETHAND flags you use when registering the signal handler. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 17:59:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 17:59:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10386] Assertion `!isa(Preds[i]->getTerminator()) && "Cannot split an edge from an IndirectBrInst" In-Reply-To: References: Message-ID: <20110719225955.1F08C2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10386 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #3 from Eli Friedman 2011-07-19 17:59:54 CDT --- r135534. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 18:56:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 18:56:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10414] New: wrong linkage for function local constant Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10414 Summary: wrong linkage for function local constant Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: echristo at gmail.com CC: llvmbugs at cs.uiuc.edu >From 2005-02-27-MarkGlobalConstant.c from the llvm-gcc test suite: void bar(); void foo() { // CHECK: private unnamed_addr constant char Blah[] = "asdlfkajsdlfkajsd;lfkajds;lfkjasd;flkajsd;lkfja;sdlkfjasd"; bar(Blah); } Blah is showing up as internal instead of private. I'm reasonably sure it can't be accessed outside the module so should be private. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 19:15:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 19:15:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10415] New: extra module asm directives? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10415 Summary: extra module asm directives? Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: echristo at gmail.com CC: llvmbugs at cs.uiuc.edu Seems a bit weird. For the test case 2006-01-23-FileScopeAsm.c: [yendi:clang/test/CodeGen] echristo% clang -S -emit-llvm -o - 2006-01-23-FileScopeAsm.c ; ModuleID = '2006-01-23-FileScopeAsm.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-apple-macosx10.7.0" module asm "foo1" module asm "" module asm "foo2" module asm "" module asm "foo3" module asm "" module asm "foo4" module asm "" module asm "foo5" [yendi:clang/test/CodeGen] echristo% llvm-gcc -S -emit-llvm -o - 2006-01-23-FileScopeAsm.c ; ModuleID = '2006-01-23-FileScopeAsm.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-apple-darwin11.0" module asm "foo1" module asm "foo2" module asm "foo3" module asm "foo4" module asm "foo5" -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 19:25:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 19:25:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10416] New: constant not unnamed_addr? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10416 Summary: constant not unnamed_addr? Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: echristo at gmail.com CC: llvmbugs at cs.uiuc.edu >From 2006-03-03-MissingInitializer.c it looks like foo.nate should be able to be unnamed_addr and llvm-gcc does that struct X { int *XX; int Y;}; void foo() { static int nate = 0; struct X bob = { &nate, 14 }; bar(&bob); } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 19:35:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 19:35:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 10417] New: accepting __attribute__((section("__ksymtab_strings"))) on mach-o Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10417 Summary: accepting __attribute__((section("__ksymtab_strings"))) on mach-o Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: echristo at gmail.com CC: llvmbugs at cs.uiuc.edu llvm-gcc/gcc accepts this code from 2006-07-31-PR854.c: struct kernel_symbol { unsigned long value; }; unsigned long loops_per_jiffy = (1<<12); static const char __kstrtab_loops_per_jiffy[] __attribute__((section("__ksymtab_strings"))) = "loops_per_jiffy"; static const struct kernel_symbol __ksymtab_loops_per_jiffy __attribute__((__used__)) __attribute__((section("__ksymtab"))) = { (unsigned long)&loops_per_jiffy, __kstrtab_loops_per_jiffy }; -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 20:04:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 20:04:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10392] _Pragma's argument gets incorrect macro expansion In-Reply-To: References: Message-ID: <20110720010406.8F4732A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10392 J?rg Sonnenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from J?rg Sonnenberger 2011-07-19 20:04:06 CDT --- Fixed in r135552. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 19 20:05:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 20:05:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10417] accepting __attribute__((section("__ksymtab_strings"))) on mach-o In-Reply-To: References: Message-ID: <20110720010542.A8A222A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10417 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #4 from Eric Christopher 2011-07-19 20:05:42 CDT --- Excellent. I seemed to recall a time when it didn't I think is the reason. I'll close this 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 Tue Jul 19 20:25:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 20:25:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10416] constant not unnamed_addr? In-Reply-To: References: Message-ID: <20110720012552.4C6FD2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10416 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Eric Christopher 2011-07-19 20:25:52 CDT --- I can agree with that. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 19 20:48:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 20:48:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 10365] missing support for %cc in inline asm In-Reply-To: References: Message-ID: <20110720014834.4CC9F2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10365 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #6 from Eric Christopher 2011-07-19 20:48:34 CDT --- And it looks like mozilla has changed their 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 Jul 19 23:31:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 19 Jul 2011 23:31:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10395] Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' In-Reply-To: References: Message-ID: <20110720043122.DAB2C2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10395 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2011-07-19 23:31:22 CDT --- Fixed in r135565. I *really really* appreciate the reduced testcase Eli! Thanks, -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 20 02:05:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 02:05:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10418] New: PthreadLockChecker's double-locking detection doesn't support recursive locks Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10418 Summary: PthreadLockChecker's double-locking detection doesn't support recursive locks Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: jediknil at belkadan.com CC: llvmbugs at cs.uiuc.edu PthreadLockChecker emits a warning when a locking function is called on the same lock twice. However, POSIX mutexes can be recursive locks (PTHREAD_MUTEX_RECURSIVE), which would make these warnings false positives. Since the code just went into trunk, there's no demand for a fix right now, but it's a known limitation, to be sure. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 02:43:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 02:43:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10419] New: 'main' function with unusual signature cannot be compiled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10419 Summary: 'main' function with unusual signature cannot be compiled Product: clang Version: 2.9 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: andrew.sampson at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com A 'main' function with an unusual signature cannot be compiled due to Sema::CheckMain(). In my case, NPAPI on MacOSX requires a main function to be exported with an unusual signature, but it will not compile with clang. Suggest the addition of a flag to suppress this error, or turn it into a warning only. For instance, this main function cannot be compiled: int main(NPNetscapeFuncs *browserFuncs, NPPluginFuncs *pluginFuncs, NPP_ShutdownProcPtr *shutdown) { return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 20 05:28:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 05:28:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10420] New: crash in DarwinX86_64AsmBackend::doesSectionRequireSymbols Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10420 Summary: crash in DarwinX86_64AsmBackend::doesSectionRequireSymbols Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6910) --> (http://llvm.org/bugs/attachment.cgi?id=6910) test case If I run: % llc bugpoint-reduced-simplified.ll -filetype=obj Then I get a crash with the following stack dump. (This is with a just-synced dev TOT). 0 llc 0x0000000100ab39e5 PrintStackTrace(void*) + 38 1 llc 0x0000000100ab3fa0 SignalHandler(int) + 254 2 libSystem.B.dylib 0x00007fff86b291ba _sigtramp + 26 3 libSystem.B.dylib 0x00007fff5fbfec30 _sigtramp + 3641531024 4 llc 0x0000000100389eeb (anonymous namespace)::DarwinX86_64AsmBackend::doesSectionRequireSymbols(llvm::MCSection const&) const + 33 5 llc 0x0000000100a37011 llvm::MCAssembler::isSymbolLinkerVisible(llvm::MCSymbol const&) const + 109 6 llc 0x0000000100a53aa9 (anonymous namespace)::MCMachOStreamer::EmitLabel(llvm::MCSymbol*) + 125 7 llc 0x0000000100a479c0 llvm::MCDwarfFrameEmitter::Emit(llvm::MCStreamer&, bool, bool) + 174 8 llc 0x0000000100a5c000 llvm::MCStreamer::EmitFrames(bool) + 64 9 llc 0x0000000100a52e5c (anonymous namespace)::MCMachOStreamer::Finish() + 36 10 llc 0x0000000100607aca llvm::AsmPrinter::doFinalization(llvm::Module&) + 2532 11 llc 0x00000001009efbd7 llvm::FPPassManager::doFinalization(llvm::Module&) + 67 12 llc 0x00000001009f3c8a llvm::FPPassManager::runOnModule(llvm::Module&) + 120 13 llc 0x00000001009f3728 llvm::MPPassManager::runOnModule(llvm::Module&) + 384 14 llc 0x00000001009f4f08 llvm::PassManagerImpl::run(llvm::Module&) + 116 15 llc 0x00000001009f4f69 llvm::PassManager::run(llvm::Module&) + 33 16 llc 0x00000001000342c8 main + 2495 17 llc 0x00000001000332f0 start + 52 18 llc 0x0000000000000003 start + 4294757703 Stack dump: 0. Program arguments: /Users/mmp/llvm-dev/bin/llc bugpoint-reduced-simplified.ll -filetype=obj 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'. [1] 76090 segmentation fault ~/llvm-dev/bin/llc bugpoint-reduced-simplified.ll -filetype=obj A run under valgrind gives a number of complaints along the way: valgrind ~/llvm-dev/bin/llc bugpoint-reduced-simplified.ll -filetype=obj ==76095== Memcheck, a memory error detector ==76095== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==76095== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==76095== Command: /Users/mmp/llvm-dev/bin/llc bugpoint-reduced-simplified.ll -filetype=obj ==76095== --76095-- /Users/mmp/llvm-dev/bin/llc: --76095-- dSYM directory is missing; consider using --dsymutil=yes ==76095== Warning: ignored attempt to set SIGUSR2 handler in sigaction(); ==76095== the SIGUSR2 signal is used internally by Valgrind ==76095== Conditional jump or move depends on uninitialised value(s) ==76095== at 0x100A496A8: llvm::MCObjectFileInfo::getEHFrameSection() (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A47960: llvm::MCDwarfFrameEmitter::Emit(llvm::MCStreamer&, bool, bool) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A5BFFF: llvm::MCStreamer::EmitFrames(bool) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A52E5B: (anonymous namespace)::MCMachOStreamer::Finish() (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100607AC9: llvm::AsmPrinter::doFinalization(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009EFBD6: llvm::FPPassManager::doFinalization(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F3C89: llvm::FPPassManager::runOnModule(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F3727: llvm::MPPassManager::runOnModule(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F4F07: llvm::PassManagerImpl::run(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F4F68: llvm::PassManager::run(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1000342C7: main (in /Users/mmp/llvm-dev/bin/llc) ==76095== ==76095== Use of uninitialised value of size 8 ==76095== at 0x1001819EC: llvm::MCSymbol::getName() const (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A47499: (anonymous namespace)::FrameEmitterImpl::EmitFDE(llvm::MCStreamer&, llvm::MCSymbol const&, llvm::MCDwarfFrameInfo const&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A47B66: llvm::MCDwarfFrameEmitter::Emit(llvm::MCStreamer&, bool, bool) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A5BFFF: llvm::MCStreamer::EmitFrames(bool) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A52E5B: (anonymous namespace)::MCMachOStreamer::Finish() (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100607AC9: llvm::AsmPrinter::doFinalization(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009EFBD6: llvm::FPPassManager::doFinalization(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F3C89: llvm::FPPassManager::runOnModule(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F3727: llvm::MPPassManager::runOnModule(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F4F07: llvm::PassManagerImpl::run(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F4F68: llvm::PassManager::run(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1000342C7: main (in /Users/mmp/llvm-dev/bin/llc) ==76095== ==76095== Invalid read of size 8 ==76095== at 0x1001819EC: llvm::MCSymbol::getName() const (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A47499: (anonymous namespace)::FrameEmitterImpl::EmitFDE(llvm::MCStreamer&, llvm::MCSymbol const&, llvm::MCDwarfFrameInfo const&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A47B66: llvm::MCDwarfFrameEmitter::Emit(llvm::MCStreamer&, bool, bool) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A5BFFF: llvm::MCStreamer::EmitFrames(bool) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A52E5B: (anonymous namespace)::MCMachOStreamer::Finish() (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100607AC9: llvm::AsmPrinter::doFinalization(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009EFBD6: llvm::FPPassManager::doFinalization(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F3C89: llvm::FPPassManager::runOnModule(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F3727: llvm::MPPassManager::runOnModule(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F4F07: llvm::PassManagerImpl::run(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F4F68: llvm::PassManager::run(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1000342C7: main (in /Users/mmp/llvm-dev/bin/llc) ==76095== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==76095== ==76095== ==76095== Process terminating with default action of signal 11 (SIGSEGV) ==76095== General Protection Fault ==76095== at 0x1028F0FC1: dyld_stub_binder (in /usr/lib/libSystem.B.dylib) ==76095== by 0x100F8953F: ??? (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x13804E323: ??? ==76095== by 0x100A47499: (anonymous namespace)::FrameEmitterImpl::EmitFDE(llvm::MCStreamer&, llvm::MCSymbol const&, llvm::MCDwarfFrameInfo const&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A47B66: llvm::MCDwarfFrameEmitter::Emit(llvm::MCStreamer&, bool, bool) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A5BFFF: llvm::MCStreamer::EmitFrames(bool) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100A52E5B: (anonymous namespace)::MCMachOStreamer::Finish() (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x100607AC9: llvm::AsmPrinter::doFinalization(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009EFBD6: llvm::FPPassManager::doFinalization(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F3C89: llvm::FPPassManager::runOnModule(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F3727: llvm::MPPassManager::runOnModule(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== by 0x1009F4F07: llvm::PassManagerImpl::run(llvm::Module&) (in /Users/mmp/llvm-dev/bin/llc) ==76095== ==76095== HEAP SUMMARY: ==76095== in use at exit: 1,072,042 bytes in 2,826 blocks ==76095== total heap usage: 22,445 allocs, 19,619 frees, 7,171,758 bytes allocated ==76095== ==76095== LEAK SUMMARY: ==76095== definitely lost: 0 bytes in 0 blocks ==76095== indirectly lost: 0 bytes in 0 blocks ==76095== possibly lost: 55,419 bytes in 139 blocks ==76095== still reachable: 1,016,623 bytes in 2,687 blocks ==76095== suppressed: 0 bytes in 0 blocks ==76095== Rerun with --leak-check=full to see details of leaked memory ==76095== ==76095== For counts of detected and suppressed errors, rerun with: -v ==76095== Use --track-origins=yes to see where uninitialised values come from ==76095== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 20 06:01:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 06:01:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 10421] New: incorrect code generated for shufflevector with i8 types (x86) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10421 Summary: incorrect code generated for shufflevector with i8 types (x86) Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu (The following happens with both LLVM 2.9 and top-of-tree.) Given this bitcode (a reduced test-case), which I would expect to end up concatenating the two i32 values and returning them as an i64: define i64 @foo(i32 %a, i32 %b) nounwind readonly { %va = bitcast i32 %a to <4 x i8> %vb = bitcast i32 %b to <4 x i8> %vshuf = shufflevector <4 x i8> %va, <4 x i8> %vb, <8 x i32> %v64 = bitcast <8 x i8> %vshuf to i64 ret i64 %v64 } And given this test program: #include #include extern "C" { int64_t foo(int32_t, int32_t); } int main() { int32_t a = 0x01010101; int32_t b = 0x02020202; int64_t val = foo(a, b); printf("val = %llx\n", val); return 0; } I get this output: % llc -o a.s a.ll && g++ a.cpp a.s && ./a.out val = 1010101 % (i.e. the 0x02020202 bit is not there in the returned i64 vaue). The generated assembly is: _foo: ## @foo ## BB#0: movd %esi, %xmm0 movd %edi, %xmm1 movlhps %xmm0, %xmm1 ## xmm1 = xmm1[0],xmm0[0] movd %xmm1, %rax ret I'm not an x86 expert, but my reading of that is that the movhlps ends up incorrectly packing the SSE register like (0, b, 0, a), rather than (0, 0, b, a), so that the final movd just returns (0, a) as an int64. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 06:38:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 06:38:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10422] New: x86/AVX codegen crashes on fcmp + br + call instruction combination. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10422 Summary: x86/AVX codegen crashes on fcmp + br + call instruction combination. Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: syoyofujita at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6911) --> (http://llvm.org/bugs/attachment.cgi?id=6911) C program to reproduce the bug. Rev: 135566 With attached main.c, in combination of AVX and optimization(-O2), $ clang -mavx -O2 main.c crashes as follows. syoyo at syoyo-desktop:~/work/llvm-bugs$ clang -mavx -O2 main.c clang: /home/syoyo/work/llvm-git/include/llvm/CodeGen/MachineInstr.h:210: llvm::MachineOperand& llvm::MachineInstr::getOperand(unsigned int): Assertion `i < getNumOperands() && "getOperand() out of range!"' failed. 0 clang 0x0000000001af5c8f 1 clang 0x0000000001af7f02 2 libpthread.so.0 0x00007f1e7078f8f0 3 libc.so.6 0x00007f1e6fa7ea75 gsignal + 53 4 libc.so.6 0x00007f1e6fa825c0 abort + 384 5 libc.so.6 0x00007f1e6fa77941 __assert_fail + 241 6 clang 0x00000000010ec364 7 clang 0x000000000143e90e llvm::X86InstrInfo::foldMemoryOperandImpl(llvm::MachineFunction&, llvm::MachineInstr*, llvm::SmallVectorImpl const&, llvm::MachineInstr*) const + 414 8 clang 0x000000000170fd2a llvm::TargetInstrInfo::foldMemoryOperand(llvm::ilist_iterator, llvm::SmallVectorImpl const&, llvm::MachineInstr*) const + 218 9 clang 0x0000000001757334 10 clang 0x000000000175ce9f 11 clang 0x000000000175db88 12 clang 0x00000000016a9f68 13 clang 0x000000000179b9f3 llvm::RegAllocBase::allocatePhysRegs() + 611 14 clang 0x00000000016a72a1 15 clang 0x0000000001a481db llvm::FPPassManager::runOnFunction(llvm::Function&) + 587 16 clang 0x0000000001a482db llvm::FPPassManager::runOnModule(llvm::Module&) + 75 17 clang 0x0000000001a47ce1 llvm::MPPassManager::runOnModule(llvm::Module&) + 497 18 clang 0x0000000001a47e6b llvm::PassManagerImpl::run(llvm::Module&) + 187 19 clang 0x00000000007d1e65 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1989 20 clang 0x00000000007cf20e clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 270 21 clang 0x0000000000912eef clang::ParseAST(clang::Sema&, bool) + 431 22 clang 0x00000000007ce434 clang::CodeGenAction::ExecuteAction() + 68 23 clang 0x00000000006af8a3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371 24 clang 0x00000000006961ee clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1326 25 clang 0x000000000068bd48 cc1_main(char const**, char const**, char const*, void*) + 1000 26 clang 0x000000000069503b main + 7131 27 libc.so.6 0x00007f1e6fa69c4d __libc_start_main + 253 28 clang 0x000000000068ae39 Stack dump: 0. Program arguments: /home/syoyo/work/llvm-git/Release+Asserts/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name main.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-feature +avx -target-linker-version 2.20.1 -momit-leaf-frame-pointer -resource-dir /home/syoyo/work/llvm-git/Release+Asserts/bin/../lib/clang/3.0 -O2 -ferror-limit 19 -fmessage-length 119 -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-5yEmeX.o -x c main.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'main.c'. 4. Running pass 'Greedy Register Allocator' on function '@render' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) --------------------------- Here's simplified IR reduced by bugpoint. $ cat bugpoint-reduced-simplified.ll ; ModuleID = 'bugpoint-reduced-simplified.bc' 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" declare void @scale() nounwind uwtable define void @render() nounwind uwtable { entry: br i1 undef, label %for.cond5, label %for.end52 for.cond5: ; preds = %for.cond30, %for.cond5, %entry %or.cond = and i1 undef, false br i1 %or.cond, label %for.body33, label %for.cond5 for.cond30: ; preds = %if.then, %for.body33 br i1 false, label %for.body33, label %for.cond5 for.body33: ; preds = %for.cond30, %for.cond5 %tobool = fcmp une double undef, 0.000000e+00 br i1 %tobool, label %if.then, label %for.cond30 if.then: ; preds = %for.body33 call void @scale() br label %for.cond30 for.end52: ; preds = %entry ret void } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 20 07:19:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 07:19:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10423] New: I think alignment policy of argument is *too strict* Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10423 Summary: I think alignment policy of argument is *too strict* Product: new-bugs Version: 2.9 Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: wuye9036 at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, thanks for your attention. I have a llvm function ( generated by my compiler ) ; Dot product. define float @"Mdot@@QV3F@@QV3F@@"(<3 x float> %.lhs, <3 x float> %.rhs) { .body: %0 = extractelement <3 x float> %.rhs, i32 0 %1 = extractelement <3 x float> %.lhs, i32 0 %2 = fmul float %1, %0 %3 = fadd float 0.000000e+00, %2 %4 = extractelement <3 x float> %.rhs, i32 1 %5 = extractelement <3 x float> %.lhs, i32 1 %6 = fmul float %5, %4 %7 = fadd float %3, %6 %8 = extractelement <3 x float> %.rhs, i32 2 %9 = extractelement <3 x float> %.lhs, i32 2 %10 = fmul float %9, %8 %11 = fadd float %7, %10 ret float %11 } define float @"Mtest_dot_f3@@QV3F@@QV3F@@"(<3 x float> %lhs, <3 x float> %rhs) { .entry: br label %.body .body: ; preds = %.entry %0 = call float @"Mdot@@QV3F@@QV3F@@"(<3 x float> %lhs, <3 x float> %rhs) ret float %0 ; No predecessors! ret float 0.000000e+00 } But if I called the JIT-ed function of test_dot_f3 in visual studio(x64), as following, it is crashed in generated code. struct vec3{ float x,y,z; // etc. }; vec3 lhs( 1.9f, 2.7f, -8.1f ); vec3 rhs( -4.8f, 1.1f, 17.5f ); loat (*test_dot_f3)(vec3, vec3) = NULL; // JIT for get test_dot_f3 float f = test_dot_f3(lhs, rhs); // Crashed! I analyzed the generated asm, and found: :cpp function float f = test_dot_f3(lhs, rhs); 000000013F78F4A5 lea rax,[rsp+1D8h] 000000013F78F4AD mov qword ptr [rsp+1E8h],rax 000000013F78F4B5 lea rax,[rsp+1F0h] 000000013F78F4BD mov qword ptr [rsp+200h],rax 000000013F78F4C5 lea rdx,[rsp+118h] 000000013F78F4CD mov rcx,qword ptr [rsp+1E8h] 000000013F78F4D5 call eflib::vec3::vec3 (13F7827C0h) 000000013F78F4DA mov qword ptr [rsp+2F0h],rax 000000013F78F4E2 lea rdx,[rsp+0E8h] 000000013F78F4EA mov rcx,qword ptr [rsp+200h] 000000013F78F4F2 call eflib::vec3::vec3 (13F7827C0h) 000000013F78F4F7 mov rcx,qword ptr [rsp+2F0h] 000000013F78F4FF mov rdx,rcx ;rdx is 0x23e378 000000013F78F502 mov rcx,rax 000000013F78F505 call qword ptr [rsp+98h] 000000013F78F50C movss dword ptr [rsp+144h],xmm0 :test_dot_f3 0000000000380014 movaps xmm0,xmmword ptr [rdx] ;rdx is 0x23e378, not 16B aligned. crashed here. 0000000000380017 movaps xmm1,xmmword ptr [rcx] 000000000038001A movaps xmmword ptr [rsp+30h],xmm1 000000000038001F movaps xmmword ptr [rsp+20h],xmm0 I don't know why temporary is not 16B aligned, and hope to know any solution for it. Thank you all guys ! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 08:15:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 08:15:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 10423] I think alignment policy of argument is *too strict* In-Reply-To: References: Message-ID: <20110720131547.71B8A2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10423 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Anton Korobeynikov 2011-07-20 08:15:47 CDT --- Well, as it seems to me vcpp does not align your vec3. Which is quite expected - you have *just struct* and have not provided any alignment specification on it. 3 x float is not a native type for the givent target and thus is promoted to 4 x float, which has alignment requirements by the platform ABI (and thus such requirements cannot be relaxed at LLVM level, really). So, the fix for you is to correct define your vec3 type and force the alignment at C level. I dunno for vcpp, but in gcc you can do this via specifying of attribute "aligned". -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 08:43:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 08:43:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10424] New: Online documentation missing sections Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10424 Summary: Online documentation missing sections Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu In the online user's manual: http://clang.llvm.org/docs/UsersManual.html in the section Command Line Options, there is the statement: However, the first part introduces the language selection and other high level options like -c, -g, etc. Yet, I do not see any such documentation. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 08:52:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 08:52:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 10425] New: clang --help is missing many options Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10425 Summary: clang --help is missing many options Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu Doing the command clang --help gets some help on the command line options. Yet it appears to be missing several options. I see no mention of -m, nor what the choicse are. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 20 09:08:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 09:08:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10426] New: ICE with inline asm Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10426 Summary: ICE with inline asm Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mattiase at acm.org CC: llvmbugs at cs.uiuc.edu clang version 3.0 (trunk 135473) Target: x86_64-unknown-linux-gnu Thread model: posix Compiling the test case below with: clang -O2 -g -m32 -c testcase.c causes the following assertion failure: clang: /home/mattias/src/llvm/lib/MC/MCStreamer.cpp:81: virtual void llvm::MCStreamer::EmitIntValue(uint64_t, unsigned int, unsigned int): Assertion `(isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) && "Invalid size"' failed. 0 clang 0x0000000001b2118f 1 clang 0x0000000001b23116 2 libpthread.so.0 0x000000311ac0eb10 3 libc.so.6 0x000000311a030265 gsignal + 53 4 libc.so.6 0x000000311a031d10 abort + 272 5 libc.so.6 0x000000311a0296e6 __assert_fail + 246 6 clang 0x0000000001acccb7 llvm::MCStreamer::EmitIntValue(unsigned long, unsigned int, unsigned int) + 247 7 clang 0x000000000162d8cd llvm::DIEBlock::EmitValue(llvm::AsmPrinter*, unsigned int) const + 221 8 clang 0x000000000160e96b llvm::DwarfDebug::emitDIE(llvm::DIE*) + 267 [etc] -------------------------------------------- typedef unsigned long long uint64; void ct(uint64 a, uint64 b); static uint64 swab64(uint64 x) { __asm__ ("xchg %%edx,%%eax\n" "bswap %%edx\n" "bswap %%eax\n" : "=A" (x) : "0" (x)); return x; } static uint64 f(const uint64 *p) { return swab64(*p); } void g(void) { uint64 a = 0xabcdef0912345678ull; ct(f(&a), 0x7856341209efcdabull); } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 10:32:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 10:32:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 10427] New: clang should warn if a macro argument expansion is "obviously" missing parentheses Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10427 Summary: clang should warn if a macro argument expansion is "obviously" missing parentheses Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Consider this bug from the valgrind sources: hummer:src thakis$ cat test.c #include struct vki_timeval { int a, b, c, d, e; }; #define PRE_timeval_READ(zzname, zzarg) \ do { \ struct vki_timeval *zztv = (struct vki_timeval *)zzarg; \ printf("Note: %s %d\n", zzname, zztv->c); \ } while (0) int main() { struct vki_timeval vals[3] = { { 1, 1, 1, 1, 1 }, { 2, 2, 2, 2, 2 }, { 3, 3, 3, 3, 3 } }; void* tvp = &vals[0]; PRE_timeval_READ( "futimes(tvp[1])", tvp+sizeof(struct vki_timeval) ); } hummer:src thakis$ gcc test.c -o foo hummer:src thakis$ ./foo Note: futimes(tvp[1]) 1836213620 The fix for the bug is (note the added parens): struct vki_timeval *zztv = (struct vki_timeval *)(zzarg); \ Clang could maybe warn if something in a macro (here: the cast) binds with a high precendence to only parts of a macro argument (here "tvp+sizeof(vki_timeval)") or some such. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 11:47:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 11:47:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10428] New: placement new with vexing parse parsed as ill-formed non-placement new Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10428 Summary: placement new with vexing parse parsed as ill-formed non-placement new Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang rejects this: using size_t = decltype(sizeof(int)); struct S {}; void *operator new(size_t, S); void f() { new (S()) int; } foo.cpp:4:17: error: cannot allocate function type 'S ()' with new void f() { new (S()) int; } ^~~ The standard does not appear to provide any guidance in disambiguating this case, but g++-4.4.5 accepts it, and it seems reasonable for us to 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 Wed Jul 20 13:15:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 13:15:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10421] incorrect code generated for shufflevector with i8 types (x86) In-Reply-To: References: Message-ID: <20110720181501.6C8AF2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10421 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-07-20 13:15:01 CDT --- r135595. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 14:36:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 14:36:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 10389] [MC assembler] dot symbol used with leal interpreted differently from GNU as In-Reply-To: References: Message-ID: <20110720193637.D0EE22A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10389 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Eli Friedman 2011-07-20 14:36:37 CDT --- r135607. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 17:07:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 17:07:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 9555] Suboptimal error message for providing T* to method requiring T or T& In-Reply-To: References: Message-ID: <20110720220742.9B7052A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9555 Anna Zaks changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |ganna at apple.com Resolution|DUPLICATE | --- Comment #2 from Anna Zaks 2011-07-20 17:07:41 CDT --- The call to bar() will be resolved as part of fixing bug 5941 (rev 135509). However, the reference examples will need extra work; so reopening. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 20 17:38:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 17:38:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 10430] New: LangRef still mentions the opaque type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10430 Summary: LangRef still mentions the opaque type Product: Documentation Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: grosser at fim.uni-passau.de CC: llvmbugs at cs.uiuc.edu -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 20 18:41:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 18:41:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 10411] assertion when using exception and ARC In-Reply-To: References: Message-ID: <20110720234156.1749C2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10411 Fariborz Jahanian changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Fariborz Jahanian 2011-07-20 18:41:55 CDT --- Fixed in r135638 > Fariborz, can you take a look? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 20 22:11:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 20 Jul 2011 22:11:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 10419] 'main' function with unusual signature cannot be compiled In-Reply-To: References: Message-ID: <20110721031145.7D6FC2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10419 Andrew Sampson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Andrew Sampson 2011-07-20 22:11:45 CDT --- A neat trick I wasn't aware of; it required __asm__("_main"), but it worked. As long as I can get around the check I'm happy, so I'll close the bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 21 00:47:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 21 Jul 2011 00:47:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10427] clang should warn if a macro argument expansion is "obviously" missing parentheses In-Reply-To: References: Message-ID: <20110721054701.7400D2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10427 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-07-21 00:47:01 CDT --- That would be really cool, but no, not going to do this. Doing so would require a lot of gymnastics that are just not worth doing in the preprocessor. Notably, when parsing the #define itself, we don't and can't actually parse the code to know that that is a cast of a macro argument. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 21 02:26:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 21 Jul 2011 02:26:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10431] New: Optionally mark memory undefined/noaccess for valgrind on entering/leaving stack frames Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10431 Summary: Optionally mark memory undefined/noaccess for valgrind on entering/leaving stack frames Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: jyasskin at google.com CC: llvmbugs at cs.uiuc.edu It would be nice if there were an option to emit Valgrind's magic sequences saying that a new stack frame has undefined contents and that a just-exited stack frame is inaccessible. The sequences are documented at http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq and http://valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs. It probably makes the most sense to use VALGRIND_MALLOCLIKE_BLOCK() for entering a frame and VALGRIND_FREELIKE_BLOCK() for leaving a frame, but VALGRIND_MAKE_MEM_UNDEFINED() and VALGRIND_MAKE_MEM_NOACCESS() might make more sense for programs that might use longjmp. This is a point midway between doing nothing and turning on asan or safecode, since it costs ~11 instructions (on x86-64) at the beginning and end of each function but allows full valgrind to catch more errors than it otherwise would. These sequences should be safe to embed into LLVM since they're designed to be compiled into lots of client programs. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 21 11:35:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 21 Jul 2011 11:35:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10406] [PATCH] _MIPS_SIM builtin macro In-Reply-To: References: Message-ID: <20110721163520.EE4612A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10406 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Bruno Cardoso Lopes 2011-07-21 11:35:20 CDT --- Applied in r135675 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 21 12:29:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 21 Jul 2011 12:29:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10432] New: Inefficient code for passing an alloca as argument to a function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10432 Summary: Inefficient code for passing an alloca as argument to a function Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Given extern bool ToNumberSlow(double *dp); void Interpret() { double l, r; for (;;) { ToNumberSlow(&l); ToNumberSlow(&r); } } We produce what is probably the best IL: define void @_Z9Interpretv() noreturn nounwind uwtable { entry: %l = alloca double, align 8 %r = alloca double, align 8 br label %for.cond for.cond: %call = call zeroext i1 @_Z12ToNumberSlowPd(double* %l) nounwind %call1 = call zeroext i1 @_Z12ToNumberSlowPd(double* %r) nounwind br label %for.cond } declare zeroext i1 @_Z12ToNumberSlowPd(double*) but that then codegens to: pushq %r14 pushq %rbx subq $24, %rsp leaq 16(%rsp), %r14 leaq 8(%rsp), %rbx .align 16, 0x90 .LBB0_1: movq %r14, %rdi callq _Z12ToNumberSlowPd movq %rbx, %rdi callq _Z12ToNumberSlowPd jmp .LBB0_1 gcc produces subq $24, %rsp .L2: movq %rsp, %rdi call _Z12ToNumberSlowPd leaq 8(%rsp), %rdi call _Z12ToNumberSlowPd jmp .L2 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 21 13:58:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 21 Jul 2011 13:58:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10433] New: clang fails with internal linkage, 'extern' at block scope and tentative definitions. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10433 Summary: clang fails with internal linkage, 'extern' at block scope and tentative definitions. Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nbowler at draconx.ca CC: llvmbugs at cs.uiuc.edu According to C99?6.2.2#4: For an identifier declared with the storage-class specifier extern in a scope in which a prior declaration of that identifier is visible, if the prior declaration specifies internal or external linkage, the linkage of the identifier at the later declaration is the same as the linkage specified at the prior declaration. However, clang does not seem to handle this properly at block scope if the only earlier declarations with internal linkage are also tentative definitions, as in the following program: /* Tentative definition of x; declares x with internal linkage. */ static int x; int main(void) { /* * A prior declaration of x with internal linkage is visible, so this * declares x with internal linkage, too. */ extern int x; return x; } /* Definition of x, again with internal linkage. */ static int x = 42; Attempting to compile this with clang yields an error: % clang -std=c99 -pedantic test.c test.c:16:12: error: static declaration of 'x' follows non-static declaration static int x = 42; ^ test.c:10:14: note: previous definition is here extern int x; ^ 1 error generated. The problems go away if the 'static int x = 42;' is moved above the declaration of main, or if the 'extern int x;' is moved outside of main to file scope. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 21 20:12:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 21 Jul 2011 20:12:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10434] New: Cannot locate stdc++ header files on driver other than 'c:'. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10434 Summary: Cannot locate stdc++ header files on driver other than 'c:'. Product: clang Version: 2.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chrisj at rtems.org CC: llvmbugs at cs.uiuc.edu The follow occurs: S:\clang>type t.cc #include S:\clang>clang-2.9\bin\clang t.cc t.cc:1:10: fatal error: 'memory' file not found #include ^ 1 error generated. S:\clang> If the same file is compiled on 'C:' there is no problem. The list of ignored directories (-v) is different in each case. There are a few '/mingw/...' entries in the case that fails. The failure happens in the MSYS shell and the cmd.exe shell. I have tested Windows 7 (64bit) and Windows XP (32bit). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 21 21:39:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 21 Jul 2011 21:39:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 10435] New: Static Analyzer fails to recognize exit() Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10435 Summary: Static Analyzer fails to recognize exit() Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tim-llvm at sentinelchicken.org CC: llvmbugs at cs.uiuc.edu I have a piece of C code that does basically: void bailOut(...) { fprintf(stderr, "ERROR!"); exit(1); } ... if (pointer == NULL) bailOut(...) pointer->property = ...; ... The problem is that the scan-build analyzer doesn't recognize that the program should stop at exit() and believes that pointer->property is a NULL dereference. This comes up in several similar contexts, all because of the lack of recognition of exit(). I imagine this could lead to many other types of false positives 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 Thu Jul 21 22:23:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 21 Jul 2011 22:23:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 10412] clang accepts extra qualifier In-Reply-To: References: Message-ID: <20110722032326.EBCAC2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10412 Sean Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Sean Hunt 2011-07-21 22:23:26 CDT --- I'm closing this now, based on seeming consensus. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 00:31:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 00:31:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10358] -Wuninitialized false negative for use inside a loop In-Reply-To: References: Message-ID: <20110722053139.DD6332A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10358 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #14 from Chandler Carruth 2011-07-22 00:31:39 CDT --- (In reply to comment #13) > Chandler: please review this patch. It's basically your patch, so I'd prefer > you to do the honors of committing it. Cool, thanks for updating it, and thanks for the review! submitted in r135748. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 01:27:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 01:27:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 10384] Assertion `Ty && "GEP indices invalid!"' In-Reply-To: References: Message-ID: <20110722062743.78F8E2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10384 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2011-07-22 01:27:43 CDT --- Yep, that was exactly it, thanks a lot Eli! Fixed in r135752 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 05:16:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 05:16:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 10438] New: Intrinsic::getType() crashes for many Intrinsic::ID values Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10438 Summary: Intrinsic::getType() crashes for many Intrinsic::ID values Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6914) --> (http://llvm.org/bugs/attachment.cgi?id=6914) c++ test program (Boiled down test case from something I ran into elsewhere). This happens from a just-synced top-of-tree. Intrinsic::getType() hits the assertion "Assertion failed: (Index < Length && "Invalid index!"), function operator[], file /Users/mmp/llvm-dev-src/include/llvm/ADT/ArrayRef.h, line 130." for many intrinsic id values. This can be seen by doing just: for (int id = 1; id < llvm::Intrinsic::num_intrinsics; ++id) intrinsicType = llvm::Intrinsic::getType(*ctx, (llvm::Intrinsic::ID)id); But see the attached for a full reproducer case. Interestingly enough, the ones that fail seem to be just the various architecture independent builtins: llvm.annotation llvm.atomic.cmp.swap llvm.atomic.load.add llvm.atomic.load.and llvm.atomic.load.max llvm.atomic.load.min llvm.atomic.load.nand llvm.atomic.load.or llvm.atomic.load.sub llvm.atomic.load.umax llvm.atomic.load.umin llvm.atomic.load.xor llvm.atomic.swap llvm.bswap llvm.convertff llvm.convertfsi llvm.convertfui llvm.convertsif llvm.convertss llvm.convertsu llvm.convertuif llvm.convertus llvm.convertuu llvm.cos llvm.ctlz llvm.ctpop llvm.cttz llvm.exp llvm.exp2 llvm.expect llvm.fma llvm.log llvm.log10 llvm.log2 llvm.memcpy llvm.memmove llvm.memset llvm.objectsize llvm.pow llvm.powi llvm.ptr.annotation llvm.sadd.with.overflow llvm.sin llvm.smul.with.overflow llvm.sqrt llvm.ssub.with.overflow llvm.uadd.with.overflow llvm.umul.with.overflow llvm.usub.with.overflow And a bunch of ARM stuff: llvm.arm.neon.vabds llvm.arm.neon.vabdu llvm.arm.neon.vabs llvm.arm.neon.vaddhn llvm.arm.neon.vcls llvm.arm.neon.vclz llvm.arm.neon.vcnt llvm.arm.neon.vcvtfp2fxs llvm.arm.neon.vcvtfp2fxu llvm.arm.neon.vcvtfxs2fp llvm.arm.neon.vcvtfxu2fp llvm.arm.neon.vhadds llvm.arm.neon.vhaddu llvm.arm.neon.vhsubs llvm.arm.neon.vhsubu llvm.arm.neon.vld1 llvm.arm.neon.vld2 llvm.arm.neon.vld2lane llvm.arm.neon.vld3 llvm.arm.neon.vld3lane llvm.arm.neon.vld4 llvm.arm.neon.vld4lane llvm.arm.neon.vmaxs llvm.arm.neon.vmaxu llvm.arm.neon.vmins llvm.arm.neon.vminu llvm.arm.neon.vmullp llvm.arm.neon.vmulls llvm.arm.neon.vmullu llvm.arm.neon.vmulp llvm.arm.neon.vpadals llvm.arm.neon.vpadalu llvm.arm.neon.vpadd llvm.arm.neon.vpaddls llvm.arm.neon.vpaddlu llvm.arm.neon.vpmaxs llvm.arm.neon.vpmaxu llvm.arm.neon.vpmins llvm.arm.neon.vpminu llvm.arm.neon.vqabs llvm.arm.neon.vqadds llvm.arm.neon.vqaddu llvm.arm.neon.vqdmlal llvm.arm.neon.vqdmlsl llvm.arm.neon.vqdmulh llvm.arm.neon.vqdmull llvm.arm.neon.vqmovns llvm.arm.neon.vqmovnsu llvm.arm.neon.vqmovnu llvm.arm.neon.vqneg llvm.arm.neon.vqrdmulh llvm.arm.neon.vqrshiftns llvm.arm.neon.vqrshiftnsu llvm.arm.neon.vqrshiftnu llvm.arm.neon.vqrshifts llvm.arm.neon.vqrshiftu llvm.arm.neon.vqshiftns llvm.arm.neon.vqshiftnsu llvm.arm.neon.vqshiftnu llvm.arm.neon.vqshifts llvm.arm.neon.vqshiftsu llvm.arm.neon.vqshiftu llvm.arm.neon.vqsubs llvm.arm.neon.vqsubu llvm.arm.neon.vraddhn llvm.arm.neon.vrecpe llvm.arm.neon.vrecps llvm.arm.neon.vrhadds llvm.arm.neon.vrhaddu llvm.arm.neon.vrshiftn llvm.arm.neon.vrshifts llvm.arm.neon.vrshiftu llvm.arm.neon.vrsqrte llvm.arm.neon.vrsqrts llvm.arm.neon.vrsubhn llvm.arm.neon.vshiftins llvm.arm.neon.vshiftls llvm.arm.neon.vshiftlu llvm.arm.neon.vshiftn llvm.arm.neon.vshifts llvm.arm.neon.vshiftu llvm.arm.neon.vst1 llvm.arm.neon.vst2 llvm.arm.neon.vst2lane llvm.arm.neon.vst3 llvm.arm.neon.vst3lane llvm.arm.neon.vst4 llvm.arm.neon.vst4lane llvm.arm.neon.vsubhn llvm.arm.vcvtr llvm.arm.vcvtru -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 06:12:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 06:12:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10439] New: [AVX] seg fault in llc due to infinite loop of SelectionDAGLegalize::LegalizeOp calls Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10439 Summary: [AVX] seg fault in llc due to infinite loop of SelectionDAGLegalize::LegalizeOp calls Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6916) --> (http://llvm.org/bugs/attachment.cgi?id=6916) bitcode to reproduce (This happens with a recently-synced top-of-tree). With the attached test case, if you run: % llc -mcpu=corei7-avx -mattr=+avx seg.bc It crashes with a seg fault due to an infinite set of mutually recursive calls to LegalizeOp [.....] #9547 0x00000001004d8b5c in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fff5fbfe8b0, Op={Node = 0x103058810, ResNo = 0}) at LegalizeDAG.cpp:976 #9548 0x00000001004e096a in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fff5fbfe8b0, Op={Node = 0x103059e10, ResNo = 0}) at LegalizeDAG.cpp:1709 #9549 0x00000001004d8b5c in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fff5fbfe8b0, Op={Node = 0x103058810, ResNo = 0}) at LegalizeDAG.cpp:976 #9550 0x00000001004e096a in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fff5fbfe8b0, Op={Node = 0x103059e10, ResNo = 0}) at LegalizeDAG.cpp:1709 #9551 0x00000001004d8b5c in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fff5fbfe8b0, Op={Node = 0x103058810, ResNo = 0}) at LegalizeDAG.cpp:976 #9552 0x00000001004e096a in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fff5fbfe8b0, Op={Node = 0x103057f10, ResNo = 0}) at LegalizeDAG.cpp:1709 #9553 0x00000001004edc85 in (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG (this=0x7fff5fbfe8b0) at LegalizeDAG.cpp:213 #9554 0x00000001004eddbd in llvm::SelectionDAG::Legalize (this=0x1029226d0) at LegalizeDAG.cpp:3892 #9555 0x00000001005d4d7c in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x10291ce80) at SelectionDAGISel.cpp:548 #9556 0x00000001005d6b1e in llvm::SelectionDAGISel::SelectBasicBlock (this=0x10291ce80, Begin={> = {}, NodePtr = 0x102912a08}, End={> = {}, NodePtr = 0x102912110}, HadTailCall=@0x7fff5fbfed78) at SelectionDAGISel.cpp:414 #9557 0x00000001005d743e in llvm::SelectionDAGISel::SelectAllBasicBlocks (this=0x10291ce80, Fn=@0x102911200) at SelectionDAGISel.cpp:972 #9558 0x00000001005d79c8 in llvm::SelectionDAGISel::runOnMachineFunction (this=0x10291ce80, mf=@0x1029320f0) at SelectionDAGISel.cpp:282 #9559 0x00000001006f5ed9 in llvm::MachineFunctionPass::runOnFunction (this=0x10291ce80, F=@0x102911200) at MachineFunctionPass.cpp:33 #9560 0x00000001009fa3e9 in llvm::FPPassManager::runOnFunction (this=0x10291be80, F=@0x102911200) at PassManager.cpp:1513 #9561 0x00000001009fa5df in llvm::FPPassManager::runOnModule (this=0x10291be80, M=@0x10290f800) at PassManager.cpp:1535 #9562 0x00000001009fa0a4 in llvm::MPPassManager::runOnModule (this=0x102919c30, M=@0x10290f800) at PassManager.cpp:1589 #9563 0x00000001009fb884 in llvm::PassManagerImpl::run (this=0x1029198f0, M=@0x10290f800) at PassManager.cpp:1671 #9564 0x00000001009fb8e5 in llvm::PassManager::run (this=0x7fff5fbff430, M=@0x10290f800) at PassManager.cpp:1715 #9565 0x00000001000372b0 in main (argc=4, argv=0x7fff5fbff5a8) at llc.cpp:373 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 06:18:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 06:18:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 10440] New: [AVX] 8-wide bitcast hits "cannot select" error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10440 Summary: [AVX] 8-wide bitcast hits "cannot select" error Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu (I know that AVX is a work-in-progress, but am assuming that bug reports don't hurt.) If I run this: define <8 x i32> @f_f(<8 x float> %x) nounwind { %xx = bitcast <8 x float> %x to <8 x i32> ret <8 x i32> %xx } through "llc bug.ll -mcpu=corei7-avx -mattr=+avx", then the following error is emitted: LLVM ERROR: Cannot select: 0x103039610: v8i32 = bitcast 0x103039510 [ORD=1] [ID=5] 0x103039510: v8f32,ch = CopyFromReg 0x10291e538, 0x103039410 [ORD=1] [ID=4] 0x103039410: v8f32 = Register %vreg0 [ORD=1] [ID=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 Jul 22 06:37:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 06:37:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10441] New: LLVM Function with structure parameter is not compatible with VS2010 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10441 Summary: LLVM Function with structure parameter is not compatible with VS2010 Product: new-bugs Version: 2.9 Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: wuye9036 at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, I was wrote a function as following: =================================================== %float3 = <{float, float, float}> define float dot_prod( %float3 %lhs, %float3 %rhs ){ // blah blah blah } =================================================== And I have a function to invoke it: =================================================== struct float3{ float x, y, z; }; float3 a, b; // Initialize a,b // get JIT-ed pointer float r = dot_prod( a, b ); // *ERROR*. =================================================== That's disassembly told us: caller: 110: float f = test_dot_f3(lhs, rhs); 000000013FEBF4A1 lea rax,[rsp+1D8h] 000000013FEBF4A9 mov qword ptr [rsp+1E8h],rax 000000013FEBF4B1 lea rax,[rsp+1F0h] 000000013FEBF4B9 mov qword ptr [rsp+200h],rax 000000013FEBF4C1 lea rdx,[rsp+118h] 000000013FEBF4C9 mov rcx,qword ptr [rsp+1E8h] 000000013FEBF4D1 call eflib::vec3::vec3 (13FEB27C0h) 000000013FEBF4D6 mov qword ptr [rsp+300h],rax 000000013FEBF4DE lea rdx,[rsp+0E8h] 000000013FEBF4E6 mov rcx,qword ptr [rsp+200h] 000000013FEBF4EE call eflib::vec3::vec3 (13FEB27C0h) 000000013FEBF4F3 mov rcx,qword ptr [rsp+300h] 000000013FEBF4FB mov rdx,rcx 000000013FEBF4FE mov rcx,rax 000000013FEBF501 call qword ptr [rsp+98h] 000000013FEBF508 movss dword ptr [rsp+144h],xmm0 callee(dot_prod): 00000000002C0013 db 38h 00000000002C0014 movss xmm4,dword ptr [rsp+68h] 00000000002C001A movss xmm5,dword ptr [rsp+60h] 00000000002C0020 movss dword ptr [rsp+20h],xmm5 00000000002C0026 movss dword ptr [rsp+28h],xmm4 00000000002C002C mov rax,0F0010h 00000000002C0036 call rax ; It's another function. 00000000002C0038 add rsp,38h 00000000002C003C ret And MSDN said if struct is bigger than 64bit, it will save the pointer to rcx and rdx as arguments. So I don't know what I mistake on it. Thank you. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 22 06:42:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 06:42:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10148] llvm-ld aborts with "Aliasee not linked" on virtual destructors In-Reply-To: References: Message-ID: <20110722114217.DCD7B2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10148 Hans-Georg Thien changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Hans-Georg Thien 2011-07-22 06:42:17 CDT --- I have just re-tried (with r134831) everything seems to be fine now! Great work - tanks a lot! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 07:57:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 07:57:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10426] ICE with inline asm In-Reply-To: References: Message-ID: <20110722125707.D0D5A2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10426 Mattias Engdeg?rd changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED AssignedTo|echristo at gmail.com |unassignedclangbugs at nondot. | |org --- Comment #2 from Mattias Engdeg?rd 2011-07-22 07:57:07 CDT --- It seems to work now (r135766). Let's assume it was just a temporary brokenness when building with gcc (which I should have mentioned - sorry). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 11:24:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 11:24:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10438] Intrinsic::getType() crashes for many Intrinsic::ID values In-Reply-To: References: Message-ID: <20110722162444.AE7592A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10438 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |clattner at apple.com Resolution| |INVALID --- Comment #2 from Chris Lattner 2011-07-22 11:24:44 CDT --- This isn't a bug. Those intrinsics require type parameters. llvm.sqrt needs to know which floating point type you're using. The assertion message could be better, but the functionality is correct. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 22 11:25:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 11:25:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 10441] LLVM Function with structure parameter is not compatible with VS2010 In-Reply-To: References: Message-ID: <20110722162550.3E3CD2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10441 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Chris Lattner 2011-07-22 11:25:49 CDT --- LLVM IR datatypes don't provide C ABI semantics. A C frontend is required to lower things in target specific ways to get the right ABI out. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 11:53:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 11:53:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 10442] New: Class with defaulted default constructor is not trivial Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10442 Summary: Class with defaulted default constructor is not trivial Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jonathan.sauer at gmx.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following program does not compile with clang r: struct type { type() = default; // trivial }; static_assert(__is_trivial(type), "Not trivial"); This results in: clang -std=c++0x clang.cpp clang.cpp:5:1: error: static_assert failed "Not trivial" static_assert(__is_trivial(Foo), "Not trivial"); ^ ~~~~~~~~~~~~~~~~~ 1 error generated. This is contrary to N2210 (where this example is excerpted from), that states that a defaulted default constructor is trivial if inline: | Critical to exploiting the benefits of N2172, an inline and explicitly defaulted definition is trivial if and | only if the implicit definition would have been trivial. The potential concern with out-of-class definition | is "How is the compiler to know if it is trivial?". The existing rule that an inline definition must occur | before any use suffices here as well. C.f. FDIS 12.1p5: | A default constructor is trivial if it is not user-provided and if [nothing that applies here] (I don't think a defaulted default constructor should count as "user-provided") -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 22 14:42:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 14:42:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10171] Substitute unpckhpd, unpcklpd and movddup for shufpd In-Reply-To: References: Message-ID: <20110722194228.2A1B82A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10171 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bruno.cardoso at gmail.com Resolution| |FIXED --- Comment #1 from Bruno Cardoso Lopes 2011-07-22 14:42:27 CDT --- Fixed in r135789 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 14:52:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 14:52:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 10440] [AVX] 8-wide bitcast hits "cannot select" error In-Reply-To: References: Message-ID: <20110722195210.E94832A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10440 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bruno Cardoso Lopes 2011-07-22 14:52:10 CDT --- Thanks. Although it's a WIP, please keep reporting bugs! :) Fixed in r135794 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 14:56:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 14:56:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10021] fatal error with AVX In-Reply-To: References: Message-ID: <20110722195644.0E2BE2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10021 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Bruno Cardoso Lopes 2011-07-22 14:56:43 CDT --- Fixed accidentally in r135729 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 15:01:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 15:01:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10134] MC has movq and movd wrong In-Reply-To: References: Message-ID: <20110722200140.5A1BF2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10134 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Nick Lewycky 2011-07-22 15:01:39 CDT --- Oh, I forgot to update this bug. I committed aliases for the instructions. Due to users who are using LLVM on Darwin machines with old assemblers, LLVM continues to emit the wrong instructions in the .s files, but accept both of them like GNU as does. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 22 15:03:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 15:03:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10443] New: scanf input string conversion format Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10443 Summary: scanf input string conversion format Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: kerolasa at iki.fi CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6917) --> (http://llvm.org/bugs/attachment.cgi?id=6917) int in two lines A strange clang behaviour found while compiling util-linux scriptreplay. $ gcc test1.c $ printf "42\n" | ./a.out i: 2 blk: 0 nl: 10 $ gcc test2.c $ printf "42\n" | ./a.out i: 2 blk: 0 nl: 10 $ clang test1.c $ printf "42\n" | ./a.out i: 2 blk: 0 nl: 10 $ clang test2.c $ printf "42\n" | ./a.out i: 2 blk: 42 nl: 10 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 15:53:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 15:53:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 10422] x86/AVX codegen crashes on fcmp + br + call instruction combination. In-Reply-To: References: Message-ID: <20110722205353.5BDB82A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10422 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Bruno Cardoso Lopes 2011-07-22 15:53:52 CDT --- Hi Syoyo, Fixed in r135801. 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 Jul 22 16:36:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 16:36:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10444] New: False -Wunreachable-code warning in switch(typedefEnum) for default: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10444 Summary: False -Wunreachable-code warning in switch(typedefEnum) for default: 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: john.engelhart at gmail.com CC: llvmbugs at cs.uiuc.edu There is a false -Wunreachable-code warning when a switch() statement has a `typedef enum` as its argument and all of the declared `enum` types have a `case ...:` statement for them. In this case, clang will give an unreachable warning if the `switch() { }` statement contains a `default:`, which clang will incorrectly warn that the `default:` case is not reachable. This is on a Mac OS X 10.7 system running clang from Xcode 4.2 Build 4D75. shell% uname -a Darwin anonymous.local 11.0.0 Darwin Kernel Version 11.0.0: Sat Jun 18 12:56:35 PDT 2011; root:xnu-1699.22.73~1/RELEASE_X86_64 x86_64 shell% /Developer4/usr/bin/clang --version Apple clang version 3.0 (tags/Apple/clang-210.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.0.0 Thread model: posix shell% /Developer4/usr/bin/clang -Wunreachable-code -fsyntax-only enumBug.c enumBug.c:17:7: warning: will never be executed [-Wunreachable-code] printf("default, an enum value that is not defined.\n"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. // enumBug.c #include typedef enum { XYEnumOne, XYEnumTwo, } XYEnumBug; XYEnumBug enumBug; int main(int argc, char *argv[]) { switch(enumBug) { case XYEnumOne: case XYEnumTwo: printf("a defined enum value\n"); break; default: printf("default, an enum value that is not defined.\n"); break; } return(0); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 22 17:27:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 17:27:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10445] New: Getting error when trying to use clang++ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10445 Summary: Getting error when trying to use clang++ Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: trustthesky at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com My OS: Linux pc 2.6.38.8-35.fc15.x86_64 GNU/Linux Here is the full log: http://pastebin.com/NHdm0qUS I'm sorry, I don't know what else to say. I just wanted to try clang out :/ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 18:17:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 18:17:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10446] New: False positive for dereferencing null pointer (C++ 'this' pointer) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10446 Summary: False positive for dereferencing null pointer (C++ 'this' pointer) 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: piers at ekioh.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6919) --> (http://llvm.org/bugs/attachment.cgi?id=6919) test case Using downloaded build checker-257, if I assign a variable the contents of 'this', then change that variable as if it were stepping along a linked list, I get a false positive dereference of a null pointer of 'this'. The attached test case shows the original code (ifdefed out), plus a simplified version. Here is a snippet of it, but the attached file is a complete compilable demonstration. 'this' is never 0. { const A *a = this; if (a != 0) a = a->m_previous; printf("%d", m_variable); } /Users/piers/a/test.cpp:31:18: warning: Access to field 'm_variable' results in a dereference of a null pointer printf("%d", m_variable); ^ (the second warning about an unused variable can be safely ignored and only exists to keep the case simple) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 18:39:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 18:39:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10447] New: clang mangles extern "C" method if it declares a type in the function decl Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10447 Summary: clang mangles extern "C" method if it declares a type in the function decl Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com This testcase emits a mangled name for test() with clang: namespace ns { extern "C" { int test(struct helper *); } int test(struct helper *) { return 0; } } but does not with GCC. Without referring to a standard, I think GCC's behaviour is correct. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 22 19:08:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 19:08:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 10448] New: -Wall should include -Wsign-compare Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10448 Summary: -Wall should include -Wsign-compare Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: fischman at chromium.org CC: llvmbugs at cs.uiuc.edu gcc's -Wall includes -Wsign-compare. It'd be nice if clang did the same. (today -Wall does not include -Wsign-compare) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 19:52:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 19:52:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10443] scanf input string conversion format In-Reply-To: References: Message-ID: <20110723005228.968612A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10443 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #3 from Eli Friedman 2011-07-22 19:52:28 CDT --- Your code is writing to random memory on the stack. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 22 21:11:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 22 Jul 2011 21:11:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 10449] New: Support gcroot attribute Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10449 Summary: Support gcroot attribute Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: echristo at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com >From 2007-09-20-GcrootAttribute.c 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 Sat Jul 23 00:12:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 00:12:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 10450] New: Clang handles ambiguous templates due to 'using' or 'inline namespace' rather horribly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10450 Summary: Clang handles ambiguous templates due to 'using' or 'inline namespace' rather horribly Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Some examples: scshunt$ clang -x c++ - namespace A { template struct foo { }; } using namespace A; template struct foo { }; foo i; // EOF :6:1: error: unknown type name 'foo' foo i; ^ :6:4: error: expected unqualified-id foo i; ^ 2 errors generated. scshunt$ clang -x c++ - inline namespace A { template struct foo { }; } template struct foo { }; foo i; // EOF :1:1: warning: inline namespaces are a C++0x feature [-Wc++0x-extensions] inline namespace A { ^ 1 warning generated. Remarkably, despite identical semantics, the results are not the same. Both should be errors due to the ambiguity of 'foo'. The inline namespace case gets far weirder if template specializations are involved. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 02:32:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 02:32:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10451] New: [AVX] another bitcast / 'cannot select' error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10451 Summary: [AVX] another bitcast / 'cannot select' error Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu With the following input, if I run the following with top-of-tree (i.e. including the recent fix for bug 10440), I get the following error. declare <8 x float> @llvm.x86.avx.maskload.ps.256(i8*, <8 x float>) nounwind readonly declare void @llvm.x86.avx.maskstore.ps.256(i8*, <8 x float>, <8 x float>) nounwind define void @f_f([0 x float]* %RET, [0 x float]* %aFOO) nounwind { allocas: %base2i8 = bitcast [0 x float]* %aFOO to i8* %floatval.i = tail call <8 x float> @llvm.x86.avx.maskload.ps.256(i8* %base2i8, <8 x float> ) nounwind %binop = fadd <8 x float> %floatval.i, %floatval.i %ptr.i = bitcast [0 x float]* %RET to i8* tail call void @llvm.x86.avx.maskstore.ps.256(i8* %ptr.i, <8 x float> , <8 x float> %binop) nounwind ret void } % llc bug.ll -o - -mcpu=corei7-avx -mattr=+avx .section __TEXT,__text,regular,pure_instructions LLVM ERROR: Cannot select: 0x7f8b51834d10: v8f32 = bitcast 0x7f8b51834c10 [ID=10] 0x7f8b51834c10: v8i32 = BUILD_VECTOR 0x7f8b51834b10, 0x7f8b51834b10, 0x7f8b51834b10, 0x7f8b51834b10, 0x7f8b51834b10, 0x7f8b51834b10, 0x7f8b51834b10, 0x7f8b51834b10 [ID=9] 0x7f8b51834b10: i32 = TargetConstant<-1> [ID=6] 0x7f8b51834b10: i32 = TargetConstant<-1> [ID=6] 0x7f8b51834b10: i32 = TargetConstant<-1> [ID=6] 0x7f8b51834b10: i32 = TargetConstant<-1> [ID=6] 0x7f8b51834b10: i32 = TargetConstant<-1> [ID=6] 0x7f8b51834b10: i32 = TargetConstant<-1> [ID=6] 0x7f8b51834b10: i32 = TargetConstant<-1> [ID=6] 0x7f8b51834b10: i32 = TargetConstant<-1> [ID=6] -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 05:04:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 05:04:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10452] New: [AVX] "cannot select" BUILD_VECTOR error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10452 Summary: [AVX] "cannot select" BUILD_VECTOR error Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Here's another AVX case.. Given: define void @f_f([0 x float]* nocapture %RET, [0 x float]* nocapture %aFOO) nounwind { allocas: %ptr2vec615 = bitcast [0 x float]* %RET to <8 x float>* store <8 x float> , <8 x float>* %ptr2vec615, align 32 ret void } If I run: % llc bug.ll -o - -mcpu=corei7-avx -mattr=+avx I get the following error: LLVM ERROR: Cannot select: 0x7f953c032110: v8i32 = BUILD_VECTOR 0x7f953c032010, 0x7f953c032010, 0x7f953c032010, 0x7f953c032010, 0x7f953c032010, 0x7f953c032010, 0x7f953c032010, 0x7f953c032010 [ID=6] 0x7f953c032010: i32 = TargetConstant<-1> [ID=4] 0x7f953c032010: i32 = TargetConstant<-1> [ID=4] 0x7f953c032010: i32 = TargetConstant<-1> [ID=4] 0x7f953c032010: i32 = TargetConstant<-1> [ID=4] 0x7f953c032010: i32 = TargetConstant<-1> [ID=4] 0x7f953c032010: i32 = TargetConstant<-1> [ID=4] 0x7f953c032010: i32 = TargetConstant<-1> [ID=4] 0x7f953c032010: i32 = TargetConstant<-1> [ID=4] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 23 05:12:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 05:12:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10453] New: Explicit conversion operator (incorrectly) used during call to object of class type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10453 Summary: Explicit conversion operator (incorrectly) used during call to object of class type Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jonathan.sauer at gmx.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following program compiles with clang r135379: void testFunctionPointer() { // 13.3.1.1.2p2: using Func = void(*)(int); struct NotFP { explicit operator Func(); }; NotFP nfp; nfp(1); } even though NotFP's conversion operator is explicit and thus according to FDIS 13.3.1.1.2p2 should not be used: | In addition, for each non-explicit conversion function declared in T of the form [...] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 23 07:41:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 07:41:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10454] New: scientific linux not detected Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10454 Summary: scientific linux not detected Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: gryzman at gmail.com CC: llvmbugs at cs.uiuc.edu This seems to fix it. But the question is - why do you need to do all that anyway ? I mean, gcc doesn't need to do that, so why would you's ? [gj at sl64 llvm]$ svn diff -x -w tools/clang/lib/Driver/ToolChains.cpp Index: tools/clang/lib/Driver/ToolChains.cpp =================================================================== --- tools/clang/lib/Driver/ToolChains.cpp (revision 135853) +++ tools/clang/lib/Driver/ToolChains.cpp (working copy) @@ -1409,6 +1409,10 @@ else if (Data.startswith("Red Hat Enterprise Linux") && Data.find("release 6") != StringRef::npos) return RHEL6; + else if (Data.startswith("Scientific Linux") && + Data.find("release 6") != StringRef::npos) + return RHEL6; + else if ((Data.startswith("Red Hat Enterprise Linux") || Data.startswith("CentOS")) && Data.find("release 5") != StringRef::npos) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 08:02:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 08:02:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10455] New: Silent conversion of vector::iterator to vector::const_iterator& Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10455 Summary: Silent conversion of vector::iterator to vector::const_iterator& Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, The following piece of code cannot be compiled by either clang++/g++ with libc++: #include #include typedef std::vector KernelVector; typedef std::unordered_map KernelVectorMap; int main() { KernelVectorMap::const_iterator kernel; KernelVector::const_iterator subkernel = kernel->second.begin(); std::distance( kernel->second.begin(), subkernel ); return 0; } clang++ -std=c++0x -stdlib=libc++ ./const_iterator.cpp ./const_iterator.cpp:12:3: error: no matching function for call to 'distance' std::distance( kernel->second.begin(), subkernel ); ^~~~~~~~~~~~~ /usr/include/c++/v1/iterator:478:1: note: candidate template ignored: deduced conflicting types for parameter '_InputIter' ('std::__1::__wrap_iter' vs. 'std::__1::__wrap_iter') distance(_InputIter __first, _InputIter __last) ^ 1 error generated. or g++ -std=c++0x -I /usr/include/c++/v1/ ./const_iterator.cpp ./const_iterator.cpp: In function ?int main()?: ./const_iterator.cpp:12:52: error: no matching function for call to ?distance(std::__1::vector::iterator, std::__1::vector::const_iterator&)? ./const_iterator.cpp:12:52: note: candidate is: /usr/include/c++/v1/iterator:479:47: note: template typename std::__1::iterator_traits::difference_type std::__1::distance(_InputIter, _InputIter) Can iterator be silently converted to const_iterator in the case like std::distance()? Please take a look at the comment by David Blaikie: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-July/016308.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 23 11:14:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 11:14:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10455] Silent conversion of vector::iterator to vector::const_iterator& In-Reply-To: References: Message-ID: <20110723161448.5D23C2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10455 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2011-07-23 11:14:48 CDT --- Committed revision 135854. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 12:16:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 12:16:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10449] Support gcroot attribute In-Reply-To: References: Message-ID: <20110723171609.25D562A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10449 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Chris Lattner 2011-07-23 12:16:08 CDT --- Hey Eric, noone is using this, it can be removed. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 13:22:58 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 13:22:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 9511] Crash on invalid variadic template code In-Reply-To: References: Message-ID: <20110723182258.D88252A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9511 jonathan.sauer at gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from jonathan.sauer at gmx.de 2011-07-23 13:22:58 CDT --- Fixed in the meantime. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 13:46:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 13:46:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 10445] Getting error when trying to use clang++ In-Reply-To: References: Message-ID: <20110723184608.8A3472A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10445 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-07-23 13:46:08 CDT --- This is fixed in top-of-tree Clang. Clang 2.9 doesn't support libstdc++ 4.6. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 13:47:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 13:47:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 10456] New: Explicit conversion operators do no implement C++ DR 899. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10456 Summary: Explicit conversion operators do no implement C++ DR 899. Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang does not implement http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#899 It should. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 14:00:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 14:00:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 10453] Explicit conversion operator (incorrectly) used during call to object of class type In-Reply-To: References: Message-ID: <20110723190047.AE2342A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10453 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-07-23 14:00:47 CDT --- Fixed by Jonathan Sauer's patch in Clang r135857! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 14:12:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 14:12:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10457] New: Delegating constructor doesn't seem to delegate Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10457 Summary: Delegating constructor doesn't seem to delegate Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hhinnant at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Apple clang version 3.0 (tags/Apple/clang-210.3) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.0.0 Thread model: posix #include #include class string { const char* data_; string(const char* str, std::size_t N); public: template string(const char (&str)[N]) : string(str, N) {} }; string::string(const char* str, std::size_t N) { printf("hi\n"); } int main() { string s("hi"); } clang++ -std=c++0x test.cpp I don't get any output. I expect the debugging "hi" print statement in string::string(const char* str, std::size_t N) to get called. If I rewrite the private constructor as a private init() function, then I see the behavior I'm expecting. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 14:59:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 14:59:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10430] LangRef still mentions the opaque type In-Reply-To: References: Message-ID: <20110723195919.D0D022A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10430 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2011-07-23 14:59:19 CDT --- Clarified in r135861, 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 Jul 23 15:04:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 15:04:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10415] extra module asm directives? In-Reply-To: References: Message-ID: <20110723200439.9BA712A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10415 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-07-23 15:04:39 CDT --- Fixed in r135862, thanks for noticing! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 15:05:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 15:05:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10397] X86 Disassembler Gives Wrong Sign for short JMP In-Reply-To: References: Message-ID: <20110723200528.314502A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10397 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2011-07-23 15:05:27 CDT --- Sounds fixed on mainline. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 15:12:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 15:12:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 10458] New: poor diagnostic when trying to use 'auto' not in '0x mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10458 Summary: poor diagnostic when trying to use 'auto' not in '0x mode Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com When trying to use auto (in this case in an range loop) but without '0x mode enabled, you get an error like: Test.cpp:88:14: error: C++ requires a type specifier for all declarations for (auto &I : MyVector) { ~~~~ ^ Test.cpp:88:8: error: loop variable 'I' may not be declared 'auto' for (auto &I : Fields) { ^ It should say that 'auto' isn't supported in C++'98 mode and recover well. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jul 23 16:21:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 16:21:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10459] New: explicit conversion function return conversions not restricted to qualifications Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10459 Summary: explicit conversion function return conversions not restricted to qualifications Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following should be rejected struct A { explicit operator int(); }; long a = long(A()); But clang accepts it. See also the GCC version of this PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 23 19:42:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 23 Jul 2011 19:42:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 10460] New: poor error recovery from unqualified class enum Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10460 Summary: poor error recovery from unqualified class enum Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Consider this: $ cat t.cc enum class foo_t { abcdef, b, c }; foo_t x = abcdef; namespace bar { enum bar_t { abcdef, b, c }; } bar::bar_t y = abcdef; $ clang t.cc -std=c++0x t.cc:4:11: error: use of undeclared identifier 'abcdef' foo_t x = abcdef; ^ t.cc:10:16: error: use of undeclared identifier 'abcdef' bar::bar_t y = abcdef; ^ It would be nice to say "did you mean foo_t::abcdef" by diving into the namespace/enum class. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 24 00:31:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 00:31:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10461] New: std::string should *not* use C string functions like strcmp, wcscmp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10461 Summary: std::string should *not* use C string functions like strcmp, wcscmp Product: libc++ Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: oneill+llvmbugs at cs.hmc.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6920) --> (http://llvm.org/bugs/attachment.cgi?id=6920) stringcheck.cpp ? show problems with std::string std::string strings are allowed to contain NUL ('\0'), C strings by definition cannot. Thus you should be very careful about where you use C string functions. % clang++ -g -o stringcheck stringcheck.cpp % ./stringcheck % clang++ -g -stdlib=libc++ -o stringcheck stringcheck.cpp % ./stringcheck Assertion failed: (x < y), function main, file stringcheck.cpp, line 9. Abort (What's interesting, perhaps, is that it's right for char_traits (that code uses memcmp) ??maybe the other code ought to be using that?) This issue is repeated with wcscmp vs wmemcmp for 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 Sun Jul 24 10:07:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 10:07:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10461] std::string should *not* use C string functions like strcmp, wcscmp In-Reply-To: References: Message-ID: <20110724150741.233DB2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10461 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2011-07-24 10:07:40 CDT --- Fix Committed revision 135873. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 24 14:12:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 14:12:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 10462] New: JumpScopeChecker crash on invalid Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10462 Summary: JumpScopeChecker crash on invalid Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang crashes on: $ cat foo.cpp enum MyEnum { something_valid, something_invalid }; bool recurse() { MyEnum K; switch (K) { case something_valid: case what_am_i_thinking: int *X = 0; if (recurse()) { } break; } } $ clang foo.cpp -w x.cpp:11:8: error: use of undeclared identifier 'what_am_i_thinking' case what_am_i_thinking: ^ Assertion failed: (LabelAndGotoScopes.count(SC) && "Case not visited?"), function VerifyJumps, file JumpDiagnostics.cpp, line 494. 0 clang 0x0000000101f7b0d5 PrintStackTrace(void*) + 53 1 clang 0x0000000101f7b78b SignalHandler(int) + 379 2 libSystem.B.dylib 0x00007fff86fba1ba _sigtramp + 26 3 libSystem.B.dylib 0x000100010044075c _sigtramp + 2034787772 4 clang 0x0000000101f7b45b raise + 27 5 clang 0x0000000101f7b51a abort + 26 6 clang 0x0000000101f7b4f4 __assert_rtn + 132 7 clang 0x0000000100429b6c (anonymous namespace)::JumpScopeChecker::VerifyJumps() + 492 8 clang 0x00000001004289e7 (anonymous namespace)::JumpScopeChecker::JumpScopeChecker(clang::Stmt*, clang::Sema&) + 263 9 clang 0x0000000100428715 (anonymous namespace)::JumpScopeChecker::JumpScopeChecker(clang::Stmt*, clang::Sema&) + 37 10 clang 0x00000001004286d1 clang::Sema::DiagnoseInvalidJumps(clang::Stmt*) + 49 ... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 24 14:24:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 14:24:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 10463] New: Assertion `SnippetCopies.count(MI) && "Remaining use wasn't a snippet copy"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10463 Summary: Assertion `SnippetCopies.count(MI) && "Remaining use wasn't a snippet copy"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: InlineSpiller.cpp:1018: void::InlineSpiller::spillAll(): Assertion `SnippetCopies.count(MI) && "Remaining use wasn't a snippet copy"' failed. 0 llc 0x000000000153ff42 1 llc 0x00000000015404d0 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000001282ea7 (anonymous namespace)::InlineSpiller::spillAll() + 979 7 llc 0x0000000001284523 (anonymous namespace)::InlineSpiller::spill(llvm::LiveRangeEdit&) + 563 8 llc 0x00000000011982bc (anonymous namespace)::RAGreedy::selectOrSplit(llvm::LiveInterval&, llvm::SmallVectorImpl&) + 940 9 llc 0x0000000001185221 llvm::RegAllocBase::allocatePhysRegs() + 523 10 llc 0x0000000001193c66 (anonymous namespace)::RAGreedy::runOnMachineFunction(llvm::MachineFunction&) + 792 11 llc 0x000000000114490d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 12 llc 0x000000000147a237 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 13 llc 0x000000000147a42f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 14 llc 0x0000000001479ee3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 15 llc 0x000000000147b698 llvm::PassManagerImpl::run(llvm::Module&) + 116 16 llc 0x000000000147b6fb llvm::PassManager::run(llvm::Module&) + 33 17 llc 0x0000000000ab6424 main + 2410 18 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 19 llc 0x0000000000ab4b69 Stack dump: 0. Program arguments: llc fail_239.ll 1. Running pass 'Function Pass Manager' on module 'fail_239.ll'. 2. Running pass 'Greedy Register Allocator' on function '@autogen_239_1000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_239_1000() { BB: %Shuff = shufflevector <8 x double> undef, <8 x double> undef, <8 x i32> br label %CF CF: ; preds = %CF, %BB %B16 = frem <8 x double> zeroinitializer, %Shuff %E19 = extractelement <8 x double> %Shuff, i32 5 br i1 undef, label %CF, label %CF75 CF75: ; preds = %CF75, %CF br i1 undef, label %CF75, label %CF76 CF76: ; preds = %CF76, %CF75 store double %E19, double* undef br i1 undef, label %CF76, label %CF77 CF77: ; preds = %CF77, %CF76 %B55 = fmul <8 x double> %B16, undef br label %CF77 } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 24 14:25:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 14:25:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 10464] New: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10464 Summary: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: /nfs/iil/disks/cvcc/nrotem/llvm/readonly-llvm-head/include/llvm/Support/Casting.h:194: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = llvm::ShuffleVectorSDNode, Y = llvm::SDValue]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. 0 llc 0x000000000153ff42 1 llc 0x00000000015404d0 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000000c1ec10 llvm::cast_retty::ret_type llvm::cast(llvm::SDValue const&) + 74 7 llc 0x0000000000eb1031 llvm::X86TargetLowering::LowerVECTOR_SHUFFLE(llvm::SDValue, llvm::SelectionDAG&) const + 5295 8 llc 0x0000000000eb5867 llvm::X86TargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&) const + 421 9 llc 0x000000000103a8f2 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 4088 10 llc 0x000000000104f987 (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG() + 179 11 llc 0x000000000104faa5 llvm::SelectionDAG::Legalize() + 49 12 llc 0x0000000000ff709c llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 2424 13 llc 0x0000000000ff8e02 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 14 llc 0x0000000000ff9764 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 15 llc 0x0000000000ff9ce3 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 16 llc 0x000000000114490d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 17 llc 0x000000000147a237 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 18 llc 0x000000000147a42f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 19 llc 0x0000000001479ee3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 20 llc 0x000000000147b698 llvm::PassManagerImpl::run(llvm::Module&) + 116 21 llc 0x000000000147b6fb llvm::PassManager::run(llvm::Module&) + 33 22 llc 0x0000000000ab6424 main + 2410 23 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 24 llc 0x0000000000ab4b69 Stack dump: 0. Program arguments: llc fail_101538.ll 1. Running pass 'Function Pass Manager' on module 'fail_101538.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_101538_1000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_101538_1000() { BB: %I = insertelement <16 x i64> undef, i64 480971, i32 7 %Shuff8 = shufflevector <16 x i64> %I, <16 x i64> undef, <16 x i32> br label %CF CF: ; preds = %CF, %BB br i1 undef, label %CF, label %CF78 CF78: ; preds = %CF78, %CF br i1 undef, label %CF78, label %CF79 CF79: ; preds = %CF79, %CF78 br i1 undef, label %CF79, label %CF80 CF80: ; preds = %CF80, %CF79 %Shuff50 = shufflevector <16 x i64> undef, <16 x i64> %Shuff8, <16 x i32> br label %CF80 } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 24 14:26:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 14:26:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 10465] New: Assertion `Inst.getOperand(0).isReg() && Inst.getOperand(ImmOp).isImm() && ((Inst.getNumOperands() == 3 && Inst.getOperand(1).isReg() && Inst.getOperand(0).getReg() == Inst.getOperand(1).getReg()) || Inst.getNumOperands() == 2) && "Unexpected instruction! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10465 Summary: Assertion `Inst.getOperand(0).isReg() && Inst.getOperand(ImmOp).isImm() && ((Inst.getNumOperands() == 3 && Inst.getOperand(1).isReg() && Inst.getOperand(0).getReg() == Inst.getOperand(1).getReg()) || Inst.getNumOperands() == 2) && "Unexpected instruction! Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: X86MCInstLower.cpp:236: void SimplifyShortImmForm(llvm::MCInst&, unsigned int): Assertion `Inst.getOperand(0).isReg() && Inst.getOperand(ImmOp).isImm() && ((Inst.getNumOperands() == 3 && Inst.getOperand(1).isReg() && Inst.getOperand(0).getReg() == Inst.getOperand(1).getReg()) || Inst.getNumOperands() == 2) && "Unexpected instruction!"' failed. 0 llc 0x000000000153ff42 1 llc 0x00000000015404d0 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000000e2c06e 7 llc 0x0000000000e2e756 8 llc 0x0000000000e2f0e8 9 llc 0x00000000010a2e1e llvm::AsmPrinter::EmitFunctionBody() + 1186 10 llc 0x0000000000e2a03f 11 llc 0x000000000114490d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 12 llc 0x000000000147a237 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 13 llc 0x000000000147a42f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 14 llc 0x0000000001479ee3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 15 llc 0x000000000147b698 llvm::PassManagerImpl::run(llvm::Module&) + 116 16 llc 0x000000000147b6fb llvm::PassManager::run(llvm::Module&) + 33 17 llc 0x0000000000ab6424 main + 2410 18 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 19 llc 0x0000000000ab4b69 Stack dump: 0. Program arguments: llc fail_5410.ll 1. Running pass 'Function Pass Manager' on module 'fail_5410.ll'. 2. Running pass 'X86 AT&T-Style Assembly Printer' on function '@autogen_5410_1000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_5410_1000(i8*) { BB: %A4 = alloca <16 x i32> %E = extractelement <4 x i1> undef, i32 3 br label %CF CF: ; preds = %CF81, %CF, %BB store i1 %E, i1* undef br i1 undef, label %CF, label %CF81 CF81: ; preds = %CF br i1 undef, label %CF, label %CF79 CF79: ; preds = %CF85, %CF79, %CF81 %L17 = load i8* %0 br i1 undef, label %CF79, label %CF83 CF83: ; preds = %CF83, %CF79 br i1 undef, label %CF83, label %CF84 CF84: ; preds = %CF84, %CF83 %B28 = frem <1 x float> zeroinitializer, undef %S30 = select i1 %E, i32 62519, i32 undef %L32 = load i1* undef br i1 %L32, label %CF84, label %CF85 CF85: ; preds = %CF84 %S39 = icmp ugt i1 undef, %E br i1 %S39, label %CF79, label %CF82 CF82: ; preds = %CF82, %CF85 br i1 undef, label %CF82, label %CF86 CF86: ; preds = %CF86, %CF82 %E49 = extractelement <1 x float> %B28, i32 0 br i1 undef, label %CF86, label %CF87 CF87: ; preds = %CF87, %CF86 br i1 undef, label %CF87, label %CF88 CF88: ; preds = %CF88, %CF87 br i1 undef, label %CF88, label %CF89 CF89: ; preds = %CF89, %CF88 %S63 = icmp eq i32 315983, %S30 br i1 %S63, label %CF89, label %CF90 CF90: ; preds = %CF90, %CF89 br i1 undef, label %CF90, label %CF91 CF91: ; preds = %CF91, %CF90 br i1 undef, label %CF91, label %CF92 CF92: ; preds = %CF91 store i8 0, i8* %0 store i1 %E, i1* undef store i8 %L17, i8* %0 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 Sun Jul 24 14:27:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 14:27:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10466] New: Assertion `(EltVT.getSizeInBits() >= 64 || (uint64_t)((int64_t)Val >> EltVT.getSizeInBits()) + 1 < 2) && "getConstant with a uint64_t value that doesn't fit in the type!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10466 Summary: Assertion `(EltVT.getSizeInBits() >= 64 || (uint64_t)((int64_t)Val >> EltVT.getSizeInBits()) + 1 < 2) && "getConstant with a uint64_t value that doesn't fit in the type!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: SelectionDAG.cpp:916: llvm::SDValue llvm::SelectionDAG::getConstant(uint64_t, llvm::EVT, bool): Assertion `(EltVT.getSizeInBits() >= 64 || (uint64_t)((int64_t)Val >> EltVT.getSizeInBits()) + 1 < 2) && "getConstant with a uint64_t value that doesn't fit in the type!"' failed. 0 llc 0x000000000153ff42 1 llc 0x00000000015404d0 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000000f90c50 llvm::SelectionDAG::getConstant(unsigned long, llvm::EVT, bool) + 258 7 llc 0x0000000000e7b505 8 llc 0x0000000000eb168e llvm::X86TargetLowering::LowerVECTOR_SHUFFLE(llvm::SDValue, llvm::SelectionDAG&) const + 6924 9 llc 0x0000000000eb5867 llvm::X86TargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&) const + 421 10 llc 0x000000000103a8f2 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 4088 11 llc 0x000000000104f987 (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG() + 179 12 llc 0x000000000104faa5 llvm::SelectionDAG::Legalize() + 49 13 llc 0x0000000000ff709c llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 2424 14 llc 0x0000000000ff8e02 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 15 llc 0x0000000000ff9764 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 16 llc 0x0000000000ff9ce3 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 17 llc 0x000000000114490d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 18 llc 0x000000000147a237 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 19 llc 0x000000000147a42f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 20 llc 0x0000000001479ee3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 21 llc 0x000000000147b698 llvm::PassManagerImpl::run(llvm::Module&) + 116 22 llc 0x000000000147b6fb llvm::PassManager::run(llvm::Module&) + 33 23 llc 0x0000000000ab6424 main + 2410 24 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 25 llc 0x0000000000ab4b69 Stack dump: 0. Program arguments: llc fail_5376.ll 1. Running pass 'Function Pass Manager' on module 'fail_5376.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_5376_1000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_5376_1000() { BB: %I = insertelement <8 x float> undef, float 0x3EC312C960000000, i32 7 %Shuff14 = shufflevector <8 x float> %I, <8 x float> undef, <8 x i32> br label %CF CF: ; preds = %CF, %BB br i1 undef, label %CF, label %CF79 CF79: ; preds = %CF79, %CF %Shuff30 = shufflevector <8 x float> %Shuff14, <8 x float> %Shuff14, <8 x i32> br label %CF79 } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 24 15:13:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 15:13:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 10467] New: Referring to a basic block in another function! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10467 Summary: Referring to a basic block in another function! Product: clang Version: unspecified Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com pes delta-2006.08.03$ clang++ -S ipaggmanip.cc Referring to a basic block in another function! switch i32 %cleanup.dest, label %cleanup [ i32 0, label %cleanup.cont i32 5, label %done ] Broken module found, compilation aborted! Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-freebsd8.2 -S -disable-free -main-file-name ipaggmanip.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.15 -momit-leaf-frame-pointer -coverage-file ipaggmanip.s -resource-dir /usr/local/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 152 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o ipaggmanip.s -x c++ ipaggmanip.cc 1. parser at end of file 2. Per-function optimization 3. Running pass 'Module Verifier' on function '@main' clang: error: unable to execute command: Abort trap: 6 (core dumped) clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 24 15:24:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 15:24:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 10463] Assertion `SnippetCopies.count(MI) && "Remaining use wasn't a snippet copy"' failed. In-Reply-To: References: Message-ID: <20110724202423.B21A62A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10463 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |stoklund at 2pi.dk Resolution| |FIXED --- Comment #1 from Jakob Stoklund Olesen 2011-07-24 15:24:23 CDT --- Fixed in r135885. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 24 18:44:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 18:44:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10468] New: Variable length arrays crash compiler Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10468 Summary: Variable length arrays crash compiler Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu Hardware: Intel Pentium 4 (32-bit mode) O.S.: Linux Fedora Core 15 (32-bit mode) The following program causes clang to "crash": /* * clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) */ #define LDBL long double /*****************************************************************/ static void ld_vla( const int m, const int n, LDBL vla[m][n] ){ int j, k; for( j=0; j http://llvm.org/bugs/show_bug.cgi?id=10469 Summary: ext/hash_set shouldn't warn when compiling with -Wno-deprecated Product: libc++ Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: oneill+llvmbugs at cs.hmc.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6926) --> (http://llvm.org/bugs/attachment.cgi?id=6926) patch to conditionalize warning People need to migrate to unordered_set, sure, and libstdc++ warns too if you use ext/hash_set, but -Wno-deprecated is the accepted way to compile legacy code without warnings. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 24 19:00:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 19:00:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 10469] ext/hash_set shouldn't warn when compiling with -Wno-deprecated In-Reply-To: References: Message-ID: <20110725000003.802532A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10469 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2011-07-24 19:00:03 CDT --- Fix Committed revision 135897. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 24 19:16:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 19:16:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10470] New: Providing ext/slist would improve GNU compatibility Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10470 Summary: Providing ext/slist would improve GNU compatibility Product: libc++ Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: oneill+llvmbugs at cs.hmc.edu CC: llvmbugs at cs.uiuc.edu Various old code uses ext/slist as a low-overhead linked list. Obviously, C++11 code should really use forward_list, but in the interest of easing migration, we ought to provide ext/slist. This is a notable issue because code compiling with the *old* libstdc++ shipped by Apple can't use forward_list because it isn't present. P.S. To make code conditionally choose an appropriate singly-linked list, I can check for _LIBCPP_VERSION, but is that the ?right? way? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 24 19:37:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 19:37:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 10471] New: FLT_EVAL_METHOD sometimes wrong for Intel FPUs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10471 Summary: FLT_EVAL_METHOD sometimes wrong for Intel FPUs Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu FLT_EVAL_METHOD needs to depend upon which FPU code is being generated for. If the sse2 FPU is being used for float, then FLT_EVAL_METHOD should be 0. If the x87 FPU is being use for float, then FLT_EVAL_METHOD should be 2. I forced the use of x87 on a Pentium 4 with -mno-see Is there some macro symbol defined by the compiler that the user's program can check to see which FPU is being used? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 24 19:39:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 24 Jul 2011 19:39:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 10472] New: nexttoward is wrong in Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10472 Summary: nexttoward is wrong in Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: tydeman at tybor.com CC: llvmbugs at cs.uiuc.edu The type generic function nexttoward() is type generic on just the first argument. The second argument is always long double. Therefore, the entry for nexttoward in is wrong. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 25 00:14:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 00:14:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 10473] New: New type system: Invalid module not caught by verifier Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10473 Summary: New type system: Invalid module not caught by verifier Product: libraries Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Archive library AssignedTo: unassignedbugs at nondot.org ReportedBy: viridia at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6927) --> (http://llvm.org/bugs/attachment.cgi?id=6927) An example of an invalid module I've been converting my frontend over to use the new type system, and I noticed that llvm-dis was asserting when I attempted to print out the module contents. It turns out that the module was invalid, but the module verifier should have caught this when the module was first created, which it did not. The main problem appears to be that the BitReader complains when you try to take a GEP of an abstract struct type. I've included an example module that causes BitReader to fail. Unfortunately, since I can't print out the module, it's hard to tell exactly what's wrong with it. I know from looking in the debugger that it's complaining that tart.reflect.Module is an opaque type. The problem is that in this case it's *supposed* to be opaque. However, that shouldn't be your concern - I'm mainly writing this bug because I think it would be good if the module verifier could catch errors like this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 25 00:46:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 00:46:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10474] New: Assert during gfortran compilation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10474 Summary: Assert during gfortran compilation Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: wendling at apple.com CC: llvmbugs at cs.uiuc.edu This program aborts when compiled with llvm-gcc. This is failing on the buildbots during a build of gfortran: $ cat testcase.i struct __mpz_struct { int _mp_size; }; typedef struct __mpz_struct mpz_t[1]; typedef struct gfc_expr { mpz_t *shape; union { struct __mpz_struct integer[1]; } value; } gfc_exec_op; struct gfc_array_ref { struct gfc_expr *start[7]; }; void gfc_copy_array_ref (struct gfc_array_ref *src) {} $ llvm-gcc -c testcase.i Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file /Users/void/llvm/llvm.src/lib/Target/TargetData.cpp, line 393. testcase.i: In function ?gfc_copy_array_ref?: testcase.i:14: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See for instructions. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 25 01:04:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 01:04:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 10475] New: Assertion `Entry.first.getNode() && "Operand isn't split"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10475 Summary: Assertion `Entry.first.getNode() && "Operand isn't split"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: LegalizeTypes.cpp:823: void llvm::DAGTypeLegalizer::GetSplitVector(llvm::SDValue, llvm::SDValue&, llvm::SDValue&): Assertion `Entry.first.getNode() && "Operand isn't split"' failed. 0 llc 0x000000000153ff42 1 llc 0x00000000015404d0 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000001051632 7 llc 0x0000000001068585 8 llc 0x000000000106e0ce 9 llc 0x0000000001055f13 10 llc 0x000000000105688e llvm::SelectionDAG::LegalizeTypes() + 50 11 llc 0x0000000000ff6b25 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1025 12 llc 0x0000000000ff8e02 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 13 llc 0x0000000000ff9764 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 14 llc 0x0000000000ff9ce3 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 15 llc 0x000000000114490d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 16 llc 0x000000000147a237 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 17 llc 0x000000000147a42f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 18 llc 0x0000000001479ee3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 19 llc 0x000000000147b698 llvm::PassManagerImpl::run(llvm::Module&) + 116 20 llc 0x000000000147b6fb llvm::PassManager::run(llvm::Module&) + 33 21 llc 0x0000000000ab6424 main + 2410 22 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 23 llc 0x0000000000ab4b69 Stack dump: 0. Program arguments: llc fail_262380.ll 1. Running pass 'Function Pass Manager' on module 'fail_262380.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_262380_1000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_262380_1000() { BB: br label %CF79 CF79: ; preds = %CF79, %BB br i1 undef, label %CF79, label %CF84.critedge.critedge CF84.critedge.critedge: ; preds = %CF79 %L35 = load <8 x i32>* undef br label %CF85 CF85: ; preds = %CF85, %CF84.critedge.critedge br i1 undef, label %CF85, label %CF86 CF86: ; preds = %CF86, %CF85 %B61 = sub <8 x i32> %L35, zeroinitializer %S64 = icmp ne <8 x i32> %B61, zeroinitializer %E73 = extractelement <8 x i1> %S64, i32 6 br i1 %E73, label %CF86, label %CF87 CF87: ; preds = %CF87, %CF86 br i1 undef, label %CF87, label %CF88 CF88: ; preds = %CF87 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 Mon Jul 25 01:05:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 01:05:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10476] New: Assertion `(!From->hasAnyUseOfValue(i) || From->getValueType(i) == To->getValueType(i)) && "Cannot use this version of ReplaceAllUsesWith!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10476 Summary: Assertion `(!From->hasAnyUseOfValue(i) || From->getValueType(i) == To->getValueType(i)) && "Cannot use this version of ReplaceAllUsesWith!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: SelectionDAG.cpp:5204: void llvm::SelectionDAG::ReplaceAllUsesWith(llvm::SDNode*, llvm::SDNode*, llvm::SelectionDAG::DAGUpdateListener*): Assertion `(!From->hasAnyUseOfValue(i) || From->getValueType(i) == To->getValueType(i)) && "Cannot use this version of ReplaceAllUsesWith!"' failed. 0 llc 0x000000000153ff42 1 llc 0x00000000015404d0 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000000fa0900 llvm::SelectionDAG::ReplaceAllUsesWith(llvm::SDNode*, llvm::SDNode*, llvm::SelectionDAG::DAGUpdateListener*) + 248 7 llc 0x0000000000f4bce9 (anonymous namespace)::DAGCombiner::Run(llvm::CombineLevel) + 1011 8 llc 0x0000000000f4bf12 llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AliasAnalysis&, llvm::CodeGenOpt::Level) + 54 9 llc 0x0000000000ff6f37 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 2067 10 llc 0x0000000000ff8e02 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 11 llc 0x0000000000ff9764 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 12 llc 0x0000000000ff9ce3 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 13 llc 0x000000000114490d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 14 llc 0x000000000147a237 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 15 llc 0x000000000147a42f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 16 llc 0x0000000001479ee3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 17 llc 0x000000000147b698 llvm::PassManagerImpl::run(llvm::Module&) + 116 18 llc 0x000000000147b6fb llvm::PassManager::run(llvm::Module&) + 33 19 llc 0x0000000000ab6424 main + 2410 20 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 21 llc 0x0000000000ab4b69 Stack dump: 0. Program arguments: llc fail_237502.ll 1. Running pass 'Function Pass Manager' on module 'fail_237502.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_237502_1000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_237502_1000() { BB: br label %CF CF: ; preds = %CF82, %CF, %BB br i1 undef, label %CF, label %CF82 CF82: ; preds = %CF br i1 undef, label %CF, label %CF81 CF81: ; preds = %CF86, %CF81, %CF82 br i1 undef, label %CF81, label %CF84 CF84: ; preds = %CF84, %CF81 br i1 undef, label %CF84, label %CF85 CF85: ; preds = %CF85, %CF84 br i1 undef, label %CF85, label %CF86 CF86: ; preds = %CF85 br i1 undef, label %CF81, label %CF83 CF83: ; preds = %CF83, %CF86 br i1 undef, label %CF83, label %CF87 CF87: ; preds = %CF87, %CF83 br i1 undef, label %CF87, label %CF88 CF88: ; preds = %CF88, %CF87 %L58 = load <8 x i32>* null %Shuff68 = shufflevector <8 x i32> %L58, <8 x i32> undef, <8 x i32> %B70 = ashr <8 x i32> zeroinitializer, %Shuff68 br i1 undef, label %CF88, label %CF89 CF89: ; preds = %CF89, %CF88 br i1 false, label %CF89, label %CF90 CF90: ; preds = %CF89 store <8 x i32> %B70, <8 x i32>* undef 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 Mon Jul 25 01:06:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 01:06:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10477] New: Assertion `N.getNode()->getNodeId() != NewNode && "Mapped to new node!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10477 Summary: Assertion `N.getNode()->getNodeId() != NewNode && "Mapped to new node!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: LegalizeTypes.cpp:622: void llvm::DAGTypeLegalizer::RemapValue(llvm::SDValue&): Assertion `N.getNode()->getNodeId() != NewNode && "Mapped to new node!"' failed. 0 llc 0x000000000153ff42 1 llc 0x00000000015404d0 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000001051580 7 llc 0x000000000105152c 8 llc 0x00000000010518fe 9 llc 0x0000000001053ce5 10 llc 0x0000000001053f79 11 llc 0x0000000001053d50 12 llc 0x0000000001056149 13 llc 0x000000000105688e llvm::SelectionDAG::LegalizeTypes() + 50 14 llc 0x0000000000ff6b25 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1025 15 llc 0x0000000000ff8e02 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 16 llc 0x0000000000ff9764 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 17 llc 0x0000000000ff9ce3 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 18 llc 0x000000000114490d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 19 llc 0x000000000147a237 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 20 llc 0x000000000147a42f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 21 llc 0x0000000001479ee3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 22 llc 0x000000000147b698 llvm::PassManagerImpl::run(llvm::Module&) + 116 23 llc 0x000000000147b6fb llvm::PassManager::run(llvm::Module&) + 33 24 llc 0x0000000000ab6424 main + 2410 25 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 26 llc 0x0000000000ab4b69 Stack dump: 0. Program arguments: llc fail_317293.ll 1. Running pass 'Function Pass Manager' on module 'fail_317293.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_317293_1000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_317293_1000() { BB: br label %CF73 CF73: ; preds = %CF73, %BB store <16 x i8> undef, <16 x i8>* undef %S22 = icmp sgt <16 x i1> undef, zeroinitializer %Shuff25 = shufflevector <16 x i1> %S22, <16 x i1> %S22, <16 x i32> %FC = uitofp <16 x i1> %Shuff25 to <16 x double> br i1 undef, label %CF73, label %CF75 CF75: ; preds = %CF73 br label %CF CF: ; preds = %CF76, %CF, %CF75 br i1 undef, label %CF, label %CF76 CF76: ; preds = %CF br i1 undef, label %CF, label %CF74 CF74: ; preds = %CF74, %CF76 br i1 undef, label %CF74, label %CF77 CF77: ; preds = %CF77, %CF74 %Shuff52 = shufflevector <16 x double> %FC, <16 x double> %FC, <16 x i32> br label %CF77 } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 03:53:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 03:53:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10478] New: undefined functions asprintf_l, snprintf_l Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10478 Summary: undefined functions asprintf_l, snprintf_l Product: libc++ Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: llvm at niebuhrt.de CC: llvmbugs at cs.uiuc.edu When compiling the following code, I get these errors. (ucontext is deprecated, but these functions should still redefined) clang++ -o main uclib.cpp -std=c++0x -U__STRICT_ANSI__ -stdlib=libc++ ----- uclib.cpp-------- #define _XOPEN_SOURCE 520 #include #include int main() { std::cout << "Hello World!"< References: Message-ID: <20110725090011.A1C412A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10357 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Duncan Sands 2011-07-25 04:00:11 CDT --- Dragonegg compiles again. I'm seeing plenty of testsuite failure due to the changes to the type system, but that's another 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 Jul 25 04:49:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 04:49:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10479] New: Dragonegg is failing to build under Debian KFreebsd Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10479 Summary: Dragonegg is failing to build under Debian KFreebsd Product: dragonegg Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: New Bugs AssignedTo: baldrick at free.fr ReportedBy: sylvestre at debian.org CC: llvmbugs at cs.uiuc.edu This bug could be reported to llvm since it seems to come from . Under Kfreebsd, the line: std::cout << T.getOSTypeName(T.getOS()) << "\n"; will returns unknown. In the Makefile at the root directory, the following command: -I$(SRC_DIR)/$(shell $(TARGET_UTIL) -o) returns "unknown" causing the unknown/OS.h file (which fails on purpose). It has been reported here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635288 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 06:27:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 06:27:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10280] undefined reference error In-Reply-To: References: Message-ID: <20110725112700.1D08D2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10280 Ryuta Suzuki changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Ryuta Suzuki 2011-07-25 06:26:59 CDT --- Hi Duncan, After http://llvm.org/bugs/show_bug.cgi?id=10357, the undefined reference errors disappeared. Though, it produced the incorrect code (bunch of unit tests failed). (In reply to comment #3) > Thanks. I will take a look at this when I get back from holiday. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 08:58:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 08:58:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10308] using libc++ with -O4 In-Reply-To: References: Message-ID: <20110725135830.603A02A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10308 Toralf Niebuhr 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 Mon Jul 25 10:22:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 10:22:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 10480] New: Assertion failed: (FD->isUsed() && "Sema didn't mark implicit function as used!"), function GetOrCreateLLVMFunction, file CodeGenModule.cpp, line 925. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10480 Summary: Assertion failed: (FD->isUsed() && "Sema didn't mark implicit function as used!"), function GetOrCreateLLVMFunction, file CodeGenModule.cpp, line 925. 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-2006.08.03$ clang++ app.cc app.cc:51:15: warning: control reaches end of non-void function [-Wreturn-type] } ^ Assertion failed: (FD->isUsed() && "Sema didn't mark implicit function as used!"), function GetOrCreateLLVMFunction, file CodeGenModule.cpp, line 931. Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-freebsd8.2 -emit-obj -mrelax-all -disable-free -main-file-name app.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 152 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-wAY1mz.o -x c++ app.cc 1. parser at end of file 2. Per-file LLVM IR generation 3. app.cc:63:43: Generating code for declaration 'Gtk::UI::Items::Array::create' 4. app.cc:69:98: LLVM IR generation of compound statement ('{}') 5. app.cc:70:34: LLVM IR generation of compound statement ('{}') clang: error: unable to execute command: Abort trap: 6 (core dumped) clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 11:53:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 11:53:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10468] Variable length arrays crash compiler In-Reply-To: References: Message-ID: <20110725165317.762182A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10468 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kremenek at apple.com Resolution| |FIXED --- Comment #3 from Ted Kremenek 2011-07-25 11:53:17 CDT --- This works for me as well on TOT. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 12:42:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 12:42:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10481] New: Assertion: `TLI.getTypeAction(*DAG.getContext(), Node->getValueType(i)) == TargetLowering::TypeLegal && "Unexpected illegal type!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10481 Summary: Assertion: `TLI.getTypeAction(*DAG.getContext(), Node->getValueType(i)) == TargetLowering::TypeLegal && "Unexpected illegal type!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: LegalizeDAG.cpp:781: llvm::SDValue::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `TLI.getTypeAction(*DAG.getContext(), Node->getValueType(i)) == TargetLowering::TypeLegal && "Unexpected illegal type!"' failed. 0 llc 0x000000000153ffea 1 llc 0x0000000001540578 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000001039ad7 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 317 7 llc 0x000000000104fa27 (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG() + 179 8 llc 0x000000000104fb45 llvm::SelectionDAG::Legalize() + 49 9 llc 0x0000000000ff713c llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 2424 10 llc 0x0000000000ff8ea2 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 11 llc 0x0000000000ff9804 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 12 llc 0x0000000000ff9d83 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 13 llc 0x00000000011449ad llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 14 llc 0x000000000147a2bb llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 15 llc 0x000000000147a4b3 llvm::FPPassManager::runOnModule(llvm::Module&) + 81 16 llc 0x0000000001479f67 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 17 llc 0x000000000147b71c llvm::PassManagerImpl::run(llvm::Module&) + 116 18 llc 0x000000000147b77f llvm::PassManager::run(llvm::Module&) + 33 19 llc 0x0000000000ab642d main + 2403 20 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 21 llc 0x0000000000ab4b79 Stack dump: 0. Program arguments: ../llc temp.ll -march=x86 -o /dev/null 1. Running pass 'Function Pass Manager' on module 'temp.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_5860_500' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_5860_500(i8*, i32*, i64*, i32, i8, i64) { BB: %A4 = alloca <8 x i32> %A3 = alloca <8 x i32> %A2 = alloca <8 x i64> %A1 = alloca <8 x i32> %A = alloca <8 x i32> %L = load <8 x i64>* %A2 store <8 x i32> undef, <8 x i32>* %A %E = extractelement <8 x i64> %L, i32 0 %E5 = extractelement <8 x i64> %L, i32 2 %Shuff = shufflevector <8 x i64> %L, <8 x i64> %L, <8 x i32> %Shuff6 = shufflevector <8 x i64> %L, <8 x i64> %L, <8 x i32> %Shuff7 = shufflevector <8 x i64> %L, <8 x i64> %L, <8 x i32> %I = insertelement <8 x i64> %L, i64 %E, i32 3 %B = xor <8 x i64> %Shuff, %L %Se = sext i32 %3 to i64 %S = select i1 true, i64 %E5, i64 %E %S8 = fcmp ugt double 0x3EC3280FC1A375B5, 0x3EC3280FC1A375B5 br label %CF CF: ; preds = %CF, %BB %L9 = load i8* %0 store <8 x i32> undef, <8 x i32>* %A %E10 = extractelement <8 x i64> %L, i32 6 %E11 = extractelement <8 x i64> %L, i32 0 %Shuff12 = shufflevector <8 x i64> %Shuff7, <8 x i64> %L, <8 x i32> %Shuff13 = shufflevector <8 x i64> %L, <8 x i64> %Shuff12, <8 x i32> %Shuff14 = shufflevector <8 x i64> %Shuff, <8 x i64> %L, <8 x i32> %I15 = insertelement <8 x i64> %L, i64 %E, i32 1 %FC = sitofp i16 0 to double %S16 = select i1 true, double 0x3EC3280FC1A375B5, double 0x3EC3280FC1A375B5 %S17 = icmp uge <8 x i64> %B, %L %L18 = load i8* %0 store i8 -121, i8* %0 %E19 = extractelement <8 x i64> %L, i32 2 %E20 = extractelement <8 x i64> %L, i32 4 %Shuff21 = shufflevector <8 x i64> %L, <8 x i64> %L, <8 x i32> %Shuff22 = shufflevector <8 x i64> %L, <8 x i64> %L, <8 x i32> %Shuff23 = shufflevector <8 x i64> %Shuff13, <8 x i64> %L, <8 x i32> %I24 = insertelement <8 x i64> %L, i64 219251, i32 5 %B25 = shl i32 -1, %3 %Tr = trunc i64 %E11 to i32 %S26 = select i1 true, i64 219251, i64 46007 %S27 = fcmp oeq double 0x3ECE6F7E564265C3, 0x3ED3CA9085EB6C6E br i1 %S27, label %CF, label %CF38 CF38: ; preds = %CF38, %CF %L28 = load i8* %0 store i8 -85, i8* %0 %E29 = extractelement <8 x i64> %L, i32 0 %E30 = extractelement <8 x i64> %L, i32 2 %Shuff31 = shufflevector <8 x i1> %S17, <8 x i1> %S17, <8 x i32> %Shuff32 = shufflevector <8 x i64> %L, <8 x i64> %Shuff23, <8 x i32> %Shuff33 = shufflevector <8 x i64> %L, <8 x i64> %L, <8 x i32> %I34 = insertelement <8 x i64> %Shuff33, i64 %E, i32 3 %B35 = srem i64 219251, 46007 %PC = bitcast <8 x i32>* %A1 to i64* %S36 = select i1 true, i64 %E5, i64 %E5 %S37 = icmp eq i8 -121, %L9 br i1 %S37, label %CF38, label %CF39 CF39: ; preds = %CF38 store i64 %E29, i64* %PC store i64 %E19, i64* %PC store i64 46007, i64* %PC store i64 %E19, i64* %PC store i64 %E, i64* %PC 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 Mon Jul 25 12:59:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 12:59:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10482] New: Assertion `(TLI.getTypeAction(*DAG.getContext(), Node->getOperand(i).getValueType()) == TargetLowering::TypeLegal || Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexpected illegal type!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10482 Summary: Assertion `(TLI.getTypeAction(*DAG.getContext(), Node->getOperand(i).getValueType()) == TargetLowering::TypeLegal || Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexpected illegal type!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: LegalizeDAG.cpp:788: llvm::SDValue::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `(TLI.getTypeAction(*DAG.getContext(), Node->getOperand(i).getValueType()) == TargetLowering::TypeLegal || Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexpected illegal type!"' failed. 0 llc 0x000000000153ffea 1 llc 0x0000000001540578 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000001039bc8 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 558 7 llc 0x00000000010428e9 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 36687 8 llc 0x000000000104fa27 (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG() + 179 9 llc 0x000000000104fb45 llvm::SelectionDAG::Legalize() + 49 10 llc 0x0000000000ff713c llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 2424 11 llc 0x0000000000ff8ea2 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 12 llc 0x0000000000ff9804 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 13 llc 0x0000000000ff9d83 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 14 llc 0x00000000011449ad llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 15 llc 0x000000000147a2bb llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 16 llc 0x000000000147a4b3 llvm::FPPassManager::runOnModule(llvm::Module&) + 81 17 llc 0x0000000001479f67 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 18 llc 0x000000000147b71c llvm::PassManagerImpl::run(llvm::Module&) + 116 19 llc 0x000000000147b77f llvm::PassManager::run(llvm::Module&) + 33 20 llc 0x0000000000ab642d main + 2403 21 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 22 llc 0x0000000000ab4b79 Stack dump: 0. Program arguments: ../llc temp.ll -march=x86 -mattr=-sse2,-sse41 -o /dev/null 1. Running pass 'Function Pass Manager' on module 'temp.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_3043_500' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_3043_500(i8*, i32*, i64*, i32, i8, i64) { BB: %A4 = alloca <2 x i16> %A3 = alloca <2 x float> %A2 = alloca <2 x float> %A1 = alloca <2 x double> %A = alloca i64 %L = load i8* %0 store i8 0, i8* %0 %E = extractelement <8 x i32> undef, i32 7 %E5 = extractelement <32 x i32> undef, i32 4 %Shuff = shufflevector <8 x double> undef, <8 x double> undef, <8 x i32> %Shuff6 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff7 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %I = insertelement <8 x double> %Shuff, double 0x3F1851E3BCD5D80D, i32 0 %B = udiv i8 -125, -125 %FC = sitofp i64 0 to double %S = select i1 true, <2 x float>* %A3, <2 x float>* %A2 %S8 = icmp ult i16 -2753, -22257 br label %CF38 CF38: ; preds = %CF38, %BB %L9 = load <2 x float>* %S store <2 x float> %L9, <2 x float>* %S %E10 = extractelement <8 x double> %Shuff, i32 2 %E11 = extractelement <8 x double> %Shuff, i32 4 %Shuff12 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff13 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff14 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff6, <8 x i32> %I15 = insertelement <8 x double> %Shuff, double %FC, i32 5 %B16 = add i1 true, %S8 br i1 %B16, label %CF38, label %CF39 CF39: ; preds = %CF38 %BC = bitcast i32 %3 to float %S17 = select i1 %B16, double 0x3EE16D9E1D8663CD, double 0x3F1851E3BCD5D80D %S18 = icmp eq i64 250647, %5 br label %CF CF: ; preds = %CF, %CF39 %L19 = load i64* %A store <2 x float> %L9, <2 x float>* %S %E20 = extractelement <8 x double> %Shuff, i32 2 %E21 = extractelement <8 x double> %Shuff, i32 4 %Shuff22 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff12, <8 x i32> %Shuff23 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff24 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff12, <8 x i32> %I25 = insertelement <8 x double> %Shuff, double 0x3EEE4B396B243C8B, i32 5 %Tr = trunc i64 250647 to i32 %S26 = select i1 %B16, i8 -125, i8 -125 %L27 = load <2 x float>* %S store i8 -125, i8* %0 %E28 = extractelement <8 x double> %Shuff, i32 5 %E29 = extractelement <2 x float> %L27, i32 1 %Shuff30 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff31 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff32 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff30, <8 x i32> %I33 = insertelement <8 x double> %Shuff22, double %S17, i32 0 %B34 = frem <8 x double> %Shuff13, %Shuff %Tr35 = trunc i32 %3 to i1 br i1 %Tr35, label %CF, label %CF40 CF40: ; preds = %CF40, %CF %S36 = select i1 %S18, i1 %B16, i1 %B16 br i1 %S36, label %CF40, label %CF41 CF41: ; preds = %CF41, %CF40 %S37 = icmp eq i64 394307, %L19 br i1 %S37, label %CF41, label %CF42 CF42: ; preds = %CF41 store <2 x float> %L27, <2 x float>* %S store <2 x float> %L9, <2 x float>* %A3 store i8 %S26, i8* %0 store <2 x float> %L9, <2 x float>* %S store i8 %L, i8* %0 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 Mon Jul 25 13:10:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 13:10:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 10472] nexttoward is wrong in In-Reply-To: References: Message-ID: <20110725181056.C8CE92A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10472 Howard Hinnant 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 Mon Jul 25 15:47:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 15:47:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 10483] New: Insert warn_unused_result attributes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10483 Summary: Insert warn_unused_result attributes Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu There are many functions in the standard library that should have warn_unused_result, such as most const member functions (the example that sparked this bug was c_str() in a void context). Potentially there should be a macro to disable them on functions where ignoring the return value is not necessarily a hard bug, as it might be with some C functions that return error codes. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 15:52:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 15:52:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 10484] New: Lifetime markers are preventing alloca promotion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10484 Summary: Lifetime markers are preventing alloca promotion Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: stoklund at 2pi.dk CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6929) --> (http://llvm.org/bugs/attachment.cgi?id=6929) Unoptimized bitcode for clang's Stmp.cpp The llvm.lifetime markers inserted by the inliner are preventing allocas from being promoted to registers. This causes some functions to use a lot more stack space. The attached example is from clang's own Stmt.cpp. The function _ZNK5clang4Stmt14getSourceRangeEv has more then 50 allocas after optimizing to file with 'opt -O2". If I apply this patch: diff --git a/lib/Transforms/Utils/InlineFunction.cpp b/lib/Transforms/Utils/InlineFunction.cpp index 714b12c..c613d1a 100644 --- a/lib/Transforms/Utils/InlineFunction.cpp +++ b/lib/Transforms/Utils/InlineFunction.cpp @@ -934,7 +934,7 @@ bool llvm::InlineFunction(CallSite CS, InlineFunctionInfo &IFI) { // Leave lifetime markers for the static alloca's, scoping them to the // function we just inlined. - if (!IFI.StaticAllocas.empty()) { + if (0 && !IFI.StaticAllocas.empty()) { IRBuilder<> builder(FirstNewBlock->begin()); for (unsigned ai = 0, ae = IFI.StaticAllocas.size(); ai != ae; ++ai) { AllocaInst *AI = IFI.StaticAllocas[ai]; All of those allocas are optimized away. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 16:37:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 16:37:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 10466] Assertion `(EltVT.getSizeInBits() >= 64 || (uint64_t)((int64_t)Val >> EltVT.getSizeInBits()) + 1 < 2) && "getConstant with a uint64_t value that doesn't fit in the type!"' failed. In-Reply-To: References: Message-ID: <20110725213751.EDE372A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10466 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-07-25 16:37:51 CDT --- r135980. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 16:39:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 16:39:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 10484] Lifetime markers are preventing alloca promotion In-Reply-To: References: Message-ID: <20110725213904.3B4D32A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10484 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |DUPLICATE --- Comment #3 from Eli Friedman 2011-07-25 16:39:03 CDT --- *** This bug has been marked as a duplicate of bug 10121 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 17:02:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 17:02:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 10485] New: Struct Passed by Value treated as if Passed By Reference with --force-interpreter Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10485 Summary: Struct Passed by Value treated as if Passed By Reference with --force-interpreter 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: bprosnitz at gmail.com CC: llvmbugs at cs.uiuc.edu In the attached code, the struct's internal data is modified by lli when --force-interpreter flag is specified while it is correctly not modified without the flag. $ lli -force-interpreter code.s.bc checksum x.A = 0 checksum x.B = 0 checksum x.C = 2 $ lli code.s.bc checksum x.A = 0 checksum x.B = 0 checksum x.C = 1 This code is compiled with llvm-2.7's version of dragonegg and run with llvm-2.7. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jul 25 17:03:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 17:03:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 10483] Insert warn_unused_result attributes In-Reply-To: References: Message-ID: <20110725220316.A94292A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10483 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #2 from Howard Hinnant 2011-07-25 17:03:16 CDT --- *** This bug has been marked as a duplicate of bug 10011 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 17:22:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 17:22:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10486] New: Warning for K&R declarations and definitions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10486 Summary: Warning for K&R declarations and definitions Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu There is a lot of code still in the wild that uses K&R-style (non-)prototypes or definitions. It would be nice to have a non-default warning for this to make it easier to clean up larger code bases. It would be even better to have an appropriate fixit. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 17:25:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 17:25:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10476] Assertion `(!From->hasAnyUseOfValue(i) || From->getValueType(i) == To->getValueType(i)) && "Cannot use this version of ReplaceAllUsesWith!"' failed. In-Reply-To: References: Message-ID: <20110725222557.4046A2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10476 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-07-25 17:25:56 CDT --- r135993. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 18:09:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 18:09:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10451] [AVX] another bitcast / 'cannot select' error In-Reply-To: References: Message-ID: <20110725230905.AA9B32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10451 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bruno Cardoso Lopes 2011-07-25 18:09:05 CDT --- Hi, Fixed in r136003! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 18:09:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 18:09:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 10452] [AVX] "cannot select" BUILD_VECTOR error In-Reply-To: References: Message-ID: <20110725230953.C36292A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10452 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bruno Cardoso Lopes 2011-07-25 18:09:53 CDT --- Fixed in r136004! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 25 18:14:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 25 Jul 2011 18:14:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10121] mem2reg/scalarrepl is blocked by llvm.lifetime.start/end In-Reply-To: References: Message-ID: <20110725231433.AC9752A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10121 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED AssignedTo|unassignedbugs at nondot.org |nlewycky at google.com --- Comment #6 from Nick Lewycky 2011-07-25 18:14:33 CDT --- Fixed in r136008. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 00:16:58 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 00:16:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 10485] Struct Passed by Value treated as if Passed By Reference with --force-interpreter In-Reply-To: References: Message-ID: <20110726051658.E39FE2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10485 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Chris Lattner 2011-07-26 00:16:58 CDT --- LLVM 2.7 files won't load with LLVM 3.0 in progress, please update a new testcase. Also, not that the IR interpreter is known broken in many ways, I would strongly recommend not using it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 01:59:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 01:59:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 9214] Convert APIs to use ArrayRef In-Reply-To: References: Message-ID: <20110726065939.4BB9A2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9214 Jay Foad changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Jay Foad 2011-07-26 01:59:38 CDT --- Fixed, then. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 02:44:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 02:44:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 10487] New: Invalid C++ code crashes frontend Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10487 Summary: Invalid C++ code crashes frontend Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: magnus.reftel at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6935) --> (http://llvm.org/bugs/attachment.cgi?id=6935) Invalid C++ code that crashes the frontend The attached (invalid) C++ code crashes clang++ in rev 136052 with the following printouts. The problem has existed since at least rev 127028. $ /opt/llvm-r136052/bin/clang++ invalid.cpp -fsyntax-only -v clang version 3.0 (trunk 136052) Target: i386-pc-cygwin Thread model: posix "/opt/llvm-r136052/bin/clang" -cc1 -triple i386-pc-cygwin -fsyntax-only -disable-free -main-file-name invalid.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.20.51.20100410 -momit-leaf-frame-pointer -v -resource-dir /opt/llvm-r136052/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 80 -fno-use-cxa-atexit -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -x c++ invalid.cpp clang -cc1 version 3.0 based upon llvm 3.0svn hosted on i386-pc-cygwin ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.3.2/include/c++" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.3.2/include/c++/i686-pc-cygwin" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.3.2/include/c++/backward" ignoring nonexistent directory "/usr/local/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++ /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/i686-pc-cygwin /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/backward /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++ /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward /opt/llvm-r136052/bin/../lib/clang/3.0/include /usr/include/w32api /usr/include End of search list. invalid.cpp:3:24: error: C++ requires a type specifier for all declarations template f(T1 a) { ^ invalid.cpp:4:3: error: use of undeclared identifier 'n2' n2::f<_> template<> s() { ^ invalid.cpp:4:9: error: use of undeclared identifier '_' n2::f<_> template<> s() { ^ assertion "getCurFunctionDecl() == 0 && "Function parsing confused"" failed: file "SemaTemplate.cpp", line 5114, function: clang::Decl* clang::Sema::ActOnStartOfFunctionTemplateDef(clang::Scope*, clang::MultiTemplateParamsArg, clang::Declarator&) Stack dump: 0. Program arguments: /opt/llvm-r136052/bin/clang -cc1 -triple i386-pc-cygwin -fsyntax-only -disable-free -main-file-name invalid.cpp -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.20.51.20100410 -momit-leaf-frame-pointer -v -resource-dir /opt/llvm-r136052/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 80 -fno-use-cxa-atexit -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -x c++ invalid.cpp 1. invalid.cpp:4:27: current parser token '{' 2. invalid.cpp:2:1: parsing namespace 'n1' 3. invalid.cpp:3:32: parsing function body 'f' 4. invalid.cpp:3:32: in compound statement ('{}') clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 03:43:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 03:43:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 6988] [analyzer++] Calling template function makes assertion "!asLValue" fail In-Reply-To: References: Message-ID: <20110726084321.A71E42A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6988 Magnus Reftel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Magnus Reftel 2011-07-26 03:43:20 CDT --- This is now working since at least version 127028. 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 Jul 26 03:52:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 03:52:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 10488] New: Assert failure in eliminateFrameIndex at -O0 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10488 Summary: Assert failure in eliminateFrameIndex at -O0 Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6936) --> (http://llvm.org/bugs/attachment.cgi?id=6936) testcase .ll $ llc -O0 20031023-4.ll llc: llvm/lib/Target/X86/X86RegisterInfo.cpp:614: virtual void llvm::X86RegisterInfo::eliminateFrameIndex(llvm::MachineBasicBlock::iterator, int, llvm::RegScavenger*) const: Assertion `(!Is64Bit || isInt<32>((long long)FIOffset + Imm)) && "Requesting 64-bit offset in 32-bit immediate!"' 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 Jul 26 04:04:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 04:04:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10489] New: [AVX] "cannot select" v8i32 = X86ISD::PALIGN error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10489 Summary: [AVX] "cannot select" v8i32 = X86ISD::PALIGN error Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6937) --> (http://llvm.org/bugs/attachment.cgi?id=6937) test case With top-of-tree, if you run: % llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx The following error is generated: LLVM ERROR: Cannot select: 0x7fd481043610: v8i32 = X86ISD::PALIGN 0x7fd481039110, 0x7fd481033210, 0x7fd481043510 [ID=83] 0x7fd481039110: v8i32 = insert_subvector 0x7fd481039010, 0x7fd481043410, 0x7fd481033a10 [ID=82] 0x7fd481039010: v8i32 = insert_subvector 0x7fd481033210, 0x7fd481039b10, 0x7fd481033610 [ID=81] 0x7fd481033210: v8i32 = undef [ORD=5] [ID=4] 0x7fd481039b10: v4i32 = X86ISD::PUNPCKLDQ 0x7fd481039910, 0x7fd481039a10 [ID=80] 0x7fd481039910: v4i32 = X86ISD::PUNPCKLDQ 0x7fd481039210, 0x7fd481039410 [ID=77] 0x7fd481039210: v4i32 = scalar_to_vector 0x7fd48103bc10 [ID=65] 0x7fd48103bc10: i32 = add 0x7fd48103ff10, 0x7fd48103e510 [ID=57] 0x7fd48103ff10: i32 = extract_vector_elt 0x7fd48103f410, 0x7fd481033d10 [ID=43] 0x7fd48103f410: v4i32 = extract_subvector 0x7fd48103f310, 0x7fd481033610 [ID=30] 0x7fd48103f310: v8i32 = X86ISD::PALIGN 0x7fd48103ab10, 0x7fd481033210, 0x7fd48103f210 [ID=26] 0x7fd481033610: i32 = Constant<4> [ORD=4] [ID=3] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd48103e510: i32 = extract_vector_elt 0x7fd481038b10, 0x7fd481033d10 [ID=35] 0x7fd481038b10: v4i32 = extract_subvector 0x7fd48103ab10, 0x7fd481033610 [ID=28] 0x7fd48103ab10: v8i32 = bitcast 0x7fd48103aa10 [ID=25] 0x7fd481033610: i32 = Constant<4> [ORD=4] [ID=3] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd481039410: v4i32 = scalar_to_vector 0x7fd48103cd10 [ID=73] 0x7fd48103cd10: i32 = add 0x7fd48103fa10, 0x7fd48103e110 [ID=67] 0x7fd48103fa10: i32 = extract_vector_elt 0x7fd48103f910, 0x7fd481033d10 [ID=59] 0x7fd48103f910: v4i32 = vector_shuffle 0x7fd48103f410, 0x7fd48103dc10<2,u,u,u> [ID=45] 0x7fd48103f410: v4i32 = extract_subvector 0x7fd48103f310, 0x7fd481033610 [ID=30] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd48103e110: i32 = extract_vector_elt 0x7fd48103e010, 0x7fd481033d10 [ID=51] 0x7fd48103e010: v4i32 = vector_shuffle 0x7fd481038b10, 0x7fd48103dc10<2,u,u,u> [ID=37] 0x7fd481038b10: v4i32 = extract_subvector 0x7fd48103ab10, 0x7fd481033610 [ID=28] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd481039a10: v4i32 = X86ISD::PUNPCKLDQ 0x7fd481039310, 0x7fd481039510 [ID=78] 0x7fd481039310: v4i32 = scalar_to_vector 0x7fd48103c010 [ID=72] 0x7fd48103c010: i32 = add 0x7fd48103fe10, 0x7fd48103e410 [ID=66] 0x7fd48103fe10: i32 = extract_vector_elt 0x7fd48103fd10, 0x7fd481033d10 [ID=58] 0x7fd48103fd10: v4i32 = vector_shuffle 0x7fd48103f410, 0x7fd48103dc10<1,u,u,u> [ID=44] 0x7fd48103f410: v4i32 = extract_subvector 0x7fd48103f310, 0x7fd481033610 [ID=30] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd48103e410: i32 = extract_vector_elt 0x7fd48103e310, 0x7fd481033d10 [ID=50] 0x7fd48103e310: v4i32 = vector_shuffle 0x7fd481038b10, 0x7fd48103dc10<1,u,u,u> [ID=36] 0x7fd481038b10: v4i32 = extract_subvector 0x7fd48103ab10, 0x7fd481033610 [ID=28] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd481039510: v4i32 = scalar_to_vector 0x7fd48103d110 [ID=74] 0x7fd48103d110: i32 = add 0x7fd48103f710, 0x7fd48103de10 [ID=68] 0x7fd48103f710: i32 = extract_vector_elt 0x7fd48103f610, 0x7fd481033d10 [ID=60] 0x7fd48103f610: v4i32 = vector_shuffle 0x7fd48103f410, 0x7fd48103dc10<3,u,u,u> [ID=46] 0x7fd48103f410: v4i32 = extract_subvector 0x7fd48103f310, 0x7fd481033610 [ID=30] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd48103de10: i32 = extract_vector_elt 0x7fd48103dd10, 0x7fd481033d10 [ID=52] 0x7fd48103dd10: v4i32 = vector_shuffle 0x7fd481038b10, 0x7fd48103dc10<3,u,u,u> [ID=38] 0x7fd481038b10: v4i32 = extract_subvector 0x7fd48103ab10, 0x7fd481033610 [ID=28] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd481033610: i32 = Constant<4> [ORD=4] [ID=3] 0x7fd481043410: v4i32 = X86ISD::PUNPCKLDQ 0x7fd481043210, 0x7fd481043310 [ID=79] 0x7fd481043210: v4i32 = X86ISD::PUNPCKLDQ 0x7fd481039c10, 0x7fd481042d10 [ID=75] 0x7fd481039c10: v4i32 = scalar_to_vector 0x7fd48103a610 [ID=61] 0x7fd48103a610: i32 = add 0x7fd481040a10, 0x7fd48103f110 [ID=53] 0x7fd481040a10: i32 = extract_vector_elt 0x7fd481040010, 0x7fd481033d10 [ID=39] 0x7fd481040010: v4i32 = extract_subvector 0x7fd48103f310, 0x7fd481033a10 [ID=29] 0x7fd48103f310: v8i32 = X86ISD::PALIGN 0x7fd48103ab10, 0x7fd481033210, 0x7fd48103f210 [ID=26] 0x7fd48103ab10: v8i32 = bitcast 0x7fd48103aa10 [ID=25] 0x7fd481033210: v8i32 = undef [ORD=5] [ID=4] 0x7fd48103f210: i8 = Constant<16> [ID=13] 0x7fd481033a10: i32 = Constant<0> [ORD=4] [ID=2] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd48103f110: i32 = extract_vector_elt 0x7fd48103e610, 0x7fd481033d10 [ID=31] 0x7fd48103e610: v4i32 = extract_subvector 0x7fd48103ab10, 0x7fd481033a10 [ID=27] 0x7fd48103ab10: v8i32 = bitcast 0x7fd48103aa10 [ID=25] 0x7fd48103aa10: v4i64 = and 0x7fd48103b510, 0x7fd481038910 [ID=24] 0x7fd481033a10: i32 = Constant<0> [ORD=4] [ID=2] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd481042d10: v4i32 = scalar_to_vector 0x7fd481035e10 [ID=70] 0x7fd481035e10: i32 = add 0x7fd481040610, 0x7fd48103ed10 [ID=63] 0x7fd481040610: i32 = extract_vector_elt 0x7fd481040510, 0x7fd481033d10 [ID=55] 0x7fd481040510: v4i32 = vector_shuffle 0x7fd481040010, 0x7fd48103dc10<2,u,u,u> [ID=41] 0x7fd481040010: v4i32 = extract_subvector 0x7fd48103f310, 0x7fd481033a10 [ID=29] 0x7fd48103f310: v8i32 = X86ISD::PALIGN 0x7fd48103ab10, 0x7fd481033210, 0x7fd48103f210 [ID=26] 0x7fd481033a10: i32 = Constant<0> [ORD=4] [ID=2] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd48103ed10: i32 = extract_vector_elt 0x7fd48103ec10, 0x7fd481033d10 [ID=48] 0x7fd48103ec10: v4i32 = vector_shuffle 0x7fd48103e610, 0x7fd48103dc10<2,u,u,u> [ID=33] 0x7fd48103e610: v4i32 = extract_subvector 0x7fd48103ab10, 0x7fd481033a10 [ID=27] 0x7fd48103ab10: v8i32 = bitcast 0x7fd48103aa10 [ID=25] 0x7fd481033a10: i32 = Constant<0> [ORD=4] [ID=2] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd481043310: v4i32 = X86ISD::PUNPCKLDQ 0x7fd481042c10, 0x7fd481042e10 [ID=76] 0x7fd481042c10: v4i32 = scalar_to_vector 0x7fd48103a510 [ID=69] 0x7fd48103a510: i32 = add 0x7fd481040910, 0x7fd48103f010 [ID=62] 0x7fd481040910: i32 = extract_vector_elt 0x7fd481040810, 0x7fd481033d10 [ID=54] 0x7fd481040810: v4i32 = vector_shuffle 0x7fd481040010, 0x7fd48103dc10<1,u,u,u> [ID=40] 0x7fd481040010: v4i32 = extract_subvector 0x7fd48103f310, 0x7fd481033a10 [ID=29] 0x7fd48103f310: v8i32 = X86ISD::PALIGN 0x7fd48103ab10, 0x7fd481033210, 0x7fd48103f210 [ID=26] 0x7fd481033a10: i32 = Constant<0> [ORD=4] [ID=2] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd48103f010: i32 = extract_vector_elt 0x7fd48103ef10, 0x7fd481033d10 [ID=47] 0x7fd48103ef10: v4i32 = vector_shuffle 0x7fd48103e610, 0x7fd48103dc10<1,u,u,u> [ID=32] 0x7fd48103e610: v4i32 = extract_subvector 0x7fd48103ab10, 0x7fd481033a10 [ID=27] 0x7fd48103ab10: v8i32 = bitcast 0x7fd48103aa10 [ID=25] 0x7fd481033a10: i32 = Constant<0> [ORD=4] [ID=2] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd481042e10: v4i32 = scalar_to_vector 0x7fd48103b810 [ID=71] 0x7fd48103b810: i32 = add 0x7fd481040310, 0x7fd48103e910 [ID=64] 0x7fd481040310: i32 = extract_vector_elt 0x7fd481040210, 0x7fd481033d10 [ID=56] 0x7fd481040210: v4i32 = vector_shuffle 0x7fd481040010, 0x7fd48103dc10<3,u,u,u> [ID=42] 0x7fd481040010: v4i32 = extract_subvector 0x7fd48103f310, 0x7fd481033a10 [ID=29] 0x7fd48103f310: v8i32 = X86ISD::PALIGN 0x7fd48103ab10, 0x7fd481033210, 0x7fd48103f210 [ID=26] 0x7fd481033a10: i32 = Constant<0> [ORD=4] [ID=2] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd48103e910: i32 = extract_vector_elt 0x7fd48103e810, 0x7fd481033d10 [ID=49] 0x7fd48103e810: v4i32 = vector_shuffle 0x7fd48103e610, 0x7fd48103dc10<3,u,u,u> [ID=34] 0x7fd48103e610: v4i32 = extract_subvector 0x7fd48103ab10, 0x7fd481033a10 [ID=27] 0x7fd48103ab10: v8i32 = bitcast 0x7fd48103aa10 [ID=25] 0x7fd481033a10: i32 = Constant<0> [ORD=4] [ID=2] 0x7fd48103dc10: v4i32 = undef [ID=12] 0x7fd481033d10: i64 = Constant<0> [ORD=9] [ID=5] 0x7fd481033a10: i32 = Constant<0> [ORD=4] [ID=2] 0x7fd481033210: v8i32 = undef [ORD=5] [ID=4] 0x7fd481043510: i8 = Constant<8> [ID=14] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 04:10:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 04:10:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10490] New: [AVX] Unknown type for unpckh / UNREACHABLE executed at X86ISelLowering.cpp:5756! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10490 Summary: [AVX] Unknown type for unpckh / UNREACHABLE executed at X86ISelLowering.cpp:5756! Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6938) --> (http://llvm.org/bugs/attachment.cgi?id=6938) test case With top of tree and the attached test case, if I run: % llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx I get the following crash: Unknown type for unpckh UNREACHABLE executed at X86ISelLowering.cpp:5756! 0 llc 0x000000010f5b2882 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6542 1 llc 0x000000010f5b2e89 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 8085 2 libsystem_c.dylib 0x00007fff8a2a9cfa _sigtramp + 26 3 libsystem_c.dylib 000000000000000000 _sigtramp + 18446603338198115104 4 llc 0x000000010f5b27e6 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6386 5 llc 0x000000010f5a33c9 std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique(std::_Rb_tree_iterator >, std::pair const&) + 1707 6 llc 0x000000010f01fce9 llvm::X86Subtarget::isTargetELF() const + 291841 7 llc 0x000000010efec917 llvm::X86Subtarget::isTargetELF() const + 81967 8 llc 0x000000010f0b7e7a llvm::DenseMap, llvm::DenseMapInfo >::insert(std::pair const&) + 26290 9 llc 0x000000010f0b19b1 llvm::DenseMap, llvm::DenseMapInfo >::insert(std::pair const&) + 489 10 llc 0x000000010f1bf881 llvm::SelectionDAGBuilder::Case::size() const + 34781 11 llc 0x000000010f1c1512 llvm::SelectionDAGBuilder::Case::size() const + 42094 12 llc 0x000000010f1c216b llvm::SelectionDAGBuilder::Case::size() const + 45255 13 llc 0x000000010f29f6d4 llvm::MachineFunctionAnalysis::getPassName() const + 458 14 llc 0x000000010f51941d llvm::cl::parser::~parser() + 26339 15 llc 0x000000010f514e0b llvm::cl::parser::~parser() + 8401 16 llc 0x000000010f51911a llvm::cl::parser::~parser() + 25568 17 llc 0x000000010f51a541 llvm::cl::parser::~parser() + 30727 18 llc 0x000000010f51a5c1 llvm::cl::parser::~parser() + 30855 19 llc 0x000000010eca33d3 20 llc 0x000000010eca1c34 Stack dump: 0. Program arguments: llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx 1. Running pass 'Function Pass Manager' on module 'bug.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"f_f___REFUf[]REFUf[]"' [1] 12060 illegal hardware instruction llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 04:14:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 04:14:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10491] New: [AVX] "cannot select" v8i32 = BUILD_VECTOR error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10491 Summary: [AVX] "cannot select" v8i32 = BUILD_VECTOR error Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6939) --> (http://llvm.org/bugs/attachment.cgi?id=6939) test case With top of tree, if I run: % llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx With the attached test program, I get the following crash: LLVM ERROR: Cannot select: 0x7f8164034310: v8i32 = BUILD_VECTOR 0x7f8164034210, 0x7f8164034210, 0x7f8164034210, 0x7f8164034210, 0x7f8164034210, 0x7f8164034210, 0x7f8164034210, 0x7f8164034210 [ID=10] 0x7f8164034210: i32 = Constant<0> [ID=4] 0x7f8164034210: i32 = Constant<0> [ID=4] 0x7f8164034210: i32 = Constant<0> [ID=4] 0x7f8164034210: i32 = Constant<0> [ID=4] 0x7f8164034210: i32 = Constant<0> [ID=4] 0x7f8164034210: i32 = Constant<0> [ID=4] 0x7f8164034210: i32 = Constant<0> [ID=4] 0x7f8164034210: i32 = Constant<0> [ID=4] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 04:21:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 04:21:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10492] New: [AVX] Assertion failed: ((VT == MVT::v4i32 || VT == MVT::v4f32) && "unsupported shuffle type"), Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10492 Summary: [AVX] Assertion failed: ((VT == MVT::v4i32 || VT == MVT::v4f32) && "unsupported shuffle type"), Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6940) --> (http://llvm.org/bugs/attachment.cgi?id=6940) test case With the attached, if I run: % llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx I get the following: Assertion failed: ((VT == MVT::v4i32 || VT == MVT::v4f32) && "unsupported shuffle type"), function getMOVHighToLow, file X86ISelLowering.cpp, line 5665. 0 llc 0x0000000101757343 _ZL15PrintStackTracePv + 51 1 llc 0x000000010175789d _ZL13SignalHandleri + 333 2 libsystem_c.dylib 0x00007fff8a2a9cfa _sigtramp + 26 3 libsystem_c.dylib 0x00007fff60434978 _sigtramp + 18446744073006525592 4 llc 0x000000010175720f raise + 31 5 llc 0x0000000101757240 abort + 16 6 llc 0x000000010175730d __assert_rtn + 189 7 llc 0x0000000100dae616 _ZL15getMOVHighToLowRN4llvm7SDValueERNS_8DebugLocERNS_12SelectionDAGE + 310 8 llc 0x0000000100deb3ec llvm::X86TargetLowering::LowerVECTOR_SHUFFLE(llvm::SDValue, llvm::SelectionDAG&) const + 1578 9 llc 0x0000000100d9bcc2 llvm::X86TargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&) const + 574 10 llc 0x0000000100ef3129 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 4841 11 llc 0x0000000100f09371 (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG() + 225 12 llc 0x0000000100ee2268 llvm::SelectionDAG::Legalize() + 56 13 llc 0x000000010102f851 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 3703 14 llc 0x000000010103229f llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 281 15 llc 0x0000000101032feb llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3397 16 llc 0x000000010103373e llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1060 17 llc 0x00000001011d8eae llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 104 18 llc 0x0000000101642727 llvm::FPPassManager::runOnFunction(llvm::Function&) + 421 19 llc 0x000000010163cf77 llvm::FPPassManager::runOnModule(llvm::Module&) + 121 20 llc 0x0000000101642258 llvm::MPPassManager::runOnModule(llvm::Module&) + 616 21 llc 0x000000010164367f llvm::PassManagerImpl::run(llvm::Module&) + 155 22 llc 0x0000000101643725 llvm::PassManager::run(llvm::Module&) + 39 23 llc 0x000000010083ceb3 main + 3763 24 llc 0x000000010083b434 start + 52 Stack dump: 0. Program arguments: llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx 1. Running pass 'Function Pass Manager' on module 'bug.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"f_fu___REFUf[]REFUf[]Uf"' [1] 15549 illegal hardware instruction llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 04:23:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 04:23:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10493] New: [AVX] "cannot select" v8f32 = X86ISD::VZEXT_MOVL error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10493 Summary: [AVX] "cannot select" v8f32 = X86ISD::VZEXT_MOVL error Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6941) --> (http://llvm.org/bugs/attachment.cgi?id=6941) test case WIth the attached test case, if I run: % llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx I get the following crash: LLVM ERROR: Cannot select: 0x7fe7fb043610: v8f32 = X86ISD::VZEXT_MOVL 0x7fe7fb043510 [ID=38] 0x7fe7fb043510: v8f32 = insert_subvector 0x7fe7fb043410, 0x7fe7fb043310, 0x7fe7fb036610 [ID=37] 0x7fe7fb043410: v8f32 = undef [ID=15] 0x7fe7fb043310: v4f32 = scalar_to_vector 0x7fe7fb03fb10 [ID=36] 0x7fe7fb03fb10: f32,ch = load 0x107010cf8, 0x7fe7fb042d10, 0x7fe7fb03fc10 [ID=35] 0x7fe7fb042d10: i64 = X86ISD::WrapperRIP 0x7fe7fb03ff10 [ID=32] 0x7fe7fb03ff10: i64 = TargetConstantPool 0 [ID=13] 0x7fe7fb03fc10: i64 = undef [ID=12] 0x7fe7fb036610: i32 = Constant<0> [ORD=14] [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 Tue Jul 26 04:25:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 04:25:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10494] New: [AVX] (Result.getValueType() == Op.getValueType() && "Bad legalization!") assert hits Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10494 Summary: [AVX] (Result.getValueType() == Op.getValueType() && "Bad legalization!") assert hits Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6942) --> (http://llvm.org/bugs/attachment.cgi?id=6942) test case With the attached, if I run: % llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx I get the following crash: Assertion failed: (Result.getValueType() == Op.getValueType() && "Bad legalization!"), function LegalizeOp, file LegalizeDAG.cpp, line 1705. 0 llc 0x0000000105b13343 _ZL15PrintStackTracePv + 51 1 llc 0x0000000105b1389d _ZL13SignalHandleri + 333 2 libsystem_c.dylib 0x00007fff8a2a9cfa _sigtramp + 26 3 libsystem_c.dylib 0x00007fff647f12a8 _sigtramp + 18446744073077552584 4 llc 0x0000000105b1320f raise + 31 5 llc 0x0000000105b13240 abort + 16 6 llc 0x0000000105b1330d __assert_rtn + 189 7 llc 0x00000001052b7428 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 38376 8 llc 0x00000001052c5371 (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG() + 225 9 llc 0x000000010529e268 llvm::SelectionDAG::Legalize() + 56 10 llc 0x00000001053eb851 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 3703 11 llc 0x00000001053ee29f llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 281 12 llc 0x00000001053eefeb llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3397 13 llc 0x00000001053ef73e llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1060 14 llc 0x0000000105594eae llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 104 15 llc 0x00000001059fe727 llvm::FPPassManager::runOnFunction(llvm::Function&) + 421 16 llc 0x00000001059f8f77 llvm::FPPassManager::runOnModule(llvm::Module&) + 121 17 llc 0x00000001059fe258 llvm::MPPassManager::runOnModule(llvm::Module&) + 616 18 llc 0x00000001059ff67f llvm::PassManagerImpl::run(llvm::Module&) + 155 19 llc 0x00000001059ff725 llvm::PassManager::run(llvm::Module&) + 39 20 llc 0x0000000104bf8eb3 main + 3763 21 llc 0x0000000104bf7434 start + 52 Stack dump: 0. Program arguments: llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx 1. Running pass 'Function Pass Manager' on module 'bug.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"f_fu___REFUf[]REFUf[]Uf"' [1] 15591 illegal hardware instruction llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 04:28:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 04:28:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10495] New: [AVX] "cannot select" ch = store error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10495 Summary: [AVX] "cannot select" ch = store error Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6943) --> (http://llvm.org/bugs/attachment.cgi?id=6943) test case With the attached test case, if I run: % llc bug.ll -o /dev/null -mcpu=corei7-avx -mattr=+avx I get the following crash: LLVM ERROR: Cannot select: 0x7fe093036110: ch = store 0x104b0e6f8, 0x7fe093035410, 0x7fe093038110, 0x7fe093037510 [ID=29] 0x7fe093035410: v4f64 = bitcast 0x7fe093035d10 [ID=28] 0x7fe093035d10: v4i64 = insert_subvector 0x7fe093036210, 0x7fe093035b10, 0x7fe093037d10 [ID=27] 0x7fe093036210: v4i64 = insert_subvector 0x7fe093037710, 0x7fe093035b10, 0x7fe093035a10 [ID=26] 0x7fe093037710: v4i64 = undef [ID=8] 0x7fe093035b10: v2i64 = X86ISD::MOVLHPS 0x7fe093037c10, 0x7fe093037c10 [ID=25] 0x7fe093037c10: v2i64 = scalar_to_vector 0x7fe093037910 [ID=24] 0x7fe093037910: i64,ch = load 0x104b0e6f8, 0x7fe093035810, 0x7fe093037510 [ORD=20] [ID=23] 0x7fe093035810: i64 = add 0x7fe093036010, 0x7fe093038010 [ORD=18] [ID=22] 0x7fe093036010: i64 = FrameIndex<0> [ORD=15] [ID=2] 0x7fe093038010: i64 = sign_extend 0x7fe093038f10 [ORD=17] [ID=21] 0x7fe093038f10: i32 = shl 0x7fe093037610, 0x7fe093039010 [ORD=16] [ID=20] 0x7fe093037510: i64 = undef [ORD=20] [ID=5] 0x7fe093037c10: v2i64 = scalar_to_vector 0x7fe093037910 [ID=24] 0x7fe093037910: i64,ch = load 0x104b0e6f8, 0x7fe093035810, 0x7fe093037510 [ORD=20] [ID=23] 0x7fe093035810: i64 = add 0x7fe093036010, 0x7fe093038010 [ORD=18] [ID=22] 0x7fe093036010: i64 = FrameIndex<0> [ORD=15] [ID=2] 0x7fe093038010: i64 = sign_extend 0x7fe093038f10 [ORD=17] [ID=21] 0x7fe093038f10: i32 = shl 0x7fe093037610, 0x7fe093039010 [ORD=16] [ID=20] 0x7fe093037510: i64 = undef [ORD=20] [ID=5] 0x7fe093035a10: i32 = Constant<0> [ID=9] 0x7fe093035b10: v2i64 = X86ISD::MOVLHPS 0x7fe093037c10, 0x7fe093037c10 [ID=25] 0x7fe093037c10: v2i64 = scalar_to_vector 0x7fe093037910 [ID=24] 0x7fe093037910: i64,ch = load 0x104b0e6f8, 0x7fe093035810, 0x7fe093037510 [ORD=20] [ID=23] 0x7fe093035810: i64 = add 0x7fe093036010, 0x7fe093038010 [ORD=18] [ID=22] 0x7fe093036010: i64 = FrameIndex<0> [ORD=15] [ID=2] 0x7fe093038010: i64 = sign_extend 0x7fe093038f10 [ORD=17] [ID=21] 0x7fe093038f10: i32 = shl 0x7fe093037610, 0x7fe093039010 [ORD=16] [ID=20] 0x7fe093037610: i32 = fp_to_sint 0x7fe093035710 [ORD=14] [ID=19] 0x7fe093039010: i8 = Constant<3> [ORD=16] [ID=3] 0x7fe093037510: i64 = undef [ORD=20] [ID=5] 0x7fe093037c10: v2i64 = scalar_to_vector 0x7fe093037910 [ID=24] 0x7fe093037910: i64,ch = load 0x104b0e6f8, 0x7fe093035810, 0x7fe093037510 [ORD=20] [ID=23] 0x7fe093035810: i64 = add 0x7fe093036010, 0x7fe093038010 [ORD=18] [ID=22] 0x7fe093036010: i64 = FrameIndex<0> [ORD=15] [ID=2] 0x7fe093038010: i64 = sign_extend 0x7fe093038f10 [ORD=17] [ID=21] 0x7fe093038f10: i32 = shl 0x7fe093037610, 0x7fe093039010 [ORD=16] [ID=20] 0x7fe093037610: i32 = fp_to_sint 0x7fe093035710 [ORD=14] [ID=19] 0x7fe093039010: i8 = Constant<3> [ORD=16] [ID=3] 0x7fe093037510: i64 = undef [ORD=20] [ID=5] 0x7fe093037d10: i32 = Constant<2> [ID=10] 0x7fe093038110: i64 = FrameIndex<2> [ID=13] 0x7fe093037510: i64 = undef [ORD=20] [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 Tue Jul 26 05:34:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 05:34:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10496] New: [AVX] missing intrinsics for integer min/max instructions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10496 Summary: [AVX] missing intrinsics for integer min/max instructions Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu AVX has instructions for {signed,unsigned} x {byte,word,dword} x {min,max} of AVX registers. (VPMINUB, VPMAXSD, etc, etc.) It looks like these aren't yet supported in 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 Tue Jul 26 06:04:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 06:04:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10497] New: SplitVecRes_BITCAST(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&): Assertion `false && "Unknown type action!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10497 Summary: SplitVecRes_BITCAST(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&): Assertion `false && "Unknown type action!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: LegalizeVectorTypes.cpp:528: void llvm::DAGTypeLegalizer::SplitVecRes_BITCAST(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&): Assertion `false && "Unknown type action!"' failed. 0 llc 0x000000000153ffea 1 llc 0x0000000001540578 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x000000000106d920 7 llc 0x000000000106e018 8 llc 0x0000000001055fb3 9 llc 0x000000000105692e llvm::SelectionDAG::LegalizeTypes() + 50 10 llc 0x0000000000ff6bc5 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1025 11 llc 0x0000000000ff8ea2 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 12 llc 0x0000000000ff9804 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 13 llc 0x0000000000ff9d83 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 14 llc 0x00000000011449ad llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 15 llc 0x000000000147a2bb llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 16 llc 0x000000000147a4b3 llvm::FPPassManager::runOnModule(llvm::Module&) + 81 17 llc 0x0000000001479f67 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 18 llc 0x000000000147b71c llvm::PassManagerImpl::run(llvm::Module&) + 116 19 llc 0x000000000147b77f llvm::PassManager::run(llvm::Module&) + 33 20 llc 0x0000000000ab642d main + 2403 21 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 22 llc 0x0000000000ab4b79 Stack dump: 0. Program arguments: ../llc temp.ll -march=x86-64 -mattr=-sse2,-sse41 -o /dev/null 1. Running pass 'Function Pass Manager' on module 'temp.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_7481_500' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_7481_500(i8*, i32*, i64*, i32, i8, i64) { BB: %A4 = alloca <2 x i8> %A3 = alloca <2 x i8> %A2 = alloca <2 x i64> %A1 = alloca <2 x double> %A = alloca <2 x float> %L = load <2 x float>* %A store i8 -21, i8* %0 %E = extractelement <2 x float> %L, i32 1 %E5 = extractelement <2 x float> %L, i32 1 %Shuff = shufflevector <2 x float> %L, <2 x float> %L, <2 x i32> %Shuff6 = shufflevector <2 x float> %L, <2 x float> %L, <2 x i32> %Shuff7 = shufflevector <2 x float> %L, <2 x float> %L, <2 x i32> %I = insertelement <2 x float> %L, float 0x3ED3791500000000, i32 0 %B = xor i32 88291, %3 %PC = bitcast i64* %2 to double* %S = fcmp uge float 0x3EE822F4A0000000, %E br label %CF38 CF38: ; preds = %BB %L8 = load double* %PC store double 0x3EC023576544245A, double* %PC %E9 = extractelement <2 x float> %L, i32 1 %E10 = extractelement <2 x float> %L, i32 1 %Shuff11 = shufflevector <2 x float> %L, <2 x float> %L, <2 x i32> %Shuff12 = shufflevector <2 x float> %I, <2 x float> %L, <2 x i32> %Shuff13 = shufflevector <2 x float> %L, <2 x float> %L, <2 x i32> %I14 = insertelement <2 x float> %L, float 0x3ECF95EC40000000, i32 0 %B15 = mul i32 %B, %3 %BC = bitcast <2 x float> %I14 to <2 x i32> %S16 = select i1 %S, <2 x i8>* %A4, <2 x i8>* %A3 %S17 = icmp ugt i32 382619, 417923 br label %CF CF: ; preds = %CF, %CF38 %L18 = load double* %PC store double %L8, double* %PC %E19 = extractelement <2 x float> %L, i32 0 %E20 = extractelement <2 x float> %L, i32 0 %Shuff21 = shufflevector <2 x float> %Shuff13, <2 x float> %L, <2 x i32> %Shuff22 = shufflevector <2 x float> %Shuff11, <2 x float> %L, <2 x i32> %Shuff23 = shufflevector <2 x float> %L, <2 x float> %L, <2 x i32> %I24 = insertelement <2 x float> %L, float 0x3EC3F52D00000000, i32 1 %B25 = urem i64 227191, 98955 %S26 = select i1 %S17, double 0x3EC1189738F421D8, double 0x3EC1189738F421D8 %S27 = fcmp ogt float 0x3EC3F52D00000000, %E br i1 %S27, label %CF, label %CF39 CF39: ; preds = %CF39, %CF %L28 = load i8* %0 store double %S26, double* %PC %E29 = extractelement <2 x float> %L, i32 0 %E30 = extractelement <2 x float> %L, i32 0 %Shuff31 = shufflevector <2 x float> %L, <2 x float> %Shuff23, <2 x i32> %Shuff32 = shufflevector <2 x float> %L, <2 x float> %Shuff22, <2 x i32> %Shuff33 = shufflevector <2 x float> %L, <2 x float> %L, <2 x i32> %I34 = insertelement <2 x float> %L, float %E19, i32 1 %B35 = or <2 x i32> %BC, %BC %BC36 = bitcast i64 -1 to double %S37 = icmp sgt i8 %4, -109 br i1 %S37, label %CF39, label %CF40 CF40: ; preds = %CF39 store double %L18, double* %PC store <2 x float> %L, <2 x float>* %A store double 0x3EDF0A2AF8AB8D52, double* %PC store <2 x i8> undef, <2 x i8>* %A4 store i8 %4, i8* %0 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 Tue Jul 26 06:05:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 06:05:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10498] New: unsigned int getFPReg(const llvm::MachineOperand&): Assertion `Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"' fa Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10498 Summary: unsigned int getFPReg(const llvm::MachineOperand&): Assertion `Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"' fa Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: X86FloatingPoint.cpp:316: unsigned int getFPReg(const llvm::MachineOperand&): Assertion `Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"' failed. 0 llc 0x000000000153ffea 1 llc 0x0000000001540578 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000000e542c8 7 llc 0x0000000000e5606a (anonymous namespace)::FPS::handleSpecialFP(llvm::ilist_iterator&) + 1412 8 llc 0x0000000000e57f27 (anonymous namespace)::FPS::processBasicBlock(llvm::MachineFunction&, llvm::MachineBasicBlock&) + 885 9 llc 0x0000000000e58459 (anonymous namespace)::FPS::runOnMachineFunction(llvm::MachineFunction&) + 341 10 llc 0x00000000011449ad llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 11 llc 0x000000000147a2bb llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 12 llc 0x000000000147a4b3 llvm::FPPassManager::runOnModule(llvm::Module&) + 81 13 llc 0x0000000001479f67 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 14 llc 0x000000000147b71c llvm::PassManagerImpl::run(llvm::Module&) + 116 15 llc 0x000000000147b77f llvm::PassManager::run(llvm::Module&) + 33 16 llc 0x0000000000ab642d main + 2403 17 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 18 llc 0x0000000000ab4b79 Stack dump: 0. Program arguments: ../llc temp.ll -march=x86-64 -mattr=-sse2,-sse41 -o /dev/null 1. Running pass 'Function Pass Manager' on module 'temp.ll'. 2. Running pass 'X86 FP Stackifier' on function '@autogen_9448_500' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_9448_500(i8*, i32*, i64*, i32, i8, i64) { BB: %A4 = alloca <8 x i64> %A3 = alloca <8 x i8> %A2 = alloca <8 x i8> %A1 = alloca <8 x i32> %A = alloca <8 x double> %L = load i8* %0 store i8 -89, i8* %0 %E = extractelement <8 x i32> undef, i32 7 %E5 = extractelement <32 x float> undef, i32 12 %Shuff = shufflevector <8 x double> undef, <8 x double> undef, <8 x i32> %Shuff6 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff7 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %I = insertelement <8 x double> %Shuff, double 0x3EC3137F3F602019, i32 0 %B = mul i8 %L, -1 %FC = fptosi double 0x3EC3137F3F602019 to i16 %S = select i1 true, i16 %FC, i16 %FC %S8 = fcmp olt float %E5, 0x3EC6F41020000000 br label %CF42 CF42: ; preds = %BB %L9 = load i8* %0 store i8 %L, i8* %0 %E10 = extractelement <8 x double> %Shuff, i32 6 %E11 = extractelement <8 x double> %Shuff, i32 0 %Shuff12 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff13 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff14 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff13, <8 x i32> %I15 = insertelement <8 x double> %Shuff12, double 0x3ED4B999595A3E38, i32 1 %B16 = frem <8 x double> %Shuff13, %Shuff %BC = bitcast float 0x3ECCE7D580000000 to i32 %S17 = select i1 true, i64 -1, i64 %5 %S18 = icmp ule i64 508019, %S17 br label %CF41 CF41: ; preds = %CF41, %CF42 %L19 = load i8* %0 store i8 -1, i8* %0 %E20 = extractelement <8 x double> %Shuff, i32 1 %E21 = extractelement <8 x double> %Shuff, i32 3 %Shuff22 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff23 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff24 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff12, <8 x i32> %I25 = insertelement <8 x double> %Shuff, double %E10, i32 4 %B26 = fdiv <8 x double> %B16, %Shuff %FC27 = sitofp i32 338935 to float %S28 = select i1 false, i32* %1, i32* %1 %S29 = icmp slt i8 -1, %B br i1 %S29, label %CF41, label %CF43 CF43: ; preds = %CF41 %L30 = load i32* %S28 store i32 413419, i32* %S28 %E31 = extractelement <8 x double> %Shuff6, i32 2 %E32 = extractelement <8 x double> %Shuff, i32 4 %Shuff33 = shufflevector <8 x double> %Shuff12, <8 x double> %Shuff, <8 x i32> %Shuff34 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %Shuff35 = shufflevector <8 x double> %Shuff, <8 x double> %Shuff, <8 x i32> %I36 = insertelement <8 x double> %Shuff, double %E10, i32 5 %B37 = fadd <8 x double> %Shuff14, %Shuff %FC38 = uitofp i8 -89 to double %S39 = select i1 true, <8 x double>* %A, <8 x double>* %A %S40 = icmp slt i32 413419, 0 br label %CF CF: ; preds = %CF43 store <8 x double> %Shuff12, <8 x double>* %A store i32 %3, i32* %S28 store i32 %3, i32* %S28 store <8 x double> %Shuff, <8 x double>* %A store <8 x double> %Shuff33, <8 x double>* %S39 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 Tue Jul 26 06:06:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 06:06:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10499] New: llvm::SDValue::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `(TLI.getTypeAction(*DAG.getContext(), Node->getOperand(i).getValueType()) == TargetLowering::TypeLegal || Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10499 Summary: llvm::SDValue::SelectionDAGLegalize::Legalize Op(llvm::SDValue): Assertion `(TLI.getTypeAction(*DAG.getContext(), Node->getOperand(i).getValueType()) == TargetLowering::TypeLegal || Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexp Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: LegalizeDAG.cpp:788: llvm::SDValue::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `(TLI.getTypeAction(*DAG.getContext(), Node->getOperand(i).getValueType()) == TargetLowering::TypeLegal || Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexpected illegal type!"' failed. 0 llc 0x000000000153ffea 1 llc 0x0000000001540578 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000001039bc8 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 558 7 llc 0x00000000010428e9 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 36687 8 llc 0x000000000104fa27 (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG() + 179 9 llc 0x000000000104fb45 llvm::SelectionDAG::Legalize() + 49 10 llc 0x0000000000ff713c llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 2424 11 llc 0x0000000000ff8ea2 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 12 llc 0x0000000000ff9804 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 13 llc 0x0000000000ff9d83 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 14 llc 0x00000000011449ad llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 15 llc 0x000000000147a2bb llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 16 llc 0x000000000147a4b3 llvm::FPPassManager::runOnModule(llvm::Module&) + 81 17 llc 0x0000000001479f67 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 18 llc 0x000000000147b71c llvm::PassManagerImpl::run(llvm::Module&) + 116 19 llc 0x000000000147b77f llvm::PassManager::run(llvm::Module&) + 33 20 llc 0x0000000000ab642d main + 2403 21 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 22 llc 0x0000000000ab4b79 Stack dump: 0. Program arguments: ../llc temp.ll -march=x86-64 -mattr=-sse2,-sse41 -o /dev/null 1. Running pass 'Function Pass Manager' on module 'temp.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_24438_500' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_24438_500(i8*, i32*, i64*, i32, i8, i64) { BB: %A4 = alloca <8 x i64> %A3 = alloca <8 x i16> %A2 = alloca <8 x i16> %A1 = alloca <8 x i32> %A = alloca <8 x i32> %L = load i8* %0 store i8 -85, i8* %0 %E = extractelement <8 x float> undef, i32 3 %E5 = extractelement <32 x float> undef, i32 24 %Shuff = shufflevector <8 x i32> undef, <8 x i32> undef, <8 x i32> %Shuff6 = shufflevector <8 x i32> %Shuff, <8 x i32> %Shuff, <8 x i32> %Shuff7 = shufflevector <8 x i32> %Shuff, <8 x i32> %Shuff, <8 x i32> %I = insertelement <8 x i32> %Shuff, i32 -1, i32 4 %B = and i32 462723, %3 %BC = bitcast <8 x i32> %I to <8 x float> %S = select i1 true, float 0x3ED0C07740000000, float 0x3EC8EBA4C0000000 %S8 = icmp ugt i8 %L, %4 br label %CF40 CF40: ; preds = %BB %L9 = load i8* %0 store i8 %L9, i8* %0 %E10 = extractelement <8 x float> %BC, i32 7 %E11 = extractelement <8 x i32> %Shuff, i32 1 %Shuff12 = shufflevector <8 x i32> %Shuff, <8 x i32> %Shuff, <8 x i32> %Shuff13 = shufflevector <8 x i32> %Shuff, <8 x i32> %Shuff12, <8 x i32> %Shuff14 = shufflevector <8 x i32> %Shuff6, <8 x i32> %Shuff, <8 x i32> %I15 = insertelement <8 x i32> %Shuff, i32 -1, i32 2 %B16 = urem <8 x i32> %Shuff14, %Shuff6 %FC = fptosi float 0x3ED0C07740000000 to i8 %S17 = select i1 %S8, i8 %L9, i8 115 %S18 = fcmp une float %S, 0x3EC9134F40000000 br label %CF CF: ; preds = %CF, %CF40 %L19 = load i8* %0 store i8 115, i8* %0 %E20 = extractelement <8 x i32> %Shuff, i32 3 %E21 = extractelement <8 x i32> %B16, i32 5 %Shuff22 = shufflevector <8 x i32> %Shuff, <8 x i32> %Shuff6, <8 x i32> %Shuff23 = shufflevector <8 x i32> %Shuff, <8 x i32> %Shuff12, <8 x i32> %Shuff24 = shufflevector <8 x i32> %Shuff, <8 x i32> %Shuff22, <8 x i32> %I25 = insertelement <8 x i32> %Shuff, i32 -1, i32 6 %B26 = lshr i8 %S17, %L %ZE = fpext <8 x float> %BC to <8 x double> %S27 = select i1 %S18, i1 true, i1 %S8 br i1 %S27, label %CF, label %CF41 CF41: ; preds = %CF41, %CF %S28 = fcmp false float %S, 0x3EC8EBA4C0000000 br i1 %S28, label %CF41, label %CF42 CF42: ; preds = %CF42, %CF41 %L29 = load i8* %0 store i8 %B26, i8* %0 %E30 = extractelement <8 x i32> %Shuff, i32 0 %E31 = extractelement <8 x i32> %Shuff, i32 2 %Shuff32 = shufflevector <8 x double> %ZE, <8 x double> %ZE, <8 x i32> %Shuff33 = shufflevector <8 x i32> %Shuff, <8 x i32> %Shuff24, <8 x i32> %Shuff34 = shufflevector <8 x double> %Shuff32, <8 x double> %ZE, <8 x i32> %I35 = insertelement <8 x double> %Shuff32, double 0x3EC79423E6864956, i32 3 %B36 = fdiv float %E, 0x3EC9134F40000000 %FC37 = uitofp i8 115 to double %S38 = select i1 %S8, float %E10, float %B36 %S39 = icmp sgt i8 -117, %4 br i1 %S39, label %CF42, label %CF43 CF43: ; preds = %CF42 store i8 %B26, i8* %0 store <8 x i32> %B16, <8 x i32>* %A store i8 115, i8* %0 store <8 x i32> %Shuff33, <8 x i32>* %A store i8 %L, i8* %0 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 Tue Jul 26 10:23:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 10:23:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10500] New: [x86/AVX CodeGen] Cannot select v8f32 = bitcast Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10500 Summary: [x86/AVX CodeGen] Cannot select v8f32 = bitcast Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: syoyofujita at gmail.com CC: llvmbugs at cs.uiuc.edu Revision: 136074 Following .ll for x86/AVX target produce these error: LLVM ERROR: Cannot select: 0x3beca00: v8f32 = bitcast 0x3bec900 [ORD=1] [ID=9] 0x3bec900: v8i32,ch = CopyFromReg 0x3bc37a8, 0x3bec800 [ORD=1] [ID=7] 0x3bec800: v8i32 = Register %vreg1 [ORD=1] [ID=1] ; ModuleID = 'bugpoint-reduced-simplified.bc' 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" declare <8 x float> @llvm.x86.avx.blendv.ps.256(<8 x float>, <8 x float>, <8 x float>) nounwind readnone define void @"ao_scanlines___UiUiUiUiUiREFUf[]"(<8 x i32> %__mask) nounwind { allocas: %floatmask.i = bitcast <8 x i32> %__mask to <8 x float> br i1 undef, label %cif_test_all, label %__gather_base_offsets_i32.exit30803 cif_test_all: ; preds = %allocas unreachable __gather_base_offsets_i32.exit30803: ; preds = %allocas %blend.i31259 = call <8 x float> @llvm.x86.avx.blendv.ps.256(<8 x float> undef, <8 x float> undef, <8 x float> %floatmask.i) nounwind unreachable } FYI, original input code is grabbed from ispc's aobench example(http://ispc.github.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 Tue Jul 26 10:32:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 10:32:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 10479] Dragonegg is failing to build under Debian KFreebsd In-Reply-To: References: Message-ID: <20110726153253.A04672A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10479 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Duncan Sands 2011-07-26 10:32:53 CDT --- Support for kfreebsd added to Triple here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110725/124853.html Support for kfreebsd added to dragonegg here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110725/124854.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 10:47:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 10:47:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 10501] New: [x86/AVX CodeGen] Cannot select v8i32 = BUILD_VECTOR Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10501 Summary: [x86/AVX CodeGen] Cannot select v8i32 = BUILD_VECTOR Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: syoyofujita at gmail.com CC: llvmbugs at cs.uiuc.edu Revision: 136074 With following .ll, llc -mattr=+avx reports these error: LLVM ERROR: Cannot select: 0x3acb010: v8i32 = BUILD_VECTOR 0x3acaf10, 0x3acaf10, 0x3acaf10, 0x3acaf10, 0x3acaf10, 0x3acaf10, 0x3acaf10, 0x3acaf10 [ID=4] 0x3acaf10: i32 = TargetConstant<-1> [ID=3] 0x3acaf10: i32 = TargetConstant<-1> [ID=3] 0x3acaf10: i32 = TargetConstant<-1> [ID=3] 0x3acaf10: i32 = TargetConstant<-1> [ID=3] 0x3acaf10: i32 = TargetConstant<-1> [ID=3] 0x3acaf10: i32 = TargetConstant<-1> [ID=3] 0x3acaf10: i32 = TargetConstant<-1> [ID=3] 0x3acaf10: i32 = TargetConstant<-1> [ID=3] ; ModuleID = 'bugpoint-reduced-simplified.bc' 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 void @mandelbrot_ispc() nounwind { allocas: br i1 undef, label %for_test40.preheader.lr.ph, label %for_exit for_test40.preheader.lr.ph: ; preds = %allocas br label %for_loop.i.lr.ph for_exit: ; preds = %allocas ret void for_loop.i.lr.ph: ; preds = %mandel___ffi.exit, %for_test40.preheader.lr.ph br label %for_loop.i for_loop.i: ; preds = %for_loop.i, %for_loop.i.lr.ph br i1 undef, label %mandel___ffi.exit, label %for_loop.i mandel___ffi.exit: ; preds = %for_loop.i store <8 x float> , <8 x float>* undef, align 32 br label %for_loop.i.lr.ph } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 11:44:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 11:44:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10502] New: .gcno version number in .gcno files is incorrect Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10502 Summary: .gcno version number in .gcno files is incorrect Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Miscellaneous Instrumentation passes AssignedTo: unassignedbugs at nondot.org ReportedBy: dmaclach at gmail.com CC: llvmbugs at cs.uiuc.edu Somebody wasn't thinking little-endian ;-) http://llvm.org/svn/llvm-project/llvm/trunk/lib/Transforms/Instrumentation/GCOVProfiling.cpp Line 380 is: out->write("oncg*402MVLL", 12); It should be: out->write("oncg*204MVLL", 12); -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 12:23:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 12:23:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10503] New: llvm::SplitEditor::leaveIntvBefore(llvm::SlotIndex): Assertion `MI && "No instruction at index"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10503 Summary: llvm::SplitEditor::leaveIntvBefore(llvm::SlotIndex): Assertion `MI && "No instruction at index"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu Testcase attached. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 13:32:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 13:32:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 10502] .gcno version number in .gcno files is incorrect In-Reply-To: References: Message-ID: <20110726183210.98D5F2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10502 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Bill Wendling 2011-07-26 13:32:10 CDT --- Gar! That's...Hrm... I added it here. Thanks! r136111 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 14:29:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 14:29:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10504] New: clang 3.0 on freebsd 9-current amd64 dies on some construct when linking Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10504 Summary: clang 3.0 on freebsd 9-current amd64 dies on some construct when linking Product: new-bugs Version: unspecified Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: clang at opsec.eu CC: llvmbugs at cs.uiuc.edu While researching the recent test run for clang in the freebsd ports, one port I maintain ran into a bug, see: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/cego-2.10.11.log The author of cego and lfcxml investigated and built a testcase for the problem, which you can download from: http://opsec.eu/src/clang-fbsd9-bug.tgz Extract and run make on freebsd9-current displays: $ make clang++ -c Main.cc clang++ -c Parent.cc clang++ -c Child.cc clang++ -c Master.cc clang++ -v -o dtest Main.o Parent.o Child.o Master.o FreeBSD clang version 3.0 (trunk 132879) 20110612 Target: x86_64-unknown-freebsd9.0 Thread model: posix "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 -o dtest /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib Main.o Parent.o Child.o Master.o -lstdc++ -lm -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 Master.o: In function `Master::~Master()': Master.cc:(.text+0x5e): undefined reference to `Parent::~Parent()' clang++: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/home/pi/src/clang-fbsd9-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 Jul 26 16:03:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 16:03:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 10497] SplitVecRes_BITCAST(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&): Assertion `false && "Unknown type action!"' failed. In-Reply-To: References: Message-ID: <20110726210324.CC8902A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10497 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-07-26 16:03:24 CDT --- r136130. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 16:28:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 16:28:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 10505] New: Assertion failed: (FieldNo < FieldCount && "Invalid Field No"), function getFieldOffset, file /usr/home/rdivacky/llvm/tools/clang/lib/AST/../../include/clang/AST/RecordLayout.h, line 121. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10505 Summary: Assertion failed: (FieldNo < FieldCount && "Invalid Field No"), function getFieldOffset, file /usr/home/rdivacky/llvm/tools/clang/lib/AST/../../incl ude/clang/AST/RecordLayout.h, line 121. Product: clang Version: unspecified Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com pes delta-2006.08.03$ clang++ RenderSlider-E.cpp RenderSlider-E.cpp:53:23: warning: control reaches end of non-void function [-Wreturn-type] } ^ Assertion failed: (FieldNo < FieldCount && "Invalid Field No"), function getFieldOffset, file /usr/home/rdivacky/llvm/tools/clang/lib/AST/../../include/clang/AST/RecordLayout.h, line 121. Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-freebsd8.2 -emit-obj -mrelax-all -disable-free -main-file-name RenderSlider-E.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 152 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-x02eo7.o -x c++ RenderSlider-E.cpp 1. parser at end of file 2. RenderSlider-E.cpp:94:45: LLVM IR generation of declaration 'WebCore' 3. RenderSlider-E.cpp:106:51: Generating code for declaration 'WebCore::RenderSlider::forwardEvent' 4. RenderSlider-E.cpp:106:78: LLVM IR generation of compound statement ('{}') clang: error: unable to execute command: Abort trap: 6 (core dumped) clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 17:51:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 17:51:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10504] clang 3.0 on freebsd 9-current amd64 dies on some construct when linking In-Reply-To: References: Message-ID: <20110726225129.CCCCF2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10504 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Eli Friedman 2011-07-26 17:51:29 CDT --- "Fixed" in r136172. (And by "fixed", I mean that the compiler gives a decent diagnostic.) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 18:00:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 18:00:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 10503] llvm::SplitEditor::leaveIntvBefore(llvm::SlotIndex): Assertion `MI && "No instruction at index"' failed. In-Reply-To: References: Message-ID: <20110726230047.DFAA92A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10503 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Jakob Stoklund Olesen 2011-07-26 18:00:47 CDT --- r136174 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 18:05:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 18:05:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 10506] New: instantiation of '0x for-range statements sloshes together temporaries Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10506 Summary: instantiation of '0x for-range statements sloshes together temporaries Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com By inspection: TreeTransform on CXXForRangeStmt is not building CXXExprWithCleanups nodes appropriately for the condition and increment expressions. Both of these typically would not require temporaries, but they certainly could if, e.g., the arguments to the equality operator have class type or the increment expression returns an (ignored) value of class type. Something like this: struct needs_temporary { needs_temporary(); needs_temporary(const needs_temporary &); ~needs_temporary(); }; struct iterator { needs_temporary temp; friend bool operator!=(iterator x, iterator y); // or even returning a temporary with a conversion to bool needs_temporary operator++(); }; struct has_iterator {}; iterator begin(has_iterator); iterator end(has_iterator); template void test() { for (auto var : T()) {} } template void 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 Jul 26 18:22:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 18:22:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10504] clang 3.0 on freebsd 9-current amd64 dies on some construct when linking In-Reply-To: References: Message-ID: <20110726232232.E94862A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10504 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Eli Friedman 2011-07-26 18:22:32 CDT --- Just discussed this with John and Doug; apparently, we're actually going to fix this, even though it's UB strictly speaking. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 18:27:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 18:27:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 10504] clang 3.0 on freebsd 9-current amd64 dies on some construct when linking In-Reply-To: References: Message-ID: <20110726232754.CA6242A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10504 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #5 from Eli Friedman 2011-07-26 18:27:54 CDT --- Really fixed with r136180 + r136183. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 18:42:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 18:42:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10507] New: unordered_set::erase(const key_type& k) does not call element's destructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10507 Summary: unordered_set::erase(const key_type& k) does not call element's destructor Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu No reduced testcase, unfortunately. I couldn't make heads or tails of the __hash_table code well enough to determine where the actual destruction should occur. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 19:42:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 19:42:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 8595] [MC assembler] .code16, .code32, .code64 not supported In-Reply-To: References: Message-ID: <20110727004240.E914C2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8595 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Evan Cheng 2011-07-26 19:42:39 CDT --- Fixed: r136197 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 19:52:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 19:52:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10508] New: DenseMapInfo's std::pair instance's second Tombstone is set to be the empty key [patch attached] Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10508 Summary: DenseMapInfo's std::pair instance's second Tombstone is set to be the empty key [patch attached] Product: new-bugs Version: 2.9 Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: michael at lunarg.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6948) --> (http://llvm.org/bugs/attachment.cgi?id=6948) patch The DenseMapInfo instance for std::pair's second Tombstone is set to be the empty key, see below and the attached patch: template struct DenseMapInfo > { typedef std::pair Pair; typedef DenseMapInfo FirstInfo; typedef DenseMapInfo SecondInfo; static inline Pair getEmptyKey() { return std::make_pair(FirstInfo::getEmptyKey(), SecondInfo::getEmptyKey()); } static inline Pair getTombstoneKey() { return std::make_pair(FirstInfo::getTombstoneKey(), SecondInfo::getEmptyKey()); I believe the last line should read: return std::make_pair(FirstInfo::getTombstoneKey(), SecondInfo::getTombstoneKey()); -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 20:30:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 20:30:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 10480] Assertion failed: (FD->isUsed() && "Sema didn't mark implicit function as used!"), function GetOrCreateLLVMFunction, file CodeGenModule.cpp, line 925. In-Reply-To: References: Message-ID: <20110727013045.061C82A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10480 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #4 from Eli Friedman 2011-07-26 20:30:44 CDT --- Should be fixed with Doug's r136081. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 20:33:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 20:33:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 10500] [x86/AVX CodeGen] Cannot select v8f32 = bitcast In-Reply-To: References: Message-ID: <20110727013346.58FBB2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10500 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Bruno Cardoso Lopes 2011-07-26 20:33:46 CDT --- Works on TOT! Try a more recent revision! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 26 20:47:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 20:47:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 9473] sitofp isel failed for x86 AVX backend. In-Reply-To: References: Message-ID: <20110727014719.3D6E02A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9473 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bruno.cardoso at gmail.com Resolution|LATER |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jul 26 20:50:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 26 Jul 2011 20:50:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10501] [x86/AVX CodeGen] Cannot select v8i32 = BUILD_VECTOR In-Reply-To: References: Message-ID: <20110727015029.B64892A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10501 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Bruno Cardoso Lopes 2011-07-26 20:50:29 CDT --- *** This bug has been marked as a duplicate of bug 10452 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 00:47:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 00:47:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10471] FLT_EVAL_METHOD sometimes wrong for Intel FPUs In-Reply-To: References: Message-ID: <20110727054701.98B5E2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10471 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2011-07-27 00:47:01 CDT --- No, please don't file bugs to ask questions. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 03:43:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 03:43:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10509] New: Maps of pairs can trigger horrid overload fallout in __map_value_compare Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10509 Summary: Maps of pairs can trigger horrid overload fallout in __map_value_compare Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu The overloaded operator() in __map_value_compare cannot properly accommodate with _Key is a specialization of pair, as _P and _CP are, and the result is that the _Key-based overloads will interact in the same overload resolution with non-_Key based overloads. Testcase: #include #include using namespace std; class Private { Private(int); }; void foo () { map, Private> Map; pair Pair; Map.find(Pair); } Run in C++03 mode, where access control is not subject to SFINAE this causes an inexplicable access control failure on Private's constructor. This is because operator()(const pair&, const pair, Private>&), the desired constructor, is participating in the overload resolution with operator()(const pair, Private>&, const pair, Private>&), and so a conversion from Private to int is attempted, causing the access control failure. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 03:46:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 03:46:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 10510] New: swap overload can trigger access control failures in C++03 mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10510 Summary: swap overload can trigger access control failures in C++03 mode Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu Swap's attempted SFINAE can quite easily trigger access control failures in C++03 mode. Testcase: #include using namespace std; class Private { Private& operator= (const Private&); friend void swap(Private&, Private&); public: Private(); }; void foo () { Private p; swap(p, p); } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 06:31:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 06:31:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10511] New: libclang crash when calling clang_reparseTranslationUnit Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10511 Summary: libclang crash when calling clang_reparseTranslationUnit Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: Erik.Verbruggen at Me.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com When reparsing a translation unit with the flag CXTranslationUnit_CXXPrecompiledPreamble on (as clang_defaultEditingTranslationUnitOptions does), then reparsing gives either: Assertion failed: ((Offset & (1U << 31)) == 0 && "Bad offset in reading source location"), function ReadSourceLocation, file /data/clang-llvm/llvm/tools/clang/include/clang/Serialization/ASTReader.h, line 1456. libclang: crash detected during reparsing reparse failed. or: Assertion failed: ((LatestDecl->getLocation().isInvalid() || NewLatest->getLocation().isInvalid() || !Reader.SourceMgr.isBeforeInTranslationUnit( NewLatest->getLocation(), LatestDecl->getLocation())) && "The new latest is supposed to come after the previous latest"), function VisitRedeclarableTemplateDecl, file /data/clang-llvm/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp, line 1094. libclang: crash detected during reparsing Turning off CXTranslationUnit_CXXPrecompiledPreamble stops clang from crashing. To reproduce: - unzip the attached zip file - download and unzip Qt 4.8 (http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.8.0-beta1.zip) - copy qconfig.h to Qt's src/corelib/global directory - edit gen-pch.sh for the QTDIR and the CLANGDIR - run gen-pch.sh, that will generate the pre-compiled header from pch.h - compile and run main.cpp which will parse crash.cpp and show the crash. I already minimized the number of includes. Preprocessing the .cpp file and including that will unfortunately not show the crash. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 27 09:59:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 09:59:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10512] New: Error generating constructor for nested anonymous structs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10512 Summary: Error generating constructor for nested anonymous structs Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clang at moocow37.plus.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6951) --> (http://llvm.org/bugs/attachment.cgi?id=6951) test case for nested anonymous struct constructor compiler bug The attached test program causes an assert "Invalid GetElementPtrInst indices for type!" when generating the constructor. Top of stack is: llvm::checkGEPType() llvm::GetElementPtrInst::Create() llvm::GetElementPtrInst::CreateInBounds() llvm::IRBuilder<1,llvm::ConstantFolder,llvm::IRBuilderDefaultInserter<1> >::CreateConstInBoundsGEP2_32() llvm::IRBuilder<1,llvm::ConstantFolder,llvm::IRBuilderDefaultInserter<1> >::CreateStructGEP() clang::CodeGen::CodeGenFunction::EmitLValueForField() Full output attached and test program. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 10:44:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 10:44:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10513] New: Virtual functions called from constructors/destructors should cause warning Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10513 Summary: Virtual functions called from constructors/destructors should cause warning Product: clang Version: trunk Platform: Other 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 would like to suggest that clang issues a warning when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. I would like to note that this isn't a clear-cut suggestion for the following reasons: * It's impossible to enforce such warning in all cases, only in case of virtual functions immediately called from constructor/destructor. * People often use virtual functions from destructors to uninitialize things. And in many cases it's semi-safe. But it's almost always wrong to call virtual functions from constructors. * It probably makes sense to add such warning to Valgrind as well to issue it based on the run-time analysis But still such warning in clang can prevent many errors waiting to happen from happening. gcc must do as much as possible preventing dangerous coding patterns. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 12:42:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 12:42:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10514] New: ConstantMerge ignores alignment, needed because of SSE use Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10514 Summary: ConstantMerge ignores alignment, needed because of SSE use Product: libraries Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu on amd64 with SSE enabled, if it doesnt crash for you try to make the "Test1" string longer (ie. "Test12" etc.): pes ~$ cat llvm-align.c #if 0 peter at daintree[10:28AM]~-1051> cc -O1 -o bar bar.c peter at daintree[10:28AM]~-1052> ./bar Test1 foo1bar2foo3bar peter at daintree[10:28AM]~-1053> cc -O2 -o bar bar.c peter at daintree[10:28AM]~-1054> ./bar Test1 foo1bar2foo3bar zsh: bus error (core dumped) ./bar If you look at assembler output, with -O1, the constant string appears twice. One has .align 16 constraint, due to SSE use, the other does not. With -O2, both strings are merged, and the alignment constraint is lost. #endif int foo(int a) { char id[] = "foo1bar2foo3bar"; id[0] += a; for (a = 0; id[a] != 0; a++) ; return a; } int main(void) { printf("Test1 %s\n", "foo1bar2foo3bar"); return foo(1); return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jul 27 13:34:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 13:34:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 10510] swap overload can trigger access control failures in C++03 mode In-Reply-To: References: Message-ID: <20110727183423.8F2812A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10510 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2011-07-27 13:34:23 CDT --- Fix Committed revision 136232. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 14:25:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 14:25:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10509] Maps of pairs can trigger horrid overload fallout in __map_value_compare In-Reply-To: References: Message-ID: <20110727192544.F26952A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10509 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2011-07-27 14:25:44 CDT --- Fix Committed revision 136247. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 14:47:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 14:47:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10514] ConstantMerge ignores alignment, needed because of SSE use In-Reply-To: References: Message-ID: <20110727194742.69D832A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10514 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Nick Lewycky 2011-07-27 14:47:42 CDT --- Fixed in r136250. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 17:23:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 17:23:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 10515] New: LoopPasses incorrectly update LoopInfo after removing a backedge. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10515 Summary: LoopPasses incorrectly update LoopInfo after removing a backedge. Product: libraries Version: trunk Platform: PC OS/Version: All Status: ASSIGNED Severity: normal Priority: P Component: Loop Optimizer AssignedTo: atrick at apple.com ReportedBy: atrick at apple.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6952) --> (http://llvm.org/bugs/attachment.cgi?id=6952) Unit test I have been able expose the problem with a simple unit test (attached) by running opt < skiplevelexit.ll -loop-unroll. Assertion failed: (HasInsideLoopSuccs && "Loop block has no in-loop successors!"), function verifyLoop, file /Volumes/Storage/llvm/include/llvm/Analysis/LoopInfo.h, line 458. I am currently implementing a a general algorithm that can rediscover the containing loop for each block in the original loop assuming that the rest of the loop tree is consistent. The fix involves - post order iteration over the blocks in the original loop only, not including subloops - deriving a block's containing loop from its successors' containing loops: it is the deepest loop that contains any successor - handling nested subloops as a single unit: essentially, a preheader's loop is the deepest loop that contains a subloop exit. - incrementally processing blocks until all predecessors are available to handle nested irreducible control flow (without irreducible flow, a single postorder traversal is sufficient). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 17:39:58 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 17:39:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 10516] New: alloc_size attribute is unknown Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10516 Summary: alloc_size attribute is unknown Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alexr at leftfield.org CC: llvmbugs at cs.uiuc.edu __attribute__((alloc_size(x))) and __attribute__((alloc_size(x,y))) should be recognized. I notice that FFmpeg uses this attribute as well as our internal 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 Wed Jul 27 18:05:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 18:05:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10517] New: Clang error in Sparc Solaris Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10517 Summary: Clang error in Sparc Solaris Product: clang Version: 2.9 Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: javpicorel at gmail.com CC: llvmbugs at cs.uiuc.edu After installing llvm-2.9 + Clang on Sparc - Solaris 10, whenever I use clang to compile whatever I receive this error: clang version 2.9 (tags/RELEASE_29/final) Target: sparc-sun-solaris2.10 Thread model: posix clang: warning: unknown platform, assuming -mfloat-abi=soft "/.../llvm-2.9/obj2/Release+Asserts/bin/clang" -cc1 -triple sparc-sun-solaris2.10 -S -disable-free -main-file-name prueba.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -msoft-float -target-feature +soft-float -target-linker-version 2.21 -momit-leaf-frame-pointer -v -resource-dir /.../llvm-2.9/obj2/Release+Asserts/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 125 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Hfaybq.s -x c prueba.c clang -cc1 version 2.9 based upon llvm 2.9 hosted on sparc-sun-solaris2.10 #include "..." search starts here: #include <...> search starts here: /usr/local/include /.../llvm-2.9/obj2/Release+Asserts/bin/../lib/clang/2.9/include /usr/include End of search list. Stack dump: 0. Program arguments: /.../llvm-2.9/obj2/Release+Asserts/bin/clang -cc1 -triple sparc-sun-solaris2.10 -S -disable-free -main-file-name prueba.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -msoft-float -target-feature +soft-float -target-linker-version 2.21 -momit-leaf-frame-pointer -v -resource-dir /.../llvm-2.9/obj2/Release+Asserts/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 125 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Hfaybq.s -x c prueba.c 1. /usr/include/stdio_impl.h:42:26: current parser token ';' 2. /usr/include/stdio_impl.h:29:1: parsing struct/union body '__FILE' clang: error: unable to execute command: Bus Error (core dumped) clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) Regards, Javier -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 27 18:48:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 18:48:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10518] New: arm failure for 2008-01-25-ByValReadNone.c Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10518 Summary: arm failure for 2008-01-25-ByValReadNone.c Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: echristo at gmail.com CC: llvmbugs at cs.uiuc.edu I don't think this should be failing, but someone should find out 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 Wed Jul 27 19:48:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 27 Jul 2011 19:48:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 9374] clang makes a lot of system calls for output files In-Reply-To: References: Message-ID: <20110728004827.B3BA32A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9374 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #9 from Argyrios Kyrtzidis 2011-07-27 19:48:26 CDT --- After changes to trunk, for writing PCH: 10 119 open:entry clang test.pch-0fa1da06 12 121 close:entry clang test.pch-0fa1da06 12 365 rename:entry clang test.pch-0fa1da06 test.pch for other output files: 4 119 open:entry clang test.o 4 121 close:entry clang test.o llvm r136310 + clang r136315. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 04:24:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 04:24:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 10519] New: Clang accepts NSAutoreleasePool in ARC mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10519 Summary: Clang accepts NSAutoreleasePool in ARC mode 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: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu @interface NSAutoreleasePool +new; @end int main(void) { [NSAutoreleasePool new]; return 0; } This program compiles in ARC mode, and the ARC migration tool does not flag any warnings or make any changes. According to section 7.2 of the ARC spec: > A program is ill-formed if it refers to the NSAutoreleasePool class. This code should therefore be rejected as ill formed. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 05:29:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 05:29:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10520] New: Assertion in register scavenger Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10520 Summary: Assertion in register scavenger 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=6953) --> (http://llvm.org/bugs/attachment.cgi?id=6953) Testcase Running the attached testcase yields: $ ./llc bugpoint-reduced-simplified.bc Assertion failed: (SubUsed && "Using an undefined register!"), function forward, file /Users/asl/Projects/llvm/src/lib/CodeGen/RegisterScavenging.cpp, line 208. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 06:37:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 06:37:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10521] New: libc++ problem: implicit instantiation of undefined template Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10521 Summary: libc++ problem: implicit instantiation of undefined template Product: libc++ Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: dmarkman at mac.com CC: llvmbugs at cs.uiuc.edu I was playing with Xcode 4.2 on Lion my clang++ version is Apple clang version 3.0 (tags/Apple/clang-210.3) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.0.0 Thread model: posix consider the following code (it was boiled down from some boost related code) #include namespace std { template struct pair; } int main (int argc, const char * argv[]) { std::pair p; return 0; } g++ (4.2.1) compiler doesn't complain: however clang++ with the following command line complains: clang++ -std=c++0x -stdlib=libc++ -c main.cpp main.cpp:10:26: error: implicit instantiation of undefined template 'std::pair' std::pair p; ^ main.cpp:5:48: note: template is declared here template struct pair; ^ 1 error generated. if I don't use the switch -stdlib=libc++ there is no error also if I place namespace std { template struct pair; } before #include namespace std { template struct pair; } #include int main (int argc, const char * argv[]) { std::pair p; return 0; } then everything is fine even with -stdlib=libc++ 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 Jul 28 07:48:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 07:48:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 10522] New: 2007-06-15-AnnotateAttribute.c does not show local variable annotations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10522 Summary: 2007-06-15-AnnotateAttribute.c does not show local variable annotations Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: retval386 at gmail.com CC: llvmbugs at cs.uiuc.edu llvm/test/FrontendC/2007-06-15-AnnotateAttribute.c has a comment that reads: // RUN: %llvmgcc -S %s -o - | grep llvm.global.annotations // RUN: %llvmgcc -S %s -o - | grep llvm.var.annotation | count 3 When I run the following I get no output of any kind: "clang -emit-llvm -S 2007-06-15-AnnotateAttribute.c -o - | grep llvm.var.annotation" The following does seem to function correctly: "clang -emit-llvm -S 2007-06-15-AnnotateAttribute.c -o - | grep llvm.global.annotation" It outputs: @llvm.global.annotations = appending global [2 x { i8*, i8*, i8*, i32 }] [{ i8*, i8*, i8*, i32 } { i8* bitcast (i32* @main.a to i8*), i8* getelementptr inbounds ([20 x i8]* @main.a1, i32 0, i32 0), i8* getelementptr inbounds ([31 x i8]* @.str, i32 0, i32 0), i32 20 }, { i8*, i8*, i8*, i32 } { i8* bitcast (i32* @X to i8*), i8* getelementptr inbounds ([20 x i8]* @X3, i32 0, i32 0), i8* getelementptr inbounds ([31 x i8]* @.str4, i32 0, i32 0), i32 7 }], section "llvm.metadata" I attached the output of "clang -emit-llvm -S 2007-06-15-AnnotateAttribute.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 Thu Jul 28 09:08:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 09:08:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 10523] New: Assertion `N2.getValueType().getSizeInBits() >= Log2_32_Ceil(N1.getValueType().getSizeInBits()) && "Invalid use of small shift amount with oversized value!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10523 Summary: Assertion `N2.getValueType().getSizeInBits() >= Log2_32_Ceil(N1.getValueType().getSizeInBits()) && "Invalid use of small shift amount with oversized value!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6955) --> (http://llvm.org/bugs/attachment.cgi?id=6955) LL file reproducing the problem llc: SelectionDAG.cpp:2758: llvm::SDValue llvm::SelectionDAG::getNode(unsigned int, llvm::DebugLoc, llvm::EVT, llvm::SDValue, llvm::SDValue): Assertion `N2.getValueType().getSizeInBits() >= Log2_32_Ceil(N1.getValueType().getSizeInBits()) && "Invalid use of small shift amount with oversized value!"' failed. 0 llc 0x0000000001549f06 1 llc 0x000000000154a494 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000000f9fc6c llvm::SelectionDAG::getNode(unsigned int, llvm::DebugLoc, llvm::EVT, llvm::SDValue, llvm::SDValue) + 3338 7 llc 0x000000000102267f llvm::TargetLowering::SimplifySetCC(llvm::EVT, llvm::SDValue, llvm::SDValue, llvm::ISD::CondCode, bool, llvm::TargetLowering::DAGCombinerInfo&, llvm::DebugLoc) const + 23869 8 llc 0x0000000000f18aa3 (anonymous namespace)::DAGCombiner::SimplifySetCC(llvm::EVT, llvm::SDValue, llvm::SDValue, llvm::ISD::CondCode, llvm::DebugLoc, bool) + 197 9 llc 0x0000000000f18b8f (anonymous namespace)::DAGCombiner::visitSETCC(llvm::SDNode*) + 203 10 llc 0x0000000000f50161 (anonymous namespace)::DAGCombiner::visit(llvm::SDNode*) + 1315 11 llc 0x0000000000f506a4 (anonymous namespace)::DAGCombiner::combine(llvm::SDNode*) + 44 12 llc 0x0000000000f53205 (anonymous namespace)::DAGCombiner::Run(llvm::CombineLevel) + 505 13 llc 0x0000000000f53628 llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AliasAnalysis&, llvm::CodeGenOpt::Level) + 54 14 llc 0x0000000000ffe10c llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 668 15 llc 0x000000000100054e llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 16 llc 0x0000000001000eb0 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 17 llc 0x000000000100142f llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 18 llc 0x000000000114c971 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 19 llc 0x0000000001484137 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 20 llc 0x000000000148432f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 21 llc 0x0000000001483de3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 22 llc 0x0000000001485598 llvm::PassManagerImpl::run(llvm::Module&) + 116 23 llc 0x00000000014855fb llvm::PassManager::run(llvm::Module&) + 33 24 llc 0x0000000000ab884d main + 2403 25 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 26 llc 0x0000000000ab6f99 Stack dump: 0. Program arguments: ../llc temp.ll -march=x86-64 -mattr=+sse2,+sse41 -o /dev/null 1. Running pass 'Function Pass Manager' on module 'temp.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_129334_5000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_129334_5000() { BB: %I74 = insertelement <32 x i32> undef, i32 undef, i32 15 %I105 = insertelement <32 x i32> undef, i32 undef, i32 14 %Shuff292 = shufflevector <32 x i32> %I74, <32 x i32> undef, <32 x i32> %Shuff302 = shufflevector <32 x i32> %Shuff292, <32 x i32> undef, <32 x i32> %I326 = insertelement <32 x i32> undef, i32 undef, i32 15 %B338 = sub <32 x i32> zeroinitializer, %I105 %FC339 = sitofp <32 x i32> %I326 to <32 x double> %S341 = icmp ne <32 x i32> %B338, undef %E376 = extractelement <32 x i1> %S341, i32 0 %Shuff419 = shufflevector <32 x i32> undef, <32 x i32> %Shuff302, <32 x i32> 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 Thu Jul 28 09:13:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 09:13:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10524] New: llvm::EVT llvm::EVT::getVectorElementType() const: Assertion `isVector() && "Invalid vector type!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10524 Summary: llvm::EVT llvm::EVT::getVectorElementType() const: Assertion `isVector() && "Invalid vector type!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6956) --> (http://llvm.org/bugs/attachment.cgi?id=6956) LL file reproducing the problem llc: /nfs/iil/disks/cvcc/nrotem/llvm/readonly-llvm-head/include/llvm/CodeGen/ValueTypes.h:561: llvm::EVT llvm::EVT::getVectorElementType() const: Assertion `isVector() && "Invalid vector type!"' failed. 0 llc 0x0000000001549f06 1 llc 0x000000000154a494 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000000b2c54e llvm::EVT::getVectorElementType() const + 74 7 llc 0x0000000001065ca2 8 llc 0x000000000106ebd2 9 llc 0x000000000105d67b 10 llc 0x000000000105dfda llvm::SelectionDAG::LegalizeTypes() + 50 11 llc 0x0000000000ffe271 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1025 12 llc 0x000000000100054e llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 13 llc 0x0000000001000eb0 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 14 llc 0x000000000100142f llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 15 llc 0x000000000114c971 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 16 llc 0x0000000001484137 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 17 llc 0x000000000148432f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 18 llc 0x0000000001483de3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 19 llc 0x0000000001485598 llvm::PassManagerImpl::run(llvm::Module&) + 116 20 llc 0x00000000014855fb llvm::PassManager::run(llvm::Module&) + 33 21 llc 0x0000000000ab884d main + 2403 22 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 23 llc 0x0000000000ab6f99 Stack dump: 0. Program arguments: ../llc temp.ll -march=x86-64 -mattr=+sse2,+sse41 -o /dev/null 1. Running pass 'Function Pass Manager' on module 'temp.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_178513_5000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_178513_5000() { BB: %Shuff22 = shufflevector <2 x i32> undef, <2 x i32> zeroinitializer, <2 x i32> %B26 = sub <2 x i32> %Shuff22, zeroinitializer %S79 = icmp eq <2 x i32> %B26, zeroinitializer %B269 = urem <2 x i1> zeroinitializer, %S79 %Se335 = sext <2 x i1> %B269 to <2 x i8> store <2 x i8> %Se335, <2 x i8>* undef 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 Thu Jul 28 09:14:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 09:14:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10525] New: const llvm::SDValue& llvm::SDNode::getOperand(unsigned int) const: Assertion `Num < NumOperands && "Invalid child # of SDNode!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10525 Summary: const llvm::SDValue& llvm::SDNode::getOperand(unsigned int) const: Assertion `Num < NumOperands && "Invalid child # of SDNode!"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6957) --> (http://llvm.org/bugs/attachment.cgi?id=6957) LL file reproducing the problem llc: /nfs/iil/disks/cvcc/nrotem/llvm/readonly-llvm-head/include/llvm/CodeGen/SelectionDAGNodes.h:533: const llvm::SDValue& llvm::SDNode::getOperand(unsigned int) const: Assertion `Num < NumOperands && "Invalid child # of SDNode!"' failed. 0 llc 0x0000000001549f06 1 llc 0x000000000154a494 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000000b27416 llvm::SDNode::getOperand(unsigned int) const + 62 7 llc 0x0000000000e83445 8 llc 0x0000000000e83704 9 llc 0x0000000000ea8147 llvm::X86TargetLowering::PerformDAGCombine(llvm::SDNode*, llvm::TargetLowering::DAGCombinerInfo&) const + 507 10 llc 0x0000000000f507e5 (anonymous namespace)::DAGCombiner::combine(llvm::SDNode*) + 365 11 llc 0x0000000000f53205 (anonymous namespace)::DAGCombiner::Run(llvm::CombineLevel) + 505 12 llc 0x0000000000f53628 llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AliasAnalysis&, llvm::CodeGenOpt::Level) + 54 13 llc 0x0000000000ffe967 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 2807 14 llc 0x000000000100054e llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 15 llc 0x0000000001000eb0 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 16 llc 0x000000000100142f llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 17 llc 0x000000000114c971 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 18 llc 0x0000000001484137 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 19 llc 0x000000000148432f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 20 llc 0x0000000001483de3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 21 llc 0x0000000001485598 llvm::PassManagerImpl::run(llvm::Module&) + 116 22 llc 0x00000000014855fb llvm::PassManager::run(llvm::Module&) + 33 23 llc 0x0000000000ab884d main + 2403 24 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 25 llc 0x0000000000ab6f99 Stack dump: 0. Program arguments: ../llc temp.ll -march=x86-64 -mattr=+sse2,+sse41 -o /dev/null 1. Running pass 'Function Pass Manager' on module 'temp.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_163411_5000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_163411_5000() { BB: %L = load <2 x i64>* undef %Shuff11 = shufflevector <2 x i64> %L, <2 x i64> %L, <2 x i32> %I51 = insertelement <2 x i64> undef, i64 undef, i32 0 %Shuff152 = shufflevector <2 x i64> %I51, <2 x i64> %Shuff11, <2 x i32> store <2 x i64> %Shuff152, <2 x i64>* undef 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 Thu Jul 28 09:15:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 09:15:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 10526] New: GetSplitVector(llvm::SDValue, llvm::SDValue&, llvm::SDValue&): Assertion `Entry.first.getNode() && "Operand isn't split"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10526 Summary: GetSplitVector(llvm::SDValue, llvm::SDValue&, llvm::SDValue&): Assertion `Entry.first.getNode() && "Operand isn't split"' failed. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: LegalizeTypes.cpp:823: void llvm::DAGTypeLegalizer::GetSplitVector(llvm::SDValue, llvm::SDValue&, llvm::SDValue&): Assertion `Entry.first.getNode() && "Operand isn't split"' failed. 0 llc 0x0000000001549f06 1 llc 0x000000000154a494 2 libpthread.so.0 0x00002aaaaabd4d60 3 libc.so.6 0x00002aaaab274f45 gsignal + 53 4 libc.so.6 0x00002aaaab276340 abort + 272 5 libc.so.6 0x00002aaaab26e486 __assert_fail + 246 6 llc 0x0000000001058d7e 7 llc 0x000000000106fcd1 8 llc 0x0000000001075806 9 llc 0x000000000105d65f 10 llc 0x000000000105dfda llvm::SelectionDAG::LegalizeTypes() + 50 11 llc 0x0000000000ffe271 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1025 12 llc 0x000000000100054e llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 230 13 llc 0x0000000001000eb0 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2400 14 llc 0x000000000100142f llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 849 15 llc 0x000000000114c971 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 16 llc 0x0000000001484137 llvm::FPPassManager::runOnFunction(llvm::Function&) + 371 17 llc 0x000000000148432f llvm::FPPassManager::runOnModule(llvm::Module&) + 81 18 llc 0x0000000001483de3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 19 llc 0x0000000001485598 llvm::PassManagerImpl::run(llvm::Module&) + 116 20 llc 0x00000000014855fb llvm::PassManager::run(llvm::Module&) + 33 21 llc 0x0000000000ab884d main + 2403 22 libc.so.6 0x00002aaaab262304 __libc_start_main + 244 23 llc 0x0000000000ab6f99 Stack dump: 0. Program arguments: ../llc temp.ll -march=x86-64 -mattr=+sse2,+sse41 -o /dev/null 1. Running pass 'Function Pass Manager' on module 'temp.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@autogen_142660_5000' ; ModuleID = 'bugpoint-reduced-simplified.bc' target triple = "x86_64-unknown-linux-gnu" define void @autogen_142660_5000() { BB: %Shuff49 = shufflevector <8 x i32> zeroinitializer, <8 x i32> undef, <8 x i32> %B85 = sub <8 x i32> %Shuff49, zeroinitializer %S242 = icmp eq <8 x i32> zeroinitializer, %B85 %FC284 = uitofp <8 x i1> %S242 to <8 x float> store <8 x float> %FC284, <8 x float>* undef 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 Thu Jul 28 09:23:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 09:23:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10038] clang++ generates HIDDEN symbols where g++ doesn't In-Reply-To: References: Message-ID: <20110728142309.47BE42A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10038 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #3 from Nico Weber 2011-07-28 09:23:09 CDT --- *** This bug has been marked as a duplicate of bug 10113 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 09:52:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 09:52:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 10303] CMake build updates cmake/modules/LLVMLibDeps.cmake In-Reply-To: References: Message-ID: <20110728145259.429522A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10303 ?scar Fuentes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from ?scar Fuentes 2011-07-28 09:52:58 CDT --- There were some reasons to auto-update LLVMLibDeps.cmake that out-weighted the inconveniences you found, but that's not relevant now. The library dependencies are going to be maintained manually. LLVMLibDeps.cmake will be no more from some hours from 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 Thu Jul 28 10:19:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 10:19:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10527] New: Assertion `Num < NumOperands && "Invalid child # of SDNode!"' failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10527 Summary: Assertion `Num < NumOperands && "Invalid child # of SDNode!"' failed Product: new-bugs Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6959) --> (http://llvm.org/bugs/attachment.cgi?id=6959) testcase .ll $ llc sse2-mmx.ll llc: llvm/include/llvm/CodeGen/SelectionDAGNodes.h:533: const llvm::SDValue& llvm::SDNode::getOperand(unsigned int) const: Assertion `Num < NumOperands && "Invalid child # of SDNode!"' failed. 6 llc 0x0000000000afab08 llvm::SDNode::getOperand(unsigned int) const + 62 llvm::X86TargetLowering::PerformDAGCombine(llvm::SDNode*, llvm::TargetLowering::DAGCombinerInfo&) const + 57 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 12:01:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 12:01:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10528] New: Windows MSVC2010: #include fails with unknown type std::collate Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10528 Summary: Windows MSVC2010: #include fails with unknown type std::collate Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: release blocker Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: Axel.Naumann at cern.ch CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The trunk of clang (compiled from scratch) fails to compile anything that #includes from Visual Studio 2010. You give the option "release blocker", and I would not release like that ;-) so I picked it. E:\build\cling\obj>type test.cxx #include E:\build\cling\obj>clang++ -c test.cxx In file included from test.cxx:1: In file included from c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc lude\string:6: In file included from c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc lude\istream:6: In file included from c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc lude\ostream:6: In file included from c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc lude\ios:6: In file included from c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc lude\xlocnum:10: In file included from c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc lude\streambuf:6: In file included from c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc lude\xiosbase:6: c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xlocale:263:14: e rror: no type named 'collate' in namespace 'std' const _STD collate<_Elem>& _Coll_fac = ~~~~ ^ c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xlocale:263:21: e rror: expected unqualified-id const _STD collate<_Elem>& _Coll_fac = ^ c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xlocale:266:11: e rror: use of undeclared identifier '_Coll_fac'; did you mean '_Collvec'? return (_Coll_fac.compare(_Left.c_str(), _Left.c_str() ... ^ 3 errors generated. E:\build\cling\obj>clang --version clang version 3.0 (trunk) Target: i686-pc-win32 Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 28 12:34:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 12:34:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10491] [AVX] "cannot select" v8i32 = BUILD_VECTOR error In-Reply-To: References: Message-ID: <20110728173412.685A02A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10491 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bruno Cardoso Lopes 2011-07-28 12:34:12 CDT --- Hi, Fixed in r136321 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 12:36:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 12:36:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10493] [AVX] "cannot select" v8f32 = X86ISD::VZEXT_MOVL error In-Reply-To: References: Message-ID: <20110728173644.6F2622A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10493 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bruno Cardoso Lopes 2011-07-28 12:36:43 CDT --- This one was fixed as a side-effect of implementing r136320 and r136322. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 13:54:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 13:54:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10474] buildbots should stop building llvm-gcc gfortran In-Reply-To: References: Message-ID: <20110728185412.5F6242A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10474 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #10 from Duncan Sands 2011-07-28 13:54:11 CDT --- Fixing llvm-gcc wasn't as bad as I thought. Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110725/125019.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110725/125023.html Note that some llvm-gcc builders are still failing, but no longer because of this kind of 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 Jul 28 14:39:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 14:39:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 10529] New: [AVX] Assertion failed: (begin() + idx < end()), function operator[], file SmallVector.h, line 154. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10529 Summary: [AVX] Assertion failed: (begin() + idx < end()), function operator[], file SmallVector.h, line 154. Product: new-bugs Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu With the attached, I get the following assertion with TOT if I run it through llc with -mattr=+avx. Assertion failed: (begin() + idx < end()), function operator[], file /Users/mmp/llvm-dev-src/include/llvm/ADT/SmallVector.h, line 154. 0 llc 0x00000001052cb062 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6494 1 llc 0x00000001052cb669 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 8037 2 libsystem_c.dylib 0x00007fff8a2a9cfa _sigtramp + 26 3 libsystem_c.dylib 000000000000000000 _sigtramp + 18446603338198115104 4 llc 0x00000001052cafc6 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6338 5 llc 0x00000001052cb018 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6420 6 llc 0x0000000104d3b6d3 llvm::X86Subtarget::isTargetELF() const + 310283 7 llc 0x0000000104d03827 llvm::X86Subtarget::isTargetELF() const + 81247 8 llc 0x0000000104dd065a llvm::DenseMap, llvm::DenseMapInfo >::insert(std::pair const&) + 26290 9 llc 0x0000000104dd28d3 llvm::DenseMap, llvm::DenseMapInfo >::insert(std::pair const&) + 35115 10 llc 0x0000000104dd0106 llvm::DenseMap, llvm::DenseMapInfo >::insert(std::pair const&) + 24926 11 llc 0x0000000104dd28d3 llvm::DenseMap, llvm::DenseMapInfo >::insert(std::pair const&) + 35115 12 llc 0x0000000104dca191 llvm::DenseMap, llvm::DenseMapInfo >::insert(std::pair const&) + 489 13 llc 0x0000000104ed8141 llvm::SelectionDAGBuilder::Case::size() const + 34781 14 llc 0x0000000104ed9dd2 llvm::SelectionDAGBuilder::Case::size() const + 42094 15 llc 0x0000000104edaa2b llvm::SelectionDAGBuilder::Case::size() const + 45255 16 llc 0x0000000104fb7f14 llvm::MachineFunctionAnalysis::getPassName() const + 458 17 llc 0x000000010523333d llvm::cl::parser::~parser() + 26339 18 llc 0x000000010522ed2b llvm::cl::parser::~parser() + 8401 19 llc 0x000000010523303a llvm::cl::parser::~parser() + 25568 20 llc 0x0000000105234461 llvm::cl::parser::~parser() + 30727 21 llc 0x00000001052344e1 llvm::cl::parser::~parser() + 30855 22 llc 0x00000001049b5ed3 23 llc 0x00000001049b4734 24 llc 0x0000000000000003 Stack dump: 0. Program arguments: llc -mattr=+avx bug.bc 1. Running pass 'Function Pass Manager' on module 'bug.bc'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"f_f___REFUf[]REFUf[]"' [1] 23018 illegal hardware instruction llc -mattr=+avx bug.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 Jul 28 15:49:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 15:49:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 10530] New: early-cse somehow produces invalid bitcode, bitcode cannot be read back Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10530 Summary: early-cse somehow produces invalid bitcode, bitcode cannot be read back Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6962) --> (http://llvm.org/bugs/attachment.cgi?id=6962) Testcase Consider the attached testcase. I'm having: $ ./opt -early-cse early-cse-bug.ll | ./llvm-dis Assertion failed: (ShuffleVectorInst::isValidOperands(V1, V2, Mask) && "Invalid shuffle vector constant expr operands!"), function getShuffleVector, file /Users/asl/Projects/llvm/src/lib/VMCore/Constants.cpp, line 1696. so, the bitcode written cannot be read back. PS: Does anyone knows how one can strip unused types from the Module in the shiny new typesystem world? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 16:39:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 16:39:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 10520] Assertion in register scavenger In-Reply-To: References: Message-ID: <20110728213927.CA1042A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10520 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Jakob Stoklund Olesen 2011-07-28 16:39:27 CDT --- Fixed in r136401. Please reopen if you can reproduce the original 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 Jul 28 17:07:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 17:07:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 10520] Assertion in register scavenger In-Reply-To: References: Message-ID: <20110728220752.0675C2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10520 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 28 18:14:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 18:14:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10531] New: In-class initializer weirdness with anonymous unions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10531 Summary: In-class initializer weirdness with anonymous unions Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I couldn't find whether the FDIS forbids this, but it seems to me that it allows this code: #include template static char const * f(T *t) { T u(*t); u.x = "hello world"; printf("%s\n", u.x); return "initialized"; } int main() { union { char const *x = f(this); }; printf("%s\n", x); } I expect that the program compiled by clang outputs: hello world initialized (Copying an union copies its object representation, so I believe I'm fine with copying "*t"). However, Clang generates this IR code for main: $ clang++ -std=c++0x -emit-llvm -S -o - main1.cpp define i32 @main() { %1 = alloca i32, align 4 %2 = alloca %union.anon, align 4 store i32 0, i32* %1 %3 = bitcast %union.anon* %2 to i8** %4 = load i8** %3, align 4 %5 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x i8]* @.str, i32 0, i32 0), i8* %4) %6 = load i32* %1 ret i32 %6 } The call to "f" and the store into x are completely missing. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jul 28 19:27:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 19:27:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10520] Assertion in register scavenger In-Reply-To: References: Message-ID: <20110729002757.3E7F32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10520 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #9 from Jakob Stoklund Olesen 2011-07-28 19:27:56 CDT --- r136440 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 20:27:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 20:27:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10532] New: Assertion `FieldNo < FieldCount && "Invalid Field No"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10532 Summary: Assertion `FieldNo < FieldCount && "Invalid Field No"' failed. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6965) --> (http://llvm.org/bugs/attachment.cgi?id=6965) Failing input Back trace from clang: #3 0x000000000133a34a in clang::ASTRecordLayout::getFieldOffset (this=0x648ce50, FieldNo=13) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/../../include/clang/AST/RecordLayout.h:121 #4 0x0000000001cc28b6 in (anonymous namespace)::EmptySubobjectMap::getFieldOffset (this=0x7fffffff9b30, Layout=..., FieldNo=13) at /home/joerg/work/LLVM/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:97 #5 0x0000000001cc3051 in (anonymous namespace)::EmptySubobjectMap::CanPlaceBaseSubobjectAtOffset (this=0x7fffffff9b30, Info=0x7063d40, Offset=...) at /home/joerg/work/LLVM/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:268 #6 0x0000000001cc33a8 in (anonymous namespace)::EmptySubobjectMap::CanPlaceBaseAtOffset (this=0x7fffffff9b30, Info=0x7063d40, Offset=...) at /home/joerg/work/LLVM/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:329 #7 0x0000000001cc58f5 in (anonymous namespace)::RecordLayoutBuilder::LayoutBase (this=0x7060910, Base=0x7063d40) at /home/joerg/work/LLVM/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:1135 #8 0x0000000001cc5127 in (anonymous namespace)::RecordLayoutBuilder::LayoutNonVirtualBase (this=0x7060910, Base=0x7063d40) at /home/joerg/work/LLVM/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:1005 #9 0x0000000001cc4fed in (anonymous namespace)::RecordLayoutBuilder::LayoutNonVirtualBases (this=0x7060910, RD=0x6dd2e90) at /home/joerg/work/LLVM/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:976 #10 0x0000000001cc5c43 in (anonymous namespace)::RecordLayoutBuilder::Layout (this=0x7060910, RD=0x6dd2e90) at /home/joerg/work/LLVM/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:1190 #11 0x0000000001cc86d4 in clang::ASTContext::getASTRecordLayout (this=0x3d7b440, D=0x6dd2e90) at /home/joerg/work/LLVM/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:1859 #12 0x0000000001419459 in (anonymous namespace)::CGRecordLayoutBuilder::Layout (this=0x7fffffff9c60, D=0x6dd2e90) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:201 #13 0x000000000141bced in clang::CodeGen::CodeGenTypes::ComputeRecordLayout (this=0x3da0a30, D=0x6dd2e90, Ty=0x6fac790) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:930 #14 0x00000000013222bf in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (this=0x3da0a30, RD=0x6dd2e90) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:602 #15 0x000000000132228b in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (this=0x3da0a30, RD=0x6dd9f50) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:597 #16 0x000000000132228b in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (this=0x3da0a30, RD=0x6ddbce0) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:597 #17 0x000000000132228b in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (this=0x3da0a30, RD=0x6e67010) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:597 #18 0x000000000132147a in clang::CodeGen::CodeGenTypes::ConvertType (this=0x3da0a30, T=...) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:288 #19 0x0000000001320c94 in clang::CodeGen::CodeGenTypes::ConvertTypeForMem (this=0x3da0a30, T=...) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:85 #20 0x00000000013217e5 in clang::CodeGen::CodeGenTypes::ConvertType (this=0x3da0a30, T=...) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:388 #21 0x0000000001320c94 in clang::CodeGen::CodeGenTypes::ConvertTypeForMem (this=0x3da0a30, T=...) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:85 #22 0x0000000001450919 in clang::CodeGen::CodeGenFunction::ConvertTypeForMem (this=0x7ffffffface0, T=...) at /home/joerg/work/LLVM/llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp:49 Input is attached, "clang -c" is enough. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 20:27:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 20:27:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 10462] JumpScopeChecker crash on invalid In-Reply-To: References: Message-ID: <20110729012757.2FF132A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10462 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |akyrtzi at gmail.com Resolution| |FIXED --- Comment #2 from Argyrios Kyrtzidis 2011-07-28 20:27:56 CDT --- r136447. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 20:34:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 20:34:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10529] [AVX] Assertion failed: (begin() + idx < end()), function operator[], file SmallVector.h, line 154. In-Reply-To: References: Message-ID: <20110729013417.722762A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10529 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Bruno Cardoso Lopes 2011-07-28 20:34:17 CDT --- Fixed in r136453! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 28 20:36:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 28 Jul 2011 20:36:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 10489] [AVX] "cannot select" v8i32 = X86ISD::PALIGN error In-Reply-To: References: Message-ID: <20110729013610.2CACB2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10489 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bruno Cardoso Lopes 2011-07-28 20:36:09 CDT --- Fixed in r136448 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 29 04:25:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 04:25:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10533] New: False positive garbage/undefined report Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10533 Summary: False positive garbage/undefined report Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: ranma42 at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6966) --> (http://llvm.org/bugs/attachment.cgi?id=6966) Checkers bug report Using checker-257 on the cairo codebase I get some invalid bug reports about garbage values. The attachment shows 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 Fri Jul 29 12:40:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 12:40:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 10519] Clang accepts NSAutoreleasePool in ARC mode In-Reply-To: References: Message-ID: <20110729174031.D2F872A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10519 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rjmccall at apple.com Resolution| |INVALID --- Comment #1 from Chris Lattner 2011-07-29 12:40:31 CDT --- This is by design. These get rejected in ARC mode because system headers have marked them unavailable when __has_feature(ARC). These aren't veto'd by the compiler, they are veto'd by the headers. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 29 12:42:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 12:42:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10532] Assertion `FieldNo < FieldCount && "Invalid Field No"' failed. In-Reply-To: References: Message-ID: <20110729174239.962B72A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10532 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Chris Lattner 2011-07-29 12:42:39 CDT --- *** This bug has been marked as a duplicate of bug 10505 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 29 13:29:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 13:29:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 10534] New: No Opt being performed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10534 Summary: No Opt being performed Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Global Analyses AssignedTo: unassignedbugs at nondot.org ReportedBy: dnicacios at yahoo.com.br CC: llvmbugs at cs.uiuc.edu I used opt -std-compile-opts on llvm-2.9 and everything was fine, but on the trunk version it does not perform some simple optimizations. When I run "opt -std-compile-opts -debug -S FlipBitRun.bc -o FlipBitRun1.bc", it outputs the following IR: while.body: ; preds = %while.body, %entry %0 = phi i32 [ 0, %entry ], [ %inc.3, %while.body ] %shr = lshr i32 %0, 5 %rem = and i32 %0, 28 %shl = shl i32 1, %rem %arrayidx = getelementptr inbounds i32* %bitmap, i32 %shr %tmp6 = load i32* %arrayidx, align 4 %xor = xor i32 %tmp6, %shl store i32 %xor, i32* %arrayidx, align 4 %shr.1 = lshr i32 %0, 5 %inc5 = and i32 %0, 28 %rem.1 = or i32 %inc5, 1 %shl.1 = shl i32 1, %rem.1 %arrayidx.1 = getelementptr inbounds i32* %bitmap, i32 %shr.1 %tmp6.1 = load i32* %arrayidx.1, align 4 %xor.1 = xor i32 %tmp6.1, %shl.1 store i32 %xor.1, i32* %arrayidx.1, align 4 %shr.2 = lshr i32 %0, 5 %inc.16 = and i32 %0, 28 %rem.2 = or i32 %inc.16, 2 %shl.2 = shl i32 1, %rem.2 %arrayidx.2 = getelementptr inbounds i32* %bitmap, i32 %shr.2 %tmp6.2 = load i32* %arrayidx.2, align 4 %xor.2 = xor i32 %tmp6.2, %shl.2 store i32 %xor.2, i32* %arrayidx.2, align 4 %shr.3 = lshr i32 %0, 5 %inc.27 = and i32 %0, 28 %rem.3 = or i32 %inc.27, 3 %shl.3 = shl i32 1, %rem.3 %arrayidx.3 = getelementptr inbounds i32* %bitmap, i32 %shr.3 %tmp6.3 = load i32* %arrayidx.3, align 4 %xor.3 = xor i32 %tmp6.3, %shl.3 store i32 %xor.3, i32* %arrayidx.3, align 4 %inc.3 = add i32 %0, 4 %exitcond.3 = icmp eq i32 %inc.3, 128 br i1 %exitcond.3, label %while.end, label %while.body while.end: ; preds = %while.body ret void clearly, all load, stores should be collapsed into a single one. And identical instruction are not being eliminated, like "%rem = and i32 %0, 28" and "%inc5 = and i32 %0, 28". All those opt were being done successfully on the 2.9 release version, but not on the trunk version. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 29 14:00:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 14:00:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10508] DenseMapInfo's std::pair instance's second Tombstone is set to be the empty key [patch attached] In-Reply-To: References: Message-ID: <20110729190048.3DDF32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10508 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-07-29 14:00:47 CDT --- Nick applied this in r 136336, but didn't close 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 Fri Jul 29 14:03:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 14:03:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10176] reassociate corrupts debug info In-Reply-To: References: Message-ID: <20110729190341.2F80C2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10176 Devang Patel 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 Jul 29 14:20:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 14:20:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 5726] Incorrrect debug info with clang and mem2reg In-Reply-To: References: Message-ID: <20110729192027.8513E2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5726 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Devang Patel 2011-07-29 14:20:26 CDT --- This has been fixed. Please try again using mainline clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 29 15:32:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 15:32:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10473] New type system: Invalid module not caught by verifier In-Reply-To: References: Message-ID: <20110729203255.CADE02A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10473 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-07-29 15:32:54 CDT --- The .bc file dies in the bitcode reader, so there is no way for me to see what the verifier should be doing. I commited a variant of Eli's patch (that adds ->getElementType()) in r136510. If this doesn't fix your issue, then we'll need some other way to know what is going wrong. -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 29 16:03:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 16:03:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10471] FLT_EVAL_METHOD sometimes wrong for Intel FPUs In-Reply-To: References: Message-ID: <20110729210305.BAAAF2A6C131@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10471 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Component|new bugs |Frontend Version|2.8 |trunk Resolution|INVALID | AssignedTo|unassignedbugs at nondot.org |unassignedclangbugs at nondot. | |org Product|new-bugs |clang --- Comment #2 from Chris Lattner 2011-07-29 16:03:05 CDT --- Howard asked me to reconsider this bug. The standard says: "If FLT_EVAL_METHOD equals 0, float_t and double_t shall be float and double, respectively; if FLT_EVAL_METHOD equals 1, they shall both be double; if FLT_EVAL_METHOD equals 2, they shall both be long double; for other values of FLT_EVAL_METHOD, they are otherwise implementation-defined." In practice, GCC and Clang implement FLT_EVAL_METHOD in by just forwarding the definition of __FLT_EVAL_METHOD__ (which is builtin) to FLT_EVAL_METHOD. GCC does set __FLT_EVAL_METHOD__ to 0 by default and to 2 with -mno-sse: $ cat t.c __FLT_EVAL_METHOD__ $ gcc -E t.c -std=gnu99 -mno-sse .. 2 So I agree that this should 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 Fri Jul 29 16:16:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 16:16:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10535] New: assertion (vs. proper diagnostic) on invalid (?) code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10535 Summary: assertion (vs. proper diagnostic) on invalid (?) code Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pageexec at freemail.hu CC: llvmbugs at cs.uiuc.edu with current trunk i get this assertion (simplified example based on some linux code that used to compile fine): $ cat a.c void f(void); inline void f(void) { } extern typeof(f) f; $ clang -c a.c clang: llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp:266: void clang::CodeGen::CodeGenFunction::StartFunction(clang::GlobalDecl, clang::QualType, llvm::Function*, const clang::CodeGen::CGFunctionInfo&, const clang::CodeGen::FunctionArgList&, clang::SourceLocation): Assertion `CurFn->isDeclaration() && "Function already has body?"' failed. 0 libLLVM-3.0svn.so 0xa17b23d8 Stack dump: 0. Program arguments: clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name a.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.1 -momit-leaf-frame-pointer -coverage-file a.o -resource-dir lib/clang/3.0 -ferror-limit 19 -fmessage-length 277 -fdiagnostics-show-option -fcolor-diagnostics -o a.o -x c a.c 1. parser at end of file 2. a.c:3:18: LLVM IR generation of declaration 'f' 3. a.c:2:13: Generating code for declaration 'f' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) if i remove 'inline' from the definition then it compiles fine. is the original code wrong? in any case a proper diagnostic would still be better instead of an assert. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 29 16:35:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 16:35:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 10536] New: Wrong implicit cast on inline asm operands Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10536 Summary: Wrong implicit cast on inline asm operands Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matthewbg at google.com CC: llvmbugs at cs.uiuc.edu, echristo at gmail.com $ cat testcases/asm-uninit.cc inline void atomic_thread_fence_acq_rel() { int dummy; __asm__ __volatile__("xchg %[value], %[mem]" : [value] "=r" (dummy) : [mem] "m" (dummy) : "memory"); } $ clang -cc1 -fsyntax-only -ast-dump -Wuninitialized testcases/asm-uninit.cc testcases/asm-uninit.cc:5:37: warning: variable 'dummy' is uninitialized when used here : [mem] "m" (dummy) ^~~~~ testcases/asm-uninit.cc:2:3: note: variable 'dummy' is declared here int dummy; ^ testcases/asm-uninit.cc:2:12: note: add initialization to silence this warning int dummy; ^ = 0 inline void atomic_thread_fence_acq_rel() (CompoundStmt 0x30f6a10 (DeclStmt 0x30f6650 0x30cc390 "int dummy") (AsmStmt 0x30f6990 (DeclRefExpr 0x30f67d8 'int' lvalue Var 0x30cc390 'dummy' 'int') (ImplicitCastExpr 0x30f6978 'int' (DeclRefExpr 0x30f68a8 'int' lvalue Var 0x30cc390 'dummy' 'int')))) 1 warning generated. We're generating an LValueToRValue cast on the output operand and not on the input operand, which seems odd (and leads to an uninitialized warning on the wrong operand). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 29 16:50:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 16:50:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10537] New: Inter-target dependency of shared libraries Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10537 Summary: Inter-target dependency of shared libraries Product: Build scripts Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: cmake AssignedTo: unassignedbugs at nondot.org ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu, ofv at wanadoo.es At revision 136527. -- Target triple: x86_64-unknown-linux-gnu -- Native target architecture is X86 -- Threads enabled. -- Building with -fPIC -- Targeting X86 -- Targeting PTX -- Clang version: 3.0 -- Configuring done CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "LLVMX86CodeGen" of type SHARED_LIBRARY depends on "LLVMX86AsmPrinter" (weak) depends on "LLVMX86Desc" (weak) "LLVMX86AsmPrinter" of type SHARED_LIBRARY depends on "LLVMX86Utils" (weak) depends on "LLVMX86CodeGen" (strong) "LLVMX86Desc" of type SHARED_LIBRARY depends on "LLVMX86AsmPrinter" (weak) depends on "LLVMX86Info" (weak) depends on "LLVMX86CodeGen" (strong) "LLVMX86Info" of type SHARED_LIBRARY depends on "LLVMX86CodeGen" (strong) "LLVMX86Utils" of type SHARED_LIBRARY depends on "LLVMX86CodeGen" (strong) At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries. -- Build files have been written to: /home/ryuta/devel/llvm/src/llvm-build ==> ERROR: A failure occurred in build(). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 29 19:55:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 19:55:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 10538] New: Assertion failed: (ParmVarDeclBits.ParameterIndex == parameterIndex && "truncation!"), function setScopeInfo Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10538 Summary: Assertion failed: (ParmVarDeclBits.ParameterIndex == parameterIndex && "truncation!"), function setScopeInfo Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rgildea at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6972) --> (http://llvm.org/bugs/attachment.cgi?id=6972) Source file that reproduces the bug The attached preprocessed file causes a clang error using the command: clang++ -c preprocessed_aaa_resolve_main.cpp clang version 3.0 (trunk 136432) Target: x86_64-apple-darwin10.8.0 Thread model: posix Assertion failed: (ParmVarDeclBits.ParameterIndex == parameterIndex && "truncation!"), function setScopeInfo, file /Users/rjgildea/llvm_clang/llvm/tools/clang/lib/Sema/../../include/clang/AST/Decl.h, line 1215.0 clang 0x00000001019a3642 llvm::SmallVectorTemplateBase::grow(unsigned long) + 818 1 clang 0x00000001019a45c3 llvm::SmallVectorTemplateBase::grow(unsigned long) + 4787 2 libSystem.B.dylib 0x00007fff809c51ba _sigtramp + 26 3 libSystem.B.dylib 0x00007fff5fbfa3b0 _sigtramp + 3743633936 4 clang 0x00000001019a3ac2 llvm::SmallVectorTemplateBase::grow(unsigned long) + 1970 5 clang 0x0000000100457659 clang::CodeCompletionBuilder::AddPlaceholderChunk(char const*) + 216457 6 clang 0x0000000100325b17 clang::Parser::LexedMethod::~LexedMethod() + 58871 7 clang 0x0000000100326c8a clang::Parser::LexedMethod::~LexedMethod() + 63338 8 clang 0x000000010032d1c2 clang::Parser::LexedMethod::~LexedMethod() + 89250 9 clang 0x000000010031ec58 clang::Parser::LexedMethod::~LexedMethod() + 30520 10 clang 0x00000001003207cc clang::Parser::LexedMethod::~LexedMethod() + 37548 11 clang 0x000000010037d608 llvm::SmallVectorTemplateBase::grow(unsigned long) + 39336 12 clang 0x000000010037da8e llvm::SmallVectorTemplateBase::grow(unsigned long) + 40494 13 clang 0x0000000100382793 llvm::SmallVectorTemplateBase::grow(unsigned long) + 60211 14 clang 0x00000001003309d1 clang::Parser::DeclaratorScopeObj::EnterDeclaratorScope() + 12913 15 clang 0x000000010033c2f7 clang::Parser::DeclaratorScopeObj::EnterDeclaratorScope() + 60311 16 clang 0x000000010032bc18 clang::Parser::LexedMethod::~LexedMethod() + 83704 17 clang 0x0000000100382278 llvm::SmallVectorTemplateBase::grow(unsigned long) + 58904 18 clang 0x0000000100382bca llvm::SmallVectorTemplateBase::grow(unsigned long) + 61290 19 clang 0x0000000100313ddb llvm::IRBuilder >::CreateGEP(llvm::Value*, llvm::Value*, llvm::Twine const&) + 859 20 clang 0x00000001002dfa6c llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 2204 21 clang 0x000000010002ea01 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 9617 22 clang 0x000000010000b8af llvm::raw_ostream::operator<<(char const*) + 1711 23 clang 0x000000010000214c 24 clang 0x000000010000a6ce std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, std::string const&) + 13550 25 clang 0x0000000100001534 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -main-file-name preprocessed_aaa_resolve_main.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 123.2 -coverage-file preprocessed_aaa_resolve_main.o -resource-dir /usr/local/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 191 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o preprocessed_aaa_resolve_main.o -x c++ preprocessed_aaa_resolve_main.cpp 1. solve_resolve/resolve/get_inputs.hpp:278:20: current parser token ',' 2. solve_resolve/resolve/get_inputs.hpp:18:1: parsing namespace 'resolve' clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jul 29 20:31:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 29 Jul 2011 20:31:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10539] New: basic_string constructors do not properly line up with standard Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10539 Summary: basic_string constructors do not properly line up with standard Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: scshunt at csclub.uwaterloo.ca CC: llvmbugs at cs.uiuc.edu There are a couple of constructors of base_string that do not precisely match the standard. There is basic_string(const_pointer) and basic_string(const_pointer, const allocator_type&); these should be merged into one with a default argument. Additionally, they should not take a const_pointer; they should take a const _CharT*, since this type does not vary for user-provided allocators. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 30 10:42:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 30 Jul 2011 10:42:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10540] New: llvm-trunk+dragonegg trunk: Cannot pop empty stack! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10540 Summary: llvm-trunk+dragonegg trunk: Cannot pop empty stack! Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: tabloid.adroit at gmail.com CC: llvmbugs at cs.uiuc.edu when compiling a fortran file, I got " Cannot pop empty stack! " error. using gcc-4.5-branch. $ gfortran -c m_rankMerge.F90 $ gfortran -c -fplugin=~/Install/dragonegg/trunk/dragonegg.so m_rankMerge.F90 LLVM ERROR: Cannot pop empty stack! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 30 19:55:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 30 Jul 2011 19:55:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 10473] New type system: Invalid module not caught by verifier In-Reply-To: References: Message-ID: <20110731005545.D93632A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10473 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #5 from Eli Friedman 2011-07-30 19:55:44 CDT --- Reopening per Talin's comment. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 30 20:38:58 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 30 Jul 2011 20:38:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 10542] New: Debug information synthesis during RAGreedy run takes a shockingly long time Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10542 Summary: Debug information synthesis during RAGreedy run takes a shockingly long time Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Register Allocator AssignedTo: unassignedbugs at nondot.org ReportedBy: chandlerc at gmail.com CC: llvmbugs at cs.uiuc.edu This looked initially like an infloop to me, but if you wait long enough, it actually completes. It's very easy to reproduce this: you hit it when self-hosting LLVM+Clang in a opt + debug info build. Specifically, lib/VMCore/Function.cpp takes 6.5 seconds to compile on my system with -O2. However, with -O2 -g it takes over 5 minutes. When I attach with gdb I get this: (gdb) bt #0 llvm::MachineBasicBlock::SkipPHIsAndLabels (this=, I=) at /home/chandlerc/src/llvm.git/include/llvm/CodeGen/MachineInstr.h:199 #1 0x0000000000f4c771 in findInsertLocation (this=, MBB=, LocNo=, LIS=Unhandled dwarf expression opcode 0xd6 ) at /home/chandlerc/src/llvm.git/lib/CodeGen/LiveDebugVariables.cpp:872 #2 (anonymous namespace)::UserValue::insertDebugValue (this=, MBB=, LocNo=, LIS=Unhandled dwarf expression opcode 0xd6 ) at /home/chandlerc/src/llvm.git/lib/CodeGen/LiveDebugVariables.cpp:892 #3 0x0000000000f4bce2 in llvm::LiveDebugVariables::emitDebugValues (this=, VRM=) at /home/chandlerc/src/llvm.git/lib/CodeGen/LiveDebugVariables.cpp:934 #4 0x0000000000ea9edb in (anonymous namespace)::RAGreedy::runOnMachineFunction (this=, mf=) at /home/chandlerc/src/llvm.git/lib/CodeGen/RegAllocGreedy.cpp:1598 #5 0x0000000000e74cbc in llvm::MachineFunctionPass::runOnFunction (this=, F=) at /home/chandlerc/src/llvm.git/lib/CodeGen/MachineFunctionPass.cpp:33 #6 0x00000000011131ae in llvm::FPPassManager::runOnFunction (this=, F=Unhandled dwarf expression opcode 0x0 ) at /home/chandlerc/src/llvm.git/lib/VMCore/PassManager.cpp:1513 #7 0x000000000111349b in llvm::FPPassManager::runOnModule (this=, M=) at /home/chandlerc/src/llvm.git/lib/VMCore/PassManager.cpp:1535 #8 0x00000000011135e2 in llvm::MPPassManager::runOnModule (this=, M=Unhandled dwarf expression opcode 0x0 ) at /home/chandlerc/src/llvm.git/lib/VMCore/PassManager.cpp:1589 #9 0x0000000001113bc1 in llvm::PassManagerImpl::run (this=, M=) at /home/chandlerc/src/llvm.git/lib/VMCore/PassManager.cpp:1671 #10 0x000000000111410d in llvm::PassManager::run (this=, M=) at /home/chandlerc/src/llvm.git/lib/VMCore/PassManager.cpp:1715 #11 0x000000000118d29c in clang::EmitBackendOutput (Diags=, CGOpts=, TOpts=, LOpts=, M=, Action=, OS=) at /home/chandlerc/src/llvm.git/tools/clang/lib/CodeGen/BackendUtil.cpp:388 #12 0x000000000118b767 in clang::BackendConsumer::HandleTranslationUnit (this=Unhandled dwarf expression opcode 0x0 ) at /home/chandlerc/src/llvm.git/tools/clang/lib/CodeGen/CodeGenAction.cpp:134 #13 0x0000000000732fae in clang::ParseAST (S=, PrintStats=) at /home/chandlerc/src/llvm.git/tools/clang/lib/Parse/ParseAST.cpp:101 #14 0x000000000118acc1 in clang::CodeGenAction::ExecuteAction (this=Unhandled dwarf expression opcode 0x0 ) at /home/chandlerc/src/llvm.git/tools/clang/lib/CodeGen/CodeGenAction.cpp:347 #15 0x00000000006b2f4b in clang::CompilerInstance::ExecuteAction (this=Unhandled dwarf expression opcode 0x0 ) at /home/chandlerc/src/llvm.git/tools/clang/lib/Frontend/CompilerInstance.cpp:614 #16 0x00000000006ffb70 in clang::ExecuteCompilerInvocation (Clang=) at /home/chandlerc/src/llvm.git/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:171 #17 0x000000000065c4ec in cc1_main (ArgBegin=, ArgEnd=Unhandled dwarf expression opcode 0x0 ) at /home/chandlerc/src/llvm.git/tools/clang/tools/driver/cc1_main.cpp:159 #18 0x0000000000657e33 in main (argc_=, argv_=) at /home/chandlerc/src/llvm.git/tools/clang/tools/driver/driver.cpp:353 I've spent some time looking at exactly what's going on with this. If I break down the backtrace and interrupt the compilation more frequently I observe the following pattern: (gdb) bt #0 llvm::MachineBasicBlock::SkipPHIsAndLabels (this=, I=) at /home/chandlerc/src/llvm.git/include/llvm/CodeGen/MachineInstr.h:199 #1 0x0000000000f4c771 in findInsertLocation (this=, MBB=, LocNo=, LIS=Unhandled dwarf expression opcode 0xd6 ) at /home/chandlerc/src/llvm.git/lib/CodeGen/LiveDebugVariables.cpp:872 #2 (anonymous namespace)::UserValue::insertDebugValue (this=, MBB=, LocNo=, LIS=Unhandled dwarf expression opcode 0xd6 ) at /home/chandlerc/src/llvm.git/lib/CodeGen/LiveDebugVariables.cpp:892 These three frames change on each interruption. the 'this' values tend to cycle etc if I use an un-optimized build of Clang so I have full debug info. #3 0x0000000000f4bce2 in llvm::LiveDebugVariables::emitDebugValues (this=, VRM=) at /home/chandlerc/src/llvm.git/lib/CodeGen/LiveDebugVariables.cpp:934 #4 0x0000000000ea9edb in (anonymous namespace)::RAGreedy::runOnMachineFunction (this=, mf=) at /home/chandlerc/src/llvm.git/lib/CodeGen/RegAllocGreedy.cpp:1598 These frames (and the rest) tended to remain the same. Not sure if (or how much) that helps. I can try to get a reduced test case, but I worry that won't really help understand the problem any better than just reproducing and looking at why we're iterating through these value structures soooo many times. I've attached a preprocessed test case just for convenience. This was extracted by building LLVM itself in verbose mode, and preprocessing Function.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 Sat Jul 30 23:20:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 30 Jul 2011 23:20:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10543] New: llvm-g++ segfaults compiling synfigstudio Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10543 Summary: llvm-g++ segfaults compiling synfigstudio Product: tools Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: llvm-g++ AssignedTo: unassignedbugs at nondot.org ReportedBy: htodd at twofifty.com CC: llvmbugs at cs.uiuc.edu gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) Attaching logs and the .ii file. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 31 01:02:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 31 Jul 2011 01:02:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 10543] llvm-g++ segfaults compiling synfigstudio In-Reply-To: References: Message-ID: <20110731060225.0D6C92A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10543 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-07-31 01:02:24 CDT --- llvm-gcc is obsolete, please upgrade to clang. If you're experiencing this with an apple compiler, please file a radar at http://bugreport.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 Sun Jul 31 02:14:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 31 Jul 2011 02:14:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 10543] llvm-g++ segfaults compiling synfigstudio In-Reply-To: References: Message-ID: <20110731071410.B90C92A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10543 htodd at twofifty.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #4 from htodd at twofifty.com 2011-07-31 02:14:10 CDT --- Ah, well, it happens with clang as well, and I filed a radar as well. I just filed here figuring you guys would care. Do you 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 Jul 31 10:51:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 31 Jul 2011 10:51:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10544] New: Darwin (10.7) llvm compiler generates bad code when compiling gcc-4.5.4-linaro for OpenWRT router project Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10544 Summary: Darwin (10.7) llvm compiler generates bad code when compiling gcc-4.5.4-linaro for OpenWRT router project Product: new-bugs Version: unspecified Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: joe at roback.cc CC: llvmbugs at cs.uiuc.edu Compiling OpenWRT from trunk for MIPS router, the OpenWRT build systems builds a toolchain for the MIPS binaries with uClibc-0.9.32 and gcc-4.5.4 with linaro enhancements. As of Mac OS X 10.7, Apple now defaults to llvm, and it causes the cross-compiler to fail and the "cfun" global to be NULL in the cross compiler. (It is like its optimizing it out or something). No matter what is attempted to be compiled, even a simple hello world, it results in the same gcc_assert() failing. For example, libpthread/nptl/sysdeps/unix/sysv/linux/gen_lowlevelbarrier.c:12:1: internal compiler error: in execute_ipa_pass_list, at passes.c:1804 If I switch back to straight gcc-4.2 by overriding the the CC and CXX variables, the entire OpenWRT build completes without 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 Sun Jul 31 11:59:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 31 Jul 2011 11:59:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10543] Xcode 4.1 clang segfaults compiling synfigstudio In-Reply-To: References: Message-ID: <20110731165900.A04402A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10543 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #12 from Chris Lattner 2011-07-31 11:59:00 CDT --- No we don't, llvm-gcc is obsolete as far as llvm.org goes. Thank you for filing the radar! -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 31 11:59:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 31 Jul 2011 11:59:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10543] Xcode 4.1 clang segfaults compiling synfigstudio In-Reply-To: References: Message-ID: <20110731165905.8728F2A6C131@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10543 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |WONTFIX -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 31 12:02:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 31 Jul 2011 12:02:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10543] Xcode 4.1 clang segfaults compiling synfigstudio In-Reply-To: References: Message-ID: <20110731170249.CC1712A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10543 htodd at twofifty.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #13 from htodd at twofifty.com 2011-07-31 12:02:49 CDT --- The actual problem is my misunderstanding. The problem occurs in clang++, and I thought the community developed version was currently llvm-g++. Should I re-open this correctly or should I just change the compiler and add the correct log file? Thanks. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jul 31 12:04:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 31 Jul 2011 12:04:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 10507] unordered_set::erase(const key_type& k) does not call element's destructor In-Reply-To: References: Message-ID: <20110731170450.ACEA12A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10507 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Howard Hinnant 2011-07-31 12:04:50 CDT --- Fix committed to trunk: Committed revision 136595. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jul 31 16:19:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 31 Jul 2011 16:19:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 10545] New: Compilation failures around structs in code generated by C backend Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10545 Summary: Compilation failures around structs in code generated by C backend Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: maemarcus at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6982) --> (http://llvm.org/bugs/attachment.cgi?id=6982) Patch with suggested fixes Code generated by C backend as of rev 136600 produces errors when compiled with gcc due to missing struct keyword in three places and incorrectly placed name for structure embedding array. Attached is patch to fix these 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 Sun Jul 31 22:56:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 31 Jul 2011 22:56:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 10546] New: Block capturing self with __weak in ARC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10546 Summary: Block capturing self with __weak in ARC Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: remy.demarest at gmail.com CC: llvmbugs at cs.uiuc.edu I would like to know if it's possible to add a feature to the blocks to allow capturing variables in a weak manner inside blocks (especially self) to avoid weak references. Currently, the recommendation to capture self in a block is this (example with NSNotification): __weak MyClass *weakSelf = self; [[NSNotificationCenter defaultCenter] addObserverForName:NSApplicationDidResignActiveNotification object:nil queue:nil usingBlock: ^(NSNotification *note) { __strong MyClass *fakeSelf = weakSelf; if(fakeSelf != nil) { fakeSelf->someIvar = value; } }]; This is incredibly verbose and repetitive for something that can be quite common. I propose to introduce a syntax allowing the developer to import self in a weak manner, and have it converted to a strong object in the block directly. Something along these lines: [[NSNotificationCenter defaultCenter] addObserverForName:NSApplicationDidResignActiveNotification object:nil queue:nil usingBlock: ^(NSNotification *note) { | __weak self | // Finding a new use to an old syntax if(self != nil) { // it's not necessary to explicitly put self-> to affect that variable someIvar = value; } }]; What this syntax means is that self is captured weakly by the block, when the block is executed, the block loads the weak self into a local strong variable thus retaining self for the time the block is executing, and releasing it at the end of the execution (or when the compiler thinks it's necessary). The behaviour of that construction is exactly the same as the one in the previous syntax, and remains also pretty explicit, but it reduces the code for the whole capture. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.