From bugzilla-daemon at llvm.org Thu Sep 1 03:43:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 03:43:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 10823] New: Failed assertion: `DefinitionData && "queried property of class with no definition"' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10823 Summary: Failed assertion: `DefinitionData && "queried property of class with no definition"' Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping at exherbo.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=7186) --> (http://llvm.org/bugs/attachment.cgi?id=7186) delta-reduced input (not valid code but manages to make clang++ crash) Reduced from libc++/src/locale.cpp % clang++ -c locale-ThMXu8.ii locale-ThMXu8.ii:1:51: error: expected class name template struct __num_get : protected __num_get_base { ^ locale-ThMXu8.ii:2:10: error: unknown type name 'string' static string __stage2_int_prep(ios_base& __iob); ^ locale-ThMXu8.ii:2:37: error: unknown type name 'ios_base' static string __stage2_int_prep(ios_base& __iob); ^ locale-ThMXu8.ii:6:16: error: no template named 'num_get'; did you mean '__num_get'? template class num_get; ^~~~~~~ __num_get locale-ThMXu8.ii:1:29: note: '__num_get' declared here template struct __num_get : protected __num_get_base { ^ clang: /var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/lib/Sema/../../include/clang/AST/DeclCXX.h:530: const clang::CXXRecordDecl::DefinitionData& clang::CXXRecordDecl::data() const: Assertion `DefinitionData && "queried property of class with no definition"' failed. 0 libLLVM-3.0svn.so 0x00007f82f313802f 1 libLLVM-3.0svn.so 0x00007f82f3138790 2 libpthread.so.0 0x00007f82f2115f10 3 libc.so.6 0x00007f82f14345c5 gsignal + 53 4 libc.so.6 0x00007f82f14358c5 abort + 389 5 libc.so.6 0x00007f82f142d235 __assert_fail + 245 6 clang 0x0000000000927e5f clang::Sema::MarkVTableUsed(clang::SourceLocation, clang::CXXRecordDecl*, bool) + 79 7 clang 0x0000000000a96be7 clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 185 8 clang 0x0000000000a29f39 clang::Sema::ActOnExplicitInstantiation(clang::Scope*, clang::SourceLocation, clang::SourceLocation, unsigned int, clang::SourceLocation, clang::CXXScopeSpec const&, clang::OpaquePtr, clang::SourceLocation, clang::SourceLocation, clang::ASTTemplateArgsPtr, clang::SourceLocation, clang::AttributeList*) + 2085 9 clang 0x0000000000827d83 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 3337 10 clang 0x000000000081587a clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 5760 11 clang 0x00000000007ea511 clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 885 12 clang 0x00000000007eef3b clang::Parser::ParseExplicitInstantiation(clang::SourceLocation, clang::SourceLocation, clang::SourceLocation&) + 91 13 clang 0x00000000007ef25e clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 766 14 clang 0x000000000081646f clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 191 15 clang 0x00000000007fdda7 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1675 16 clang 0x00000000007fe847 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 241 17 clang 0x00000000007d1210 clang::ParseAST(clang::Sema&, bool) + 308 18 clang 0x0000000000593c64 clang::ASTFrontendAction::ExecuteAction() + 200 19 clang 0x00000000006884c9 clang::CodeGenAction::ExecuteAction() + 2691 20 clang 0x0000000000594203 clang::FrontendAction::Execute() + 389 21 clang 0x0000000000581410 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 868 22 clang 0x00000000005680cd clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3805 23 clang 0x000000000055eeee cc1_main(char const**, char const**, char const*, void*) + 7074 24 clang 0x0000000000565078 main + 751 25 libc.so.6 0x00007f82f1420c7d __libc_start_main + 253 26 clang 0x000000000055d179 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name locale-ThMXu8.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 locale-ThMXu8.o -resource-dir /usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 118 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o locale-ThMXu8.o -x c++-cpp-output locale-ThMXu8.ii 1. locale-ThMXu8.ii:6:32: current parser token ';' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. % -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 1 03:45:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 03:45:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10824] New: Segmentation Fault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10824 Summary: Segmentation Fault 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=7187) --> (http://llvm.org/bugs/attachment.cgi?id=7187) delta-reduced input (not valid code but manages to make clang++ crash) Reduced from libc++/src/locale.cpp % clang++ -std=c++0x locale-ThMXu8.ii locale-ThMXu8.ii:1:9: error: address expression must be an lvalue or a function designator typedef union { ^~~~~ 0 libLLVM-3.0svn.so 0x00007f0425d2602f 1 libLLVM-3.0svn.so 0x00007f0425d26790 2 libpthread.so.0 0x00007f0424d03f10 3 clang 0x0000000000e52430 clang::Expr::hasAnyTypeDependentArguments(clang::Expr**, unsigned int) + 38 4 clang 0x000000000098030a clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, clang::ASTMultiPtr, clang::SourceLocation, clang::Expr*) + 566 5 clang 0x000000000091a953 clang::Sema::DefineImplicitMoveAssignment(clang::SourceLocation, clang::CXXMethodDecl*) + 6369 6 clang 0x000000000095bc77 clang::Sema::MarkDeclarationReferenced(clang::SourceLocation, clang::Decl*) + 869 7 clang 0x00000000009ff199 clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int, clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*) + 1581 8 clang 0x000000000097cab6 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 274 9 clang 0x000000000097d52a clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 2456 10 clang 0x000000000082f9a5 clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) + 2533 11 clang 0x000000000082fb75 clang::Parser::ParseAssignmentExpression() + 335 12 clang 0x0000000000830919 clang::Parser::ParseExpression() + 9 13 clang 0x00000000007e92f2 clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 74 14 clang 0x00000000007e522a clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 2816 15 clang 0x00000000007e2845 clang::Parser::ParseCompoundStatementBody(bool) + 2395 16 clang 0x00000000007e2f07 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 217 17 clang 0x0000000000805256 clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 3608 18 clang 0x00000000008058de clang::Parser::LexedMethod::ParseLexedMethodDefs() + 16 19 clang 0x00000000008043e9 clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 185 20 clang 0x0000000000826f78 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 3750 21 clang 0x00000000008286e0 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 5734 22 clang 0x000000000081587a clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 5760 23 clang 0x00000000007fbb8f clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 93 24 clang 0x00000000007fc282 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 696 25 clang 0x00000000007fe27d clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2913 26 clang 0x00000000007fe847 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 241 27 clang 0x00000000007d1210 clang::ParseAST(clang::Sema&, bool) + 308 28 clang 0x0000000000593c64 clang::ASTFrontendAction::ExecuteAction() + 200 29 clang 0x00000000006884c9 clang::CodeGenAction::ExecuteAction() + 2691 30 clang 0x0000000000594203 clang::FrontendAction::Execute() + 389 31 clang 0x0000000000581410 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 868 32 clang 0x00000000005680cd clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3805 33 clang 0x000000000055eeee cc1_main(char const**, char const**, char const*, void*) + 7074 34 clang 0x0000000000565078 main + 751 35 libc.so.6 0x00007f042400ec7d __libc_start_main + 253 36 clang 0x000000000055d179 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name locale-ThMXu8.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 -resource-dir /usr/bin/../lib/clang/3.0 -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 118 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/locale-ThMXu8-q8Yp1g.o -x c++-cpp-output locale-ThMXu8.ii 1. locale-ThMXu8.ii:11:38: current parser token ';' 2. locale-ThMXu8.ii:7:1: parsing struct/union/class body 'mutex' 3. locale-ThMXu8.ii:10:11: parsing function body 'mutex' 4. locale-ThMXu8.ii:10:11: 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) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. % -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 1 06:50:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 06:50:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 10824] Segmentation Fault In-Reply-To: References: Message-ID: <20110901115031.73A3C2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10824 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Douglas Gregor 2011-09-01 06:50:30 CDT --- Ah, this is the same as http://llvm.org/bugs/show_bug.cgi?id=10822 which I fixed last night. *** This bug has been marked as a duplicate of bug 10822 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 07:25:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 07:25:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10825] New: [AVX] Assertion failed: (0 && "getSizeInBits called on extended MVT.") in CodeGen/ValueTypes.h Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10825 Summary: [AVX] Assertion failed: (0 && "getSizeInBits called on extended MVT.") in CodeGen/ValueTypes.h 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=7188) --> (http://llvm.org/bugs/attachment.cgi?id=7188) test case With top-of-tree and the attached bitcode file, I'm seeing the following crash/assertion failure: % llc -mattr=+avx bugpoint-reduced-simplified.ll Assertion failed: (0 && "getSizeInBits called on extended MVT."), function getSizeInBits, file /Users/mmp/llvm-dev-src/include/llvm/CodeGen/ValueTypes.h, line 251. 0 llc 0x00000001048444a2 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6504 1 llc 0x0000000104844aa9 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 8047 2 libsystem_c.dylib 0x00007fff88c4dcfa _sigtramp + 26 3 libsystem_c.dylib 000000000000000000 _sigtramp + 18446603338221560608 4 llc 0x0000000104844406 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6348 5 llc 0x0000000104844458 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6430 6 llc 0x000000010429c8dd llvm::X86Subtarget::isTargetELF() const + 303765 7 llc 0x00000001042691db llvm::X86Subtarget::isTargetELF() const + 93075 8 llc 0x000000010434237a llvm::DenseMap, llvm::DenseMapInfo >::insert(std::pair const&) + 26434 9 llc 0x000000010433be21 llvm::DenseMap, llvm::DenseMapInfo >::insert(std::pair const&) + 489 10 llc 0x000000010444cc81 llvm::SelectionDAGBuilder::Case::size() const + 34861 11 llc 0x000000010444e902 llvm::SelectionDAGBuilder::Case::size() const + 42158 12 llc 0x000000010444f56b llvm::SelectionDAGBuilder::Case::size() const + 45335 13 llc 0x0000000104524754 llvm::MachineFunctionAnalysis::getPassName() const + 458 14 llc 0x00000001047ab3ed llvm::cl::parser::~parser() + 26675 15 llc 0x00000001047a698b llvm::cl::parser::~parser() + 7633 16 llc 0x00000001047ab0ea llvm::cl::parser::~parser() + 25904 17 llc 0x00000001047ac501 llvm::cl::parser::~parser() + 31047 18 llc 0x00000001047ac581 llvm::cl::parser::~parser() + 31175 19 llc 0x00000001041c9c73 20 llc 0x00000001041c8534 21 llc 0x0000000000000003 Stack dump: 0. Program arguments: llc -mattr=+avx bugpoint-reduced-simplified.ll 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"f_f___REFUf[]REFUf[]"' [1] 5845 illegal hardware instruction llc -mattr=+avx bugpoint-reduced-simplified.ll -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 1 08:39:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 08:39:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10826] New: Code completion in macro with # operator crashes libclang Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10826 Summary: Code completion in macro with # operator crashes libclang Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: Erik.Verbruggen at Me.com CC: llvmbugs at cs.uiuc.edu It looks like MacroArgs::StringifyArgument doesn't handle # operator arguments correctly. So when doing code-completion with: #define A(x) "A"#x A() then this causes an out-of-bounds array access. When running c-index-test on the attached test case, the stack-trace is: #0 0x00007fff90adece2 in __pthread_kill () #1 0x00007fff8afde7d2 in pthread_kill () #2 0x0000000100ad755f in raise (sig=6) at Signals.inc:281 #3 0x0000000100ad7590 in abort () at Signals.inc:298 #4 0x0000000100ad765d in __assert_rtn (func=0x100aff350 "operator[]", file=0x100b88650 "/data/clang-llvm/llvm/include/llvm/ADT/SmallVector.h", line=150, expr=0x100afb2ad "begin() + idx < end()") at Signals.inc:294 #5 0x0000000100ad4705 in llvm::SmallVectorTemplateCommon::operator[] (this=0x102ffd080, idx=1) at SmallVector.h:150 #6 0x0000000100a129cb in clang::MacroArgs::StringifyArgument (ArgToks=0x1031091b0, PP=@0x104001a00, Charify=false, hashInstLoc={ID = 2147492696}) at MacroArgs.cpp:229 #7 0x0000000100a12fe7 in clang::MacroArgs::getStringifiedArgument (this=0x103109170, ArgNo=0, PP=@0x104001a00, hashInstLoc={ID = 2147492696}) at MacroArgs.cpp:300 #8 0x0000000100a4c56a in clang::TokenLexer::ExpandFunctionArguments (this=0x103108ea0) at TokenLexer.cpp:151 #9 0x0000000100a4a8d5 in clang::TokenLexer::Init (this=0x103108ea0, Tok=@0x10401f010, ELEnd={ID = 171}, Actuals=0x103109170) at TokenLexer.cpp:69 #10 0x0000000100a29758 in clang::Preprocessor::EnterMacro (this=0x104001a00, Tok=@0x10401f010, ILEnd={ID = 171}, Args=0x103109170) at PPLexerChange.cpp:153 #11 0x0000000100a30b7b in clang::Preprocessor::HandleMacroExpandedIdentifier (this=0x104001a00, Identifier=@0x10401f010, MI=0x104036770) at PPMacroExpansion.cpp:308 #12 0x0000000100a43ea6 in clang::Preprocessor::HandleIdentifier (this=0x104001a00, Identifier=@0x10401f010) at Preprocessor.cpp:489 #13 0x0000000100a04ee1 in clang::Lexer::LexIdentifier (this=0x103108100, Result=@0x10401f010, CurPtr=0x1031072ba "(") at Lexer.cpp:1279 #14 0x0000000100a06f1a in clang::Lexer::LexTokenInternal (this=0x103108100, Result=@0x10401f010) at Lexer.cpp:2481 #15 0x00000001001f281b in clang::Lexer::Lex (this=0x103108100, Result=@0x10401f010) at Lexer.h:130 #16 0x0000000100387b35 in clang::Preprocessor::Lex (this=0x104001a00, Result=@0x10401f010) at Preprocessor.h:548 #17 0x0000000100a189f7 in clang::Preprocessor::CachingLex (this=0x104001a00, Result=@0x10401f010) at PPCaching.cpp:57 #18 0x0000000100387bed in clang::Preprocessor::Lex (this=0x104001a00, Result=@0x10401f010) at Preprocessor.h:554 #19 0x00000001003a7871 in clang::Parser::ConsumeParen (this=0x10401f000) at Parser.h:324 #20 0x00000001003c2ffc in clang::Parser::SkipUntil (this=0x10401f000, Toks=0x102ffeab4, NumToks=1, StopAtSemi=false, DontConsume=false, StopAtCodeCompletion=true) at Parser.cpp:264 #21 0x00000001003ceb75 in clang::Parser::SkipUntil (this=0x10401f000, T=clang::tok::r_brace, StopAtSemi=false, DontConsume=false, StopAtCodeCompletion=true) at Parser.h:624 #22 0x00000001003ad669 in clang::Parser::trySkippingFunctionBodyForCodeCompletion (this=0x10401f000) at ParseStmt.cpp:1883 #23 0x00000001003b5371 in clang::Parser::ParseFunctionStatementBody (this=0x10401f000, Decl=0x104037410, BodyScope=@0x102ffede0) at ParseStmt.cpp:1816 #24 0x00000001003c8f2a in clang::Parser::ParseFunctionDefinition (this=0x10401f000, D=@0x102fff0e0, TemplateInfo=@0x102fff668) at Parser.cpp:988 #25 0x000000010035ddf5 in clang::Parser::ParseDeclGroup (this=0x10401f000, DS=@0x102fff950, Context=0, AllowFunctionDefinitions=true, DeclEnd=0x0, FRI=0x0) at ParseDecl.cpp:886 #26 0x00000001003c671e in clang::Parser::ParseDeclarationOrFunctionDefinition (this=0x10401f000, DS=@0x102fff950, AS=clang::AS_none) at Parser.cpp:806 #27 0x00000001003c67c1 in clang::Parser::ParseDeclarationOrFunctionDefinition (this=0x10401f000, attrs=@0x103000320, AS=clang::AS_none) at Parser.cpp:819 #28 0x00000001003cad60 in clang::Parser::ParseExternalDeclaration (this=0x10401f000, attrs=@0x103000320, DS=0x0) at Parser.cpp:689 #29 0x00000001003cb2a2 in clang::Parser::ParseTopLevelDecl (this=0x10401f000, Result=@0x1030003d8) at Parser.cpp:510 #30 0x000000010034f13b in clang::ParseAST (S=@0x10401e000, PrintStats=false) at ParseAST.cpp:84 #31 0x00000001001c63bf in clang::ASTFrontendAction::ExecuteAction (this=0x103100c30) at FrontendAction.cpp:403 #32 0x00000001001c6557 in clang::FrontendAction::Execute (this=0x103100c30) at FrontendAction.cpp:323 #33 0x000000010018ec40 in clang::ASTUnit::CodeComplete (this=0x103801a00, File={Data = 0x101c00a60 "/data/clang-llvm/llvm/tools/clang/test/Index/complete-in-macro.c", Length = 64}, Line=12, Column=11, RemappedFiles=0x103000d80, NumRemappedFiles=0, IncludeMacros=true, IncludeCodePatterns=false, Consumer=@0x103000c00, Diag=@0x103100490, LangOpts=@0x103100368, SourceMgr=@0x103100930, FileMgr=@0x103100770, StoredDiagnostics=@0x1031000c0, OwnedBuffers=@0x1031003c0) at ASTUnit.cpp:2283 #34 0x000000010014befc in clang_codeCompleteAt_Impl (UserData=0x101d80c28) at CIndexCodeCompletion.cpp:672 #35 0x0000000100ac47d9 in llvm::CrashRecoveryContext::RunSafely (this=0x101d80c18, Fn=0x10014ba30 , UserData=0x101d80c28) at CrashRecoveryContext.cpp:309 #36 0x0000000100ac44d9 in RunSafelyOnThread_Dispatch (UserData=0x101d80b58) at CrashRecoveryContext.cpp:340 #37 0x0000000100add9a8 in ExecuteOnThread_Dispatch (Arg=0x101d80b18) at Threading.cpp:75 #38 0x00007fff8afdc8bf in _pthread_start () #39 0x00007fff8afdfb75 in thread_start () -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 08:53:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 08:53:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10827] New: Crash when analyzing a file Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10827 Summary: Crash when analyzing a file Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: tobias.hunger at gmx.de CC: llvmbugs at cs.uiuc.edu I get a crash when running the attached file through the analyzer. Sources are taken from SVN, llvm was last changed at rev. 138934, clang at rev. 138937. The output is also 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 Thu Sep 1 11:26:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 11:26:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10744] Can't specify linker to use with the -B flag In-Reply-To: References: Message-ID: <20110901162617.A005D2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10744 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #7 from Rafael ?vila de Esp?ndola 2011-09-01 11:26:17 CDT --- Fixed in r138941. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 11:32:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 11:32:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10828] New: No warning for Most Vexing Parse of 0-argument function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10828 Summary: No warning for Most Vexing Parse of 0-argument function Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matthewbg at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang gives no warning for the following code: class C { C () { } }; void f() { C c(); } We should warn on ambiguous declarations in block 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 Sep 1 11:43:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 11:43:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 10829] New: Possible problem with debug metadata generated for empty 'return' statements Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10829 Summary: Possible problem with debug metadata generated for empty 'return' statements Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: eliben at gmail.com CC: llvmbugs at cs.uiuc.edu Consider this C code: void func(char c, char* d) { *d = c + 1; return; } The LLVM IR generated with "clang -g -S -O0 -emit-llvm" is: define void @func(i8 signext %c, i8* %d) nounwind { entry: %c.addr = alloca i8, align 1 %d.addr = alloca i8*, align 4 store i8 %c, i8* %c.addr, align 1 call void @llvm.dbg.declare(metadata !{i8* %c.addr}, metadata !11), !dbg !13 store i8* %d, i8** %d.addr, align 4 call void @llvm.dbg.declare(metadata !{i8** %d.addr}, metadata !14), !dbg !16 %tmp = load i8* %c.addr, align 1, !dbg !17 %conv = sext i8 %tmp to i32, !dbg !17 %add = add nsw i32 %conv, 1, !dbg !17 %conv1 = trunc i32 %add to i8, !dbg !17 %tmp2 = load i8** %d.addr, align 4, !dbg !17 store i8 %conv1, i8* %tmp2, !dbg !17 ret void, !dbg !19 } Relevant metadata nodes: !17 = metadata !{i32 3, i32 5, metadata !18, null} !19 = metadata !{i32 5, i32 1, metadata !18, null} As you can see, the metadata node attached to the 'ret void' instruction reports line 5, although the 'return' is on line 4. This is an error, which will cause a breakpoint placed on the 'return' not to stop there. Some preliminary investigation in the source code of Clang reveals that in all likeness Clang optimizes away the empty "return" at the end of the function, using its own return inserted by CodeGenFunction::EmitFunctionEpilog Examination of emitted AST shows that the return statement appears there, so the optimization is done after 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 Thu Sep 1 12:36:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 12:36:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 9535] LegalizeVectorTypes.cpp assertion hits (v8f32 fp_round) In-Reply-To: References: Message-ID: <20110901173644.345BD2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9535 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |evan.cheng at apple.com Resolution| |FIXED --- Comment #2 from Evan Cheng 2011-09-01 12:36:43 CDT --- Bruno said 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 Thu Sep 1 13:15:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 13:15:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10825] [AVX] Assertion failed: (0 && "getSizeInBits called on extended MVT.") in CodeGen/ValueTypes.h In-Reply-To: References: Message-ID: <20110901181529.8B2032A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10825 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Bruno Cardoso Lopes 2011-09-01 13:15:29 CDT --- Fixed in r138951 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 16:04:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 16:04:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 10817] getline broken, reads an extra line In-Reply-To: References: Message-ID: <20110901210413.8B64A2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10817 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 Thu Sep 1 17:04:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 17:04:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 10830] New: missing error when bound member function not called Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10830 Summary: missing error when bound member function not called Product: clang Version: unspecified 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 Sometimes clang doesn't diagnose when a bound non-static member function is not called: struct C { void f() {}; }; decltype(C().f); // -Wmissing-declarations warning, expected error -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Sep 1 18:07:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 18:07:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 9337] ARM: misaligned data In-Reply-To: References: Message-ID: <20110901230726.C89912A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9337 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |FIXED --- Comment #6 from Benjamin Kramer 2011-09-01 18:07:26 CDT --- Fixed in r138976. (I didn't test it though due to lack of arm hardware) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 18:07:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 18:07:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 10128] ARM Thumb 2: Alignment getting lost between .ll and .s In-Reply-To: References: Message-ID: <20110901230738.44D902A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10128 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |FIXED --- Comment #7 from Benjamin Kramer 2011-09-01 18:07:37 CDT --- Fixed in r138976. (I didn't test it though due to lack of arm hardware) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 18:08:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 18:08:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 9483] [Win32][MCAsm][MCCOFF] local storage is unaware of required alignment In-Reply-To: References: Message-ID: <20110901230815.2BC7D2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9483 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution| |FIXED --- Comment #4 from Benjamin Kramer 2011-09-01 18:08:14 CDT --- I committed a modified version of Takumi's patch as r138976. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 18:16:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 18:16:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10831] New: [x86 disassembler] vmovapd disassembled incorrectly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10831 Summary: [x86 disassembler] vmovapd disassembled incorrectly Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: kkhoo at perfwizard.com CC: llvmbugs at cs.uiuc.edu >From the "Intel? 64 and IA-32 Architectures Software Developer?s Manual Volume 2 (2A & 2B): Instruction Set Reference, A-Z", p. 3-656: VEX.128.66.0F.WIG 28 /r VMOVAPD xmm1, xmm2/m128 Clang on OSX assembles the following: vmovapd %xmm0, %xmm2 to these bytes: C5 F9 28 D0 But using llvm-mc built from trunk r138250, this byte sequence doesn't disassemble as expected: $ echo '0xc5 0xf9 0x28 0xd0'| ./llvm-mc -disassemble -triple="x86_64" movaps %xmm0, %xmm2 The 3-byte VEX prefix form is also incorrect: $ echo '0xc4 0xc1 0xf9 0x28 0xd0'| ./llvm-mc -disassemble -triple="x86_64" movaps %xmm8, %xmm2 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 18:31:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 18:31:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10832] New: "movbe" is not recognized as an x86 mnemonic Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10832 Summary: "movbe" is not recognized as an x86 mnemonic Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 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. 3-662: 0F 38 F0 /r MOVBE r32, m32 $ clang -mavx avx.s -c /var/folders/J5/J5ahEYzWEFC1BPEW37amTE+++TM/-Tmp-/cc-1qUg1a.s:5:1: error: invalid instruction mnemonic 'movbe' movbe (%ecx), %eax -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 23:19:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 23:19:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10806] [x86 disassembler] vldmxcsr disassembled incorrectly In-Reply-To: References: Message-ID: <20110902041935.2B0532A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10806 Craig Topper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Craig Topper 2011-09-01 23:19:34 CDT --- VEX.L=1 decoding is fixed in r138997. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 1 23:38:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 1 Sep 2011 23:38:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 10831] [x86 disassembler] vmovapd/vmovaps/vmovd disassembled incorrectly In-Reply-To: References: Message-ID: <20110902043826.7870F2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10831 Craig Topper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Craig Topper 2011-09-01 23:38:26 CDT --- I think movd works provided you use pp=1. pp=0 would be the MMX form which doesn't have VEX equivalent. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 04:17:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 04:17:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10833] New: LLVM generates wrong reloc type for global_ctors (section .init_array) for ARM target Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10833 Summary: LLVM generates wrong reloc type for global_ctors (section .init_array) for ARM target Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: barto at gmx.net CC: llvmbugs at cs.uiuc.edu Hi, I'm trying to get my LLVM generated .obj file (ELF) to link with the official ARM linker together with a project that is C++ code compiled with ARMCC. The file contains llvm.global_ctors that are emitted (correctly) to the .init_array section. However LLVM emits a R_ARM_ABS32(2) relocation for the entries in the .init_array section. A comparison with a .cpp file compiled with ARMCC showed that it uses a R_ARM_TARGET1(38) relocation. (see also http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474c/CHDECJAJ.html) As a consequence, the linked project crashes in __cpp_initialize__aeabi as the relocation (from the LLVM compiled module) is wrong. I tried for myself to find where to change code in LLVM to make LLVM emit the correct relocation, but was unfortunately stuck. Is there an easy way for LLVM to generate R_ARM_TARGET1 instead of R_ARM_ABS32 for .init_array? My exact target configuration when generating the .obj file using LLVM is: std::string triple = "armv6-unknown-unknown-eabi"; cpu = "mpcore"; // (ARM) needed for VFP // all these options needed for the ARM linker to use fz (fpmode=fast) library instead of f or g (fpmode=ieee_full) llvm::FloatABIType = llvm::FloatABI::Hard; llvm::UnsafeFPMath = true; llvm::NoInfsFPMath = true; llvm::NoNaNsFPMath = true; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 08:04:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 08:04:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10834] New: shared library linkage regressions under dragonegg svn Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10834 Summary: shared library linkage regressions under dragonegg svn Product: dragonegg Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: New Bugs AssignedTo: baldrick at free.fr ReportedBy: howarth at nitro.med.uc.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7194) --> (http://llvm.org/bugs/attachment.cgi?id=7194) linkage failure example The dragonegg plugin on x86_64-apple-darwin11 now triggers linkage error failures (segfaults in ld) that weren't present before a yesterday. These appear as... [MacPro:~/linkage_failure] howarth% /usr/bin/ld -dynamic -dylib -arch x86_64 -flat_namespace -macosx_version_min 10.7.2 -single_module -undefined suppress -weak_reference_mismatches non-weak -undefined suppress -o libvmd.dylib -ldylib1.10.5.o dpApi.o vmd.o vmdInter.o tclStream.o dpStream.o ssStream.o publicVMDInter.o thread.o -lcrypto -lstdc++ -no_compact_unwind -lSystem -L. -lgcc_ext.10.5 -lgcc -lSystem crtfastmath.o Segmentation fault This back traces in gdb as... [MacPro:~/linkage_failure] howarth% gdb /usr/bin/ld GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done (gdb) r -dynamic -dylib -arch x86_64 -flat_namespace -macosx_version_min 10.7.2 -single_module -undefined suppress -weak_reference_mismatches non-weak -undefined suppress -o libvmd.dylib -ldylib1.10.5.o dpApi.o vmd.o vmdInter.o tclStream.o dpStream.o ssStream.o publicVMDInter.o thread.o -lcrypto -lstdc++ -no_compact_unwind -lSystem -L. -lgcc_ext.10.5 -lgcc -lSystem crtfastmath.o Starting program: /usr/bin/ld -dynamic -dylib -arch x86_64 -flat_namespace -macosx_version_min 10.7.2 -single_module -undefined suppress -weak_reference_mismatches non-weak -undefined suppress -o libvmd.dylib -ldylib1.10.5.o dpApi.o vmd.o vmdInter.o tclStream.o dpStream.o ssStream.o publicVMDInter.o thread.o -lcrypto -lstdc++ -no_compact_unwind -lSystem -L. -lgcc_ext.10.5 -lgcc -lSystem crtfastmath.o Reading symbols for shared libraries ++......................... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000028 0x00000001000159b9 in mach_o::relocatable::Section::addRelocFixup () (gdb) bt #0 0x00000001000159b9 in mach_o::relocatable::Section::addRelocFixup () #1 0x0000000100047a4c in mach_o::relocatable::Section::makeFixups () #2 0x00000001000437a3 in mach_o::relocatable::Parser::parse () #3 0x000000010001ec17 in mach_o::relocatable::Parser::parse () #4 0x000000010001809f in mach_o::relocatable::parse () #5 0x0000000100070ffc in ld::tool::InputFiles::makeFile () #6 0x00000001000726f9 in ld::tool::InputFiles::InputFiles () #7 0x0000000100012947 in main () (gdb) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 08:40:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 08:40:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10835] New: Obj-C++ instance method that returns a C++ derived class causes crash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10835 Summary: Obj-C++ instance method that returns a C++ derived class causes crash 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: bradmarston at mac.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7195) --> (http://llvm.org/bugs/attachment.cgi?id=7195) Xcode 4 project that demonstrates the problem with minimal code An Objective-C++ instance method that returns a derived C++ object causes a crash when the code is compiled with clang but works under LLVM GCC. The debugger says that a pointer being freed wasn't allocated. The problem occurs under both OS X 10.6 and 10.7, and with versions of clang that support Objective-C++. The attached Xcode project illustrates the problem with minimal code. Note that the function "D dummy2()" is able to properly return a derived C++ object of class D, but the Obj-C instance method "- (D) dummy" fails (but only when compiled with clang). Obj-C instance properly return C++ objects of the base class (B). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 09:56:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 09:56:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10836] New: Emails sent to llvmdev@cs.uiuc.edu and cfe-dev@cs.uiuc.edu have not appeared Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10836 Summary: Emails sent to llvmdev at cs.uiuc.edu and cfe-dev at cs.uiuc.edu have not appeared Product: new-bugs Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: johannesobermayr at gmx.de CC: llvmbugs at cs.uiuc.edu I cannot find below emails on mailing lists: (see [not]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-August/date.html and http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-August/date.html) chandlerc received the 2nd one only because I CCed him ... An email to the personal email adresses of the mailing list admins has not been answered for ~1 week. Btw. I have subscribed "write-only" to both mailings lists and the first email to llvmdev appeared immediately: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/042068.html From: Johannes Obermayr To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [PATCH] llvm-config: Support LLVM_LIBDIR_SUFFIX on CMake build. Date: Tue, 23 Aug 2011 22:31:01 +0200 Message-ID: <1756789.xopMuqWVFC at jobermayr> User-Agent: KMail/4.8 pre (Linux/3.0.2-1-desktop; KDE/4.7.41; x86_64; ; ) In-Reply-To: References: <1471500.jJZEM6TCal at jobermayr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart3406760.QRvOM4eNH8" Content-Transfer-Encoding: 7Bit --nextPart3406760.QRvOM4eNH8 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" --------------------------------------------------- From: Johannes Obermayr To: llvmdev at cs.uiuc.edu, cfe-dev at cs.uiuc.edu Cc: Chandler Carruth Subject: Re: [PATCH] llvm-config,clang: Support for LLVM_LIBDIR_SUFFIX. Date: Wed, 24 Aug 2011 10:53:06 +0200 Message-ID: <2792457.EhriF2R5QN at jobermayr> User-Agent: KMail/4.8 pre (Linux/3.0.2-1-desktop; KDE/4.7.41; x86_64; ; ) In-Reply-To: References: <1471500.jJZEM6TCal at jobermayr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart3778642.XZtxV5PQCI" Content-Transfer-Encoding: 7Bit --nextPart3778642.XZtxV5PQCI Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 10:50:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 10:50:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10837] New: Warn when assigning null character to pointer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10837 Summary: Warn when assigning null character to pointer Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: akyrtzi at gmail.com CC: llvmbugs at cs.uiuc.edu void f() { char *p; p = '\0'; // warn 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 Fri Sep 2 13:04:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 13:04:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 10702] [x86 disassembler] crc32 not disassembled correctly In-Reply-To: References: Message-ID: <20110902180451.487042A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10702 Kevin Enderby changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Kevin Enderby 2011-09-02 13:04:50 CDT --- Fix the disassembly of the X86 "crc32w %ax, %eax" instruction in r139014. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 15:13:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 15:13:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10838] New: [AVX] movmsk on undef value hits assert in X86 isel: (TLI.isTypeLegal(Op.getValueType()) && "Intrinsic uses a non-legal type?"), function visitTargetIntrinsic, file SelectionDAGBuilder.cpp, line 3482. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10838 Summary: [AVX] movmsk on undef value hits assert in X86 isel: (TLI.isTypeLegal(Op.getValueType()) && "Intrinsic uses a non-legal type?"), function visitTargetIntrinsic, file SelectionDAGBuilder.cpp, line 3482. Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu If I run llc on the attached. (On a Mac with a Sandybridge CPU): % llc bugpoint-reduced-simplified.ll -o - The following assertion hits Assertion failed: (TLI.isTypeLegal(Op.getValueType()) && "Intrinsic uses a non-legal type?"), function visitTargetIntrinsic, file SelectionDAGBuilder.cpp, line 3482. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 15:27:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 15:27:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 10838] [AVX] movmsk on undef value hits assert in X86 isel: (TLI.isTypeLegal(Op.getValueType()) && "Intrinsic uses a non-legal type?"), function visitTargetIntrinsic, file SelectionDAGBuilder.cpp, line 3482. In-Reply-To: References: Message-ID: <20110902202716.B0EEE2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10838 Bruno Cardoso Lopes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Bruno Cardoso Lopes 2011-09-02 15:27:16 CDT --- What's happening here is that you're trying to codegen a 256-bit intrinsic without using -mattr=+avx, it works if you specify the flag! :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 Sep 2 15:29:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 15:29:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 6978] lit should not unset CCACHE_DIR In-Reply-To: References: Message-ID: <20110902202948.81BB42A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6978 Elias Pipping changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Elias Pipping 2011-09-02 15:29:47 CDT --- This doesn't seem to be a problem anymore. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 15:31:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 15:31:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 10839] New: Weird accepts-invalid with operator as field (?) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10839 Summary: Weird accepts-invalid with operator as field (?) Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Testcase: struct A { operator int; }; Somehow, we actually accept 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 Sep 2 15:41:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 15:41:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 10840] New: [AVX] encoding issue with roundss instruction? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10840 Summary: [AVX] encoding issue with roundss instruction? Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7203) --> (http://llvm.org/bugs/attachment.cgi?id=7203) test case If I run llvm-objdump -disassemble on the object file generated by running the attached test case through llc -filetype=obj, I get errors about invalid instruction encoding. Specifically, if I run "llc -mattr=+avx bug.ll -o -", there is this instruction sequence toward the end: vmulss LCPI0_1(%rip), %xmm1, %xmm2 vroundss $9, %xmm2, %xmm2, %xmm2 vcvttss2si %xmm2, %edx andl $3, %edx However, if I run "llc -mattr=+avx -filetype=obj bug.ll -o - | llvm-objdump - -disassemble", then the output for the corresponding part is: 160: c5 f2 59 15 bc 00 00 00 vmulss 188(%rip), %xmm1, %xmm2 llvm-objdump: warning: invalid instruction encoding 16c: d2 09 rorb %cl, (%rcx) 16e: c5 fa 2c d2 vcvttss2si %xmm2, %edx 172: 83 e2 03 andl $3, %edx So either the wrong encoding is being generated when making object files, or llvm-objdump doesn't know about this instruction. (I hope it's the former, since I'm seeing crashes when running the generated code. :-) ). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 16:13:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 16:13:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 10841] New: [AVX] crash due to aligned move being used for register spill with 48 byte offset from %rbp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10841 Summary: [AVX] crash due to aligned move being used for register spill with 48 byte offset from %rbp Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7204) --> (http://llvm.org/bugs/attachment.cgi?id=7204) test case (I am not an x86 expert, so my diagnosis may be wrong. But I'm pretty sure it's right.) With the attached test case, the first few instructions generated for f_fu are: _f_fu: ## @f_fu ## BB#0: ## %allocas pushq %rbp movq %rsp, %rbp subq $304, %rsp ## imm = 0x130 vmovups (%rsi), %ymm1 vmovaps %ymm1, -48(%rbp) Note that in the last instruction, it's using an aligned move but with an offset of 48 from %rbp. Thus, even if %rbp is 32-byte aligned, -48(%rbp) isn't and thence a crash due to a misaligned address. (And as it turns out, if I try to run the compiled code, I get a crash at just that 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 Fri Sep 2 16:25:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 16:25:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 10842] New: [AVX, llc] Assertion failed: (Bits != 0 && "Cannot print this instruction."), function printInstruction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10842 Summary: [AVX,llc] Assertion failed: (Bits != 0 && "Cannot print this instruction."), function printInstruction Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7205) --> (http://llvm.org/bugs/attachment.cgi?id=7205) test case With the attached, I'm seeing the following crash. Note that if -O0 is not specified, there is no crash (so presumably the trigger is being optimized out.) % llc -O0 -mattr=+avx bugpoint-reduced-simplified.ll -o /dev/null Assertion failed: (Bits != 0 && "Cannot print this instruction."), function printInstruction, file /Users/mmp/llvm-dev-src/lib/Target/X86/InstPrinter/../X86GenAsmWriter.inc, line 3995. 0 llc 0x0000000100bd0082 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6504 1 llc 0x0000000100bd0689 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 8047 2 libsystem_c.dylib 0x00007fff885e8cfa _sigtramp + 26 3 libsystem_c.dylib 0x00007fff60150820 _sigtramp + 18446744073033644864 4 llc 0x0000000100bcffe6 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6348 5 llc 0x0000000100bd0038 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6430 6 llc 0x0000000100a7a62c llvm::MCRegisterInfo::~MCRegisterInfo() + 3584 7 llc 0x0000000100a7b822 llvm::MCRegisterInfo::~MCRegisterInfo() + 8182 8 llc 0x0000000100b6950c llvm::ELFObjectWriter::String64(llvm::MCDataFragment&, unsigned long long) + 20734 9 llc 0x00000001006517fb llvm::X86JITInfo::~X86JITInfo() + 15751 10 llc 0x0000000100805231 llvm::TargetSelectionDAGInfo::EmitTargetCodeForMemset(llvm::SelectionDAG&, llvm::DebugLoc, llvm::SDValue, llvm::SDValue, llvm::SDValue, llvm::SDValue, unsigned int, bool, llvm::MachinePointerInfo) const + 27537 11 llc 0x00000001005a7977 llvm::df_iterator, true, llvm::GraphTraits >::toNext() + 561 12 llc 0x00000001008af284 llvm::MachineFunctionAnalysis::getPassName() const + 458 13 llc 0x0000000100b3713d llvm::cl::parser::~parser() + 26675 14 llc 0x0000000100b326db llvm::cl::parser::~parser() + 7633 15 llc 0x0000000100b36e3a llvm::cl::parser::~parser() + 25904 16 llc 0x0000000100b38251 llvm::cl::parser::~parser() + 31047 17 llc 0x0000000100b382d1 llvm::cl::parser::~parser() + 31175 18 llc 0x0000000100554273 19 llc 0x0000000100552b34 Stack dump: 0. Program arguments: llc -O0 -mattr=+avx bugpoint-reduced-simplified.ll -o /dev/null 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'. 2. Running pass 'X86 AT&T-Style Assembly Printer' on function '@f_fu' [1] 48762 illegal hardware instruction llc -O0 -mattr=+avx bugpoint-reduced-simplified.ll -o /dev/null -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 16:29:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 16:29:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10843] New: [AVX] Assertion failed: (Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"), function getFPReg Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10843 Summary: [AVX] Assertion failed: (Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"), function getFPReg Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7206) --> (http://llvm.org/bugs/attachment.cgi?id=7206) test case With the attached and top-of-tree, I'm seeing the following crash: % llc -O0 -mattr=+avx bug.bc -o /dev/null Assertion failed: (Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"), function getFPReg, file X86FloatingPoint.cpp, line 331. 0 llc 0x0000000105f39082 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6504 1 llc 0x0000000105f39689 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 8047 2 libsystem_c.dylib 0x00007fff885e8cfa _sigtramp + 26 3 libsystem_c.dylib 0x00000001062a2258 _sigtramp + 18446603342626657656 4 llc 0x0000000105f38fe6 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6348 5 llc 0x0000000105f39038 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6430 6 llc 0x0000000105932af2 llvm::EVT::getPow2VectorType(llvm::LLVMContext&) const + 22834 7 llc 0x0000000105933117 llvm::EVT::getPow2VectorType(llvm::LLVMContext&) const + 24407 8 llc 0x0000000105c18284 llvm::MachineFunctionAnalysis::getPassName() const + 458 9 llc 0x0000000105ea013d llvm::cl::parser::~parser() + 26675 10 llc 0x0000000105e9b6db llvm::cl::parser::~parser() + 7633 11 llc 0x0000000105e9fe3a llvm::cl::parser::~parser() + 25904 12 llc 0x0000000105ea1251 llvm::cl::parser::~parser() + 31047 13 llc 0x0000000105ea12d1 llvm::cl::parser::~parser() + 31175 14 llc 0x00000001058bd273 15 llc 0x00000001058bbb34 16 llc 0x0000000000000006 Stack dump: 0. Program arguments: llc -O0 -mattr=+avx bug.bc -o /dev/null 1. Running pass 'Function Pass Manager' on module 'bug.bc'. 2. Running pass 'X86 FP Stackifier' on function '@"f_fu___REFUf[]REFUf[]Uf"' [1] 48775 illegal hardware instruction llc -O0 -mattr=+avx bug.bc -o /dev/null Note that this is the same assertion that is hitting in http://llvm.org/bugs/show_bug.cgi?id=10498, though there it's only when all of the SSE feature bits are disabled, but here I'm seeing it with a regular AVX target... -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 16:32:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 16:32:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10844] New: [AVX] Cannot select: v8f32 = X86ISD::VZEXT_MOVL Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10844 Summary: [AVX] Cannot select: v8f32 = X86ISD::VZEXT_MOVL Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7207) --> (http://llvm.org/bugs/attachment.cgi?id=7207) test case With the attached test case, I'm seeing the following crash: % llc -O0 bug.bc -filetype=obj -o x.o -mattr=+avx LLVM ERROR: Cannot select: 0x7fd50907a310: v8f32 = X86ISD::VZEXT_MOVL 0x7fd50907ab10 [ID=96] 0x7fd50907ab10: v8f32 = insert_subvector 0x7fd50907aa10, 0x7fd50907a910, 0x7fd50902f410 [ID=91] 0x7fd50907aa10: v8f32 = undef [ID=35] 0x7fd50907a910: v4f32 = scalar_to_vector 0x7fd509029e10 [ID=85] 0x7fd509029e10: f32,ch = load 0x10dfe7bd8, 0x7fd509027d10, 0x7fd50902ed10 [ID=75] 0x7fd509027d10: i64 = X86ISD::WrapperRIP 0x7fd509028010 [ID=50] 0x7fd509028010: i64 = TargetConstantPool 0 [ID=27] 0x7fd50902ed10: i64 = undef [ORD=181] [ID=3] 0x7fd50902f410: i32 = Constant<0> [ORD=185] [ID=8] (If I try to reduce it to a simpler test case with bugpoint, then it ends up reducing it to something that hits 10842 or 10843.) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 16:39:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 16:39:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 10845] New: [AVX] x86 isel hits assert: (false && "Couldn't find the register class"), function getSuperRegisterRegClass Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10845 Summary: [AVX] x86 isel hits assert: (false && "Couldn't find the register class"), function getSuperRegisterRegClass Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7208) --> (http://llvm.org/bugs/attachment.cgi?id=7208) test case With the attached, I'm seeing the following crash. (Sorry the test case isn't smaller; here also bugpoint reduces it to a different crash. Also, without -O0, the crash doesn't happen.) % llc -O0 -mattr=+avx bug.ll -o /dev/null Assertion failed: (false && "Couldn't find the register class"), function getSuperRegisterRegClass, file InstrEmitter.cpp, line 403. 0 llc 0x0000000107dc6082 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6504 1 llc 0x0000000107dc6689 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 8047 2 libsystem_c.dylib 0x00007fff885e8cfa _sigtramp + 26 3 libsystem_c.dylib 0x00000001082e2b40 _sigtramp + 18446603342660476512 4 llc 0x0000000107dc5fe6 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6348 5 llc 0x0000000107dc6038 llvm::PrettyStackTraceProgram::~PrettyStackTraceProgram() + 6430 6 llc 0x00000001078b9ebb llvm::MachineModuleInfo::setVariableDbgInfo(llvm::MDNode*, unsigned int, llvm::DebugLoc) + 10689 7 llc 0x00000001078bb57b llvm::MachineModuleInfo::setVariableDbgInfo(llvm::MDNode*, unsigned int, llvm::DebugLoc) + 16513 8 llc 0x0000000107953a0a llvm::DenseMap, llvm::DenseMapInfo, llvm::DenseMapInfo > >::FindAndConstruct(llvm::SUnit* const&) + 2468 9 llc 0x00000001079cd8b3 llvm::SelectionDAGBuilder::Case::size() const + 36623 10 llc 0x00000001079cee52 llvm::SelectionDAGBuilder::Case::size() const + 42158 11 llc 0x00000001079cfabb llvm::SelectionDAGBuilder::Case::size() const + 45335 12 llc 0x0000000107aa5284 llvm::MachineFunctionAnalysis::getPassName() const + 458 13 llc 0x0000000107d2d13d llvm::cl::parser::~parser() + 26675 14 llc 0x0000000107d286db llvm::cl::parser::~parser() + 7633 15 llc 0x0000000107d2ce3a llvm::cl::parser::~parser() + 25904 16 llc 0x0000000107d2e251 llvm::cl::parser::~parser() + 31047 17 llc 0x0000000107d2e2d1 llvm::cl::parser::~parser() + 31175 18 llc 0x000000010774a273 19 llc 0x0000000107748b34 20 llc 0x0000000000000006 Stack dump: 0. Program arguments: llc -O0 -mattr=+avx bug.ll -o /dev/null 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] 49022 illegal hardware instruction llc -O0 -mattr=+avx bug.ll -o /dev/null -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 16:47:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 16:47:09 -0500 (CDT) Subject: [LLVMbugs] [Bug 10846] New: [AVX] Cannot select i64 = bitcast Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10846 Summary: [AVX] Cannot select i64 = bitcast Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7209) --> (http://llvm.org/bugs/attachment.cgi?id=7209) test case With the attached, I get the following crash: % llc -O0 -mattr=+avx bug.bc LLVM ERROR: Cannot select: 0x7fbbf3050410: i64 = bitcast 0x7fbbf3056410 [ORD=318] [ID=29] 0x7fbbf3056410: f64,ch = load 0x7fbbf304fb10, 0x7fbbf3061210, 0x7fbbf304f310 [ORD=317] [ID=28] 0x7fbbf3061210: i64 = FrameIndex<57> [ORD=310] [ID=10] 0x7fbbf304f310: i64 = undef [ORD=301] [ID=3] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 17:02:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 17:02:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10847] New: precompiled header broken with c++0x (issue with rvalue ?) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10847 Summary: precompiled header broken with c++0x (issue with rvalue ?) Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: devlists at shadowlab.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=7210) --> (http://llvm.org/bugs/attachment.cgi?id=7210) Sample While trying to compile a c++0x file using precompiled header, clang failed with some error diagnostics that does not appear without precompiled header. This bug occurs when trying to used precompiled libc++ headers for instance (either trunk or Xcode 4.1 libc++ version). And as it is a precompiled header bug, it's not easy to write a simple reduced test case. To reproduce the bug, you can use the attached sample. Uncompress the archive. cd to the created directory. launch test.sh By default, the test.sh script will try to use the system libc++, but you can use the attached preprocessed version instead by toggling commented lines in the script. $tar -xf bug.tbz $cd bug $bash test.sh # Compile without precompiled header. Works fine clang++ -std=c++0x -stdlib=libc++ -include include/map.h -c map.cpp # Precompile header # toggle between the 2 following line to use either the system libc++ (first line) # or the included preprocessed libc++ header file. clang++ -x c++-header -std=c++0x -stdlib=libc++ include/map.h -o map.h.pth # clang++ -v -x c++-header -std=c++0x include/libc++.ii -o map.h.pth # Compile using precompiled header clang++ -std=c++0x -stdlib=libc++ -include map.h -c map.cpp In file included from map.cpp:1: In file included from Desktop/bug/include/map.h:2: In file included from llvm/release/Release+Asserts/bin/../lib/c++/v1/unordered_map:318: In file included from llvm/release/Release+Asserts/bin/../lib/c++/v1/__hash_table:16: llvm/release/Release+Asserts/bin/../lib/c++/v1/memory:1469:26: error: call to constructor of 'true_type' (aka 'integral_constant') is ambiguous {__construct(__has_construct(), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ llvm/release/Release+Asserts/bin/../lib/c++/v1/unordered_map:1066:20: note: in instantiation of function template specialization 'std::__1::allocator_traits, void *> > >::construct' requested here __node_traits::construct(__na, _VSTD::addressof(__h->__value_.first), ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/unordered_map:1146:25: note: in instantiation of function template specialization 'std::__1::unordered_map, std::__1::equal_to, std::__1::allocator > >::__construct_node' requested here __node_holder __h = __construct_node(__k); ^ map.cpp:7:17: note: in instantiation of member function 'std::__1::unordered_map, std::__1::equal_to, std::__1::allocator > >::operator[]' requested here sAllClassesDict[name] = NULL; ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/type_traits:161:24: note: candidate is the implicit move constructor struct _LIBCPP_VISIBLE integral_constant ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/type_traits:161:24: note: candidate is the implicit move constructor llvm/release/Release+Asserts/bin/../lib/c++/v1/type_traits:161:24: note: candidate is the implicit copy constructor llvm/release/Release+Asserts/bin/../lib/c++/v1/memory:1530:42: note: passing argument to parameter here static void __construct(true_type, allocator_type& __a, _Tp* __p, _Args&&... __args) ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/memory:1469:26: error: call to constructor of 'true_type' (aka 'integral_constant') is ambiguous {__construct(__has_construct(), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ llvm/release/Release+Asserts/bin/../lib/c++/v1/unordered_map:1069: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), ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/unordered_map:1146:25: note: in instantiation of function template specialization 'std::__1::unordered_map, std::__1::equal_to, std::__1::allocator > >::__construct_node' requested here __node_holder __h = __construct_node(__k); ^ map.cpp:7:17: note: in instantiation of member function 'std::__1::unordered_map, std::__1::equal_to, std::__1::allocator > >::operator[]' requested here sAllClassesDict[name] = NULL; ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/type_traits:161:24: note: candidate is the implicit move constructor struct _LIBCPP_VISIBLE integral_constant ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/type_traits:161:24: note: candidate is the implicit move constructor llvm/release/Release+Asserts/bin/../lib/c++/v1/type_traits:161:24: note: candidate is the implicit copy constructor llvm/release/Release+Asserts/bin/../lib/c++/v1/memory:1530:42: note: passing argument to parameter here static void __construct(true_type, allocator_type& __a, _Tp* __p, _Args&&... __args) ^ In file included from map.cpp:1: In file included from Desktop/bug/include/map.h:2: In file included from llvm/release/Release+Asserts/bin/../lib/c++/v1/unordered_map:318: In file included from llvm/release/Release+Asserts/bin/../lib/c++/v1/__hash_table:18: llvm/release/Release+Asserts/bin/../lib/c++/v1/algorithm:2296:33: error: call to constructor of 'std::__1::__less' is ambiguous return _VSTD::max(__a, __b, __less<_Tp>()); ^~~~~~~~~~~~~ llvm/release/Release+Asserts/bin/../lib/c++/v1/__hash_table:1204:20: note: in instantiation of function template specialization 'std::__1::max' requested here rehash(_VSTD::max(2 * __bc + 1, ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/__config:178:15: note: expanded from: #define _VSTD std::_LIBCPP_NAMESPACE ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/unordered_map:1147:41: note: in instantiation of member function 'std::__1::__hash_table, std::__1::__unordered_map_hasher, std::__1::hash, true>, std::__1::__unordered_map_equal, std::__1::equal_to, true>, std::__1::allocator > >::__node_insert_unique' requested here pair __r = __table_.__node_insert_unique(__h.get()); ^ map.cpp:7:17: note: in instantiation of member function 'std::__1::unordered_map, std::__1::equal_to, std::__1::allocator > >::operator[]' requested here sAllClassesDict[name] = NULL; ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/algorithm:632:8: note: candidate is the implicit move constructor struct __less ^ llvm/release/Release+Asserts/bin/../lib/c++/v1/algorithm:632:8: note: candidate is the implicit move constructor llvm/release/Release+Asserts/bin/../lib/c++/v1/algorithm:632:8: note: candidate is the implicit copy constructor llvm/release/Release+Asserts/bin/../lib/c++/v1/algorithm:2286:46: note: passing argument to parameter '__comp' here max(const _Tp& __a, const _Tp& __b, _Compare __comp) ^ 3 errors generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 17:20:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 17:20:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 10848] New: [x86 disassembler] vmovdqa not disassembled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10848 Summary: [x86 disassembler] vmovdqa not disassembled Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: kkhoo at perfwizard.com CC: llvmbugs at cs.uiuc.edu >From the "Intel? 64 and IA-32 Architectures Software Developer?s Manual Volume 2 (2A & 2B): Instruction Set Reference, A-Z", p. 3-671: VEX.128.66.0F.WIG 6F /r VMOVDQA xmm1, xmm2/m128 VEX.128.66.0F.WIG 7F /r VMOVDQA xmm2/m128, xmm1 Clang on OSX assembles the following: vmovdqa (%rcx), %xmm0 vmovdqa %xmm0, (%rcx) to these bytes: C5 F9 6F 01 C5 F9 7F 01 But using llvm-mc built from trunk r139013, this byte sequence doesn't disassemble as expected: $ echo '0xc5 0xf9 0x6f 0x01'| ./llvm-mc -disassemble -triple="x86_64" :1:1: warning: invalid instruction encoding 0xc5 0xf9 0x6f 0x01 $ echo '0xc5 0xf9 0x7f 0x01'| ./llvm-mc -disassemble -triple="x86_64" :1:1: warning: invalid instruction encoding 0xc5 0xf9 0x7f 0x01 ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 17:41:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 17:41:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10849] New: Failed assertion: `!SpecializedTemplate.is() && "Already set to a class template partial specialization!"' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10849 Summary: Failed assertion: `!SpecializedTemplate.is() && "Already set to a class template partial specialization!"' Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping at exherbo.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=7211) --> (http://llvm.org/bugs/attachment.cgi?id=7211) delta-reduced input (not valid code but manages to make clang++ crash) % clang++ -c spec_tree-sRt9vh.ii spec_tree-sRt9vh.ii:1:19: warning: variadic templates are a C++0x extension [-Wc++0x-extensions] template ^ spec_tree-sRt9vh.ii:10:18: error: implicit instantiation of undefined template 'MakeTypeList' typedef SpecTree::Type> LicenseSpecTree; ^ spec_tree-sRt9vh.ii:5:8: note: template is declared here struct MakeTypeList; ^ clang: /var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/lib/Sema/../../include/clang/AST/DeclTemplate.h:1482: void clang::ClassTemplateSpecializationDecl::setInstantiationOf(clang::ClassTemplatePartialSpecializationDecl*, clang::TemplateArgumentList*): Assertion `!SpecializedTemplate.is() && "Already set to a class template partial specialization!"' failed. 0 libLLVM-3.0svn.so 0x00007fd53204d6af 1 libLLVM-3.0svn.so 0x00007fd53204de10 2 libpthread.so.0 0x00007fd531016f10 3 libc.so.6 0x00007fd5303355c5 gsignal + 53 4 libc.so.6 0x00007fd5303368c5 abort + 389 5 libc.so.6 0x00007fd53032e235 __assert_fail + 245 6 clang 0x0000000000aab5c0 clang::ClassTemplateSpecializationDecl::setInstantiationOf(clang::ClassTemplatePartialSpecializationDecl*, clang::TemplateArgumentList*) + 68 7 clang 0x0000000000a99556 clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 2760 8 clang 0x0000000000ad2781 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 327 9 clang 0x0000000000ad3e43 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 53 10 clang 0x00000000008755ce clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&, clang::DeclContext*) + 638 11 clang 0x00000000008d17fc clang::Sema::getTypeName(clang::IdentifierInfo&, clang::SourceLocation, clang::Scope*, clang::CXXScopeSpec*, bool, bool, clang::OpaquePtr, bool) + 422 12 clang 0x0000000000801b81 clang::Parser::TryAnnotateTypeOrScopeToken(bool) + 1857 13 clang 0x00000000007f412d clang::Parser::isCXXDeclarationSpecifier() + 311 14 clang 0x00000000007f6b36 clang::Parser::isCXXTypeId(clang::Parser::TentativeCXXTypeIdContext, bool&) + 46 15 clang 0x00000000007f0140 clang::Parser::ParseTemplateArgument() + 32 16 clang 0x00000000007f225d clang::Parser::ParseTemplateArgumentList(llvm::SmallVector&) + 65 17 clang 0x00000000007f2650 clang::Parser::ParseTemplateIdAfterTemplateName(clang::OpaquePtr, clang::SourceLocation, clang::CXXScopeSpec const&, bool, clang::SourceLocation&, llvm::SmallVector&, clang::SourceLocation&) + 316 18 clang 0x00000000007f2e5f clang::Parser::AnnotateTemplateIdToken(clang::OpaquePtr, clang::TemplateNameKind, clang::CXXScopeSpec&, clang::UnqualifiedId&, clang::SourceLocation, bool) + 249 19 clang 0x000000000083e02d clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&, clang::OpaquePtr, bool, bool*, bool) + 6985 20 clang 0x00000000008291a3 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 1129 21 clang 0x00000000008174a8 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 5786 22 clang 0x00000000007ebf75 clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 889 23 clang 0x00000000007f09a1 clang::Parser::ParseExplicitInstantiation(clang::SourceLocation, clang::SourceLocation, clang::SourceLocation&) + 91 24 clang 0x00000000007f0cc3 clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 765 25 clang 0x000000000081809f clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 191 26 clang 0x00000000007ff8c0 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1684 27 clang 0x000000000080037f clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 253 28 clang 0x00000000007d2c10 clang::ParseAST(clang::Sema&, bool) + 308 29 clang 0x0000000000593c74 clang::ASTFrontendAction::ExecuteAction() + 200 30 clang 0x0000000000689d89 clang::CodeGenAction::ExecuteAction() + 2691 31 clang 0x0000000000594213 clang::FrontendAction::Execute() + 389 32 clang 0x0000000000581420 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 868 33 clang 0x00000000005680bd clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3805 34 clang 0x000000000055eede cc1_main(char const**, char const**, char const*, void*) + 7074 35 clang 0x0000000000565068 main + 751 36 libc.so.6 0x00007fd530321c7d __libc_start_main + 253 37 clang 0x000000000055d169 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name spec_tree-sRt9vh.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 spec_tree-sRt9vh.o -resource-dir /usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 238 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o spec_tree-sRt9vh.o -x c++-cpp-output spec_tree-sRt9vh.ii 1. spec_tree-sRt9vh.ii:13:35: current parser token 'Type' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. % -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 17:47:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 17:47:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 10850] New: llvm-as crash on file that uses libc++'s hash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10850 Summary: llvm-as crash on file that uses libc++'s hash Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: llvm-as AssignedTo: unassignedbugs at nondot.org ReportedBy: alonzakai at gmail.com CC: llvmbugs at cs.uiuc.edu The attachment is a tiny program using libc++'s hash implementation. It crashes when processed with llvm-as src.cpp.o.ll.pre -o=src.cpp.o A debug build gives this stack: Program received signal SIGSEGV, Segmentation fault. 0x080585fe in llvm::Value::getType (this=0x0) at /home/alon/Dev/llvm-svn/include/llvm/Value.h:108 108 Type *getType() const { return VTy; } (gdb) where #0 0x080585fe in llvm::Value::getType (this=0x0) at /home/alon/Dev/llvm-svn/include/llvm/Value.h:108 #1 0x08133dc9 in LoadInst (this=0x82999c4, Ptr=0x0, Name=0x0, isVolatile=false, InsertBef=0x0) at /home/alon/Dev/llvm-svn/lib/VMCore/Instructions.cpp:1027 #2 0x080b894e in llvm::IRBuilder >::CreateLoad (this=0xbfffec60, Ptr=0x0, Name=0x821bf94 "exn") at /home/alon/Dev/llvm-svn/include/llvm/Support/IRBuilder.h:754 #3 0x080b6c73 in llvm::UpgradeExceptionHandling (M=0x827abb0) at /home/alon/Dev/llvm-svn/lib/VMCore/AutoUpgrade.cpp:518 #4 0x0807b825 in llvm::LLParser::ValidateEndOfModule (this=0xbffff0bc) at /home/alon/Dev/llvm-svn/lib/AsmParser/LLParser.cpp:124 #5 0x0807ad72 in llvm::LLParser::Run (this=0xbffff0bc) at /home/alon/Dev/llvm-svn/lib/AsmParser/LLParser.cpp:42 #6 0x08072bb1 in llvm::ParseAssembly (F=0x827ab80, M=0x0, Err=..., Context=...) at /home/alon/Dev/llvm-svn/lib/AsmParser/Parser.cpp:38 #7 0x08072d1f in llvm::ParseAssemblyFile (Filename=..., Err=..., Context=...) at /home/alon/Dev/llvm-svn/lib/AsmParser/Parser.cpp:52 #8 0x0804c7b3 in main (argc=3, argv=0xbffff484) at /home/alon/Dev/llvm-svn/tools/llvm-as/llvm-as.cpp:97 (gdb) This is on latest LLVM svn. This appears to be a regression since the same automatic test (in the emscripten test suite) worked on 2.9. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 18:41:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 18:41:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10851] New: [x86 disassembler] vmovmskpd disassembled when reserved bits not set Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10851 Summary: [x86 disassembler] vmovmskpd disassembled when reserved bits not set Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: kkhoo at perfwizard.com CC: llvmbugs at cs.uiuc.edu >From the "Intel? 64 and IA-32 Architectures Software Developer?s Manual Volume 2 (2A & 2B): Instruction Set Reference, A-Z", p. 3-691: VEX.128.66.0F.WIG 50 /r VMOVMSKPD reg, xmm2 VEX.256.66.0F.WIG 50 /r VMOVMSKPD reg, ymm2 Note: In VEX-encoded versions, VEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD. Clang on OSX assembles the following: vmovmskpd %xmm0, %eax to these bytes: C5 F9 50 C0 But using llvm-mc built from trunk r139013, this byte sequence disassembles even though the VEX.vvvv field is not 1111b (it's 0000b): $ echo '0xc5 0x81 0x50 0xc0'| ./llvm-mc -disassemble -triple="x86_64" vmovmskpd %xmm0, %eax The 3-byte VEX prefix form is also incorrect: $ echo '0xc4 0xe1 0x81 0x50 0xc0'| ./llvm-mc -disassemble -triple="x86_64" vmovmskpd %xmm0, %eax -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 19:22:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 19:22:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 7597] Crash creating object without defined constructor. In-Reply-To: References: Message-ID: <20110903002206.A1A422A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7597 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Eli Friedman 2011-09-02 19:22:05 CDT --- Elias, the problem you're reporting is very unlikely to be the same issue; please file a new bug (and mention rvalue references in the title). Closing this bug due to lack of response from the original reporter. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 20:30:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 20:30:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 10852] New: ARM llc assertion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10852 Summary: ARM llc assertion Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: pdox at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7214) --> (http://llvm.org/bugs/attachment.cgi?id=7214) minimal example llc: llvm/lib/CodeGen/RegisterScavenging.cpp:215: void llvm::RegScavenger::forward(): Assertion `SubUsed && "Using an undefined register!"' failed. Attached is a minimal example (minimal.ll), emitted by bugpoint. Compile with: $ llc minimal.ll -march=arm -mcpu=cortex-a8 -mtriple=armv7a-none-linux-gnueabi The assertion started happening at r138791. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Sep 2 20:38:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 2 Sep 2011 20:38:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 10850] llvm-as crash on file that uses libc++'s hash In-Reply-To: References: Message-ID: <20110903013827.B6EE12A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10850 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Bill Wendling 2011-09-02 20:38:27 CDT --- Fixed r139076 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 3 01:23:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 3 Sep 2011 01:23:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10702] [x86 disassembler] crc32 not disassembled correctly In-Reply-To: References: Message-ID: <20110903062307.9A4902A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10702 Craig Topper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #5 from Craig Topper 2011-09-03 01:23:07 CDT --- But now this doesn't decode correctly 0xf2 0x0f 0x38 0xf1 0xc0 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 3 09:20:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 3 Sep 2011 09:20:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 10813] Assertion "getOperand() out of range" hits in Constants.h In-Reply-To: References: Message-ID: <20110903142004.4C8502A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10813 Jakub Staszak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kuba.staszak at gmail.com Resolution| |FIXED --- Comment #1 from Jakub Staszak 2011-09-03 09:20:02 CDT --- Fixed in r139006 with some small changes in the next revs. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 3 10:21:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 3 Sep 2011 10:21:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10402] Failed assertion: `Rep && "no type provided!"' In-Reply-To: References: Message-ID: <20110903152122.6FC972A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10402 Elias Pipping changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #2 from Elias Pipping 2011-09-03 10:21:21 CDT --- I can no longer reproduce this (current version: clang 3.0-git-fec0959f95454b4241e3060408656e8fbe4ac6c1). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 3 11:06:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 3 Sep 2011 11:06:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 10853] New: [AVX, perf?] suboptimal code generated to set 'all bits on' in ymm register Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10853 Summary: [AVX,perf?] suboptimal code generated to set 'all bits on' in ymm register 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 Given: define <8 x i32> @foo() { ret <8 x i32> } The AVX backend generates the code: _foo: ## @foo vpcmpeqd %xmm0, %xmm0, %xmm0 vinsertf128 $1, %xmm0, %ymm0, %ymm0 ret Unless I'm missing something, I think this could be more efficiently done with something like: vcmpeqd %ymm0, %ymm0, %ymm0 (There may be an AVX subtlety that I'm not aware of that prevents this; apologies if 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 Sat Sep 3 16:29:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 3 Sep 2011 16:29:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10853] [AVX, perf?] suboptimal code generated to set 'all bits on' in ymm register In-Reply-To: References: Message-ID: <20110903212948.C77DD2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10853 Matt Pharr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Matt Pharr 2011-09-03 16:29:48 CDT --- Yes. I was thinking that a fp compare could used to get an 8-wide register of on bits (I should have had vcmpeqps in the below), but I realize that won't work if there happens to be a NaN value in the ymm register. So marking this as invalid. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Sep 3 22:35:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 3 Sep 2011 22:35:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10826] Code completion in macro with # operator crashes libclang In-Reply-To: References: Message-ID: <20110904033520.0091D2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10826 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Argyrios Kyrtzidis 2011-09-03 22:35:18 CDT --- Fixed at r139087. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 07:16:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 07:16:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 10854] New: slow upstart of binaries in clang+llvm-2.9-x86_64-linux.tar, due to /home/duncan in search path Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10854 Summary: slow upstart of binaries in clang+llvm-2.9-x86_64-linux.tar, due to /home/duncan in search path Product: new-bugs Version: 2.9 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: patrik.h.hagglund at ericsson.com CC: llvmbugs at cs.uiuc.edu The binaries in http://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2, contains /home/duncan/... in the search path for dynamic libraries. On our Linux servers, this means a start-up penalty of about 1 second: > strace -T clang+llvm-2.9-x86_64-linux.tar/bin/clang --version [...] open("/home/duncan/llvm-2.9/64/Phase2/Release/llvmCore-2.9-release.obj/Release/bin/tls/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <0.131968> stat("/home/duncan/llvm-2.9/64/Phase2/Release/llvmCore-2.9-release.obj/Release/bin/tls/x86_64", 0x7fffbd5d2310) = -1 ENOENT (No such file or directory) <0.131093> open("/home/duncan/llvm-2.9/64/Phase2/Release/llvmCore-2.9-release.obj/Release/bin/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <0.088312> stat("/home/duncan/llvm-2.9/64/Phase2/Release/llvmCore-2.9-release.obj/Release/bin/tls", 0x7fffbd5d2310) = -1 ENOENT (No such file or directory) <0.134553> open("/home/duncan/llvm-2.9/64/Phase2/Release/llvmCore-2.9-release.obj/Release/bin/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <0.132172> stat("/home/duncan/llvm-2.9/64/Phase2/Release/llvmCore-2.9-release.obj/Release/bin/x86_64", 0x7fffbd5d2310) = -1 ENOENT (No such file or directory) <0.130809> open("/home/duncan/llvm-2.9/64/Phase2/Release/llvmCore-2.9-release.obj/Release/bin/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <0.132083> stat("/home/duncan/llvm-2.9/64/Phase2/Release/llvmCore-2.9-release.obj/Release/bin", 0x7fffbd5d2310) = -1 ENOENT (No such file or directory) <0.133924> (Maybe due to a huge number of /home directories, and therefore a slow response from the automounter?) Please remove the search path /home/duncan/... from binaries (in future releases). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 08:27:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 08:27:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10855] New: llc miscompiles negation of long long (ARM) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10855 Summary: llc miscompiles negation of long long (ARM) Product: tools Version: trunk Platform: PC OS/Version: All Status: NEW Severity: release blocker Priority: P Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: pdox at google.com CC: llvmbugs at cs.uiuc.edu This bug started happening at revision 138791. Compile this bitcode for ARM: target triple = "armv7-none-linux-gnueabi" define i64 @foo(i64 %x) nounwind readnone { entry: %0 = sub nsw i64 0, %x ret i64 %0 } The resulting code for foo is: rsb r0, r0, #0 rsc r1, r1, #0 bx lr The correct code is: rsbs r0, r0, #0 rsc r1, r1, #0 bx lr (rsc uses the carry bit provided by rsbs) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 09:12:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 09:12:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 10856] New: Clang is unable to infer template argument for friend function inside namesapce. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10856 Summary: Clang is unable to infer template argument for friend function inside namesapce. 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: expipiplus1 at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=7215) --> (http://llvm.org/bugs/attachment.cgi?id=7215) A testcase program illustrating the problem. The attached code compiles with gcc 4.6 with -std=c++0x It fails to compile with clang, with -std=c++0x and -stdlib=libc++ Commenting out lines 1, 2, 24 and 26 (removing the use of the namespace) will allow clang to compile the code. Qualifying "operator" on line 15 doesn't fix the error. Clang is unable to compile the code because it's unable to infer the template argument R. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 09:52:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 09:52:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 10857] New: [AVX] incorrect code generated for simple loop Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10857 Summary: [AVX] incorrect code generated for simple loop 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=7216) --> (http://llvm.org/bugs/attachment.cgi?id=7216) llvm asm The attached short test case represents the compilation of the loop: void result(float *p) { for (int i = 0; i < 4; ++i) { p[2*i+1] = (float)(10+i); p[2*i] = (float)(14+i); } } (The llvm asm is simple enough that this should be easy to verify by inspection.) If I compile it using "llc -O0 -mattr=+avx", incorrect assembly is generated; the output of the test program indicates that the even array elements aren't being written to. Correct code is generated with -O2 -mattr=+avx, or if I don't use the AVX backend. Here is the result of disassembling the code generated with -O0, avx. (Intel asm syntax.) Note that the result of the second vcvtsi2ss instruction is never written to memory, which is aligned with the indication from the test that the even elements aren't written to. _result: # Function .type _result, @function mov eax, 0 # 0000 _ B8, 00000000 mov dword ptr [rsp-0x4], eax # 0005 _ 89. 44 24, FC mov qword ptr [rsp-0x10], rdi # 0009 _ 48: 89. 7C 24, F0 $_001: mov eax, dword ptr [rsp-0x4] # 000E _ 8B. 44 24, FC # Note: Immediate operand could be made smaller by sign extension cmp eax, 4 # 0012 _ 3D, 00000004 mov dword ptr [rsp-0x14], eax # 0017 _ 89. 44 24, EC jl $_003 # 001B _ 7C, 11 jmp $_004 # 001D _ EB, 3E $_002: mov eax, dword ptr [rsp-0x14] # 001F _ 8B. 44 24, EC # Note: Immediate operand could be made smaller by sign extension add eax, 1 # 0023 _ 05, 00000001 mov dword ptr [rsp-0x4], eax # 0028 _ 89. 44 24, FC jmp $_001 # 002C _ EB, E0 $_003: mov eax, dword ptr [rsp-0x14] # 002E _ 8B. 44 24, EC mov ecx, dword ptr [rsp-0x14] # 0032 _ 8B. 4C 24, EC lea eax, [rcx+rax+0x1] # 0036 _ 8D. 44 01, 01 lea edx, [rcx+rcx] # 003A _ 8D. 14 09 movsxd rsi, eax # 003D _ 48: 63. F0 lea eax, [rcx+0xA] # 0040 _ 8D. 41, 0A vcvtsi2ss xmm0, xmm0, eax # 0043 _ C5 FA: 2A. C0 mov rdi, qword ptr [rsp-0x10] # 0047 _ 48: 8B. 7C 24, F0 vmovss dword ptr [rdi+rsi*4], xmm0 # 004C _ C5 FA: 11. 04 B7 lea eax, [rcx+0xE] # 0051 _ 8D. 41, 0E vcvtsi2ss xmm0, xmm0, eax # 0054 _ C5 FA: 2A. C0 movsxd rsi, edx # 0058 _ 48: 63. F2 jmp $_002 # 005B _ EB, C2 $_004: ret # 005D _ C3 .size _result, . - _result # End of function is probably 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 Sep 4 13:47:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 13:47:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10858] New: Optimizer removes call to relevant function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10858 Summary: Optimizer removes call to relevant function 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: dwelch at dwelch.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7219) --> (http://llvm.org/bugs/attachment.cgi?id=7219) simple source files needed to reproduce this problem See attached. show.c has a function get_onechar that calls uart_getc(). uart_getc() for debugging includes an infinite loop. the call to uart_getc() appears to be optimized completely out and the code continues as if it had never happened. 00000000 : 0: b510 push {r4, lr} 2: 4604 mov r4, r0 4: 20ff movs r0, #255 ; 0xff 6: 4020 ands r0, r4 8: 280a cmp r0, #10 Interestingly I added a function called fun() which also calls uart_getc() and this one appears to have been implemented with a call to uart_putc() 00000022 : 22: b500 push {lr} 24: 4601 mov r1, r0 26: 2007 movs r0, #7 28: 0740 lsls r0, r0, #29 2a: f7ff fffe bl 0 2e: bd00 pop {pc} Without optimization everything looks fine. Tried with both a near trunk (will svn up and try again today) as well as release 2.9 Dont actually need to assemble and disassemble with binutils as the Makefile does, the problem can be seen in the .s file. running ubuntu 10.4LTS 64 bit Linux dwelch-desktop 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 GNU/Linux Low Level Virtual Machine (http://llvm.org/): llvm version 3.0svn Optimized build with assertions. Built Aug 31 2011 (22:39:17). Host: x86_64-unknown-linux-gnu Host CPU: amdfam10 llvm# svn info Path: . URL: http://llvm.org/svn/llvm-project/llvm/trunk Repository Root: http://llvm.org/svn/llvm-project Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8 Revision: 138935 Node Kind: directory Schedule: normal Last Changed Author: evancheng Last Changed Rev: 138934 Last Changed Date: 2011-08-31 21:45:00 -0400 (Wed, 31 Aug 2011) llvm/tools/clang# svn info Path: . 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: 138935 Node Kind: directory Schedule: normal Last Changed Author: dgregor Last Changed Rev: 138935 Last Changed Date: 2011-08-31 22:09:07 -0400 (Wed, 31 Aug 2011) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 13:51:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 13:51:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 10858] Optimizer removes call to relevant function In-Reply-To: References: Message-ID: <20110904185149.9B8962A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10858 Matti Niemenmaa changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Matti Niemenmaa 2011-09-04 13:51:49 CDT --- *** This bug has been marked as a duplicate of bug 965 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 15:39:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 15:39:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 10458] poor diagnostic when trying to use 'auto' not in '0x mode In-Reply-To: References: Message-ID: <20110904203920.28D692A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10458 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Richard Smith 2011-09-04 15:39:19 CDT --- r139103 fixes the issue with new-type-ids. For error recovery, we now handle 'auto' well enough to pass the C++0x 'auto' test suite in C++98 mode (apart from the ExtWarn warnings and no error when using 'auto' as a storage class specifier). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 16:12:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 16:12:18 -0500 (CDT) Subject: [LLVMbugs] [Bug 10859] New: Macro expansion notes are not colored Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10859 Summary: Macro expansion notes are not colored Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dblaikie at gmail.com CC: llvmbugs at cs.uiuc.edu Given #define call fob(); void foo(); int main() { call } Compiled as C++, clang's output contains: * an error (no 'fob' function) * a note (pointing to the call macro) * and then another note (suggesting foo instead of fob) Problem: The second note is printed without any highlighting/color (it should be bold and the "note:" portion should be black (shows up as grey)). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 18:56:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 18:56:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 10506] instantiation of '0x for-range statements sloshes together temporaries In-Reply-To: References: Message-ID: <20110904235605.7DA732A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10506 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution| |WORKSFORME --- Comment #1 from Richard Smith 2011-09-04 18:56:04 CDT --- Manual tests indicate that this works fine. I've extended the unit test for temporary cleanups in range-based for to cover the dependent case in r139109. When the range is dependent, the condition and increment expressions aren't built until the template is instantiated. When they're built (by BuildCXXForRangeStmt), ActOnFinishFullExpr is called to clean up the temopraries. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 21:15:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 21:15:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10860] New: "Trying to aggregate-copy a type without a trivial copy " "constructor or assignment operator"' failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10860 Summary: "Trying to aggregate-copy a type without a trivial copy " "constructor or assignment operator"' failed Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang -cc1 -S -std=gnu++0x crashes on struct ElfValue { }; class ElfLocation: public ElfValue { virtual unsigned int getValue(); }; template struct remove_reference; template struct remove_reference<_Tp&> { typedef _Tp type; }; template typename remove_reference<_Tp>::type&& move(_Tp&& __t) { return static_cast::type&&>(__t); } ElfLocation* __old_finish; void foo() { *__old_finish = move(*--__old_finish); } With clang: /home/espindola/llvm/llvm/tools/clang/lib/CodeGen/CGExprAgg.cpp:1074: void clang::CodeGen::CodeGenFunction::EmitAggregateCopy(llvm::Value *, llvm::Value *, clang::QualType, bool): Assertion `(Record->hasTrivialCopyConstructor() || Record->hasTrivialCopyAssignment()) && "Trying to aggregate-copy a type without a trivial copy " "constructor or assignment operator"' failed. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 4 23:12:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 4 Sep 2011 23:12:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 10861] New: C++0x POD changes not implemented Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10861 Summary: C++0x POD changes not implemented Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: xocotl at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Howdy I didn't see a bug for this, but ran into it recently trying to add a constexpr constructor from double to a fixed point type. So, for tracking's sake, figured I should add a bug. :) Clang doesn't appear to presently support C++0x style looser POD definition. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 5 02:13:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 5 Sep 2011 02:13:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 10862] New: False positives related to try catch blocks (Value stored to '...' during its initialization is never read) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10862 Summary: False positives related to try catch blocks (Value stored to '...' during its initialization is never read) Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: tom.vercauteren at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, I am using scan-build (svn from 2011-09-02) to analyze c++ code and get a few false positives related to try catch blocks. My initial attempts to make a small test case did not succeed in replicating the bug. Below are two code snippets for which I get "Value stored to 'status' during its initialization is never read" in a large projet: ----------------- uint32_t status = info.refStatus; try { status = foo(); } catch(...) { } bar(status); ----------------- ----------------- int status = this->m_status; this->m_status = foo(); try { bar(); } catch(...) { this->m_status = status; } ----------------- -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 5 02:59:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 5 Sep 2011 02:59:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 10863] New: False positives related to while loops in a threaded environment (Value stored to '...' during its initialization is never read) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10863 Summary: False positives related to while loops in a threaded environment (Value stored to '...' during its initialization is never read) Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: tom.vercauteren at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, I am using scan-build (svn from 2011-09-02) to analyze c++ code and get a few false positives related to while loops in a threaded environment. Below is a code snippet for which I get "Value stored to 'first' during its initialization is never read" in a large projet: ----------------- bool first = true; while( this->m_continue ) { // some mutex if( first ) { first = false; foo(); } else { bar(); } } ----------------- -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 5 10:59:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 5 Sep 2011 10:59:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 10864] New: Sema::ActOnAsmStmt() is called before template instantiation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10864 Summary: Sema::ActOnAsmStmt() is called before template instantiation Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: liulk at likai.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=7221) --> (http://llvm.org/bugs/attachment.cgi?id=7221) An example showing inline assembly and CRTP usage. Sema::ActOnAsmStmt() performs type checking on the inline assembly. It is currently called when the templated class method is declared, not when the template class is instantiated, causing problem with Curiously Recurring Template Pattern usage because it is not able to reduce dependent type. liulk -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 5 14:00:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 5 Sep 2011 14:00:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10865] New: Address-space casts cause LLVM assertion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10865 Summary: Address-space casts cause LLVM assertion Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pcwalton at mimiga.net CC: llvmbugs at cs.uiuc.edu This code causes an LLVM assertion ("Pointer must be a pointer to Val type" during generation of a StoreInst): #define MY_ADDRESS_SPACE __attribute__((address_space(512))) void MY_ADDRESS_SPACE *x = (void MY_ADDRESS_SPACE *)malloc(123); But this works fine: #define MY_ADDRESS_SPACE __attribute__((address_space(512))) void MY_ADDRESS_SPACE *x = (void MY_ADDRESS_SPACE *)(uintptr_t)malloc(123); Looks like clang isn't generating a bitcast instruction where one is needed, and the intermediate uintptr_t forces the bitcast generation. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Sep 5 15:23:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 5 Sep 2011 15:23:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 10866] New: template static const is not always initialized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10866 Summary: template static const is not always initialized Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: adriano.mitre at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=7222) --> (http://llvm.org/bugs/attachment.cgi?id=7222) example showing the bug and how to work around it A template static constant is not always initialized as it should. This behaviour deviates from g++'s. An example is attached which produces incorrect behaviour unless WORKAROUND{1,2} is defined (see comment in the beginning of the source). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 5 19:31:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 5 Sep 2011 19:31:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10866] template static const is not always initialized In-Reply-To: References: Message-ID: <20110906003132.63A742A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10866 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nicholas at mxc.ca Resolution| |INVALID --- Comment #1 from Nick Lewycky 2011-09-05 19:31:31 CDT --- If I'm not mistaken, your testcase boils down to: static const int test1 = bar(); static const double test2 = test1 * 0.5; What's the guarantee that either of those is evaluated first? I realize that reordering them doesn't make the bug go away, but as I just said, there's no guarantee that it would. Further, I just tried it with G++ 4.6.1 on my machine: $ g++ example.cpp -o example $ ./example inf I'm going to close this bug as invalid. If you think I'm mistaken, please reopen 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 Sep 5 21:57:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 5 Sep 2011 21:57:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10867] New: Multiple RUN: lines and || don't play well Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10867 Summary: Multiple RUN: lines and || don't play well Product: Test Suite Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: lit AssignedTo: unassignedbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org This test fails: RUN: false RUN: true This test passes: RUN: false RUN: true || true This is because lit combines multiple RUN: lines together with " && " and passes them to the shell, where && binds tighter than ||. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 00:06:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 00:06:32 -0500 (CDT) Subject: [LLVMbugs] [Bug 10383] Assertion `isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant!"' In-Reply-To: References: Message-ID: <20110906050632.996682A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10383 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Nick Lewycky 2011-09-06 00:06:32 CDT --- Fixed in r139133. The equivalent code in getAddExpr does not have this bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 07:43:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 07:43:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 10868] New: libclang does not respect line directives when reporting source locations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10868 Summary: libclang does not respect line directives when reporting source locations Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: vinay_sajip at yahoo.co.uk CC: llvmbugs at cs.uiuc.edu Given a simple file somefile.c with the contents #123 "dummy.c" 1 static int func() { return 0; } the source location of the func() definition is reported as line 3 of somefile.c, whereas it should be line 124 of dummy.c as per the # directive. The # line is correctly parsed in PPDirectives.cpp and a line note added, but this is not available via the source location APIs. This problem means that libclang's source location functionality is not much use when processing files which have already been pre-processed, say via gcc -E. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 07:44:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 07:44:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10869] New: [LLVM, llvm-mc] Unclear error for files without newline at the end of file (ARM, x86). Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10869 Summary: [LLVM, llvm-mc] Unclear error for files without newline at the end of file (ARM, x86). 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: stpworld at narod.ru CC: llvmbugs at cs.uiuc.edu ARMAsmParser and X86AsmParser doesn't process files without newline at the end of file properly. llvm-mc failed to parse file with error message: nonl-x86.s:2:17: error: unexpected token in argument list Reproduction steps: 1. Create the file "nonl-x86.s" with the next contents (or use attachment): movl %gs:8, %eax movl %gs:8, %eax 2. Ensure that it has no newlines at EOF. 3. run llvm-mc: llvm-mc nonl-x86.s 4. llvm-mc fails with message: nonl-x86.s:2:17: error: unexpected token in argument list -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 10:15:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 10:15:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 10870] New: buggy behaviour when exception is thrown from the constructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10870 Summary: buggy behaviour when exception is thrown from the constructor Product: clang Version: 2.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: adriano.mitre at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The attached example demonstrates what seems to be a bug in clang when an exception is thrown from the constructor. Although the behaviour is different whether the construction/allocation is static or dynamic, it is wrong in both cases. Constrast $ make CXX=g++ # default $ /ctorexcept static 1234 instances: 0 $ /ctorexcept dynamic 1234 instances: 0 with $ make CXX=clang++ $ /ctorexcept static 1234 instances: 10 $ /ctorexcept dynamic 1234 # segmentation fault! # according to valgrind it was an "Invalid free() / delete / delete[]" If the destructor is not defined, which may be achieved compiling with $ make CXX_FLAGS=-DISABLE_DTOR no segmentation fault ocurrs in the dynamic case, making its behaviour seemly identical to the static case. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 10:23:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 10:23:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 9271] dependent decltype in parameter of template function causes name mangling crash In-Reply-To: References: Message-ID: <20110906152348.BB4142A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9271 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-09-06 10:23:48 CDT --- This is already fixed in top-of-tree; the correct mangled name is __Z1fIRiEvOT_DtfL0p_E. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 10:25:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 10:25:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 9273] dependent operator name in template function argument type crashes clang In-Reply-To: References: Message-ID: <20110906152533.D11312A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9273 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2011-09-06 10:25:33 CDT --- Clang now correctly rejects this: .cpp:2:15: error: explicit instantiation of 'operator_' does not refer to a function template, member function, member class, or static data member template void operator_(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 Sep 6 10:27:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 10:27:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 9230] "Unresolved overloaded function" assertion failure In-Reply-To: References: Message-ID: <20110906152717.53EB42A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9230 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-09-06 10:27:15 CDT --- This no longer crashes with top-of-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 Tue Sep 6 11:27:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 11:27:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 10860] "Trying to aggregate-copy a type without a trivial copy " "constructor or assignment operator"' failed In-Reply-To: References: Message-ID: <20110906162736.08E1A2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10860 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-09-06 11:27:35 CDT --- Fixed in Clang r139143. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 11:32:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 11:32:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 10871] New: -Warray-bounds fires on usr/include/socket.h ipv6 sockaddr usage Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10871 Summary: -Warray-bounds fires on usr/include/socket.h ipv6 sockaddr usage 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 >From /Developer/SDKs/MacOSX10.6.sdk/usr/include/sys/socket.h: struct sockaddr { __uint8_t sa_len; /* total length */ sa_family_t sa_family; /* [XSI] address family */ char sa_data[14]; /* [XSI] addr value (actually larger) */ }; For ipv6 ( in6.h somewhere in Kernel.frameworkl ): struct in6_addr { union { __uint8_t __u6_addr8[16]; __uint16_t __u6_addr16[8]; __uint32_t __u6_addr32[4]; } __u6_addr; /* 128-bit IP6 address */ }; struct sockaddr_in6 { __uint8_t sin6_len; /* length of this struct(sa_family_t)*/ sa_family_t sin6_family; /* AF_INET6 (sa_family_t) */ in_port_t sin6_port; /* Transport layer port # (in_port_t)*/ __uint32_t sin6_flowinfo; /* IP6 flow information */ struct in6_addr sin6_addr; /* IP6 address */ __uint32_t sin6_scope_id; /* scope zone index */ }; Given `sockaddr* myaddr = ...`, if myaddr->sa_family == AF_INET6, then accessing myaddr->sa_data[6 + 15] is valid (it's some byte of the in6_addr), yet clang warns " warning: array index of '21' indexes past the end of an array (that contains 14 elements) [-Warray-bounds]". -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 11:39:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 11:39:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 10847] Implicit move constructor breaks precompiled header support. In-Reply-To: References: Message-ID: <20110906163931.E68462A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10847 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2011-09-06 11:39:30 CDT --- Fixed in Clang r139144. Thanks for the great reduced test case! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 11:40:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 11:40:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10383] Assertion `isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant!"' In-Reply-To: References: Message-ID: <20110906164000.8ED932A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10383 J?rg Sonnenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #5 from J?rg Sonnenberger 2011-09-06 11:39:59 CDT --- The original test case still hits 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 Tue Sep 6 11:40:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 11:40:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 10871] -Warray-bounds fires on usr/include/socket.h ipv6 sockaddr usage In-Reply-To: References: Message-ID: <20110906164008.BA7562A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10871 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chandler Carruth 2011-09-06 11:40:08 CDT --- I think we've reached the limit of what we can do with this warning. The header file gives an explicit size to the array (14) which is explicitly a lie (as indicated by the comment). I think Clang is entirely within its rights to complain here. However, if the reason you "know" you can overflow this array is because you "know" that the actual struct is sockaddr_in6, simply cast the pointer ta sockaddr_in6, and use that struct. =] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 12:02:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 12:02:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10775] ADTTests trigger valgrind failures In-Reply-To: References: Message-ID: <20110906170240.27CB72A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10775 Andrew Trick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED AssignedTo|unassignedbugs at nondot.org |atrick at apple.com --- Comment #1 from Andrew Trick 2011-09-06 12:02:39 CDT --- valgrind doesn't recognize optimized strcasecmp in glib yet. It's supposed to be fixed in 3.6.1. Until then we are suppressing the error. Fixed by r139048 and r139084 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 12:30:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 12:30:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 10872] New: [loop-idiom] GVN fails to remove loads after loop-idiom recognition Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10872 Summary: [loop-idiom] GVN fails to remove loads after loop-idiom recognition Product: libraries Version: trunk Platform: PC OS/Version: All Status: ASSIGNED Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: resistor at mac.com ReportedBy: atrick at apple.com CC: llvmbugs at cs.uiuc.edu Test case: SingleSource/Benchmarks/Stanford test.simple.Puzzle on A9 is 14% slower with -unroll-scev. Running with -O3 optimizes to O3.ll (0.54s) -unroll-scev produces O3-unroll-scev.ll (0.64s) These runs were using r138990. -unroll-scev will soon be default, but -disable-unroll-scev will be available. llc -mcpu=cortex-a9 -relocation-model=pic -disable-fp-elim -disable-non-leaf-fp-elim O3.ll -unroll-scev exposes more opportunities for memset_pattern, resulting in: call void @memset_pattern16(i8* bitcast (i32* getelementptr inbounds ([13 x [512 x i32]]* @p, i32 0, i32 6, i32 0) to i8*), i8* bitcast ([4 x i32]* @.memset_pattern3 to i8*), i32 12) nounwind This is fine, but then GVN fails to remove the subsequent loads: %tmp2.i = load i32* getelementptr inbounds ([13 x i32]* @piecemax, i32 0, i32 0), align 4, !tbaa !3 for.end.i: ; preds = %for.inc.i8, %if.then %tmp14.i = load i32* getelementptr inbounds ([13 x i32]* @class, i32 0, i32 0), align 4, !tbaa !3 Removing %tmp2.i exposes lots of constant folding, but it is the removal of %tmp14.i that speeds up the benchmark. Also rdar://10065079 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 12:43:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 12:43:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 10852] ARM llc assertion In-Reply-To: References: Message-ID: <20110906174331.00D072A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10852 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Jakob Stoklund Olesen 2011-09-06 12:43:30 CDT --- Fixed in r139148. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 13:53:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 13:53:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10870] buggy behaviour when exception is thrown from the constructor In-Reply-To: References: Message-ID: <20110906185323.2B5FA2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10870 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Eli Friedman 2011-09-06 13:53:22 CDT --- r139158. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 13:54:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 13:54:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 10855] llc miscompiles negation of i64 (ARM) In-Reply-To: References: Message-ID: <20110906185424.670C62A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10855 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Evan Cheng 2011-09-06 13:54:24 CDT --- Fixed: r139157 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 14:00:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 14:00:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 5035] False Positive NSData and NSString ........NoCopy: methods In-Reply-To: References: Message-ID: <20110906190019.01A432A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5035 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |INVALID --- Comment #3 from Ted Kremenek 2011-09-06 14:00:18 CDT --- There is simply no information in this PR to go on. I'm closing this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 15:10:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 15:10:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10776] Tests failure: MC/Disassembler/ARM/thumb* segfaults In-Reply-To: References: Message-ID: <20110906201044.A0A282A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10776 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Owen Anderson 2011-09-06 15:10:43 CDT --- Fixed in r139059. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 15:34:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 15:34:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 10835] Obj-C++ instance method that returns a C++ derived class causes crash In-Reply-To: References: Message-ID: <20110906203423.9EA472A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10835 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2011-09-06 15:34:23 CDT --- Fixed in Clang r139175. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 16:33:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 16:33:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 10873] New: clang messes up dependence, improperly moves load past use Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10873 Summary: clang messes up dependence, improperly moves load past use Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: whaley at cs.utsa.edu CC: llvmbugs at cs.uiuc.edu I believe I've found a bug in clang/llvm on a sandy bridge CPU. I am using the svn version of clang downloaded Sep 03, 2011: >sb4>clang -v >clang version 3.0 (trunk 139049) >Target: x86_64-unknown-linux-gnu >Thread model: posix Take this piece of code: ******************************************************************************* void ATL_UGEMV(const int M, const int N, const double *A, const int lda, const double *X, double *Y) /* * y = [0,1]*y + A*x, A is MxN, storing the transpose of the matrix */ { double ry, iy; const int lda2 = lda+lda; int j; void dotu_sub(const int, const double*, const int, const double*, const int, double *); for (j=0; j < N; j++, A += lda2, Y += 2) { ry = *Y; iy = Y[1]; dotu_sub(M, A, 1, X, 1, Y); *Y += ry; Y[1] += iy; } } ******************************************************************************* If you compile with clang -fomit-frame-pointer -mavx -O2 -m64 -S I believe you will find that clang waits until *after* the subroutine call to load the values, at which point they have been overwritten by the call. In order to get clang to produce the right answer, you must rewrite the loop in this way: for (j=0; j < N; j++, A += lda2, Y += 2) { double dot[2] dotu_sub(M, A, 1, X, 1, dot); *Y += dot[0]; Y[1] += dot[1]; } Thanks, Clint -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 17:12:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 17:12:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 10874] New: segfault on error: "cannot use 'c++-cpp-output' output with multiple -arch options" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10874 Summary: segfault on error: "cannot use 'c++-cpp-output' output with multiple -arch options" Product: clang Version: trunk Platform: Macintosh OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dane at dbsgeo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang++ was working fine, then I updated to svn trunk r139135 from r138729. Now I get: https://gist.github.com/1199127 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 17:24:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 17:24:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 10875] New: [x86 disassembler] movs comes up blank with intel syntax Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10875 Summary: [x86 disassembler] movs comes up blank with intel syntax Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: kkhoo at perfwizard.com CC: llvmbugs at cs.uiuc.edu >From the "Intel? 64 and IA-32 Architectures Software Developer?s Manual Volume 2 (2A & 2B): Instruction Set Reference, A-Z", p. 3-713: A4 MOVS m8, m8 $ echo '0xa4'| ./llvm-mc -disassemble -triple="x86_64" -x86-asm-syntax=intel $ echo '0xa4'| ./llvm-mc -disassemble -triple="x86_64" movsb This should show as "MOVS" with Intel syntax, but there's no output. AT&T syntax looks ok. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 17:29:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 17:29:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 10876] New: byval causes infinite recursion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10876 Summary: byval causes infinite recursion 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: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu The four tests: llvm/trunk/test/CodeGen/ARM/2011-06-09-TailCallByVal.ll llvm/trunk/test/CodeGen/Mips/cprestore.ll llvm/trunk/test/CodeGen/Mips/largeimmprinting.ll llvm/trunk/test/CodeGen/Thumb/2011-05-11-DAGLegalizer.ll all suffer the same problem: they infinitely recurse due to byval stuff. Here's the stack trace: Program received signal SIGSEGV, Segmentation fault. 0x0000000000fd9288 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp ( this=Cannot access memory at address 0x7fffff5fe898 ) at LegalizeDAG.cpp:766 766 SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) { (gdb) bt #0 0x0000000000fd9288 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=Cannot access memory at address 0x7fffff5fe898 ) at LegalizeDAG.cpp:766 #1 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #2 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #3 0x0000000000fdb147 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:1071 #4 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #5 0x0000000000fdabc0 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:1028 #16 0x0000000000fdb02e in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:1062 #17 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #18 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #19 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #20 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #21 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #22 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 [...] #1537 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #1538 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #1539 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #1540 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #1541 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #1542 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 #1543 0x0000000000fdb147 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:1071 #1544 0x0000000000fdaf45 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:1054 #1545 0x0000000000fd3ac2 in (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG (this=0x7fffffffd740) at LegalizeDAG.cpp:210 #1546 0x0000000000ffb8e7 in llvm::SelectionDAG::Legalize (this=0x1d5b5c0) at LegalizeDAG.cpp:3917 #1547 0x0000000000f9983e in llvm::SelectionDAGISel::CodeGenAndEmitDAG ( this=0x1d53ba0) at SelectionDAGISel.cpp:559 #1548 0x0000000000f98a80 in llvm::SelectionDAGISel::SelectBasicBlock ( this=0x1d53ba0, Begin=..., End=..., HadTailCall=@0x7fffffffdb68) at SelectionDAGISel.cpp:424 #1549 0x0000000000f9b28a in llvm::SelectionDAGISel::SelectAllBasicBlocks ( this=0x1d53ba0, Fn=...) at SelectionDAGISel.cpp:989 #1550 0x0000000000f97fe2 in llvm::SelectionDAGISel::runOnMachineFunction ( this=0x1d53ba0, mf=...) at SelectionDAGISel.cpp:292 #1551 0x0000000001105095 in llvm::MachineFunctionPass::runOnFunction ( this=0x1d53ba0, F=...) at MachineFunctionPass.cpp:33 #1552 0x00000000014930e8 in llvm::FPPassManager::runOnFunction ( this=0x1d526e0, F=...) at PassManager.cpp:1512 #1553 0x0000000001493333 in llvm::FPPassManager::runOnModule (this=0x1d526e0, M=...) at PassManager.cpp:1534 #1554 0x0000000001493679 in llvm::MPPassManager::runOnModule (this=0x1d4d390, M=...) at PassManager.cpp:1588 #1555 0x0000000001493b78 in llvm::PassManagerImpl::run (this=0x1d4d040, M=...) at PassManager.cpp:1670 #1556 0x00000000014940c1 in llvm::PassManager::run (this=0x7fffffffe1e0, M=...) at PassManager.cpp:1714 #1557 0x00000000009dfedd in main (argc=3, argv=0x7fffffffe418) at llc.cpp:374 (gdb) up 100 #100 0x0000000000fd9c24 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd740, Op=...) at LegalizeDAG.cpp:908 908 Ops.push_back(LegalizeOp(Node->getOperand(i))); (gdb) p Node $1 = (llvm::SDNode *) 0x1d92380 (gdb) p *Node $2 = { = { NextInFoldingSetBucket = 0x0}, > = {> = {Prev = 0x1d92280}, Next = 0x1d92580}, NodeType = 41, OperandsNeedDelete = 1, HasDebugValue = 0, SubclassData = 0, NodeId = 87, OperandList = 0x1d92ff0, ValueList = 0x1d86150, UseList = 0x1d93118, NumOperands = 4, NumValues = 2, debugLoc = { LineCol = 0, ScopeIdx = 0}} (gdb) p Node->dump() Cannot access memory at address 0x7fffff5fe778 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 17:36:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 17:36:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 10877] New: [x Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10877 Summary: [x Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: kkhoo at perfwizard.com 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 Tue Sep 6 18:34:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 18:34:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 10872] [loop-idiom] GVN fails to remove loads after loop-idiom recognition In-Reply-To: References: Message-ID: <20110906233411.46C992A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10872 Owen Anderson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Owen Anderson 2011-09-06 18:34:10 CDT --- Fixed in r139204. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 19:37:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 19:37:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 10383] Assertion `isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant!"' In-Reply-To: References: Message-ID: <20110907003750.89B322A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10383 J?rg Sonnenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 21:31:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 21:31:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 10878] New: Segmentation fault in clang::FunctionDecl::getParamDecl(unsigned int) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10878 Summary: Segmentation fault in clang::FunctionDecl::getParamDecl(unsigned int) 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 Created an attachment (id=7231) --> (http://llvm.org/bugs/attachment.cgi?id=7231) Failing input Beginning of stack trace: 0 clang 0x0000000002a1657d 1 clang 0x0000000002a16379 2 libpthread.so.0 0x00007fc99be1dc60 3 clang 0x000000000155e181 clang::FunctionDecl::getParamDecl(unsigned int) + 81 4 clang 0x000000000162cc13 clang::Sema::GatherArgumentsForCall(clang::SourceLocation, clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int, clang::Expr**, unsigned int, llvm::SmallVector&, clang::Sema::VariadicCallType) + 405 5 clang 0x000000000162c9f7 clang::Sema::ConvertArgumentsForCall(clang::CallExpr*, clang::Expr*, clang::FunctionDecl*, clang::FunctionProtoType const*, clang::Expr**, unsigned int, clang::SourceLocation) + 1271 6 clang 0x000000000162e2d8 clang::Sema::BuildResolvedCallExpr(clang::Expr*, clang::NamedDecl*, clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation, clang::Expr*) + 2066 7 clang 0x000000000162d7d4 clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, clang::ASTMultiPtr, clang::SourceLocation, clang::Expr*) + 2024 8 clang 0x000000000150d651 clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) + 2503 9 clang 0x000000000150cc78 clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 7378 Pre-processed input is attached. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 22:01:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 22:01:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 10843] [AVX] Assertion failed: (Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"), function getFPReg In-Reply-To: References: Message-ID: <20110907030119.C9F462A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10843 Matt Pharr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Matt Pharr 2011-09-06 22:01:19 CDT --- This was fixed somewhere between r139208 and r138982. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 22:02:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 22:02:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 10842] [AVX, llc] Assertion failed: (Bits != 0 && "Cannot print this instruction."), function printInstruction In-Reply-To: References: Message-ID: <20110907030207.2D3792A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10842 Matt Pharr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Matt Pharr 2011-09-06 22:02:06 CDT --- This was fixed somewhere between r139208 and r138982 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 22:02:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 22:02:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 10845] [AVX] x86 isel hits assert: (false && "Couldn't find the register class"), function getSuperRegisterRegClass In-Reply-To: References: Message-ID: <20110907030244.F13D22A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10845 Matt Pharr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Matt Pharr 2011-09-06 22:02:44 CDT --- This was fixed somewhere between r139208 and r138982 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 22:06:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 22:06:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 10857] [AVX] incorrect code generated for simple loop In-Reply-To: References: Message-ID: <20110907030636.212B92A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10857 Matt Pharr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Matt Pharr 2011-09-06 22:06:35 CDT --- This was fixed somewhere between r139208 and r138982. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 23:05:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 23:05:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 10878] Segmentation fault in clang::FunctionDecl::getParamDecl(unsigned int) In-Reply-To: References: Message-ID: <20110907040538.5392B2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10878 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-09-06 23:05:38 CDT --- r139224. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Sep 6 23:14:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 6 Sep 2011 23:14:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 10879] New: Possibly mismatched push_back/pop_back in SemaTemplateInstantiate.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10879 Summary: Possibly mismatched push_back/pop_back in SemaTemplateInstantiate.cpp Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: liulk at likai.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=7232) --> (http://llvm.org/bugs/attachment.cgi?id=7232) An example showing template instantiation stack bleed. There is an error in the template instantiation stack. The symptom is somewhat misleading. Running clang++ against the attached example gives you this error: clang-sync-tying.cc:27:38: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'ValueType *' (aka 'void **') if (__sync_bool_compare_and_swap(&Self()->Value(), that.Value(), expect)) { ^~~~~~~~~~~~~~~~ clang-sync-tying.cc:55:12: note: in instantiation of member function 'CompareSwapImpl, void *>::CompareSwap' requested here csv_ptr1.CompareSwap(csv_ptr2, (void *) 1u); ^ 1 error generated. The instantiation here should find the first argument to __sync_bool_compare_and_swap() the type of void *volatile *, not volatile char *. The type volatile char * comes from the previous instantiation. liulk -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 7 01:18:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 01:18:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 10880] New: indvars doesn't update scev's analyses, for the worse Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10880 Summary: indvars doesn't update scev's analyses, for the worse Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer AssignedTo: unassignedbugs at nondot.org ReportedBy: nicholas at mxc.ca CC: llvmbugs at cs.uiuc.edu, atrick at apple.com Created an attachment (id=7233) --> (http://llvm.org/bugs/attachment.cgi?id=7233) testcase This testcase is a simplified version of: vector v; for (int i = 0; i < n; ++i) v[i]++; Note that vector::operator[] takes a int64, while the index is an int32. This is an extremely common pattern in our (Google's) codebase, thanks to our style rules. The attached testcase is from right before we go into -indvars. The main problem is visible if you just run -O2 over it, there's an extra add(zext(add(n, 1)), -1) in the middle. (The slowdown each time is small, but over our codebase, it accumulates, and GCC doesn't have this problem.) What happened? Let's take a look: $ opt -analyze -scalar-evolution 2011-01-17-LinearReplaceForgetLoop.ll [...] Determining loop execution counts for: @test Loop %for.body: backedge-taken count is (-1 + %n) Loop %for.body: max backedge-taken count is 2147483646 $ opt -indvars -analyze -scalar-evolution 2011-01-17-LinearReplaceForgetLoop.ll [...] Determining loop execution counts for: @test Loop %for.body: backedge-taken count is (-1 + %n) Loop %for.body: max backedge-taken count is 2147483646 $ opt -indvars 2011-01-17-LinearReplaceForgetLoop.ll | opt -analyze -scalar-evolution [...] Determining loop execution counts for: @test Loop %for.body: backedge-taken count is (-1 + (zext i32 %n to i64)) Loop %for.body: max backedge-taken count is (-1 + (zext i32 %n to i64)) Indvars changed the backedge-taken count (consider %n = 0), but only in cases where the loop wouldn't be entered anyways. However, SCEV doesn't do enough analysis to determine what happened. It also bails on the max backedge-taken count. Finally, if you run "opt -indvars 2011-01-17-LinearReplaceForgetLoop.ll | opt -O2 -S -o -", then the unnecessary +1/-1 pairing around the zext is gone. This is directly caused by the different information returned by SCEV, not by other optz'ns happening in the -O2 pipeline. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 7 06:25:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 06:25:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 10881] New: Compiler optimizer generates incorrect i386 code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10881 Summary: Compiler optimizer generates incorrect i386 code 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: eric.trepanier at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7234) --> (http://llvm.org/bugs/attachment.cgi?id=7234) Small Foundation Obj-C program that demonstrates the issue The attached code sample demonstrates a situation in which the 32-bit compiler optimizer generates incorrect code for a given while loop. Compile the attached source file using the following command: clang -arch i386 -framework Foundation -Os main.m The run the resulting executable, you should see the following result: 2011-09-07 07:19:42.458 a.out[27557:507] Calculating r using while loop = {{287, 733}, {33.000004, 5.0509523e-40}} 2011-09-07 07:19:42.460 a.out[27557:507] Calculating r without using while loop = {{287, 733}, {33.000004, 15.999994}} If you disable compiler optimizations, (-O0), you will instead see that the calculated "r" results are the same in both cases: 2011-09-07 07:23:20.042 a.out[27564:507] Calculating r using while loop = {{287, 733}, {33.000004, 15.999994}} 2011-09-07 07:23:20.044 a.out[27564:507] Calculating r without using while loop = {{287, 733}, {33.000004, 15.999994}} Our code was initially using the while-loop approach and generating some incorrect results. Fortunately, unrolling the loop works around the problem for us so it is not a showstopper, but it's probably something you want to look at nonetheless. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 7 09:49:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 09:49:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 10882] New: FileManager::getVirtualFile() fails due to bug in FileManager::addAncestorsAsVirtualDirs() Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10882 Summary: FileManager::getVirtualFile() fails due to bug in FileManager::addAncestorsAsVirtualDirs() Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: vinay_sajip at yahoo.co.uk CC: llvmbugs at cs.uiuc.edu A call to FileManager::getVirtualFile() with a filename such as "/usr/include/i386._types.h" fails with an assertion error: "The directory of a virtual file should already be in the cache." This is because code in the FileManager::addAncestorsAsVirtualDirs() method - called from FileManager::getVirtualFile() - looks like this: llvm::StringMapEntry &NamedDirEnt = SeenDirEntries.GetOrCreateValue(DirName); // When caching a virtual directory, we always cache its ancestors // at the same time. Therefore, if DirName is already in the cache, // we don't need to recurse as its ancestors must also already be in // the cache. if (NamedDirEnt.getValue()) return; // continue to set the value and add the directory's ancestors However, the GetOrCreateValue() call creates an entry with a bogus "tombstone" value of -1. So, the if test always returns true and causes a premature return. If the test is changed to if (NamedDirEnt.getValue() != (DirectoryEntry *) SeenDirEntries.getTombstoneVal()) return; all is seemingly well. See: https://github.com/vsajip/clang/commit/6958016e54862b1f5bc17a44bffeba8d4df7cb97 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 7 10:08:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 10:08:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 10879] Possibly mismatched push_back/pop_back in SemaTemplateInstantiate.cpp In-Reply-To: References: Message-ID: <20110907150837.6C5702A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10879 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Douglas Gregor 2011-09-07 10:08:36 CDT --- This is another manifestation of PR8345 *** This bug has been marked as a duplicate of bug 8345 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 7 12:16:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 12:16:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 10701] Assert failure in DwarfDebug.cpp In-Reply-To: References: Message-ID: <20110907171629.457C22A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10701 Thomas B. Jablin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Thomas B. Jablin 2011-09-07 12:16:28 CDT --- I rebuilt the test case from source with clang and LLVM revision 139148. It appears to work correctly now, so I am marking the bug fixed. Thanks. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Sep 7 14:34:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 14:34:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10883] New: Crash stemming from typo correction when compiling template subclass Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10883 Summary: Crash stemming from typo correction when compiling template subclass Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rikka at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code causes clang to crash due to a NULL Decl pointer: template class Base { public: typedef long Container; }; template class Derived : public Base { public: using Base::Container; void foo(const Container& current); }; The crash is at SemaDecl.cpp:310 309 NamedDecl *Result = Corrected.getCorrectionDecl(); 310 if ((isa(Result) || isa(Result)) && 311 !Result->isInvalidDecl()) { (gdb) p Result $1 = (clang::NamedDecl *) 0x0 Simply put, this is a situation where Sema::CorrectTypo returns a non-keyword correction without an associated NamedDecl. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 7 15:02:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 15:02:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 10884] New: [AVX] crash in generated code due to %rbp being clobbered Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10884 Summary: [AVX] crash in generated code due to %rbp being clobbered Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=7236) --> (http://llvm.org/bugs/attachment.cgi?id=7236) test case I'm seeing a crash upon exiting the _mandelbrot_ispc function defined in the attached test case. Upon examination, it turns out that %rbp is 0x0, such that things go south upon the following at the end: mov %rbp, %rsp pop %rbp The issue seems to be that %ebp has been used as a temporary register in the vmovmskps %ymm12, %ebp instruction at line 242 in the attached 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 Wed Sep 7 15:27:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 15:27:38 -0500 (CDT) Subject: [LLVMbugs] [Bug 10883] Crash stemming from typo correction when compiling template subclass In-Reply-To: References: Message-ID: <20110907202738.3F9AF2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10883 Kaelyn Uhrain changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from Kaelyn Uhrain 2011-09-07 15:27:38 CDT --- The fix and test case have been committed as r139252. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Sep 7 15:32:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 15:32:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 10874] segfault on error: "cannot use 'c++-cpp-output' output with multiple -arch options" In-Reply-To: References: Message-ID: <20110907203248.3E0AA2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10874 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #9 from Eli Friedman 2011-09-07 15:32:47 CDT --- 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 Wed Sep 7 15:36:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 7 Sep 2011 15:36:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 10578] C++ compiler skips parent constructor In-Reply-To: References: Message-ID: <20110907203633.7AB702A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=10578 Douglas Gregor