From bugzilla-daemon at llvm.org Sat Jan 1 05:00:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 05:00:37 -0600 (CST) Subject: [LLVMbugs] [Bug 8879] New: -Wtype-limits not implemented Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8879 Summary: -Wtype-limits not implemented Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tss at iki.fi CC: llvmbugs at cs.uiuc.edu No warnings are given when comparing a type against impossible values. Example: int main(void) { unsigned short a = 0; if (a < 0) return 1; if (a > 65535) return 1; if (a == -1) return 1; return 0; } gcc warns: test2.c:3: warning: comparison is always false due to limited range of data type test2.c:4: warning: comparison is always false due to limited range of data type test2.c:5: warning: comparison is always false due to limited range of data type clang doesn't warn anything. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 13:07:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 13:07:38 -0600 (CST) Subject: [LLVMbugs] [Bug 8878] [MC] regression: unknown fixup kind in ELF In-Reply-To: References: Message-ID: <20110101190738.2F2582A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8878 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Rafael ?vila de Esp?ndola 2011-01-01 13:07:37 CST --- Fixed in 122658. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 13:55:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 13:55:42 -0600 (CST) Subject: [LLVMbugs] [Bug 8880] New: clang dies processing a for loop Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8880 Summary: clang dies processing a for loop Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bagnara at cs.unipr.it CC: llvmbugs at cs.uiuc.edu $ cat f3.c int f3() { int first = 1; for ( ; ({ if (first) { first = 0; continue; } 0; }); ) return 0; return 1; } $ ~/llvm.debug/Debug+Asserts/bin/clang /tmp/f3.c 0 clang 0x00000000020d461a 1 clang 0x00000000020d440d 2 libpthread.so.0 0x0000003dcd80f3c0 3 libc.so.6 0x0000003dccd34245 4 clang 0x00000000016a5d53 clang::BumpVector::grow(clang::BumpVectorContext&, unsigned long) + 165 5 clang 0x00000000016a419f clang::BumpVector::push_back(clang::CFGBlock* const&, clang::BumpVectorContext&) + 127 6 clang 0x00000000016a361e clang::CFGBlock::addSuccessor(clang::CFGBlock*, clang::BumpVectorContext&) + 64 7 clang 0x000000000169517e 8 clang 0x000000000169a8db 9 clang 0x00000000016968c6 10 clang 0x0000000001694fe1 11 clang 0x0000000001697be1 12 clang 0x000000000169687d 13 clang 0x0000000001694fe1 14 clang 0x0000000001698725 15 clang 0x0000000001696ae5 16 clang 0x0000000001694fe1 17 clang 0x0000000001697be1 18 clang 0x000000000169aa6f 19 clang 0x0000000001696cbf 20 clang 0x0000000001694fe1 21 clang 0x0000000001698fe9 22 clang 0x0000000001696a9f 23 clang 0x0000000001694fe1 24 clang 0x0000000001697be1 25 clang 0x000000000169687d 26 clang 0x0000000001694fe1 27 clang 0x0000000001695568 28 clang 0x000000000169c4c7 clang::CFG::buildCFG(clang::Decl const*, clang::Stmt*, clang::ASTContext*, clang::CFG::BuildOptions) + 103 29 clang 0x000000000168e6a1 clang::AnalysisContext::getCFG() + 233 30 clang 0x0000000001555a0c 31 clang 0x0000000001556535 32 clang 0x0000000001556a0a clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy, clang::Decl const*, clang::QualType) + 558 33 clang 0x0000000001556b21 clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy, clang::FunctionDecl const*) + 57 34 clang 0x0000000001385bca clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 2164 35 clang 0x000000000138534e clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*) + 60 36 clang 0x00000000012da581 clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 271 37 clang 0x00000000012e04d9 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 1001 38 clang 0x00000000012e6458 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 522 39 clang 0x00000000012e0065 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 1079 40 clang 0x00000000012e00d1 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 95 41 clang 0x00000000012dfa2c clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList, clang::Parser::ParsingDeclSpec*) + 2364 42 clang 0x00000000012df061 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 343 43 clang 0x00000000012c9468 clang::ParseAST(clang::Sema&, bool) + 328 44 clang 0x000000000103d3ed clang::ASTFrontendAction::ExecuteAction() + 263 45 clang 0x00000000011675af clang::CodeGenAction::ExecuteAction() + 969 46 clang 0x000000000103d040 clang::FrontendAction::Execute() + 320 47 clang 0x0000000001025c11 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 745 48 clang 0x0000000000fd52f5 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 878 49 clang 0x0000000000fc763f cc1_main(char const**, char const**, char const*, void*) + 990 50 clang 0x0000000000fd0890 main + 484 51 libc.so.6 0x0000003dccc1ee7d __libc_start_main + 253 52 clang 0x0000000000fc6cd9 Stack dump: 0. Program arguments: /home/roberto/llvm.debug/Debug+Asserts/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name f3.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51.0.7 -resource-dir /home/roberto/llvm.debug/Debug+Asserts/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-91LqrB.o -x c /tmp/f3.c 1. parser at end of file 2. /tmp/f3.c:1:10: parsing function body 'f3' clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 1 14:38:58 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 14:38:58 -0600 (CST) Subject: [LLVMbugs] [Bug 2313] ARM: Rd and Rm registers should be different in MUL on ARMv5 In-Reply-To: References: Message-ID: <20110101203858.44E192A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=2313 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #12 from Anton Korobeynikov 2011-01-01 14:38:56 CST --- Should be fixed in r122663 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 14:39:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 14:39:07 -0600 (CST) Subject: [LLVMbugs] [Bug 8157] ARM: rdhi, rdlo and rm registers should be different in SMULL on ARMv5 In-Reply-To: References: Message-ID: <20110101203907.F321E2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8157 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Anton Korobeynikov 2011-01-01 14:39:07 CST --- Should be fixed in r122663 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 15:56:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 15:56:09 -0600 (CST) Subject: [LLVMbugs] [Bug 8881] New: We need warnings or errors for unsupported uses of 'asm' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8881 Summary: We need warnings or errors for unsupported uses of 'asm' Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Currently clang uses the asm in a local variable declaration only when that variable is used in a asm statement. We should produce warnings when we can. Some options: 1) Produce warnings when a variable is not use in an asm statement. This would warn in void foo(void) { register unsigned long long bar asm("rax"); //Warning } 2) Warn when a variable is used in a non asm statement. This would warn in int foo(void) { register unsigned long long bar asm("rax"); return bar + 1; // Warning } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 1 16:40:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 16:40:10 -0600 (CST) Subject: [LLVMbugs] [Bug 8882] New: Poor scalar optimization loses trip count info Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8882 Summary: Poor scalar optimization loses trip count info Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu We compile this: template void fill(Iterator first, Iterator last, T value) { while (first != last) *first++ = value; } int X[1000]; void foo() { fill(X, X+1000, 0); } with: clang t.cpp -S -o - -emit-llvm -O3 into: while.body.i: ; preds = %while.body.i, %entry %indvar.i = phi i64 [ %tmp.i, %while.body.i ], [ 0, %entry ] %tmp.i = add i64 %indvar.i, 1 %first.addr.05.i = getelementptr [1000 x i32]* @X, i64 0, i64 %indvar.i store i32 0, i32* %first.addr.05.i, align 4, !tbaa !0 %ptrincdec.i.idx.mask = and i64 %tmp.i, 4611686018427387903 %cmp.i = icmp eq i64 %ptrincdec.i.idx.mask, 1000 br i1 %cmp.i, label %_Z4fillIPiiEvT_S1_T0_.exit, label %while.body.i This loop executes exactly 1000 times. This appears to be being pessimized by the -indvars pass, as can be seen by: clang t.cpp -S -o - -emit-llvm -O0 | opt -mem2reg -S -inline -loop-rotate -instcombine -indvars which introduces the 'and'. The and is not needed because the GEP can't wrap around. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 16:44:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 16:44:06 -0600 (CST) Subject: [LLVMbugs] [Bug 8883] New: SCEV doing a poor job simplifying constant expressions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8883 Summary: SCEV doing a poor job simplifying constant expressions Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu This code: void fill(Iterator first, Iterator last, T value) { while (first != last) *first++ = value; } char X[1000]; void foo() { fill(X, X+1000, 0); } Compiles with: clang t.cpp -S -o - -emit-llvm -O3 into: ... while.body.i: ; preds = %while.body.i, %entry %indvar.i = phi i64 [ 0, %entry ], [ %indvar.next.i, %while.body.i ] %first.addr.05.i = getelementptr [1000 x i8]* @X, i64 0, i64 %indvar.i store i8 0, i8* %first.addr.05.i, align 1, !tbaa !0 %indvar.next.i = add i64 %indvar.i, 1 %exitcond = icmp eq i64 %indvar.next.i, ptrtoint (i8* getelementptr ([1000 x i8]* @X, i64 1, i64 sub (i64 0, i64 ptrtoint ([1000 x i8]* @X to i64))) to i64) br i1 %exitcond, label %_Z4fillIPciEvT_S1_T0_.exit, label %while.body.i Notice the poor icmp, which should be comparing the indvar against 1000. SCEV should simplify this away. This can also be seen in simple_types_constant_folding.llvm.bc in Nehalem:SingleSource/Benchmarks/Adobe-C++ where SCEV is expanding an expression for the loop-idiom pass, resulting in this crazy memset: call void @llvm.memset.p0i8.i64(i8* getelementptr inbounds ([8000 x i8]* @data8, i64 0, i64 0), i8 %11, i64 ptrtoint (i8* getelementptr ([8000 x i8]* @data8, i64 1, i64 sub (i64 0, i64 ptrtoint ([8000 x i8]* @data8 to i64))) to i64), i32 16, i1 false) Codegen is able to simplify the constant to "8000", but the expression simplification logic in SCEV should do this. This may be just a matter of using lib/Analysis/ConstantFolding APIs with target data in scev. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 17:49:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 17:49:22 -0600 (CST) Subject: [LLVMbugs] [Bug 6394] Optimizer swaps bitcast and getelementptr in an invalid way In-Reply-To: References: Message-ID: <20110101234922.7B1282A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6394 Henning Thielemann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Version|2.6 |2.8 Resolution|FIXED | --- Comment #7 from Henning Thielemann 2011-01-01 17:49:21 CST --- (In reply to comment #6) > Please update to LLVM 2.8, or better yet, mainline. We do not put out bug > fixes for previous releases. I'm continuing to comment on this problem, because it still exists. The only difference between LLVM-2.6 and LLVM-2.8 is, that the problem now only occurs when calling the optimizer via LLVM's C interface, and I cannot reproduce it any longer via 'opt' in the shell. The ticket was closed as FIXED without a comment how it was fixed. The last comment before closing the ticket was, that I shall set a target string in LL file and I answered, that I have initially no LL file, because I'm using JIT (via the C wrapper to LLVM). I think the following phenomenon is just another instance of the same problem. I have generated code with the JIT, written to a Bitcode file and disassembled. Then I have optimized it, trying to match -O1 as good as possible as the C wrapper around LLVM allows. In the optimized module some getelementptrs to a struct are replaced by accesses via constant offsets and pointer casting, where the offsets seem to be made for a 64 bit machine (but I have a 32 bit machine). optimized by opt (correct): %9 = getelementptr %0* %2, i32 0, i32 0, i32 0 store i1 true, i1* %9 %10 = getelementptr %0* %2, i32 0, i32 0, i32 1, i32 0, i32 0, i32 0 store i32 1, i32* %10 %11 = getelementptr %0* %2, i32 0, i32 0, i32 1, i32 0, i32 0, i32 1, i32 0, i32 1 store float 0x3FD99999A0000000, float* %11 %12 = getelementptr %0* %2, i32 0, i32 0, i32 1, i32 0, i32 1, i32 0, i32 0, i32 1 store i32 %4, i32* %12 %13 = getelementptr %0* %2, i32 0, i32 1, i32 0 store float 0.000000e+00, float* %13 %14 = getelementptr %0* %2, i32 0, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 0, i32 0, i32 0 store i32 %6, i32* %14 %15 = getelementptr %0* %2, i32 0, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 0, i32 0, i32 1 store float* %8, float** %15 %16 = getelementptr %0* %2, i32 0, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 0, i32 1, i32 1 store float 0.000000e+00, float* %16 optimized by JIT (invalid): %9 = bitcast i8* %1 to i1* store i1 true, i1* %9, align 1 %10 = getelementptr i8* %1, i64 4 %11 = bitcast i8* %10 to i32* store i32 1, i32* %11, align 4 %12 = getelementptr i8* %1, i64 8 %13 = bitcast i8* %12 to float* store float 0x3FD99999A0000000, float* %13, align 4 %14 = getelementptr i8* %1, i64 12 %15 = bitcast i8* %14 to i32* store i32 %4, i32* %15, align 4 %16 = getelementptr i8* %1, i64 16 %17 = bitcast i8* %16 to float* store float 0.000000e+00, float* %17, align 4 %18 = getelementptr i8* %1, i64 24 %19 = bitcast i8* %18 to i32* store i32 %6, i32* %19, align 4 %20 = getelementptr i8* %1, i64 32 %21 = bitcast i8* %20 to float** store float* %8, float** %21, align 8 %22 = getelementptr i8* %1, i64 40 %23 = bitcast i8* %22 to float* store float 0.000000e+00, float* %23, align 4 The offsets 16, 24, 32, 40 should have been 16, 20, 24, 28. The Release Notes of 2.7 say that in LLVM-2.6 no target string meant 'SparcV9'. Now I tried to reproduce the JIT behaviour via 'opt' by placing target triple = "sparcv9" on top of a disassembled bitcode file. However 'opt' still does not generate those accesses via constant offsets. The LLVM tools also do not complain about fictional target names, what made me nervous. In the end I still do not know, how to set the target specification via C wrapper around LLVM. I hoped that calling LLVMInitializeX86Target and LLVMInitializeX86TargetInfo would be enough, since these are the appropriate functions for my machine. If I have to set something other (LLVMSetDataLayout?) then I wonder how to do that (how to find out the appropriate settings for every target?) and why its default does not match my information given at initialization time. Since you said, that the problem is fixed, I assumed that my current problem must have another reason. Thus I have spent more than 15 hours with trying to simulate 'opt's behaviour via LLVM's C interface and since JIT-opt and Shell-opt still differed, I tried to simulate the JIT optimizer behaviour by 'opt'. Without success. I flooded my code with debug output. I tried hard to export my JIT constructed functions and typical parameter records to disk together with a driving main program, that allows to narrow the bug using bugpoint. No luck: JIT fails, LLVM shell tools work. I dissected my code with GDB in order to see what actually goes wrong. I am really frustrated now. I can well imagine that I use LLVM the wrong way. But if it is that easy, then there must be something improved in the JIT or in the C wrapper. At the very least the JIT optimizer behaviour must be better documented. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 19:17:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 19:17:40 -0600 (CST) Subject: [LLVMbugs] [Bug 8884] New: Surprising behavior with 'friend' and 'extern "C"' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8884 Summary: Surprising behavior with 'friend' and 'extern "C"' Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang rejects ---------- extern "C" { //struct foo; struct bar { friend struct foo; private: void zed () const; const struct foo& baz () const; }; struct foo { bar x; void zed () const; }; void foo::zed () const { x.zed (); } } ---------- but any of the following makes it accept it: *) Uncommenting the forward declaration of foo. *) Removing the extern "C". *) Commenting out the declaration of baz. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 1 21:41:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 1 Jan 2011 21:41:20 -0600 (CST) Subject: [LLVMbugs] [Bug 6394] Optimizer swaps bitcast and getelementptr in an invalid way In-Reply-To: References: Message-ID: <20110102034120.55BB82A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6394 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME --- Comment #8 from Chris Lattner 2011-01-01 21:41:19 CST --- Please provide a testcase that reproduces the problem. Without a testcase, we cannot fix it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 2 06:32:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 Jan 2011 06:32:49 -0600 (CST) Subject: [LLVMbugs] [Bug 8885] New: CMake Generator "Visual Studio 10 Win64" fails Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8885 Summary: CMake Generator "Visual Studio 10 Win64" fails Product: Build scripts Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Keywords: build-problem Severity: normal Priority: P Component: cmake AssignedTo: unassignedbugs at nondot.org ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu running the following commands: cmake ../../Source/LLVM -G"Visual Studio 10 Win64" causes following error: >-- Targeting X86 >CMake Error at M:/Development/utils/cmake/share/cmake-2.8/Modules/CMakeDetermineASMCompiler.cmake:68 (CMAKE_DETERMINE_COMPILER_ID_VENDOR): > Unknown CMake command "CMAKE_DETERMINE_COMPILER_ID_VENDOR". >Call Stack (most recent call first): > M:/Development/utils/cmake/share/cmake-2.8/Modules/CMakeDetermineASM_MASMCompiler.cmake:26 (INCLUDE) > lib/Target/X86/CMakeLists.txt:44 (enable_language) > > >CMake Error: Could not find cmake module file:M:/Development/x64-msvc/llvm/CMakeFiles/CMakeASM_MASMCompiler.cmake >-- Configuring incomplete, errors occurred! The generator "Visual Studio 10" does not exhibit this issue. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 2 07:29:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 Jan 2011 07:29:26 -0600 (CST) Subject: [LLVMbugs] [Bug 8886] New: GCC testcases that clang fails to devirtualize Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8886 Summary: GCC testcases that clang fails to devirtualize Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The attached testcases were recently posted to the gcc mailing list. GCC from top-of-tree apparently manages to completely devirtualize the code in "main" for each of them, but clang does not at -O4. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 2 07:39:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 Jan 2011 07:39:31 -0600 (CST) Subject: [LLVMbugs] [Bug 8702] opt -loop-rotate never completes In-Reply-To: References: Message-ID: <20110102133931.232DC2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8702 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #13 from Duncan Sands 2011-01-02 07:39:30 CST --- Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20101227/114494.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 2 12:55:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 Jan 2011 12:55:59 -0600 (CST) Subject: [LLVMbugs] [Bug 8885] CMake Generator "Visual Studio 10 Win64" fails In-Reply-To: References: Message-ID: <20110102185559.EB1CD2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8885 ?scar Fuentes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from ?scar Fuentes 2011-01-02 12:55:59 CST --- This is a cmake 2.8.3 bug. If you put INCLUDE(CMakeDetermineCompilerId) at the beginning of M:/Development/utils/cmake/share/cmake-2.8/Modules/CMakeDetermineASMCompiler.cmake, it works fine. It is already fixed on cmake's git repo. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 2 15:27:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 Jan 2011 15:27:59 -0600 (CST) Subject: [LLVMbugs] [Bug 8887] New: [deadargelim] should be reworked as a CGSCC pass Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8887 Summary: [deadargelim] should be reworked as a CGSCC pass Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu The DeadArgElim is an old-school Module pass. It should be reworked to be a CGSCC pass, which would allow it to benefit from things like "iterate after devirtualization" as well as making it more powerful since it will benefit from things done by the scalar optimizer. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 2 17:40:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 Jan 2011 17:40:38 -0600 (CST) Subject: [LLVMbugs] [Bug 8888] New: [MS Bugs] char/signed char decl compatibility. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8888 Summary: [MS Bugs] char/signed char decl compatibility. Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bigcheesegs at gmail.com CC: llvmbugs at cs.uiuc.edu, pichet2000 at gmail.com MSVC allows the following in C mode (in C++ it's always legal because of overloading) while clang (correctly) does not. Clang should support this in ms-extensions mode, although I do not yet know the exact semantics (does it use signed or unsigned?). int __cdecl _access( const char * _Filename, int _AccessMode); int __cdecl _access( const signed char *path,int amode) { return 0; } C:\Users\Michael\Projects\msvcrt\research>clang -fsyntax-only double-decl.c double-decl.c(2) : error: conflicting types for '_access' int __cdecl _access( const signed char *path,int amode) ^ double-decl.c(1) : note: previous declaration is here int __cdecl _access( const char * _Filename, int _AccessMode); ^ 1 error generated. C:\Users\Michael\Projects\msvcrt\research>clang++ -fsyntax-only -x c++ double-decl.c C:\Users\Michael\Projects\msvcrt\research>cl -Zs double-decl.c -nologo -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 2 21:26:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 Jan 2011 21:26:39 -0600 (CST) Subject: [LLVMbugs] [Bug 8889] New: codegenprepare takes about 10% of llc time on 403.gcc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8889 Summary: codegenprepare takes about 10% of llc time on 403.gcc 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: zwarich at apple.com CC: llvmbugs at cs.uiuc.edu codegenprepare takes about 10% of llc time on 403.gcc. Even when I remove the fixed point iteration, it still uses a bit over half of that. Something is wrong here, because there is no way codegenprepare should take that long. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 2 23:10:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 Jan 2011 23:10:18 -0600 (CST) Subject: [LLVMbugs] [Bug 8890] New: build.llvm.org should redirect to http://google1.osuosl.org:8011/ Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8890 Summary: build.llvm.org should redirect to http://google1.osuosl.org:8011/ Product: Website Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: General Website AssignedTo: unassignedbugs at nondot.org ReportedBy: zwarich at apple.com CC: llvmbugs at cs.uiuc.edu I am so used to typing build.webkit.org. It would be nice to have something as easy to remember for LLVM. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 2 23:33:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 2 Jan 2011 23:33:05 -0600 (CST) Subject: [LLVMbugs] [Bug 8891] New: Early phases of backend recompute dominators too often Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8891 Summary: Early phases of backend recompute dominators too often 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: zwarich at apple.com CC: llvmbugs at cs.uiuc.edu Machine Module Information ModulePass Manager FunctionPass Manager Preliminary module verification Dominator Tree Construction Module Verifier Natural Loop Information Loop Pass Manager Canonicalize natural loops Scalar Evolution Analysis Loop Pass Manager Induction Variable Users Canonicalize natural loops Induction Variable Users Loop Strength Reduction Lower Garbage Collection Instructions Remove unreachable blocks from the CFG Dominator Tree Construction <--- Here Exception handling preparation Optimize for code generation Insert stack protectors Preliminary module verification Dominator Tree Construction <--- Here Module Verifier The last dominator tree computation should be easy to get rid of, since DwarfEHPrepare already preserves dominators, CodeGenPrepare only messes with blocks that have a single successor, and StackProtector only needs to be concerned with the two blocks that it adds (which both have the same idom). The one before it might not be so easy, but "UnreachableBlockElim" is entirely dominator based, so it won't be the problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 3 00:12:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 00:12:47 -0600 (CST) Subject: [LLVMbugs] [Bug 8892] New: CGSCCPassManager does not visit all functions. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8892 Summary: CGSCCPassManager does not visit all functions. Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5945) --> (http://llvm.org/bugs/attachment.cgi?id=5945) testcase The call graph SCC pass manager does not visit any of the functions in this example .ll file. For fun, try running: opt -instcombine -debug x.ll to see that it visits every function, then opt -functionattrs -instcombine -debug x.ll to see that it visits none. The pass' runOnSCC is being called only once with a single CallGraphNode, being the external one (CGN->getFunction() == NULL). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 3 00:29:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 00:29:34 -0600 (CST) Subject: [LLVMbugs] [Bug 8892] CGSCCPassManager does not visit all functions. In-Reply-To: References: Message-ID: <20110103062934.C28252A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8892 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2011-01-03 00:29:34 CST --- All your functions are invalid, therefore they are not reachable from the callgraph. We're optimizing compile time! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 3 02:28:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 02:28:10 -0600 (CST) Subject: [LLVMbugs] [Bug 8893] New: Build warning in APInt.cpp while building trunk on DragonflyBSD current. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8893 Summary: Build warning in APInt.cpp while building trunk on DragonflyBSD current. Product: new-bugs Version: trunk Platform: PC OS/Version: DragonFly BSD Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: eocallaghan at auroraux.org CC: llvmbugs at cs.uiuc.edu APInt.cpp: In member function 'llvm:APInt llvm:APInt:sqrt() const': APInt.cpp:1378: warning: passing double for argument 2 to 'llvm:APInt:APInt(unsigned int, uint64_t, bool)' Building with GCC 4.1.2 and llvm/clang svn rev 122743. Regards, -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 05:11:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 05:11:27 -0600 (CST) Subject: [LLVMbugs] [Bug 8894] New: Clang++ misses an invalid construct in Sema and assert in codegen. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8894 Summary: Clang++ misses an invalid construct in Sema and assert in codegen. Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: devlists at shadowlab.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5946) --> (http://llvm.org/bugs/attachment.cgi?id=5946) Make clang assert Attached is a sample where clang++ does not emit any diagnostic (where it should) and so try to codegen invalid code (and assert). > clang++ --version clang version 2.9 (trunk 122743) Target: x86_64-apple-darwin10 Thread model: posix > clang++ Metadata.cpp Assertion failed: (E && !hasAggregateLLVMType(E->getType()) && "Invalid scalar expression to emit"), function EmitScalarExpr, file /Volumes/MacPro/Projects/OpenSource/llvm/tools/clang/lib/CodeGen/CGExprScalar.cpp, line 2515. 0 clang 0x0000000100eb6aa2 PrintStackTrace(void*) + 34 1 clang 0x0000000100eb7049 SignalHandler(int) + 857 2 libSystem.B.dylib 0x00007fff8326667a _sigtramp + 26 3 libSystem.B.dylib 0x010000010204ba01 _sigtramp + 2128499617 4 clang 0x0000000100011b06 abort + 22 5 clang 0x0000000100011ac8 __assert_rtn + 56 6 clang 0x0000000100186f5e clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 222 7 clang 0x000000010019139a clang::StmtVisitor<(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 21242 8 clang 0x0000000100186f3d clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 189 [?] 1. parser at end of file 2. Metadata.cpp:15:13: LLVM IR generation of declaration 'test' 3. Metadata.cpp:15:13: Generating code for declaration 'test' 4. Metadata.cpp:15:20: LLVM IR generation of compound statement ('{}') clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 3 06:30:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 06:30:44 -0600 (CST) Subject: [LLVMbugs] [Bug 8895] New: [REGRESSION] Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8895 Summary: [REGRESSION] Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!") Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ismail at namtrac.org CC: llvmbugs at cs.uiuc.edu Trying to compile snow.c with clang trunk; clang -I. -I"/Users/cartman/Sources/ffmpeg" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -DHAVE_AV_CONFIG_H -std=c99 -mdynamic-no-pic -fomit-frame-pointer -fPIC -g -Wdeclaration-after-statement -Wall -Wno-parentheses -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -O3 -fno-math-errno -fno-signed-zeros -mllvm -stack-alignment=16 -Qunused-arguments -MMD -c -o libavcodec/snow.o libavcodec/snow.c Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"), function ~ScopedHashTableScope, file /Users/cartman/Sources/llvm/include/llvm/ADT/ScopedHashTable.h, line 224. 0 clang 0x00000001014b4df2 llvm::SmallVectorTemplateBase::grow(unsigned long) + 754 1 clang 0x00000001014b5c43 llvm::SmallVectorTemplateBase::grow(unsigned long) + 4419 2 libSystem.B.dylib 0x00007fff81fe867a _sigtramp + 26 3 libSystem.B.dylib 0x0000000102afc080 _sigtramp + 2159098400 4 clang 0x000000010001a472 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 3474 5 clang 0x00000001010fc920 llvm::cast_retty >::ret_type llvm::cast >(llvm::ilist_iterator const&) + 5984 6 clang 0x00000001010fcf12 llvm::cast_retty >::ret_type llvm::cast >(llvm::ilist_iterator const&) + 7506 7 clang 0x00000001010fcedf llvm::cast_retty >::ret_type llvm::cast >(llvm::ilist_iterator const&) + 7455 8 clang 0x00000001010fcedf llvm::cast_retty >::ret_type llvm::cast >(llvm::ilist_iterator const&) + 7455 9 clang 0x00000001010fcedf llvm::cast_retty >::ret_type llvm::cast >(llvm::ilist_iterator const&) + 7455 10 clang 0x00000001010fcedf llvm::cast_retty >::ret_type llvm::cast >(llvm::ilist_iterator const&) + 7455 11 clang 0x00000001010fe19c llvm::cast_retty >::ret_type llvm::cast >(llvm::ilist_iterator const&) + 12252 12 clang 0x00000001013e8af0 llvm::BasicBlockPass::~BasicBlockPass() + 31584 13 clang 0x0000000101256eb1 std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique(std::_Rb_tree_iterator >, std::pair const&) + 7473 14 clang 0x0000000101257c81 std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique(std::_Rb_tree_iterator >, std::pair const&) + 11009 15 clang 0x00000001013ea7ff llvm::BasicBlockPass::~BasicBlockPass() + 39023 16 clang 0x00000001013eaaf3 llvm::BasicBlockPass::~BasicBlockPass() + 39779 17 clang 0x00000001013eabcd llvm::BasicBlockPass::~BasicBlockPass() + 39997 18 clang 0x0000000100177d6f clang::PCHGenerator::~PCHGenerator() + 5823 19 clang 0x000000010029f2fe llvm::IRBuilder >::CreateIsNull(llvm::Value*, llvm::Twine const&) + 1822 20 clang 0x00000001002e4dc9 llvm::IRBuilder >::CreateGEP(llvm::Value*, llvm::Value*, llvm::Twine const&) + 1065 21 clang 0x000000010029fefc llvm::IRBuilder >::CreateIsNull(llvm::Value*, llvm::Twine const&) + 4892 22 clang 0x0000000100052829 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 7561 23 clang 0x0000000100024612 std::_Rb_tree, std::less, std::allocator >::_M_insert_unique(std::string const&) + 2002 24 clang 0x000000010001c29a std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 11194 25 clang 0x0000000100023644 std::vector >::operator=(std::vector > const&) + 12196 26 clang 0x000000010001abf4 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 5396 27 clang 0x0000000000000046 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 4294863206 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name snow.c -pic-level 2 -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.14 -g -resource-dir /usr/local/bin/../lib/clang/2.9 -dependency-file libavcodec/snow.d -MT libavcodec/snow.o -D _ISOC99_SOURCE -D _POSIX_C_SOURCE=200112 -D _FILE_OFFSET_BITS=64 -D _LARGEFILE_SOURCE -D PIC -D HAVE_AV_CONFIG_H -I . -I /Users/cartman/Sources/ffmpeg -O3 -Wdeclaration-after-statement -Wall -Wno-parentheses -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -std=c99 -ferror-limit 19 -fmessage-length 120 -stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -mllvm -stack-alignment=16 -o libavcodec/snow.o -x c libavcodec/snow.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'libavcodec/snow.c'. 4. Running pass 'Early CSE' on function '@mc_block' clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 3 11:41:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 11:41:15 -0600 (CST) Subject: [LLVMbugs] [Bug 8654] clang-as-a-library's preprocessor doesn't trigger Elif, Else and Endif callbacks at the right times In-Reply-To: References: Message-ID: <20110103174115.668CF2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8654 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |chandlerc at gmail.com Resolution| |FIXED --- Comment #4 from Chandler Carruth 2011-01-03 11:41:14 CST --- Fixed in r122755. Thanks for the patch, and sorry for delays committing 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 Jan 3 12:28:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 12:28:30 -0600 (CST) Subject: [LLVMbugs] [Bug 8895] [REGRESSION] Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!") In-Reply-To: References: Message-ID: <20110103182830.49B5E2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8895 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2011-01-03 12:28:29 CST --- Fixed in r122758, thanks for the testcase! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 3 13:28:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 13:28:04 -0600 (CST) Subject: [LLVMbugs] [Bug 8841] Spurious "unused function" diagnostic with inline friend definition In-Reply-To: References: Message-ID: <20110103192804.264002A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8841 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chandler Carruth 2011-01-03 13:28:03 CST --- Submitted this patch in r122763 w/ dgregor's sign off. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 15:32:58 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 15:32:58 -0600 (CST) Subject: [LLVMbugs] [Bug 8896] New: dragonegg: Assertion `bitPosition < getBitWidth() && "Bit position out of bounds!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8896 Summary: dragonegg: Assertion `bitPosition < getBitWidth() && "Bit position out of bounds!"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu We've not done any dragonegg testing before today. If it's not ready for a bit of stress testing just say. The -v output doesn't say the dragonegg/LLVM versions; they are 122764 and 122768. [regehr at gamow tmp439]$ gcc-4.5 -fplugin=/home/regehr/z/compiler-source/dragonegg/dragonegg.so -v Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.3/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/home/regehr/z --enable-languages=c,c++ --program-suffix=-4.5 --enable-plugin --enable-lto Thread model: posix gcc version 4.5.3 20110103 (prerelease) (GCC) [regehr at gamow tmp439]$ gcc-4.5 -fplugin=/home/regehr/z/compiler-source/dragonegg/dragonegg.so -O2 small.c small.c:17:1: warning: overflow in implicit constant conversion small.c: In function 'func_91': small.c:31:6: warning: comparison between pointer and integer cc1: APInt.cpp:486: bool llvm::APInt::operator[](unsigned int) const: Assertion `bitPosition < getBitWidth() && "Bit position out of bounds!"' failed. Stack dump: 0. Running pass 'Combine redundant instructions' on function '@func_91' gcc-4.5: Internal error: Aborted (program cc1) Please submit a full bug report. See for instructions. [regehr at gamow tmp439]$ cat small.c static short foo (short left, int right) { return left || right || right >= 0 ? left : left >> right; } static unsigned char bar (unsigned long ui1, unsigned long ui2) { ui2 ? : (ui1 % ui2); return 0; } short *g_22; short g_38; short g_54[7] = { 0x1F32AFCBL }; short **volatile g = &g_22; short g_265[4] = { 0x4F2AL }; int func_14 (short*, short*, short*, int); void func_91 (int * const p_92) { short l_125; short *l_264 = &l_125; *g >= bar (g_38, (1 && *p_92) ^ foo (func_14 (l_264, &g_54[0], &g_54[6], 0), 0x9DADCB93L)), g_265[2]; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 3 19:01:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 19:01:59 -0600 (CST) Subject: [LLVMbugs] [Bug 8897] New: Clang fails to find crtbegin.o Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8897 Summary: Clang fails to find crtbegin.o Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: greened at obbligato.org CC: llvmbugs at cs.uiuc.edu I get the following for the Driver/hello.c test on SuSE Linux 10.1: "/ptmp/dag/build.llvm.trunk.official.opt/x86_64-unknown-linux-gnu/Release+Asserts/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name hello.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.17 -resource-dir /ptmp/dag/build.llvm.trunk.official.opt/x86_64-unknown-linux-gnu/Release+Asserts/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 0 -fgnu-runtime -fdiagnostics-show-option -o /tmp/cc-cppG60.o -x c /ptmp/dag/llvm-project.official/llvm/trunk/tools/clang/test/Driver/hello.c "/opt/cpkg/v6/binutils/2.17/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /ptmp/dag/build.llvm.trunk.official.opt/x86_64-unknown-linux-gnu/tools/clang/test/Driver/Output/hello.c.tmp /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o crtbegin.o -L -L/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/../../.. /tmp/cc-cppG60.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o /usr/lib/../lib64/crtn.o /opt/cpkg/v6/binutils/2.17/bin/ld: crtbegin.o: No such file: No such file or directory clang: error: linker command failed with exit code 1 (use -v to see invocation) I believe this is happening because the gcc used to build clang is not in a standard location: /opt/gcc/4.5.1/bin/g++ Or alternatively, the system gcc is not listed in the ToolChains.cpp GccVersions list: const char* GccVersions[] = {"4.5.1", "4.5", "4.4.5", "4.4.4", "4.4.3", "4.4", "4.3.4", "4.3.3", "4.3.2"}; dag at royale:/ptmp/dag/compiler_ref$ which gcc /usr/bin/gcc dag at royale:/ptmp/dag/compiler_ref$ gcc --version gcc (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. In any case, the driver should not rely on a small set of hardcoded guesses as to where crtbegin.o is. A simple solution would be to use the build gcc's -print-search-dirs to get a list of candidate directories and fall back on the hardcoded ones as a last resort. Obviously different handling would be required if gcc were not the build compiler but for Linux, most of the time it will be. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 3 21:39:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 3 Jan 2011 21:39:17 -0600 (CST) Subject: [LLVMbugs] [Bug 8898] New: dragonegg bug: nondeterministic wrong code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8898 Summary: dragonegg bug: nondeterministic wrong code Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu The correct answer is 1. No idea what's going on, perhaps memory unsafety + ASLR. GCC-4.5, dragonegg, and LLVM are all from today. [regehr at gamow tmp440]$ gcc-4.5 -fplugin=/home/regehr/z/compiler-source/dragonegg/dragonegg.so -O0 small.c -o small [regehr at gamow tmp440]$ ./small g_321[1].f0 = 252 [regehr at gamow tmp440]$ gcc-4.5 -fplugin=/home/regehr/z/compiler-source/dragonegg/dragonegg.so -O0 small.c -o small [regehr at gamow tmp440]$ ./small g_321[1].f0 = 235 [regehr at gamow tmp440]$ gcc-4.5 -fplugin=/home/regehr/z/compiler-source/dragonegg/dragonegg.so -O0 small.c -o small [regehr at gamow tmp440]$ ./small g_321[1].f0 = 156 [regehr at gamow tmp440]$ clang -O0 small.c -o small[regehr at gamow tmp440]$ ./small g_321[1].f0 = 1 [regehr at gamow tmp440]$ gcc-4.5 -fplugin=/home/regehr/z/compiler-source/dragonegg/dragonegg.so -v Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.3/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/home/regehr/z --enable-languages=c,c++ --program-suffix=-4.5 --enable-plugin --enable-lto Thread model: posix gcc version 4.5.3 20110103 (prerelease) (GCC) [regehr at gamow tmp440]$ cat small.c #pragma pack(push) #pragma pack(1) struct S1 { int f0 : 23; }; #pragma pack(pop) static struct S1 g_36 = {0}; static struct S1 g_321[2] = {{1}, {1}}; static struct S1 func_31(void) { return g_36; } int printf(const char *format, ...); int main (void) { g_321[0] = func_31(); printf("g_321[1].f0 = %d\n", g_321[1].f0); return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 4 03:23:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 03:23:24 -0600 (CST) Subject: [LLVMbugs] [Bug 8899] New: including fenv.h fails on linux Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8899 Summary: including fenv.h fails on linux Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: quintino at vki.ac.be CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5953) --> (http://llvm.org/bugs/attachment.cgi?id=5953) raising fe exceptions When including the header: #include in Linux, the compiler loses track of the headers being included inside this header... ---- /usr/include/c++/4.4/fenv.h has this snippet: #include #if _GLIBCXX_HAVE_FENV_H # include_next #endif and I think that the #include_next is treated incorrectly, because it should then parse the /usr/include/fenv.h and apparently it does not. For the attached example, the errors are: main.cxx:6:17: error: use of undeclared identifier 'FE_DIVBYZERO' if ( flags & FE_DIVBYZERO ) printf(" division by zero exception\n"); ^ main.cxx:7:17: error: use of undeclared identifier 'FE_ALL_EXCEPT' if (!(flags & FE_ALL_EXCEPT)) printf(" no exceptions\n"); ^ main.cxx:12:3: error: use of undeclared identifier 'fexcept_t' fexcept_t flags; ^ main.cxx:14:20: error: use of undeclared identifier 'flags' fegetexceptflag(&flags, FE_ALL_EXCEPT); ^ main.cxx:16:15: error: use of undeclared identifier 'flags' print_flags(flags); ^ main.cxx:18:17: error: use of undeclared identifier 'FE_DIVBYZERO' feraiseexcept(FE_DIVBYZERO); /* raise divide-by-zero exception */ ^ main.cxx:19:30: error: use of undeclared identifier 'FE_DIVBYZERO' int excepts = fetestexcept(FE_DIVBYZERO | FE_INEXACT); I can attest that it works on: - Mac OS X (Snow Leopard) + clang++ 2.8 (but of course the fenv.h headers are different) - Linux Ubuntu 10.10 + gcc 4.4 It fails so far in: - Linux Ubuntu 10.10 + clang++ 2.8 (but of course the fenv.h headers are different) I also tried the svn trunk around one month ago and the problem was the same. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 4 08:11:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 08:11:44 -0600 (CST) Subject: [LLVMbugs] [Bug 8900] New: Shufflevector of doubles generates incorrect code (using float shuff) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8900 Summary: Shufflevector of doubles generates incorrect code (using float shuff) Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav256 at gmail.com CC: llvmbugs at cs.uiuc.edu In the code below, the shuffle instruction is first selected to be unpckld, which is correct. However, during the ISel pattern matching phase, it is replaced with the unpackls instruction (which is incorrect). define <2 x double> @test_even_double4(<4 x double>* %srcA, <2 x double>* %dst){ %i5 = getelementptr inbounds <4 x double> * %srcA, i32 3 %i6 = load <4 x double>* %i5, align 32 %m387 = shufflevector <4 x double> %i6, <4 x double> undef, <2 x i32> ret <2 x double> %m387 } movaps XMM0, XMMWORD PTR [RDI + 96] unpcklps XMM0, XMMWORD PTR [RDI + 112] # xmm0 = xmm0[0],mem[0],xmm0[1],mem[1] ret -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 4 08:29:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 08:29:19 -0600 (CST) Subject: [LLVMbugs] [Bug 8901] New: Attribute mode rejected for enum types. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8901 Summary: Attribute mode rejected for enum types. Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: zaffanella at cs.unipr.it CC: llvmbugs at cs.uiuc.edu gcc allows mode attribute to be applied to (a declaration of) an enumerated type: typedef enum { a, b } E __attribute__((__mode__(__QI__))); clang rejects the code above with the following message: error: mode attribute only supported for integer and floating-point types typedef enum { a, b } E __attribute__((__mode__(__QI__))); In C99 (6.2.5 p17) an enumerated type is an integer type. Also note that gcc allows for the mode attribute to be directly specified on the enumeration type declaration (i.e., not necessarily through a typedef declaration). Namely, the following variants are accepted too: enum __attribute__((__mode__(__QI__))) E { a, b }; typedef enum __attribute__((__mode__(__QI__))) { a, b } E; clang instead complains as follows: error: 'mode' attribute invalid on this declaration, requires typedef or value typedef enum __attribute__((__mode__(__QI__))) { a, b } 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 Jan 4 08:43:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 08:43:28 -0600 (CST) Subject: [LLVMbugs] [Bug 8902] New: Wrong type source location for CXXMethodDecl Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8902 Summary: Wrong type source location for CXXMethodDecl Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alr at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com CXXMethodDecl *decl; When I call decl->getResultType().getAsString() I get: const string & However: decl->getTypeSourceInfo()->getTypeLoc().getBeginLoc().dump() gives me location of string not const No matter what type location methods I try to use, I can't seem to get to correct source pos (the one for const). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 4 08:48:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 08:48:14 -0600 (CST) Subject: [LLVMbugs] [Bug 8903] New: Wrong source location returned by FieldDecl::getLocEnd Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8903 Summary: Wrong source location returned by FieldDecl::getLocEnd Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alr at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com FieldDecl::getLocEnd() returns position after type decl, not semicolon class A { bool field1; // ^the value returned by getLocEnd() bool field2; // ^ expected -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 4 08:53:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 08:53:17 -0600 (CST) Subject: [LLVMbugs] [Bug 8903] Wrong source location returned by FieldDecl::getLocEnd In-Reply-To: References: Message-ID: <20110104145317.4A7BE2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8903 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Douglas Gregor 2011-01-04 08:53:16 CST --- Clang doesn't keep track of semicolons. This was essentially a design decision, so it doesn't make sense for us to hold a bug open for any specific case of missing-semicolon information (they're all missing). If the lack of semicolon location information is a problem, please open a discussion on the mailing 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 Jan 4 09:06:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 09:06:30 -0600 (CST) Subject: [LLVMbugs] [Bug 8903] Wrong source location returned by FieldDecl::getLocEnd In-Reply-To: References: Message-ID: <20110104150630.835E32A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8903 Alex changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from Alex 2011-01-04 09:06:30 CST --- (In reply to comment #1) > Clang doesn't keep track of semicolons. This was essentially a design decision, > so it doesn't make sense for us to hold a bug open for any specific case of > missing-semicolon information (they're all missing). If the lack of semicolon > location information is a problem, please open a discussion on the mailing > list. The problem is not about semicolons. getLocEnd() position returns position after type declaration, not after name (the end of token before semicolon). Please take another look at the description. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 09:08:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 09:08:19 -0600 (CST) Subject: [LLVMbugs] [Bug 8903] Wrong source location returned by FieldDecl::getLocEnd In-Reply-To: References: Message-ID: <20110104150819.BA9F62A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8903 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #3 from Douglas Gregor 2011-01-04 09:08:19 CST --- Clang is providing the location at the beginning of the field name, which is the last token in the declaration (except for the semicolon, which is not in the design). Please see http://clang.llvm.org/docs/InternalsManual.html#SourceRange for more information on this design. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 4 10:59:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 10:59:12 -0600 (CST) Subject: [LLVMbugs] [Bug 7696] SelectionDAGBuilder doing bad things on certain architectures In-Reply-To: References: Message-ID: <20110104165912.7034D2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7696 Micah Villmow changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Micah Villmow 2011-01-04 10:59:11 CST --- This was checked in by chris lattner. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 12:19:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 12:19:28 -0600 (CST) Subject: [LLVMbugs] [Bug 8896] instcombine crash on overlarge ashr In-Reply-To: References: Message-ID: <20110104181928.A5C162A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8896 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2011-01-04 12:19:28 CST --- Fixed in r122814, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 4 12:59:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 12:59:01 -0600 (CST) Subject: [LLVMbugs] [Bug 8902] Clang does not track the source locations of cv-qualifiers In-Reply-To: References: Message-ID: <20110104185901.A4CD52A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8902 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #5 from Douglas Gregor 2011-01-04 12:59:01 CST --- We decided not to include source-location information for cv-qualifiers because we're worried that it will greatly increase Clang's memory footprint. Zhanyong brings up a good point, though: I'm closing this bug as WONTFIX. If someone believes that this is the wrong choose, please discuss it on the mailing list rather than in a 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 Jan 4 13:03:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 13:03:37 -0600 (CST) Subject: [LLVMbugs] [Bug 8853] Clang goes into an endless loop while trying to compile ScummVM In-Reply-To: References: Message-ID: <20110104190337.BD3162A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8853 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Dale Johannesen 2011-01-04 13:03:36 CST --- This case is fixed by 122821. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 15:40:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 15:40:50 -0600 (CST) Subject: [LLVMbugs] [Bug 8904] New: gnu screen with/without InstCombine Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8904 Summary: gnu screen with/without InstCombine Product: libraries Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu these three files show difference: (first one is with InstCombine, second one is without) -rw------- 1 root wheel 64904 Jan 4 22:37 work/screen-4.0.3/ansi.o -rw------- 1 root wheel 64920 Jan 4 22:40 work/screen-4.0.3/ansi.o -rw------- 1 root wheel 9464 Jan 4 22:37 work/screen-4.0.3/input.o -rw------- 1 root wheel 10880 Jan 4 22:40 work/screen-4.0.3/input.o -rw------- 1 root wheel 68744 Jan 4 22:37 work/screen-4.0.3/screen.o -rw------- 1 root wheel 68792 Jan 4 22:40 work/screen-4.0.3/screen.o all the files are compiled with simple: clang -c -I. -I. -O2 -pipe -fno-strict-aliasing foo.c -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 4 16:31:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 16:31:28 -0600 (CST) Subject: [LLVMbugs] [Bug 8905] New: Clang rejects partial specialization with non-type template argument of different type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8905 Summary: Clang rejects partial specialization with non-type template argument of different type Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dgregor at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com terfin:clang dgregor$ cat t.cpp template struct X; template struct X; terfin:clang dgregor$ clang++ t.cpp t.cpp:5:10: error: non-type template argument depends on a template parameter of the partial specialization struct X; ^~ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 4 17:37:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 17:37:14 -0600 (CST) Subject: [LLVMbugs] [Bug 8905] Clang rejects partial specialization with non-type template argument of different type In-Reply-To: References: Message-ID: <20110104233714.402072A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8905 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-01-04 17:37:14 CST --- FUN! Fixed in Clang r122851. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 17:51:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 17:51:43 -0600 (CST) Subject: [LLVMbugs] [Bug 8906] New: Overly aggressive memset optimization. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8906 Summary: Overly aggressive memset optimization. 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: rich at pennware.com CC: llvmbugs at cs.uiuc.edu I updated to 122785 and compiled the my modified NetBSD standard library. Unfortunately the memset() function blew up the stack. Its body was replaced by a call to memset(). Ouch. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 18:13:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 18:13:56 -0600 (CST) Subject: [LLVMbugs] [Bug 7851] clang++ can't compile CryptoPP 5.6.0 In-Reply-To: References: Message-ID: <20110105001356.2ABEE2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7851 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #10 from Douglas Gregor 2011-01-04 18:13:55 CST --- Fixed in Clang r122853. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 19:03:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 19:03:54 -0600 (CST) Subject: [LLVMbugs] [Bug 8906] Overly aggressive memset optimization. In-Reply-To: References: Message-ID: <20110105010354.B56C72A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8906 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2011-01-04 19:03:54 CST --- Fixed in r122854. If you don't want the compiler to form a memset, please build with -fno-builtin. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 4 22:43:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 4 Jan 2011 22:43:36 -0600 (CST) Subject: [LLVMbugs] [Bug 8907] New: [meta] build firefox 4 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8907 Summary: [meta] build firefox 4 Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Currently clang cannot build firefox 4 because of issues in Firefox's code that are tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=574346 and because of clang issues that are tracked by 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 Wed Jan 5 00:39:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 00:39:38 -0600 (CST) Subject: [LLVMbugs] [Bug 8908] New: call ModRefInfo not sensitive to ordering Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8908 Summary: call ModRefInfo not sensitive to ordering Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5960) --> (http://llvm.org/bugs/attachment.cgi?id=5960) .ll testcase (run opt -basicaa -gvn) This is a breakout bug from bug 8886 comment 2. The problem is that we have in pseudo: %x = alloca store @CONSTANT, %x call @external1() %DEAD = load %x call @external2(%x) and the load isn't being eliminated by GVN. MemDep does its backwards scan but when it asks BasicAA about the call to external1, BasicAA looks at the alloca's address leaking into external2 and bails returning ModRef. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 08:00:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 08:00:28 -0600 (CST) Subject: [LLVMbugs] [Bug 8911] New: VMLA/VMLS codegen error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8911 Summary: VMLA/VMLS codegen error Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: rengolin at gmail.com CC: llvmbugs at cs.uiuc.edu When faced with the following code: #define __ARM_NEON__ #include float32x2_t f32d; void vmul() { f32d = vmla_f32(f32d, f32d, f32d); } Clang produces the IR sequence: %tmp.i = load <2 x float>* %__a.addr.i, align 8 %tmp1.i = load <2 x float>* %__b.addr.i, align 8 %tmp2.i = load <2 x float>* %__c.addr.i, align 8 %mul.i = fmul <2 x float> %tmp1.i, %tmp2.i %add.i = fadd <2 x float> %tmp.i, %mul.i Which used to be translated into: vmla.f32 d0, d1, d2 A while ago, this was expanded wrongly to a pair of vmul+vadd but in the latest trunk I'm getting the assert: clang: /work/llvm/src/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:810: llvm::SDValue::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `(isTypeLegal(Node->getOperand(i).getValueType()) || Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexpected illegal type!"' failed. With Last error in the stack: 4. Running pass 'ARM Instruction Selection' on function '@vmul' I believe there are two bugs here, fixing the codegen assert will clear to expose the real error, not matching mul+add to vmla. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 09:14:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 09:14:39 -0600 (CST) Subject: [LLVMbugs] [Bug 8912] New: Non-type template argument parse error (with a functional cast expression). Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8912 Summary: Non-type template argument parse error (with a functional cast expression). Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: zaffanella at cs.unipr.it CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Parsing the following program template struct S {}; S 1)> s; produces the following error: bug.cc:2:10: error: expected ')' S 1)> s; ^ bug.cc:2:7: note: to match this '(' S 1)> s; ^ NOTE: no error is obtained if the functional cast is changed into a C-style cast. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 09:45:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 09:45:30 -0600 (CST) Subject: [LLVMbugs] [Bug 8913] New: clang++ asserts when compiling vmac.cpp from CryptoPP 5.6.1 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8913 Summary: clang++ asserts when compiling vmac.cpp from CryptoPP 5.6.1 Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mclow at qualcomm.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5961) --> (http://llvm.org/bugs/attachment.cgi?id=5961) Preprocessed source code After Doug fixed bug #7851, I decided to make sure that CryptoPP would, in fact, build. Clang threw several errors about "dependent base classes", so I fixed those in the CryptoPP sources. However, there was one file that it didn't handle. This was done with clang/llvm built from revision 122872 attached file was created via: clang++ -DNDEBUG -g -O2 -DCRYPTOPP_DISABLE_ASM -pipe -E vmac.cpp > vmac.i ----- clang++ -DNDEBUG -g -O2 -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -c vmac.cpp In file included from vmac.cpp:5: In file included from ./vmac.h:4: In file included from ./iterhash.h:5: In file included from ./secblock.h:7: ./misc.h:414:8: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (a < 0) ~ ^ ~ In file included from vmac.cpp:5: In file included from ./vmac.h:4: In file included from ./iterhash.h:7: ./simple.h:35:110: note: in instantiation of function template specialization 'CryptoPP::IntToString' requested here ...length) : InvalidArgument(algorithm + ": " + IntToString(length) + " is not a ... ^ In file included from vmac.cpp:5: In file included from ./vmac.h:4: In file included from ./iterhash.h:5: In file included from ./secblock.h:7: ./misc.h:414:8: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (a < 0) ~ ^ ~ In file included from vmac.cpp:5: In file included from ./vmac.h:4: In file included from ./iterhash.h:7: ./simple.h:42:113: note: in instantiation of function template specialization 'CryptoPP::IntToString' requested here ...rounds) : InvalidArgument(algorithm + ": " + IntToString(rounds) + " is not a ... ^ Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for int64_t"), function getSExtValue, file /Volumes/Bay2/LLVM/llvm/include/llvm/ADT/APInt.h, line 1158. 0 clang 0x00000001012bd3ae PrintStackTrace(void*) + 38 1 clang 0x00000001012bd969 SignalHandler(int) + 254 2 libSystem.B.dylib 0x00007fff8630467a _sigtramp + 26 3 clang 0x000000010107cd29 llvm::isa_impl_wrap::doit(llvm::Value const&) + 21 4 clang 0x000000010001fc09 raise + 27 5 clang 0x000000010001fc19 abort + 14 6 clang 0x000000010001fca6 __gnu_cxx::new_allocator >::new_allocator() + 0 7 clang 0x00000001009a0094 llvm::APInt::getSExtValue() const + 148 8 clang 0x0000000100a4695d llvm::ConstantInt::getSExtValue() const + 25 9 clang 0x0000000100d9688e llvm::DwarfDebug::constructGlobalVariableDIE(llvm::MDNode const*) + 1706 10 clang 0x0000000100d97447 llvm::DwarfDebug::beginModule(llvm::Module*) + 423 11 clang 0x0000000100d9bb3a llvm::DwarfDebug::DwarfDebug(llvm::AsmPrinter*, llvm::Module*) + 1048 12 clang 0x0000000100d8277b llvm::AsmPrinter::doInitialization(llvm::Module&) + 853 13 clang 0x00000001011ebeab llvm::FPPassManager::doInitialization(llvm::Module&) + 65 14 clang 0x00000001011efb5b llvm::FPPassManager::runOnModule(llvm::Module&) + 29 15 clang 0x00000001011ef68c llvm::MPPassManager::runOnModule(llvm::Module&) + 384 16 clang 0x00000001011f0e3d llvm::PassManagerImpl::run(llvm::Module&) + 111 17 clang 0x00000001011f0e9f llvm::PassManager::run(llvm::Module&) + 33 18 clang 0x000000010017deea (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, llvm::raw_ostream*) + 748 19 clang 0x000000010017df9e clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 115 20 clang 0x0000000100261526 (anonymous namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 436 21 clang 0x000000010029f969 clang::ParseAST(clang::Sema&, bool) + 534 22 clang 0x000000010008a1c7 clang::ASTFrontendAction::ExecuteAction() + 233 23 clang 0x0000000100261b98 clang::CodeGenAction::ExecuteAction() + 794 24 clang 0x000000010008a2ce clang::FrontendAction::Execute() + 256 25 clang 0x000000010006b4f8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 710 26 clang 0x000000010002d2ad clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 725 27 clang 0x0000000100021e98 cc1_main(char const**, char const**, char const*, void*) + 941 28 clang 0x0000000100029c3b main + 450 29 clang 0x00000001000215d8 start + 52 30 clang 0x0000000000000028 start + 4294830724 Stack dump: 0. Program arguments: /Volumes/Bay2/LLVM/llvm-build/Debug+Asserts/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name vmac.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17 -g -resource-dir /Volumes/Bay2/LLVM/llvm-build/Debug+Asserts/bin/../lib/clang/2.9 -D NDEBUG -D CRYPTOPP_DISABLE_ASM -O2 -ferror-limit 19 -fmessage-length 87 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/E-/E-Uv6JW8Hni-PjXnXWJGbU+++TI/-Tmp-/cc-TfbSZn.o -x c++ vmac.cpp 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'vmac.cpp'. clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) make: *** [vmac.o] Error 255 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 09:57:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 09:57:44 -0600 (CST) Subject: [LLVMbugs] [Bug 8914] New: __dead2 not respected Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8914 Summary: __dead2 not respected Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: erik at cederstrand.dk CC: llvmbugs at cs.uiuc.edu FreeBSD run the analyzer regularly on our source code. The scan reports contain many false positives caused by the analyzer not knowing that a call to e.g. errx() or exit() doesn't return. Instead it proceeds to find e.g. a bogus null dereference. Examples: http://scan.freebsd.your.org/freebsd-head/usr.sbin.jail/2011-01-05-amd64/report-W2zjAu.html#EndPath: Step 12 (line 192) calls usage() (line 552) which in turn calls exit() http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath: Step 6 (line 167) calls cmdhelp() (line 285) which in turn calls exit() Many such functions in FreeBSD are marked with "__dead2" to indicate that the function never returns (e.g. exit() in http://svn.freebsd.org/viewvc/base/head/include/stdlib.h?revision=206997&view=markup and errx() in http://svn.freebsd.org/viewvc/base/head/include/err.h?revision=203964&view=markup). If the analyzer was able to find and honour this flag we would be able to ignore a huge number of false positive reports, increasing the value of the reports. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 10:41:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 10:41:29 -0600 (CST) Subject: [LLVMbugs] [Bug 5314] [Linux Kernel] Inline asm asmprinter crash with P modifier In-Reply-To: References: Message-ID: <20110105164129.A53EB2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5314 Rob changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |rob1weld at aol.com Resolution|FIXED | --- Comment #5 from Rob 2011-01-05 10:41:28 CST --- (In reply to comment #4) > Crash fixed in 108545. Generated code made correct in 108548 (I think). I downloaded the Attachment and I can reproduce this BR, I 'REOPENED' Tiago's BR to avoid a Dupe: # uname -a Linux debian 2.6.33.7 #1 SMP PREEMPT Tue Jan 4 19:10:07 PST 2011 i686 GNU/Linux # cd /usr/local/linux-2.6.33.7 # make-kpkg clean # MAKEFLAGS="CC=llvm-gcc-4.2" make-kpkg --initrd kernel_image ... HOSTCC scripts/kallsyms HOSTCC scripts/pnmtologo HOSTCC scripts/conmakehash HOSTCC scripts/bin2c CC init/main.o UNREACHABLE executed! init/main.c:897: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[2]: *** [init/main.o] Error 1 make[1]: *** [init] Error 2 make[1]: Leaving directory `/usr/local/linux-2.6.33.7' make: *** [debian/stamp/build/kernel] Error 2 root at debian:/usr/local/linux-2.6.33.7# (Note: Line init/main.c:897 is EOF - nothing to see but "}") # llc-2.7 -version Low Level Virtual Machine (http://llvm.org/): llvm version 2.7 (Debian 2.7-6) Optimized build. Built Sep 23 2010 (21:14:53). Host: i386-pc-linux-gnu Host CPU: athlon64 ... # llc-2.7 t.bc -o - .file "t.bc" .text .globl init_post .type init_post, at function init_post: # @init_post # BB#0: # %entry subl $4, %esp xorb %al, %al testb %al, %al movl $per_cpu__current_task, %eax #APP movl %fs:UNREACHABLE executed! 0 libLLVM-2.7.so.1 0xb7554c08 Stack dump: 0. Program arguments: llc-2.7 t.bc -o - 1. Running pass 'X86 AT&T-Style Assembly Printer' on function '@init_post' Aborted I will try and grab LLVM's Trunk and see if _another_ BR (and associated fix) has resolved this. Thanks, Rob -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 10:46:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 10:46:05 -0600 (CST) Subject: [LLVMbugs] [Bug 5314] [Linux Kernel] Inline asm asmprinter crash with P modifier In-Reply-To: References: Message-ID: <20110105164605.BFB522A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5314 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #6 from Anton Korobeynikov 2011-01-05 10:46:04 CST --- (In reply to comment #5) > I will try and grab LLVM's Trunk and see if _another_ BR (and associated fix) > has resolved this. Please reopen only in case if the problem can be reproduced with LLVM top of the tree. LLVM 2.7 is pretty ancient right now. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 11:26:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 11:26:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8915] New: Assertion failure when instantiating member class of class template. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8915 Summary: Assertion failure when instantiating member class of class template. Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: zaffanella at cs.unipr.it CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following test (from the g++ test suite) causes a clang assertion to trigger. template struct A { struct B { struct C {}; }; }; template void foo() { class A::B::C X; } void bar() { foo<0>(); } clang: include/clang/AST/DeclTemplate.h:1283: void clang::ClassTemplateSpecializationDecl::setPointOfInstantiation(clang::SourceLocation): Assertion `Loc.isValid() && "point of instantiation must be valid!"' 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 Wed Jan 5 11:38:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 11:38:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8911] VMLA/VMLS codegen error In-Reply-To: References: Message-ID: <20110105173845.AA9D02A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8911 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #5 from Bob Wilson 2011-01-05 11:38:45 CST --- This works fine for me -- no assertion. We're not producing a VMLA instruction, but as Anton already pointed out, that is intentional. Renato, please reopen if you have a reproducible testcase. The IR excerpt you copied into the PR is not usable and does not match the C source you provided. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 11:59:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 11:59:30 -0600 (CST) Subject: [LLVMbugs] [Bug 8916] New: clang tot takes a long, long time (maybe forever) to compile Cryptopp's sha.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8916 Summary: clang tot takes a long, long time (maybe forever) to compile Cryptopp's sha.cpp Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mclow at qualcomm.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5962) --> (http://llvm.org/bugs/attachment.cgi?id=5962) Preprocessed source code for sha.cpp When trying to compile CryptoPP , there was a file that appeared to hang the compiler. I don't know for sure, but I got impatient and killed it after 30 minutes. This was done with clang/llvm built from revision 122872 attached file was created via: clang++ -Wno-tautological-compare -DNDEBUG -g -DCRYPTOPP_DISABLE_ASM -E sha.cpp > sha.i Here are some timings: $ time clang++ -Wno-tautological-compare -DNDEBUG -g -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -fsyntax-only sha.cpp real 6.234s $ time clang++ -Wno-tautological-compare -DNDEBUG -g -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -c sha.cpp real 7.863s $ time clang++ -Wno-tautological-compare -DNDEBUG -g -O1 -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -c sha.cpp real 17.882s $ time clang++ -Wno-tautological-compare -DNDEBUG -g -O2 -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -c sha.cpp .... long, long time; I killed it after 30 minutes. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 12:03:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 12:03:23 -0600 (CST) Subject: [LLVMbugs] [Bug 8917] New: clang much slower than gcc compiling CryptoPP sources Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8917 Summary: clang much slower than gcc compiling CryptoPP sources Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mclow at qualcomm.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5965) --> (http://llvm.org/bugs/attachment.cgi?id=5965) preprocessed source code for sha.cpp When trying to compile CryptoPP , I noticed that the compile times were much, much slower than gcc. Some of this is the optimizer, but there's something going on in the front end, too. This was done with clang/llvm built from revision 122872 attached file was created via: clang++ -Wno-tautological-compare -DNDEBUG -g -DCRYPTOPP_DISABLE_ASM -E sha.cpp > sha.i Compare: $ time clang++ -Wno-tautological-compare -DNDEBUG -g -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -fsyntax-only sha.cpp real 6.234s $ time clang++ -Wno-tautological-compare -DNDEBUG -g -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -c sha.cpp real 7.863s with: $ time g++ -DNDEBUG -g -O2 -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -c sha.cpp real 1.662s -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 12:20:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 12:20:36 -0600 (CST) Subject: [LLVMbugs] [Bug 8911] VMLA/VMLS codegen error In-Reply-To: References: Message-ID: <20110105182036.2CF7D2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8911 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | --- Comment #9 from Bob Wilson 2011-01-05 12:20:35 CST --- OK, I can reproduce it now. It's quite a bit different with EABI. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 12:36:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 12:36:28 -0600 (CST) Subject: [LLVMbugs] [Bug 8917] clang much slower than gcc compiling CryptoPP sources In-Reply-To: References: Message-ID: <20110105183628.F21CE2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8917 Marshall Clow (work) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Marshall Clow (work) 2011-01-05 12:36:28 CST --- More timings; this one with a non-debug build. Looks like pilot error to me. $ time clang++ -Wno-tautological-compare -DNDEBUG -g -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -c sha.cpp real 0m0.764s $ time clang++ -Wno-tautological-compare -DNDEBUG -g -arch x86_64 -arch i386 -DCRYPTOPP_DISABLE_ASM -pipe -fsyntax-only sha.cpp real 0m0.581s -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 5 14:59:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 14:59:52 -0600 (CST) Subject: [LLVMbugs] [Bug 8911] VMLA/VMLS codegen error In-Reply-To: References: Message-ID: <20110105205952.1D2862A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8911 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME --- Comment #10 from Bob Wilson 2011-01-05 14:59:51 CST --- Clang doesn't know what to do with the "armv7-none-eabi" triple that you have specified. It's warning about that: clang: warning: unknown platform, assuming -mfloat-abi=soft The "soft" ABI means that hardware floating-point instructions cannot be used. Apparently no one has implemented that for vector operations. If you specify -mfloat-abi=softfp, you'll get what you want. If you want that triple to be recognized, you'll need to update the Clang::AddARMTargetArgs() function in lib/Driver/Tools.cpp. I'm going to close this again, since I don't think we need to keep a bug report open to track that. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 15:00:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 15:00:11 -0600 (CST) Subject: [LLVMbugs] [Bug 8909] explicit move in move_iterator::operator* In-Reply-To: References: Message-ID: <20110105210011.5D50C2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8909 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |llvmbugs at cs.uiuc.edu -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 15:00:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 15:00:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8910] _LIBCPP_HAS_NO_ALWAYS_INLINE_VARIADICS and g++-4.6 In-Reply-To: References: Message-ID: <20110105210045.5ADD32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8910 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |llvmbugs at cs.uiuc.edu -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 16:29:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 16:29:06 -0600 (CST) Subject: [LLVMbugs] [Bug 8900] Shufflevector of doubles generates incorrect code (using float shuff) In-Reply-To: References: Message-ID: <20110105222906.A58232A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8900 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-01-05 16:29:06 CST --- Wow, that is really scary. Your patch looks great, applied in r122921. Thanks a lot! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 18:00:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 18:00:52 -0600 (CST) Subject: [LLVMbugs] [Bug 8918] New: LLVM generates incorrect __main call with MinGW64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8918 Summary: LLVM generates incorrect __main call with MinGW64 Product: libraries Version: trunk Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: sreeram at tachyontech.net CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5966) --> (http://llvm.org/bugs/attachment.cgi?id=5966) Patch for fixing the above issue. When used with MinGW64, LLVM generates a "calll __main" at the beginning of the "main" function. The assembler complains about the invalid suffix for the 'call' instruction. The right instruction is "callq __main". I've attached a patch that fixes it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 18:05:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 18:05:48 -0600 (CST) Subject: [LLVMbugs] [Bug 8919] New: LLVM generated code crashes if stack frame > 4k on MinGW64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8919 Summary: LLVM generated code crashes if stack frame > 4k on MinGW64 Product: libraries Version: trunk Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: sreeram at tachyontech.net CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5967) --> (http://llvm.org/bugs/attachment.cgi?id=5967) Patch for fixing the above issue. LLVM incorrectly generates "_alloca" as the stack probing call. That works only on MinGW32. On 64-bit, the function to call is "__chkstk". I've attached a patch to fix it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 18:47:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 18:47:28 -0600 (CST) Subject: [LLVMbugs] [Bug 8918] LLVM generates incorrect __main call with MinGW64 In-Reply-To: References: Message-ID: <20110106004728.AE5F22A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8918 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |wendling at apple.com Resolution| |FIXED --- Comment #1 from Bill Wendling 2011-01-05 18:47:28 CST --- Fixed r122933. Thanks for the patch! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 5 18:50:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 5 Jan 2011 18:50:50 -0600 (CST) Subject: [LLVMbugs] [Bug 8919] LLVM generated code crashes if stack frame > 4k on MinGW64 In-Reply-To: References: Message-ID: <20110106005050.C751F2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8919 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |wendling at apple.com Resolution| |FIXED --- Comment #1 from Bill Wendling 2011-01-05 18:50:50 CST --- Applied r122934. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 6 00:20:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 00:20:39 -0600 (CST) Subject: [LLVMbugs] [Bug 8883] constant folding doesn't simplify constantexpr gep to constantint In-Reply-To: References: Message-ID: <20110106062039.F2BFF2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8883 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Summary|instcombine doesn't |constant folding doesn't |simplify constantexpr |simplify constantexpr gep |operands |to constantint --- Comment #5 from Chris Lattner 2011-01-06 00:20:39 CST --- Inliner is doing the right thing, constantfolding.cpp just didn't know how to handle this case. Simple enough, implemented in r122950. Thanks for tracking down what the root issue is Dan! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 04:26:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 04:26:28 -0600 (CST) Subject: [LLVMbugs] [Bug 8920] New: clang-analyzer can't deal with FD_SET and FD_ZERO Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8920 Summary: clang-analyzer can't deal with FD_SET and FD_ZERO Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: asn at cryptomilk.org CC: llvmbugs at cs.uiuc.edu clang-analyzer can't really deal with FD_SET and FD_ZERO. I think the problem is cause these macros are assembler code. Code: rc = select(maxfd, &localset, NULL, NULL, timeout); ... FD_ZERO(&localset2); for (f = 0; f < maxfd; f++) { if (FD_ISSET(f, readfds) && FD_ISSET(f, &localset)) { FD_SET(f, &localset2); } } http://test.libssh.org/clang-analyzer/ Result: Within the expansion of the macro 'FD_SET': The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage. Test code: If you're looking for some test code see the EXAMPLE section in the select(2) manpage. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 04:39:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 04:39:39 -0600 (CST) Subject: [LLVMbugs] [Bug 8919] LLVM generated code crashes if stack frame > 4k on MinGW64 In-Reply-To: References: Message-ID: <20110106103939.49F492A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8919 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |geek4civic at gmail.com Resolution|FIXED | OS/Version|other |Windows XP --- Comment #3 from NAKAMURA Takumi 2011-01-06 04:39:38 CST --- I have to reopen this. Sreeram's patch would be effective only on TDM. I think it would not be needed to revert r122934. Prior implementation (_alloca by %eax) was bogus, too. in http://tdm-gcc.tdragon.net/development > TDM64 edition only: Includes a patch to remove a leading underscore from the 64-bit cygwin.asm symbols "__chkstk" and "_alloca", allowing them to be exported with the same rule as the 32-bit versions after underscoring rules are applied. The symbol "__chkstk" is unique to tdm. gcc's cygwin.asm and mingw-w64-gcc (and I) assume "___chkstk". ps. see also bug 8777 ;) Anton, > Also, I believe mingw-w64 provided *both* __alloca and > __chkstk. We may prefer ___chkstk on win64 rather than __alloca. ___chkstk does not modify %rcx %rdx %r8 and %r9. (__alloca does not) Or shall we implement our chkstk? :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 Thu Jan 6 09:22:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 09:22:09 -0600 (CST) Subject: [LLVMbugs] [Bug 8921] New: ARM/Thumb interoperability broken in v4T Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8921 Summary: ARM/Thumb interoperability broken in v4T Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: rengolin at gmail.com CC: llvmbugs at cs.uiuc.edu The following code generates wrong assembly when compiled to ARM: extern int c(); int b() { return c()+1; } int a() { return b(); } EABI requires ARM/Thumb interoperability by default (unless you know *exactly* what you're doing, which is not the case). LLVM back-end (either through clang or clang+llc) is generating b() as: b: push {r11, lr} mov r11, sp bl c add r0, r0, #1 ldmia sp!, {r11, pc} which doesn't take into account the instruction set change. The correct way to return is "bx lr" as a default case. We're having problems when linking against 7TDMI libraries, since it has both ARM and Thumb functions. The command lines: $ clang -ccc-host-triple armv4t-none-eabi -mfloat-abi=softfp -S test.c or $ clang -ccc-host-triple armv4t-none-eabi -mfloat-abi=softfp -emit-llvm -S test.c -o test.ll $ llc -march=arm test.ll -o - Attaching source, IR and assembly generated with trunk clang+llc. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 09:43:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 09:43:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8922] New: Win64 Does not codegen correctly alloca align 64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8922 Summary: Win64 Does not codegen correctly alloca align 64 Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: zvi.rackover at intel.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5971) --> (http://llvm.org/bugs/attachment.cgi?id=5971) Reproducer test The following test case produces the assertion below when running on the Win64 subtarget: define noalias i32* @factorial() nounwind readnone { entry: %a = alloca i32, align 64 ret i32* %a } Assertion failed: (-(Offset + StackSize)) % Align == 0, file ..\..\..\..\lib\Target\X86\X86FrameInfo.cpp, line 867 Explanation: Win64 CodeGen adds an extra 32 bytes to frame size, to be used as a Red Zone for potential calls. This addition ruins the stack alignment in case the required alignment is greater than 32 bytes. Proposed fix is to add max(32, MaxAlignment) bytes instead. Attached are the testcase and patch. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 6 10:57:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 10:57:46 -0600 (CST) Subject: [LLVMbugs] [Bug 8485] error: unknown target CPU 'cortex-m3' In-Reply-To: References: Message-ID: <20110106165746.828E52A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8485 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Bob Wilson 2011-01-06 10:57:46 CST --- Thanks for the reminder. I applied the patch as svn r122965. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 13:26:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 13:26:54 -0600 (CST) Subject: [LLVMbugs] [Bug 8921] ARM/Thumb interoperability broken in v4T In-Reply-To: References: Message-ID: <20110106192655.00E552A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8921 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Bob Wilson 2011-01-06 13:26:54 CST --- Fixed in svn 122970 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 13:49:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 13:49:22 -0600 (CST) Subject: [LLVMbugs] [Bug 8582] [legalize crash] Assertion `N.getNode()->getNodeId() != NewNode && "Mapped to new node!"' failed. In-Reply-To: References: Message-ID: <20110106194922.5D1F52A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8582 John Regehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from John Regehr 2011-01-06 13:49:21 CST --- A couple hundred 1000 testcases failed to turn up anything triggering this on x86 or x64, so let's call it good for now. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 6 15:40:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 15:40:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8913] clang++ asserts when compiling vmac.cpp from CryptoPP 5.6.1 In-Reply-To: References: Message-ID: <20110106214045.744FE2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8913 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Devang Patel 2011-01-06 15:40:44 CST --- Fixed in r122971 and r122972. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 17:45:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 17:45:29 -0600 (CST) Subject: [LLVMbugs] [Bug 8629] clang++ fails an assertion In-Reply-To: References: Message-ID: <20110106234529.192C42A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8629 Elias Pipping changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #5 from Elias Pipping 2011-01-06 17:45:27 CST --- This still fails for me. bogus% clang++ --version clang version 2.9 (trunk 122981) Target: x86_64-pc-linux-gnu Thread model: posix bogus% bogus% clang++ -c dgfparserblocks.ii dgfparserblocks.ii:25:14: warning: 'template' keyword outside of a template [-Wc++0x-extensions] simplex_.template initialize<0>(); ^~~~~~~~ dgfparserblocks.ii:9:24: warning: template argument uses local type 'GenericReferenceElement::type' [-Wlocal-type-template-args] typedef Initialize Init; ^~~~~~~~ dgfparserblocks.ii:15:5: note: in instantiation of function template specialization 'GenericReferenceElement::initializeTopology::type>' requested here initializeTopology(); ^ dgfparserblocks.ii:25:5: note: in instantiation of function template specialization 'GenericReferenceElement::initialize<0>' requested here simplex_.template initialize<0>(); ^ clang: /var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/lib/Sema/../../include/clang/AST/DeclTemplate.h:1287: void clang::ClassTemplateSpecializationDecl::setPointOfInstantiation(clang::SourceLocation): Assertion `Loc.isValid() && "point of instantiation must be valid!"' failed. 0 libLLVM-2.9svn.so 0x00007f44f88d2dcf 1 libLLVM-2.9svn.so 0x00007f44f88d3b61 2 libpthread.so.0 0x00007f44f7e19fe0 3 libc.so.6 0x00007f44f71376a5 gsignal + 53 4 libc.so.6 0x00007f44f71389a5 abort + 389 5 libc.so.6 0x00007f44f7130235 __assert_fail + 245 6 clang 0x0000000000969a52 clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) + 1666 7 clang 0x000000000096a4cb clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) + 1147 8 clang 0x000000000099a4a9 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&, std::pair) + 1081 9 clang 0x000000000099ae94 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::PartialDiagnostic const&) + 84 10 clang 0x00000000007bd46a clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&, clang::DeclContext*) + 378 11 clang 0x000000000092c080 clang::Sema::LookupTemplateName(clang::LookupResult&, clang::Scope*, clang::CXXScopeSpec&, clang::QualType, bool, bool&) + 2032 12 clang 0x000000000092cace clang::Sema::isTemplateName(clang::Scope*, clang::CXXScopeSpec&, bool, clang::UnqualifiedId&, clang::OpaquePtr, bool, clang::OpaquePtr&, bool&) + 366 13 clang 0x000000000092ce2e clang::Sema::ActOnDependentTemplateName(clang::Scope*, clang::SourceLocation, clang::CXXScopeSpec&, clang::UnqualifiedId&, clang::OpaquePtr, bool, clang::OpaquePtr&) + 206 14 clang 0x000000000095a7e6 15 clang 0x000000000096d54b 16 clang 0x0000000000961e2b 17 clang 0x0000000000964bd0 18 clang 0x000000000096c770 19 clang 0x000000000096ca7e 20 clang 0x0000000000974d78 21 clang 0x00000000009602e5 22 clang 0x00000000009766b0 23 clang 0x0000000000976863 24 clang 0x000000000095fa85 25 clang 0x0000000000971f45 26 clang 0x0000000000972ca4 27 clang 0x000000000097209d 28 clang 0x000000000097354d clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) + 45 29 clang 0x00000000009866f6 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 790 30 clang 0x0000000000986c4d clang::Sema::PerformPendingInstantiations(bool) + 365 31 clang 0x000000000098699f clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 1471 32 clang 0x0000000000986c4d clang::Sema::PerformPendingInstantiations(bool) + 365 33 clang 0x00000000007aa8f2 clang::Sema::ActOnEndOfTranslationUnit() + 242 34 clang 0x0000000000771409 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 201 35 clang 0x0000000000758a23 clang::ParseAST(clang::Sema&, bool) + 147 36 clang 0x00000000006305b4 clang::CodeGenAction::ExecuteAction() + 68 37 clang 0x000000000052e863 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 355 38 clang 0x000000000050c9ac clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 39 clang 0x0000000000504f40 cc1_main(char const**, char const**, char const*, void*) + 672 40 clang 0x000000000050b9aa main + 4458 41 libc.so.6 0x00007f44f7123c7d __libc_start_main + 253 42 clang 0x0000000000503699 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name dgfparserblocks.ii -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.51.0.2.20101206 -resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 118 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o dgfparserblocks.o -x c++-cpp-output dgfparserblocks.ii 1. parser at end of file 2. dgfparserblocks.ii:12:24: instantiating function definition 'initialize' 3. dgfparserblocks.ii:7:33: instantiating function definition 'initializeTopology' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) bogus% -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 6 17:54:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 17:54:57 -0600 (CST) Subject: [LLVMbugs] [Bug 8923] New: DAGTypeLegalizer::PerformExpensiveChecks(): Assertion `NewVal.getNode()->getNodeId() != NewNode && "ReplacedValues maps to a new node!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8923 Summary: DAGTypeLegalizer::PerformExpensiveChecks(): Assertion `NewVal.getNode()->getNodeId() != NewNode && "ReplacedValues maps to a new node!"' failed. Product: libraries Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu llc: lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:106: void llvm::DAGTypeLegalizer::PerformExpensiveChecks(): Assertion `NewVal.getNode()->getNodeId() != NewNode && "ReplacedValues maps to a new node!"' failed. We hit an assert for the code below (both Linux and Windows): target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64 f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32 n8:16:32" target triple = "i686-pc-win32" define void @test() nounwind { %i17 = icmp eq <4 x i8> undef, zeroinitializer %cond = extractelement <4 x i1> %i17, i32 0 %_comp = select i1 %cond, i8 0, i8 undef %merge = insertelement <4 x i8> undef, i8 %_comp, i32 0 %cond3 = extractelement <4 x i1> %i17, i32 1 %_comp4 = select i1 %cond3, i8 0, i8 undef %merge5 = insertelement <4 x i8> %merge, i8 %_comp4, i32 1 %cond8 = extractelement <4 x i1> %i17, i32 2 %_comp9 = select i1 %cond8, i8 0, i8 undef %m387 = insertelement <4 x i8> %merge5, i8 %_comp9, i32 2 store <4 x i8> %m387, <4 x i8>* undef ret void } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 6 17:59:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 17:59:49 -0600 (CST) Subject: [LLVMbugs] [Bug 8924] New: /lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:784: llvm::SDValue::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `getTypeAction(Node->getValueType(i)) == Legal && "Unexpected illegal type!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8924 Summary: /lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:784: llvm::SDValue::SelectionDAGLegalize::Legalize Op(llvm::SDValue): Assertion `getTypeAction(Node->getValueType(i)) == Legal && "Unexpected illegal type!"' failed. Product: libraries Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu We hit the assertion above on the code below. Tested on LLVM 2.8 on Windows and Linux. define void @m387() nounwind { %1 = load <4 x i64> addrspace(1)* undef, align 32 %temp.vect37 = shufflevector <4 x i64> undef, <4 x i64> %1, <4 x i32> %2 = mul <4 x i64> zeroinitializer, %temp.vect37 %3 = shufflevector <4 x i64> undef, <4 x i64> %2, <4 x i32> %4 = shufflevector <4 x i64> %3, <4 x i64> undef, <4 x i32> store <4 x i64> %4, <4 x i64> addrspace(1)* undef, align 32 ret void } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 6 18:09:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 18:09:53 -0600 (CST) Subject: [LLVMbugs] [Bug 8923] DAGTypeLegalizer::PerformExpensiveChecks(): Assertion `NewVal.getNode()->getNodeId() != NewNode && "ReplacedValues maps to a new node!"' failed. In-Reply-To: References: Message-ID: <20110107000953.EB9132A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8923 Nadav Rotem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Nadav Rotem 2011-01-06 18:09:53 CST --- This is a duplicate of 8582. Duncan Sands reported that he commited the fix for this issue. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 6 18:10:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 18:10:59 -0600 (CST) Subject: [LLVMbugs] [Bug 8923] DAGTypeLegalizer::PerformExpensiveChecks(): Assertion `NewVal.getNode()->getNodeId() != NewNode && "ReplacedValues maps to a new node!"' failed. In-Reply-To: References: Message-ID: <20110107001100.0D5EC2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8923 Nadav Rotem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #3 from Nadav Rotem 2011-01-06 18:10:59 CST --- My mistake. Duncan Sands fixed another issue. This one is still open. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 18:16:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 18:16:06 -0600 (CST) Subject: [LLVMbugs] [Bug 8923] DAGTypeLegalizer::PerformExpensiveChecks(): Assertion `NewVal.getNode()->getNodeId() != NewNode && "ReplacedValues maps to a new node!"' failed. In-Reply-To: References: Message-ID: <20110107001606.B67622A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8923 Nadav Rotem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #4 from Nadav Rotem 2011-01-06 18:16:06 CST --- Fixed in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110103/114745.html. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 6 20:03:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 20:03:50 -0600 (CST) Subject: [LLVMbugs] [Bug 8925] New: Unnecessary munging of stack pointer with guarantee tail calls Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8925 Summary: Unnecessary munging of stack pointer with guarantee tail calls Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: arplynn at gmail.com CC: llvmbugs at cs.uiuc.edu In the following test case: define fastcc i32* @force.ri32(i32* %x) nounwind { entry: %nz = icmp eq i32* %x, null br i1 %nz, label %Limpl1.pre, label %Limpl0.pre Limpl0.pre: ; preds = %entry ret i32* %x Limpl1.pre: ; preds = %entry tail call fastcc void @pr.error() noreturn nounwind unreachable } declare fastcc void @pr.error() noreturn nounwind LLVM currently generates: _force.ri32: ## @force.ri32 ## BB#0: ## %entry subq $8, %rsp testq %rdi, %rdi je LBB0_2 ## BB#1: ## %Limpl0.pre movq %rdi, %rax addq $8, %rsp ret $8 LBB0_2: ## %Limpl1.pre addq $8, %rsp jmp _pr.error ## TAILCALL The instructions that change %rsp are unnecessary. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 6 23:09:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 6 Jan 2011 23:09:57 -0600 (CST) Subject: [LLVMbugs] [Bug 8411] ARM back end is not very clever with shufflevector In-Reply-To: References: Message-ID: <20110107050957.4CB1D2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8411 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Bob Wilson 2011-01-06 23:09:56 CST --- I committed the Tim Northover's extract_subvector patch which fixes this. svn 122995. I'm also going to change clang's vget_low and vget_high intrinsics to use __builtin_shufflevector. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 7 04:21:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 Jan 2011 04:21:20 -0600 (CST) Subject: [LLVMbugs] [Bug 8924] /lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:784: llvm::SDValue::SelectionDAGLegalize::LegalizeOp(llvm::SDValue): Assertion `getTypeAction(Node->getValueType(i)) == Legal && "Unexpected illegal type!"' failed. In-Reply-To: References: Message-ID: <20110107102120.84B182A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8924 Nadav Rotem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Nadav Rotem 2011-01-07 04:21:19 CST --- I can only reproduce this on LLVM2.8. I guess that it is fixed in the trunk. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 7 06:34:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 Jan 2011 06:34:48 -0600 (CST) Subject: [LLVMbugs] [Bug 8926] New: clang++ assert while compiling c++ source file Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8926 Summary: clang++ assert while compiling c++ source file Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: felix.ritter at mevis.fraunhofer.de CC: llvmbugs at cs.uiuc.edu clang version 2.9 (trunk 122999) Target: x86_64-apple-darwin10 Thread model: posix I've attached the preprocessed source file, that crashes when compiled with the trunk clang++: clang++ -c PythonQtSlot.ii Assertion failed: (!HasCachedLinkage || Linkage(CachedLinkage) == LI.linkage()), function getLinkageAndVisibility, file Decl.cpp, line 587. 0 clang 0x00000001014cb4c2 PrintStackTrace(void*) + 34 1 clang 0x00000001014cc313 SignalHandler(int) + 707 2 libSystem.B.dylib 0x00007fff8596a67a _sigtramp + 26 3 libSystem.B.dylib 0x00007fff5fbf9cf8 _sigtramp + 3660117656 4 clang 0x000000010001a2b2 __assert_rtn + 66 5 clang 0x00000001007d3695 clang::NamedDecl::getLinkageAndVisibility() const + 149 6 clang 0x00000001002adbd7 clang::CodeGen::CodeGenModule::SetFunctionAttributes(clang::CodeGen::GlobalDecl, llvm::Function*, bool) + 87 7 clang 0x00000001002b1272 clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef, llvm::Type const*, clang::CodeGen::GlobalDecl) + 914 8 clang 0x00000001001f508e clang::CodeGen::CodeGenFunction::EmitCXXMemberCallExpr(clang::CXXMemberCallExpr const*, clang::CodeGen::ReturnValueSlot) + 1630 9 clang 0x00000001001dc7b8 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) + 104 10 clang 0x00000001002171ce clang::StmtVisitor<(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 3374 11 clang 0x00000001002181b0 (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) + 272 12 clang 0x0000000100218239 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 121 13 clang 0x00000001001dc4e6 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) + 86 14 clang 0x00000001001dc64c clang::CodeGen::CodeGenFunction::EmitAnyExprToTemp(clang::Expr const*) + 76 15 clang 0x000000010019ed5e clang::CodeGen::CodeGenFunction::EmitCallArg(clang::Expr const*, clang::QualType) + 62 16 clang 0x00000001001ea1f8 void clang::CodeGen::CodeGenFunction::EmitCallArgs(llvm::SmallVector, 16u>&, clang::FunctionProtoType const*, clang::ConstExprIterator, clang::ConstExprIterator) + 440 17 clang 0x00000001001dace0 clang::CodeGen::CodeGenFunction::EmitCall(clang::QualType, llvm::Value*, clang::CodeGen::ReturnValueSlot, clang::ConstExprIterator, clang::ConstExprIterator, clang::Decl const*) + 352 18 clang 0x00000001001dc98a clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) + 570 19 clang 0x000000010021715f clang::StmtVisitor<(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 3263 20 clang 0x00000001002181b0 (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) + 272 21 clang 0x0000000100218239 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 121 22 clang 0x000000010027d08d clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) + 173 23 clang 0x000000010027eb94 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 964 24 clang 0x00000001002816ab clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 283 25 clang 0x0000000100281a42 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 498 26 clang 0x000000010027e800 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48 27 clang 0x00000001002813eb clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&) + 459 28 clang 0x000000010027ec2f clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 1119 29 clang 0x00000001002816ab clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 283 30 clang 0x0000000100281a42 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 498 31 clang 0x000000010027e800 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48 32 clang 0x00000001002813eb clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&) + 459 33 clang 0x000000010027ec2f clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 1119 34 clang 0x0000000100281457 clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&) + 567 35 clang 0x000000010027ec2f clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 1119 36 clang 0x00000001002816ab clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 283 37 clang 0x0000000100281a42 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 498 38 clang 0x000000010027e800 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48 39 clang 0x00000001002a6d2f clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl, llvm::Function*) + 1071 40 clang 0x00000001002b3291 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl) + 753 41 clang 0x00000001002b62eb clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl) + 395 42 clang 0x00000001002b6466 clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 150 43 clang 0x00000001002b70a0 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 912 44 clang 0x00000001002da20c (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 60 45 clang 0x00000001002a0a2b (anonymous namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 155 46 clang 0x00000001002e6206 clang::ParseAST(clang::Sema&, bool) + 182 47 clang 0x00000001002a130c clang::CodeGenAction::ExecuteAction() + 60 48 clang 0x0000000100052c89 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 393 49 clang 0x0000000100024392 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1602 50 clang 0x000000010001c01a cc1_main(char const**, char const**, char const*, void*) + 586 51 clang 0x00000001000233c4 main + 5524 52 clang 0x000000010001a994 start + 52 Stack dump: 0. Program arguments: /Users/ritter/Temp/llvm/Release+Asserts/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -mrelax-all -disable-free -main-file-name PythonQtSlot.ii -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17 -resource-dir /Users/ritter/Temp/llvm/Release+Asserts/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o PythonQtSlot.o -x c++-cpp-output PythonQtSlot.ii 1. src/PythonQtSlot.cpp:249:1: current parser token 'PyObject' 2. src/PythonQtSlot.cpp:197:11: LLVM IR generation of declaration 'PythonQtSlotFunction_Call' 3. src/PythonQtSlot.cpp:197:11: Generating code for declaration 'PythonQtSlotFunction_Call' 4. src/PythonQtSlot.cpp:198:1: LLVM IR generation of compound statement ('{}') 5. src/PythonQtSlot.cpp:210:64: LLVM IR generation of compound statement ('{}') 6. src/PythonQtSlot.cpp:212:35: LLVM IR generation of compound statement ('{}') clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 7 08:25:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 Jan 2011 08:25:20 -0600 (CST) Subject: [LLVMbugs] [Bug 8927] New: Invalid constant merging Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8927 Summary: Invalid constant merging Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu The C standard says that Two pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space. With -O0 and some cleanup passes clang compiles struct foobar { int x; }; static const struct foobar* foo() { static const struct foobar d = { 0 }; return &d; } static const struct foobar* bar() { static const struct foobar d = { 0 }; return &d; } int zed(const struct foobar *a, const struct foobar *b); int main() { zed(foo(), bar()); } to %struct.foobar = type { i32 } @bar.d = internal constant %struct.foobar zeroinitializer, align 4 @foo.d = internal constant %struct.foobar zeroinitializer, align 4 define i32 @main() nounwind ssp { entry: %call2 = tail call i32 @zed(%struct.foobar* @foo.d, %struct.foobar* @bar.d) nounwind ret i32 0 } declare i32 @zed(%struct.foobar*, %struct.foobar*) but constmerge (which is included in -O2) transforms it to %struct.foobar = type { i32 } @bar.d = internal constant %struct.foobar zeroinitializer, align 4 define i32 @main() nounwind ssp { entry: %call2 = tail call i32 @zed(%struct.foobar* @bar.d, %struct.foobar* @bar.d) nounwind ret i32 0 } declare i32 @zed(%struct.foobar*, %struct.foobar*) Since the function zed in unknown, it might compare the pointers and now it will get a different result. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 7 11:45:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 Jan 2011 11:45:56 -0600 (CST) Subject: [LLVMbugs] [Bug 8928] New: Assertion failed: (T && "getTerminator returned null!"), function SuccIterator, file /data/home/rdivacky/llvm/include/llvm/Support/CFG.h, line 105. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8928 Summary: Assertion failed: (T && "getTerminator returned null!"), function SuccIterator, file /data/home/rdivacky/llvm/include/llvm/Support/CFG.h, line 105. Product: libraries Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Global Analyses AssignedTo: unassignedbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu Assertion failed: (T && "getTerminator returned null!"), function SuccIterator, file /data/home/rdivacky/llvm/include/llvm/Support/CFG.h, line 105. Stack dump: 0. Program arguments: opt boot2.bc -adce -basicaa -codegenprepare -constprop -die -domtree -early-cse -globaldce -inline -insert-optimal-edge-profiling -internalize -ipconstprop -jump-threading -lcssa -lda -libcall-aa -licm -live-values -loop-deletion -loop-extract-single -loop-idiom -loop-rotate -loop-unroll -loop-unswitch -loops -loweratomic -mem2reg -mergefunc -no-aa -postdomfrontier -postdomtree -profile-estimator -simplify-libcalls -simplifycfg -strip -strip-debug-declare -strip-nondebug -tailcallelim -tbaa 1. Running pass 'Function Pass Manager' on module 'boot2.bc'. 2. Running pass 'Profiling information estimator' on function '@lookup' and Assertion failed: (T && "getTerminator returned null!"), function SuccIterator, file /data/home/rdivacky/llvm/include/llvm/Support/CFG.h, line 105. Stack dump: 0. Program arguments: opt boot2.bc -adce -always-inline -constprop -correlated-propagation -dce -domfrontier -dse -early-cse -extract-blocks -functionattrs -globalsmodref-aa -gvn -indvars -inline -instnamer -intervals -ipsccp -iv-users -jump-threading -lcssa -live-values -loop-deletion -loop-extract-single -loop-rotate -loop-unroll -lowersetjmp -lowerswitch -mem2reg -mergereturn -module-debuginfo -partial-inliner -partialspecialization -profile-estimator -scalar-evolution -sccp -scev-aa -simplify-libcalls -simplify-libcalls-halfpowr -simplifycfg -sink -strip-dead-debug-info -strip-dead-prototypes -strip-nondebug -tailduplicate -tbaa the boot2.bc 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 Fri Jan 7 11:49:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 Jan 2011 11:49:08 -0600 (CST) Subject: [LLVMbugs] [Bug 8929] New: Assertion failed: (CallSites.empty() && "Dangling pointers found in call sites map"), function RefreshCallGraph, file CallGraphSCCPass.cpp, line 333. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8929 Summary: Assertion failed: (CallSites.empty() && "Dangling pointers found in call sites map"), function RefreshCallGraph, file CallGraphSCCPass.cpp, line 333. Product: libraries Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Interprocedural Analyses AssignedTo: unassignedbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu Assertion failed: (CallSites.empty() && "Dangling pointers found in call sites map"), function RefreshCallGraph, file CallGraphSCCPass.cpp, line 333. Stack dump: 0. Program arguments: opt boot2.bc -always-inline -basicaa -basiccg -break-crit-edges -codegenprepare -deadtypeelim -die -domtree -early-cse -functionattrs -globaldce -globalopt -globalsmodref-aa -indvars -inline -instcombine -instnamer -instsimplify -intervals -iv-users -lazy-value-info -lda -libcall-aa -licm -lint -live-values -loop-deletion -loop-extract -loop-instsimplify -loop-reduce -loop-rotate -loop-unswitch -loops -mem2reg -memcpyopt -mergefunc -mergereturn -no-profile -postdomfrontier -postdomtree -profile-estimator -reg2mem -scalar-evolution -sccp -scev-aa -simplify-libcalls -simplify-libcalls-halfpowr -sink -split-geps -strip-dead-debug-info -strip-debug-declare -tailduplicate -tbaa 1. Running pass 'CallGraph Pass Manager' on module 'boot2.bc'. and Assertion failed: (CallSites.empty() && "Dangling pointers found in call sites map"), function RefreshCallGraph, file CallGraphSCCPass.cpp, line 333. Stack dump: 0. Program arguments: opt boot2.bc -adce -block-placement -break-crit-edges -constprop -die -dse -globalopt -indvars -inline -instcombine -instsimplify -iv-users -jump-threading -lazy-value-info -lda -licm -live-values -loop-deletion -loop-extract -loop-idiom -loop-unroll -loops -loweratomic -lowerinvoke -lowersetjmp -mem2reg -memcpyopt -mergefunc -no-profile -postdomtree -prune-eh -reassociate -reg2mem -scalar-evolution -scalarrepl -sccp -scev-aa -simplify-libcalls -simplify-libcalls-halfpowr -simplifycfg -sink -sretpromotion -strip-dead-debug-info -strip-debug-declare -strip-nondebug -tbaa 1. Running pass 'CallGraph Pass Manager' on module 'boot2.bc'. the test file is the same as in bug 8928 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 7 12:51:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 Jan 2011 12:51:26 -0600 (CST) Subject: [LLVMbugs] [Bug 3099] multiple errors in gcc/config/rs6000/rs6000.c In-Reply-To: References: Message-ID: <20110107185126.78BF62A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3099 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |baldrick at free.fr Resolution| |WONTFIX --- Comment #38 from Chris Lattner 2011-01-07 12:51:23 CST --- There is no reason to fix this anymore. If you're interested in this, please try out dragonegg. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 7 15:55:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 Jan 2011 15:55:04 -0600 (CST) Subject: [LLVMbugs] [Bug 8866] instcombine does not get max if hidden by sext In-Reply-To: References: Message-ID: <20110107215504.3BD752A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8866 Tobias Grosser changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Tobias Grosser 2011-01-07 15:55:03 CST --- (In reply to comment #3) > Patch posted: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110103/114606.html > > Thanks Dan for the hint An improved version of this patch committed: Revision: 123034 URL: http://llvm.org/viewvc/llvm-project?rev=123034&view=rev Log: InstCombine: Match min/max hidden by sext/zext X = sext x; x >s c ? X : C+1 --> X = sext x; X X = sext x; X >s C-1 ? C-1 : X X = zext x; x >u c ? X : C+1 --> X = zext x; X X = zext x; X >u C-1 ? C-1 : X X = sext x; x >u c ? X : C+1 --> X = sext x; X X = sext x; X >u C-1 ? C-1 : X Instead of calculating this with mixed types promote all to the larger type. This enables scalar evolution to analyze this expression. PR8866 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 7 21:30:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 Jan 2011 21:30:01 -0600 (CST) Subject: [LLVMbugs] [Bug 8930] New: std::ios_base is not forward declared by Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8930 Summary: std::ios_base is not forward declared by Product: libc++ Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: eric at boostpro.com CC: llvmbugs at cs.uiuc.edu title says it all -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 7 22:24:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 7 Jan 2011 22:24:07 -0600 (CST) Subject: [LLVMbugs] [Bug 8931] New: Missing FPU type directives in generated gas assembly for ARM ELF target Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8931 Summary: Missing FPU type directives in generated gas assembly for ARM ELF target Product: new-bugs Version: trunk Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: siarhei.siamashka at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5975) --> (http://llvm.org/bugs/attachment.cgi?id=5975) arm-fpu-type-fix.patch This problem in LLVM causes failure to compile anything that uses floating point by clang. The issue be fixed by applying the attached patch to LLVM. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 8 15:10:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 Jan 2011 15:10:23 -0600 (CST) Subject: [LLVMbugs] [Bug 8932] New: "opt -O3" goes into an infinite loop with the attached IR Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8932 Summary: "opt -O3" goes into an infinite loop with the attached IR Product: libraries Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: sreeram at tachyontech.net CC: llvmbugs at cs.uiuc.edu I'm using LLVM r123062 on Mac OS X 64-bit. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 8 16:31:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 Jan 2011 16:31:21 -0600 (CST) Subject: [LLVMbugs] [Bug 8933] New: multilib support not detected on Debian squeeze Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8933 Summary: multilib support not detected on Debian squeeze Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: michael.kostylev at gmail.com CC: llvmbugs at cs.uiuc.edu Since base-files 6.0 the /etc/debian_version file contains "6.0" instead of "squeeze/sid" that leads to the misdetection of the multilib support. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 8 17:01:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 Jan 2011 17:01:02 -0600 (CST) Subject: [LLVMbugs] [Bug 8934] New: GCC ignores conversion function template specializatons if a derived class' conversion function converts to the same type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8934 Summary: GCC ignores conversion function template specializatons if a derived class' conversion function converts to the same type Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Unless I'm missing something, the following is ambiguous: template struct A { }; struct base { template operator A(); }; struct derived : base { template operator A(); }; int main() { derived().operator A(); } However, clang always wants to take the derived class version. The reason for ambiguity is: A is another type than A (prior to deduction. When collecting candidates, 14.5.2/6 says: "A specialization of a conversion function template is not found by name lookup. Instead, any conversion function templates visible in the context of the use are considered. For each such operator, if argument deduction succeeds (14.8.2.3), the resulting specialization is used as if found by name lookup." In the context of the use, both functions templates are visible, so both are sent to argument deduction. Deduction will succeed, so *the specialization is used as if found by name lookup*. Name lookup cannot find declarations that are hidden, so this quite clearly requires the above to be ambiguous, and doesn't allow the base-class version to be "filtered out" later on. Hiding only takes place prior to deduction: template struct A { }; struct base { template operator A(); }; struct derived : base { template operator A(); }; int main() { derived().operator A(); } Now that is not ambiguous anymore, and will call the derived class version, because in the context of the use, the base-class version is hidden (12.3/5 and 3/8). Note that by constructing cases making the base-class version more specialized than the derived class version, we could actually make this a rejects-valid bug: template struct A { }; struct base { template operator A(); }; struct derived : base { private: template operator A(); }; int main() { derived().operator A(); } Comeau accepts this one just fine, while clang/GCC rejects it, thinking the base-version is hidden. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 8 17:29:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 Jan 2011 17:29:07 -0600 (CST) Subject: [LLVMbugs] [Bug 8935] New: [MC x86] does not know xgetbv instruction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8935 Summary: [MC x86] does not know xgetbv instruction Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: kaffeemonster at googlemail.com CC: llvmbugs at cs.uiuc.edu TOT at 123092 int test_cpu_feature_avx_callback(void) { unsigned low, high; asm volatile( "xgetbv\n" : /* %0 */ "=a" (low), /* %1 */ "=d" (high) : /* %2 */ "c" (0) ); if((low & 0x06) != 0x06) return 0; return 1; }; $ clang -c xgetbv.c xgetbv.c:5:3: error: invalid instruction mnemonic 'xgetbv' "xgetbv\n" ^ :1:2: note: instantiated into assembly here xgetbv ^ 1 error generated. Greetings Jan -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 8 17:36:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 Jan 2011 17:36:34 -0600 (CST) Subject: [LLVMbugs] [Bug 8936] New: [MC x86] does not know xcryptecb instruction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8936 Summary: [MC x86] does not know xcryptecb instruction Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: kaffeemonster at googlemail.com CC: llvmbugs at cs.uiuc.edu TOT at 123092 struct aes_encrypt_ctx { unsigned k[(11*16)/4]; } __attribute__((aligned(16))); void aes_ecb_encrypt_padlock(const struct aes_encrypt_ctx *ctx, void *out, const void *in) { static const unsigned control_word[4] __attribute__((aligned(16))) = {138, 0, 0, 0}; unsigned c, S, D; asm( "rep xcryptecb\n\t" : /* %0 */ "=S" (S), /* %1 */ "=D" (D), /* %2 */ "=c" (c), /* %4 */ "=m" (*(char *)out) : /* %4 */ "d" (control_word), /* %5 */ "b" (&ctx->k), /* %6 */ "2" (1), /* %7 */ "0" (in), /* %8 */ "1" (out), /* %9 */ "m" (*(const char *)in) ); } $ clang -c xcryptecb.c xcryptecb.c:13:4: error: invalid instruction mnemonic 'xcryptecb' "rep xcryptecb\n\t" ^ :1:6: note: instantiated into assembly here rep xcryptecb ^ 1 error generated. Greetings Jan -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 8 18:03:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 Jan 2011 18:03:36 -0600 (CST) Subject: [LLVMbugs] [Bug 8937] New: [MC x86] gas knows a default size for stack access? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8937 Summary: [MC x86] gas knows a default size for stack access? 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: kaffeemonster at googlemail.com CC: llvmbugs at cs.uiuc.edu TOT at 123092 int foo(int c) { asm ( "push %0\n\t" "and $3, (%%esp)\n\t" "pop %0\n\t" : "=r" (c) : "0" (c) ); return c; } $ gcc -c clang_and.c gcc or more correct gas eats it $ as --version GNU assembler (GNU Binutils) 2.20.1.20100303 $ clang -c clang_and.c clang_and.c:4:14: error: ambiguous instructions require an explicit suffix (could be 'andb', 'andw', 'andl', or 'andq') "push %0\n\t" ^ :2:2: note: instantiated into assembly here and $3, (%esp) ^ 1 error generated. clang/llvm does not Greetings Jan -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 8 18:54:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 Jan 2011 18:54:22 -0600 (CST) Subject: [LLVMbugs] [Bug 8938] New: wint_t definition clashes with GCC compiled c++ standard library Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8938 Summary: wint_t definition clashes with GCC compiled c++ standard library Product: clang Version: unspecified Platform: Macintosh OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Headers AssignedTo: unassignedclangbugs at nondot.org ReportedBy: admin at thefireflyproject.us CC: llvmbugs at cs.uiuc.edu The definition of wint_t (http://llvm.org/svn/llvm-project/cfe/trunk/lib/Basic/TargetInfo.cpp line 45, `WIntType = SignedInt;') conflicts with the definition of wint_t provided by GCC (GCC defines wint_t as an unsigned int). This (subtly) breaks clang on Linux, unless one uses a non-GCC compiled GNU stdlib (I can't remember when I last tried compiling GNU stdlib with clang, but I didn't have success. libc++ uses a Mac OSX centric build set up and I've only had moderate success getting it to function on Linux). Debian and Ubuntu's clang packages depend on GCC compiled GNU stdlib packages; there is not a clang-compiled GNU stdlib package that I know of. I believe other distros (RPM-based, etc) also distribute clang with GCC-built GNU stdlib. Subsequently, this leads clang to fail to pass Boost C++ regressions for a number of Boost libraries: string_algo, asio, graph, iostreams, math, regex, serialization, spirit, units and uuid. The point of failure is std::wstreambuf; the pbackfail and overflow methods take a parameter of int_type, which is wint_t in the case of the std::wstreambuf typedef. GCC compiles the shared library with wint_t typedef'd to an unsigned int, thus leading to a mismatch in the function signature of pbackfail and overflows declaration (in the headers, compiled by clang) and the definition (in the shared library, compiled by GCC). This definition was introduced on Oct 21st, 2009 - git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk at 84740 91177308-0d34-0410-b5e6-96231b3b80d8. This problem doesn't occur on darwin (our clang-linux tester has been down for awhile, so I thought this was just a problem for me for a period of time). I'm assuming that's because either 0.) Apple ships a modified version of gcc with Xcode that defines wint_t as an int, and Apple's shipped GNU stdlib package is compiled with said modified version of gcc 1.) Apple has been building GNU stdlib with clang since this change was introduced 2.) Apple has been using libc++ since this change was introduced. This is not a problem that I have been able to solve on the Boost end of things with a workaround (I've fixed other stream-related stdlib issues with clang + linux + gnu stdlib + boost by hacking together an implementation of the broken component and having Boost use it if in a clang linux environment, but I'd pretty much have to reimplement the entire stream library for this one). I suspect changing the definition of wint_t in clang for all platforms will break some existing code/interoperability with existing binaries. OTOH, this seems to be a pretty fundamental inconsistency between clang and GCC-4.2 throught GCC-4.4 (at least on Debian and from GNU's VCS trunk, GCC-4.5/libstdc++-4.5 replaces previously working C++03 and C++98 parts of the GNU standard library with C++0x code that only GCC can compile, so I didn't bother checking if GCC-4.5 defines wint_t differently). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 8 19:18:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 Jan 2011 19:18:55 -0600 (CST) Subject: [LLVMbugs] [Bug 8937] [MC x86] gas knows a default size for stack access? In-Reply-To: References: Message-ID: <20110109011855.C78012A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8937 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2011-01-08 19:18:55 CST --- The MC assembler is behaving correctly. There is nothing that specifies the size for the operation, and you'll see that it picks a "default size" even if not referencing ESP. Please add an explicit suffix. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 8 22:41:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 8 Jan 2011 22:41:08 -0600 (CST) Subject: [LLVMbugs] [Bug 8939] New: AST/CMakeLists.txt update Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8939 Summary: AST/CMakeLists.txt update Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu I've got the following message: At revision 123105. Export complete. -- Target triple: i686-pc-linux-gnu -- Native target architecture is X86 -- Threads enabled. -- Building with -fPIC -- Targeting X86 -- Targeting PTX -- Clang version: 2.9 CMake Error at cmake/modules/LLVMProcessSources.cmake:79 (message): Found unknown source file /home/ryuta/devel/llvm/src/llvm/tools/clang/lib/AST/FullExpr.cpp Please update /home/ryuta/devel/llvm/src/llvm/tools/clang/lib/AST/CMakeLists.txt Call Stack (most recent call first): cmake/modules/LLVMProcessSources.cmake:35 (llvm_check_source_file_list) tools/clang/CMakeLists.txt:58 (llvm_process_sources) tools/clang/lib/AST/CMakeLists.txt:5 (add_clang_library) -- Configuring incomplete, errors occurred! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 02:49:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 Jan 2011 02:49:15 -0600 (CST) Subject: [LLVMbugs] [Bug 8940] New: libclang API to access CXCodeCompleteResults and CXCompletionResult structures Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8940 Summary: libclang API to access CXCodeCompleteResults and CXCompletionResult structures Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: lightside at safebox.ru CC: llvmbugs at cs.uiuc.edu There are no API to access CXCodeCompleteResults structure to get CXCompletionResult and unsigned NumResults. The same situation with CXCompletionResult structure (e.g. CXCursorKind CursorKind, CXCompletionString CompletionString). They used inside clang_sortCodeCompletionResults, clang_getCompletionChunkKind, clang_getCompletionChunkText, clang_getCompletionChunkCompletionString, clang_getNumCompletionChunks, etc. functions. Currently, it possible to get them directly only, e.g.: //... CXIndex idx = clang_createIndex(NULL, NULL); CXTranslationUnit tu = clang_createTranslationUnit(idx, ast_filename); CXCodeCompleteResults *rs = clang_codeCompleteAt(tu, complete_filename, complete_line, complete_column, unsaved_files, num_unsaved_files, options); clang_sortCodeCompletionResults(rs->Results, rs->NumResults); for (unsigned i = 0, n = rs->NumResults; i < n; ++i) { CXCompletionResult r = rs->Results[i]; CXCursorKind kind = r.CursorKind; CXCompletionString cs = r.CompletionString; for (unsigned j = 0, m = clang_getNumCompletionChunks(cs); j < m; ++j) { CXString text = clang_getCompletionChunkText(cs, j); printf("%d: %s\n", i, text); clang_disposeString(text); } } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 9 07:15:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 Jan 2011 07:15:28 -0600 (CST) Subject: [LLVMbugs] [Bug 8939] AST/CMakeLists.txt update In-Reply-To: References: Message-ID: <20110109131528.9DBC22A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8939 ?scar Fuentes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |ofv at wanadoo.es Resolution| |INVALID --- Comment #1 from ?scar Fuentes 2011-01-09 07:15:28 CST --- That source file does not exists on the clang sources. I have no idea why you have it on your disk (does `snv status' report it as unknown? Maybe your working copy is on a inconsistent state.) Just delete 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 Sun Jan 9 17:02:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 Jan 2011 17:02:53 -0600 (CST) Subject: [LLVMbugs] [Bug 8882] Need an "isexact" bit for shift left In-Reply-To: References: Message-ID: <20110109230253.080212A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8882 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #4 from Chris Lattner 2011-01-09 17:02:52 CST --- Just duping this to PR8862, we'll track the issue there. *** This bug has been marked as a duplicate of bug 8862 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 17:38:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 Jan 2011 17:38:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8942] New: Not aggressively optimizing std::fill loop Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8942 Summary: Not aggressively optimizing std::fill loop Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu Chandler observed that we don't optimize this function into a memset: void f1(int* begin, int* end) { std::fill(begin, end, 0); } With recent changes, we now compute a backedge taken count for this loop, of "((-4 + (-1 * %__first) + %__last) /u 4)". The problem is that indvars has some (very reasonable in general) code that Dan added at the top of IndVarSimplify::LinearFunctionTestReplace: // Special case: If the backedge-taken count is a UDiv, it's very likely a // UDiv that ScalarEvolution produced in order to compute a precise // expression, rather than a UDiv from the user's code. If we can't find a // UDiv in the code with some simple searching, assume the former and forego // rewriting the loop. if (isa(BackedgeTakenCount)) { If I hack out that code, we form a memset and delete the loop. There are two problems here. First, if I disable the code, I get some pretty gross IR: define void @_Z1fPiS_(i32* %begin, i32* %end) nounwind { entry: %cmp7.i.i = icmp eq i32* %begin, %end br i1 %cmp7.i.i, label %_ZSt4fillIPiiEvT_S1_RKT0_.exit, label %for.body.lr.ph.i.i for.body.lr.ph.i.i: ; preds = %entry %begin2 = bitcast i32* %begin to i8* %__first10.i.i = ptrtoint i32* %begin to i64 %scevgep.i.i = getelementptr i32* %end, i64 -1 %scevgep9.i.i = bitcast i32* %scevgep.i.i to i8* %tmp.i.i = sub i64 0, %__first10.i.i %uglygep.i.i = getelementptr i8* %scevgep9.i.i, i64 %tmp.i.i %uglygep11.i.i = ptrtoint i8* %uglygep.i.i to i64 %tmp12.i.i4 = add i64 %uglygep11.i.i, 4 %tmp3 = and i64 %tmp12.i.i4, -4 call void @llvm.memset.p0i8.i64(i8* %begin2, i8 0, i64 %tmp3, i32 4, i1 false) ret void _ZSt4fillIPiiEvT_S1_RKT0_.exit: ; preds = %entry ret void } 1. The "gep -1", and "add -4" should be merged together. It is unclear if it should be SCEV doing this or instcombine. 2. The "and x, -4" is because we don't have an "isexact" bit on the udiv generated by the trip count. We have no way to represent this in SCEV or IR (PR8862). The second issue is that just hacking out the code isn't the right thing to do. We should use the "isexact" bit on the udiv scev to decide if the end result will be simple enough to make it profitable. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 17:50:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 Jan 2011 17:50:25 -0600 (CST) Subject: [LLVMbugs] [Bug 8943] New: pow is transformed to exp2 in -std=gnu89 mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8943 Summary: pow is transformed to exp2 in -std=gnu89 mode Product: clang Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: amine.khaldi at reactos.org CC: llvmbugs at cs.uiuc.edu I got undefined reference to `exp2' from this line of code: r->f = a->f * pow(2., n.f); exp2 doesn't seem to be in the C89 standard, so this transformation is a bug most likely. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 9 18:56:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 Jan 2011 18:56:31 -0600 (CST) Subject: [LLVMbugs] [Bug 8944] New: Integrated assembler doesn't resolve local symbol differences Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8944 Summary: Integrated assembler doesn't resolve local symbol differences Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Target Description Classes AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu OpenSSL's aes-x86_64.s does something like movq T-S, %rax .globl T T: .globl S S: This results in a R_X86_64_PC32 text relocation, which GNU ld doesn't like. Runnning the same code through GNU as doesn't result in a relocation, e.g. the difference is handled internally. Same for using . in place of S. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 9 19:06:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 Jan 2011 19:06:30 -0600 (CST) Subject: [LLVMbugs] [Bug 8945] New: Support for -cxx-isystem Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8945 Summary: Support for -cxx-isystem 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 GCC has a special option to override the builtin c++ include path in combination with -nostdinc++. The option -cxx-isystem is different from -isystem in so far as that it only applies to C++ compilation. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 9 20:01:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 Jan 2011 20:01:05 -0600 (CST) Subject: [LLVMbugs] [Bug 8946] New: SSE2 : valid reg-to-reg MOVDQU rejected by the x86 backend Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8946 Summary: SSE2 : valid reg-to-reg MOVDQU rejected by the x86 backend Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: jmenon86 at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5977) --> (http://llvm.org/bugs/attachment.cgi?id=5977) test case Attached code is valid and compiles fine with gcc but with clang, I get [jai at outrax tmp]$ ~/llvm-build/Debug+Asserts/bin/clang -msse2 -c sse2_test.c sse2_test.c:3:13: error: invalid operand for instruction __asm__("movdqu %%xmm0, %%xmm1\n" : ); ^ :1:2: note: instantiated into assembly here movdqu %xmm0, %xmm1 ^ 1 error generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 9 23:14:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 9 Jan 2011 23:14:53 -0600 (CST) Subject: [LLVMbugs] [Bug 8947] New: Miscompilation when optimizing OpenSSL Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8947 Summary: Miscompilation when optimizing OpenSSL 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: jhendrix at galois.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5979) --> (http://llvm.org/bugs/attachment.cgi?id=5979) Test case reduced by bugpoint In trying to build OpenSSL with clang, I ran into a crypto algorithm where the LLVM optimizer is generating bad code. This error was found on LLVM 2.8, but I have reproduced it on 2.9-svn. I was able to extract a simple test case and use bugpoint to narrow down the bug into LLVM's optimizer, and have attached LLVM code that triggered the bug. To reproduce the bug use the following script: opt -o bad-reduced.bc good-reduced.ll -no-aa -tbaa -basicaa -globalopt -ipsccp -deadargelim -instcombine -simplifycfg -basiccg -prune-eh -inline -functionattrs -domtree -domfrontier -scalarrepl -early-cse -simplify-libcalls -lazy-value-info -jump-threading -correlated-propagation -simplifycfg -instcombine -tailcallelim -simplifycfg -reassociate -domtree -loops -loopsimplify -lcssa -loop-rotate -licm -lcssa -loop-unswitch -instcombine -scalar-evolution -loopsimplify -lcssa -iv-users -indvars -loop-idiom -loop-deletion -loop-unroll -instcombine -memdep -gvn -memdep -memcpyopt -sccp -instcombine -lazy-value-info -jump-threading -correlated-propagation -domtree -memdep -dse -adce -simplifycfg -strip-dead-prototypes -print-used-types -deadtypeelim -constmerge -preverify -domtree -verify echo "Running unoptimized" clang -o good-reduced good-reduced.ll && ./good-reduced echo "Running optimized" clang -o bad-reduced bad-reduced.bc && ./bad-reduced On my machine, the following output shows the expected result: Running unoptimized ok 10ce4c18 broken 4c ok 527039d8 broken 39 Running optimized ok 10ce4c18 broken 4e ok 320ab844 broken ba -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 00:06:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 00:06:40 -0600 (CST) Subject: [LLVMbugs] [Bug 8948] New: .section parsed incorrectly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8948 Summary: .section parsed incorrectly Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM assembly language parser AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu On a ELF system, compile .section "foo" and check the output of readelf -S. Expected output is a section with name foo, but created is a section with name "fo. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 01:53:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 01:53:40 -0600 (CST) Subject: [LLVMbugs] [Bug 6371] Assertion failed: (TInfo && "couldn't build declarator info for anonymous struct/union") In-Reply-To: References: Message-ID: <20110110075340.6EADA2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6371 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-01-10 01:53:39 CST --- This looks like it got fixed along the way. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 10 09:50:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 09:50:39 -0600 (CST) Subject: [LLVMbugs] [Bug 8949] New: Redefining a weak symbol crashes with integrated as Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8949 Summary: Redefining a weak symbol crashes with integrated as Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Target Description Classes AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Consider: asm("bar:\n.weak foo\nfoo = bar"); int foo(void) { return 0; } Assembling first and pushing the result through the integrated assembler works and correctly flags the redefinition. Compiling this directly with the integrated assembler crashes with: #2 0x00007ffff6cada71 in __assert_fail ( assertion=0x170c300 "!Symbol->isVariable() && \"Cannot emit a variable symbol!\"", file=, line=100, function=0x1714780 "virtual void llvm::MCObjectStreamer::EmitLabel(llvm::MCSymbol*)") at assert.c:81 #3 0x00000000010b0d89 in llvm::MCObjectStreamer::EmitLabel ( this=, Symbol=0x1d629f0) at /home/joerg/work/infrastructure/llvm.org/llvm/lib/MC/MCObjectStreamer.cpp:100 #4 0x00000000010a0bcc in (anonymous namespace)::MCELFStreamer::EmitLabel ( this=0x1d5fd60, Symbol=0x3fc) at /home/joerg/work/infrastructure/llvm.org/llvm/lib/MC/MCELFStreamer.cpp:191 #5 0x0000000000da248e in llvm::AsmPrinter::EmitFunctionEntryLabel ( this=0x1d631f0) at /home/joerg/work/infrastructure/llvm.org/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:468 #6 0x0000000000da5333 in llvm::AsmPrinter::EmitFunctionHeader ( this=0x1d631f0) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 11:53:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 11:53:31 -0600 (CST) Subject: [LLVMbugs] [Bug 8950] New: Crypto++ validation test crashes in IDEA code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8950 Summary: Crypto++ validation test crashes in IDEA code Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mclow at qualcomm.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5981) --> (http://llvm.org/bugs/attachment.cgi?id=5981) Replacement makefile (uses clang, removes -O2) This looks like a codegen error; but I'm not 100% sure. To reproduce: 1) Get crypto++ from here: "svn co https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5 cryptopp" 2) Replace GNUMakefile with one from this bug report. 3) make test --> segmentation fault Running under gdb shows: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x000000010017d7a0 in CryptoPP::IDEA::Base::DeKey (this=0x100d04ba0) at idea.cpp:141 141 tempkey[i*6+5] = m_key[(ROUNDS-1-i)*6+5]; and some poking around shows that i == 0, and that the sizes of the arrays are ok. More questions? Drop me a line. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 12:59:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 12:59:19 -0600 (CST) Subject: [LLVMbugs] [Bug 8951] New: Support for .equiv in integrated assembler Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8951 Summary: Support for .equiv in integrated assembler Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM assembly language parser AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu .equiv works like .set / .equ, but disallows redefinition. Attached patch adds support for it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 10 15:54:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 15:54:09 -0600 (CST) Subject: [LLVMbugs] [Bug 8916] clang tot takes a long, long time (maybe forever) to compile Cryptopp's sha.cpp In-Reply-To: References: Message-ID: <20110110215409.DE8E22A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8916 Dale Johannesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Dale Johannesen 2011-01-10 15:54:09 CST --- I've checked in the 1liner described above in 123191, which fixes this particular problem, anyway. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 16:30:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 16:30:49 -0600 (CST) Subject: [LLVMbugs] [Bug 8952] New: extern "C" function returning pointer to class in namespace{} silently drops symbol Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8952 Summary: extern "C" function returning pointer to class in namespace{} silently drops symbol Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ps at kr.tuwien.ac.at CC: llvmbugs at cs.uiuc.edu I compiled the following minimal example with clang trunk using "clang++ -c" === namespace{ class Foo {}; Foo f; } extern "C" Foo* bar() { return &f; } extern "C" void* baz() { return reinterpret_cast(&f); } === The resulting object file has no symbol "bar" but it has a symbol "baz". There is no warning and no error. g++ 4.4.5 creates an object file with both symbols (and they are usable). I honestly do not know which compiler is right, but probably if the symbol is not generated there should at least be a warning. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 10 18:33:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 18:33:29 -0600 (CST) Subject: [LLVMbugs] [Bug 8912] Non-type template argument parse error (with a functional cast expression). In-Reply-To: References: Message-ID: <20110111003329.C6E372A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8912 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-01-10 18:33:29 CST --- Fixed in Clang r123201. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 20:51:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 20:51:49 -0600 (CST) Subject: [LLVMbugs] [Bug 8953] New: Edge splitting should update LiveIntervals Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8953 Summary: Edge splitting should update LiveIntervals Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: zwarich at apple.com CC: llvmbugs at cs.uiuc.edu Edge splitting should update LiveIntervals so that we can split edges on demand throughout the register allocation 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 Mon Jan 10 21:18:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 21:18:05 -0600 (CST) Subject: [LLVMbugs] [Bug 8954] New: non deterministic "-basicaa -loop-unroll -gvn" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8954 Summary: non deterministic "-basicaa -loop-unroll -gvn" Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5984) --> (http://llvm.org/bugs/attachment.cgi?id=5984) testcase Running opt -basicaa -loop-unroll -gvn t.ll -o sched-vis2.ll on the attached file multiple times produces different results if address space randomization is enabled. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 10 22:44:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 10 Jan 2011 22:44:46 -0600 (CST) Subject: [LLVMbugs] [Bug 8955] New: Assertion `DidIt && "Block merge failed??"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8955 Summary: Assertion `DidIt && "Block merge failed??"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu regehr at home:~/volatile/bugs/tmp344$ clang -c -w small.c -O1 clang: LoopRotation.cpp:343: bool::LoopRotate::rotateLoop(llvm::Loop*): Assertion `DidIt && "Block merge failed??"' failed. 0 clang 0x09476448 Stack dump: 0. Program arguments: /mnt/z/z/compiler-install/llvm-gcc-r123209-install/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.20.51 -resource-dir /mnt/z/z/compiler-install/llvm-gcc-r123209-install/bin/../lib/clang/2.9 -O1 -w -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Loop Pass Manager' on function '@func_46' 5. Running pass 'Rotate Loops' on basic block '%lbl_283' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) regehr at home:~/volatile/bugs/tmp344$ clang -v clang version 2.9 (trunk 123209) Target: i386-pc-linux-gnu Thread model: posix regehr at home:~/volatile/bugs/tmp344$ cat small.c int g_2; int *g_37; int **g = &g_37; int g_57; int *g_141 = &g_2; int *g_143 = &g_57; int func_64 (int *); void func_46 (int p_47) { int l_166; int *l_261 = &l_166; int *l_286; l_286 = &l_166; lbl_283: *g_143 |= 0; if (p_47) { int **l_262 = &l_261; if (**l_262) { for (; g; ) { } lbl_281: *g = 0; } if (g_57) goto lbl_281; goto lbl_283; } else { int **l_295 = &l_286; if (func_64 (*l_295)); } } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 01:48:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 01:48:16 -0600 (CST) Subject: [LLVMbugs] [Bug 8955] Assertion `DidIt && "Block merge failed??"' failed. In-Reply-To: References: Message-ID: <20110111074816.10B862A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8955 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-01-11 01:48:15 CST --- Aha, great catch, fixed in r123219. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 11 09:26:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 09:26:33 -0600 (CST) Subject: [LLVMbugs] [Bug 8956] New: asm labels are ignored for static local variables Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8956 Summary: asm labels are ignored for static local variables Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: abramobagnara at tin.it CC: llvmbugs at cs.uiuc.edu $ cat t.c int f() { static int x asm("qq"); return x; } $ clang -c t.c $ nm t.o 0000000000000000 T f 0000000000000000 b f.x $ gcc -c t.c $ nm t.o 0000000000000000 T f 0000000000000000 b qq No symbol called qq has been created by clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 11 10:58:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 10:58:25 -0600 (CST) Subject: [LLVMbugs] [Bug 8957] New: Recognize ARM EABI triple Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8957 Summary: Recognize ARM EABI triple Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rengolin at gmail.com CC: llvmbugs at cs.uiuc.edu The EABI triples are not being recognized by Clang (but are by llc), so we need to add it to lib/Driver/Tools.cpp:Clang::AddARMTargetArgs() and possibly update llvm/ADT/Triple.h with an "EABI" Environment (or OS). See bug 8911 for full discussion. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 11:05:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 11:05:19 -0600 (CST) Subject: [LLVMbugs] [Bug 8946] [MC] SSE2 : valid reg-to-reg MOVDQU rejected by the x86 backend In-Reply-To: References: Message-ID: <20110111170519.E1F1F2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8946 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Summary|SSE2 : valid reg-to-reg |[MC] SSE2 : valid |MOVDQU rejected by the x86 |reg-to-reg MOVDQU rejected |backend |by the x86 backend --- Comment #2 from Chris Lattner 2011-01-11 11:05:19 CST --- Nice catch, fixed in r123242, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 11 11:28:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 11:28:21 -0600 (CST) Subject: [LLVMbugs] [Bug 8958] New: Hit assertion in SelectionDAG.cpp for the attached code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8958 Summary: Hit assertion in SelectionDAG.cpp for the attached code Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu Assertion failed: !VT.isVector() && "getZeroExtendInReg should use the vector element type instead of " "the vector type!", file ..\..\..\..\..\llvm\lib\CodeGen\SelectionDAG\SelectionDAG.cpp, line 855 Checked on today's trunk. ; ModuleID = 'bugpoint-reduced-simplified.bc' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i686-pc-win32" define void @m_387() nounwind { %1 = load <4 x i8> addrspace(1)* undef, align 1 %2 = zext <4 x i8> %1 to <4 x i32> store <4 x i32> %2, <4 x i32> addrspace(1)* undef, align 4 ret void } Fix forthcoming. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 11:34:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 11:34:59 -0600 (CST) Subject: [LLVMbugs] [Bug 8318] ARM EABI: inefficient code saving/restoring sp around function call In-Reply-To: References: Message-ID: <20110111173459.2A6472A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8318 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Bob Wilson 2011-01-11 11:34:58 CST --- This is expected behavior. You need to compile with -fomit-frame-pointer. I think GCC automatically enables that option for some targets when compiling with optimization, but clang does not do that, as far as I know. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 11 13:52:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 13:52:42 -0600 (CST) Subject: [LLVMbugs] [Bug 8959] New: inline asm "0" constraint doesn't implicitly cast Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8959 Summary: inline asm "0" constraint doesn't implicitly cast Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, spectral at google.com This is a breakout from bug 3373 comment 11. New testcase: int test_and_set(volatile int *addr) { unsigned char oldval; /* Note: the "xchg" instruction does not need a "lock" prefix */ __asm__ __volatile__("xchgb %0, %1" : "=Q"(oldval), "=m"(*addr) : "0"(0xff), "m"(*addr) : "memory"); return (int)oldval; } which produces: $ clang t.c -S -o - t.c:7:25: error: unsupported inline asm: input with type 'int' matching output with type 'unsigned char' : "0"(0xff), "m"(*addr) : "memory"); ^~~~ 1 error generated. Ian Taylor explains: "Clang is incorrectly assuming that when given an operand number as a constraint that the type of a constant must be identical to the type of the other operand. When the operand is a constant, it should be converted to the relevant type as though in an assignment. When the operand is a variable of some sort, it must of course have exactly the correct type." -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 11 14:32:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 14:32:47 -0600 (CST) Subject: [LLVMbugs] [Bug 8960] New: Wrong end location for CXXNamedCastExpr Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8960 Summary: Wrong end location for CXXNamedCastExpr Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alr at google.com CC: llvmbugs at cs.uiuc.edu For the following expression: x = static_cast(f(y)); CXXStaticCastExpr::GetLocEnd() returns: x = static_cast(f(y)); ^ expected: x = static_cast(f(y)); ^ The last token in static_cast<> should be the closing parenthesis, not last token of sub-expression. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 16:27:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 16:27:12 -0600 (CST) Subject: [LLVMbugs] [Bug 8658] clang doesn't ignore '/' comments in assembler .s files In-Reply-To: References: Message-ID: <20110111222712.CC0DB2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8658 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #10 from Nick Lewycky 2011-01-11 16:27:12 CST --- After a lengthy discussion on IRC, the concensus was reached that this is an undesirable extension to binutils and since the binutils documentation doesn't list it as a valid way to write comments, we shouldn't accept it either. I'm going to file bugs on both binutils and mozilla to get their sides fixed respectively and will update this bug with link to those bugs as they're filed. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 17:25:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 17:25:11 -0600 (CST) Subject: [LLVMbugs] [Bug 8956] asm labels are ignored for static local variables In-Reply-To: References: Message-ID: <20110111232511.5CFC32A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8956 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |asl at math.spbu.ru Resolution| |DUPLICATE --- Comment #1 from Anton Korobeynikov 2011-01-11 17:25:11 CST --- *** This bug has been marked as a duplicate of bug 4777 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 18:32:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 18:32:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8954] non deterministic "-basicaa -loop-unroll -gvn" In-Reply-To: References: Message-ID: <20110112003245.3FF022A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8954 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #47 from Jakob Stoklund Olesen 2011-01-11 18:32:44 CST --- The llvm-gcc-i386-darwin9 likes the patch, closing as fixed by r123286. Thanks, Cameron. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 11 20:16:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 11 Jan 2011 20:16:18 -0600 (CST) Subject: [LLVMbugs] [Bug 8961] New: Wrong assembly is written for x86_64 target in JIT Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8961 Summary: Wrong assembly is written for x86_64 target in JIT Product: libraries Version: trunk Platform: Other OS/Version: All Status: NEW Severity: release blocker Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: jerrry94087 at yahoo.com CC: llvmbugs at cs.uiuc.edu When I try running one llvm function in JIT without optimization I get SEGV. Looking at assembly (below) I see that the local value 0xffffffffffffffe0(%rbp) is used without being ever initialized (see my comment in asm). Same code on i386 works fine, with and w/out optimization. The uninitialized load has been erroneously moved ahead of the spill. Yuri --- llvm --- %struct.mystruct = type { i32, i8, i8, i8, i8 } define i32 @xfunc(%struct.mystruct* %a1, %struct.mystruct* %a2) { br label %lbl1 lbl1: %v1 = call i32 @yfunc(i32 1, i32 0, i32 0) %v2 = bitcast %struct.mystruct* %a1 to i8* %v3 = getelementptr i8* %v2, i32 %v1 %v4 = bitcast i8* %v3 to i32* %v5 = load i32* %v4 %v6 = call i32 @yfunc(i32 1, i32 4, i32 0) %v7 = bitcast %struct.mystruct* %a2 to i8* %v8 = getelementptr i8* %v7, i32 %v6 %v9 = bitcast i8* %v8 to i32* %v10 = load i32* %v9 %op.dual.plus.uint32 = add i32 %v5, %v10 br label %lbl2 lbl2: ret i32 %op.dual.plus.uint32 } declare i32 @yfunc(i32, i32, i32) --- assembly obtained in gdb for JITted code --- 0x0000000800989bf0: push %rbp 0x0000000800989bf1: mov %rsp,%rbp 0x0000000800989bf4: sub $0x30,%rsp 0x0000000800989bf8: mov %rdi,0xfffffffffffffff8(%rbp) 0x0000000800989bfc: mov %rsi,0xfffffffffffffff0(%rbp) 0x0000000800989c00: mov $0x1,%edi 0x0000000800989c05: xor %eax,%eax 0x0000000800989c07: mov $0x800a09060,%rcx 0x0000000800989c11: mov %eax,%esi 0x0000000800989c13: mov %eax,%edx 0x0000000800989c15: callq *%ecx 0x0000000800989c17: movslq %eax,%rcx 0x0000000800989c1a: mov 0xfffffffffffffff8(%rbp),%r8 0x0000000800989c1e: mov (%r8,%rcx,1),%eax 0x0000000800989c22: mov $0x1,%edi 0x0000000800989c27: mov $0x4,%esi 0x0000000800989c2c: xor %edx,%edx 0x0000000800989c2e: mov $0x800a09060,%rcx 0x0000000800989c38: mov %eax,0xffffffffffffffec(%rbp) 0x0000000800989c3b: callq *%ecx 0x0000000800989c3d: mov 0xffffffffffffffec(%rbp),%edx 0x0000000800989c40: mov 0xfffffffffffffff0(%rbp),%rcx 0x0000000800989c44: mov 0xffffffffffffffe0(%rbp),%r8 ; XXX use of uninitialized value 0x0000000800989c48: add (%rcx,%r8,1),%edx ; SEGV 0x0000000800989c4c: movslq %eax,%r8 0x0000000800989c4f: mov %edx,0xffffffffffffffdc(%rbp) 0x0000000800989c52: mov %r8,0xffffffffffffffe0(%rbp) 0x0000000800989c56: mov 0xffffffffffffffdc(%rbp),%eax 0x0000000800989c59: add $0x30,%rsp 0x0000000800989c5d: pop %rbp 0x0000000800989c5e: retq --- result after running llvm-as and llc on the same function --- subq $56, %rsp .Ltmp0: movq %rdi, 48(%rsp) # 8-byte Spill movq %rsi, 40(%rsp) # 8-byte Spill # BB#1: # %lbl1 movl $1, %eax movl $4, %esi movl $0, %ecx movl %eax, %edi movl %esi, 36(%rsp) # 4-byte Spill movl %ecx, %esi movl %ecx, %edx movl %eax, 32(%rsp) # 4-byte Spill movl %ecx, 28(%rsp) # 4-byte Spill callq yfunc movslq %eax, %r8 movq 48(%rsp), %r9 # 8-byte Reload movl (%r9,%r8), %eax movl 32(%rsp), %edi # 4-byte Reload movl 36(%rsp), %esi # 4-byte Reload movl 28(%rsp), %edx # 4-byte Reload movl %eax, 24(%rsp) # 4-byte Spill callq yfunc movl 24(%rsp), %ecx # 4-byte Reload movq 40(%rsp), %r8 # 8-byte Reload movq 16(%rsp), %r9 # 8-byte Reload addl (%r8,%r9), %ecx movslq %eax, %r9 movl %ecx, 12(%rsp) # 4-byte Spill movq %r9, 16(%rsp) # 8-byte Spill # BB#2: # %lbl2 movl 12(%rsp), %eax # 4-byte Reload addq $56, %rsp ret -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 12 03:11:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 03:11:13 -0600 (CST) Subject: [LLVMbugs] [Bug 3558] ASTContext::getIntWidth, getTypeInfo, etc should be const In-Reply-To: References: Message-ID: <20110112091113.36F672A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3558 Jay Foad changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Jay Foad 2011-01-12 03:11:12 CST --- Fixed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110110/037801.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 12 04:54:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 04:54:31 -0600 (CST) Subject: [LLVMbugs] [Bug 8962] New: Static analyzer fail on GTK g_return_if_fail Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8962 Summary: Static analyzer fail on GTK g_return_if_fail Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: batolettre at gmail.com CC: llvmbugs at cs.uiuc.edu Static analyzer fail to understand the g_return_if_fail from GTK and trigger a "dereference of a null pointer" error. Example below: http://pellelatarte.fr/dawa/gimp-llvm/report-SqiBmn.html#EndPath Analyzer from trunk, compiled the 10 january 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 Wed Jan 12 11:30:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 11:30:54 -0600 (CST) Subject: [LLVMbugs] [Bug 8963] New: Buffer Overflow Check False Positives Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8963 Summary: Buffer Overflow Check False Positives Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: william.metcalf at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5998) --> (http://llvm.org/bugs/attachment.cgi?id=5998) scan-build output Seems that all four out-of-bounds memory access errors are false positives in the included report. This check in all four reported instances makes sure that no out-of-bounds access is made. while ((prev > name_start) && (htp_is_lws(data[prev]))) {} -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 12:07:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 12:07:43 -0600 (CST) Subject: [LLVMbugs] [Bug 8964] New: LLVM 2.8: still crashes on CPUs without CMOV instruction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8964 Summary: LLVM 2.8: still crashes on CPUs without CMOV instruction Product: libraries Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: edwintorok at gmail.com CC: llvmbugs at cs.uiuc.edu LLVM 2.8 still crashes on CPUs without CMOV instruction like AMD K6-2, VIA C3, etc. See http://bugs.debian.org/609759 Here's an output of the JIT with --debug, appears to contain all instruction selection stuff: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=2011-01-12_clambc.767944.cbc.log;att=2;bug=609759 The .td files seem to properly guard all CMOV* instructions with HasCMOV, so I don't see where its coming from. Are there some machine-instr level optimizers that introduce it? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 12 14:53:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 14:53:33 -0600 (CST) Subject: [LLVMbugs] [Bug 8965] New: clang fails assertion "Unable to find instantiation of declaration!" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8965 Summary: clang fails assertion "Unable to find instantiation of declaration!" Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ps at kr.tuwien.ac.at CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5999) --> (http://llvm.org/bugs/attachment.cgi?id=5999) slightly reduced input that creates the problem, bz2 compressed $ clang++ -v clang version 2.9 (trunk 123293) Target: x86_64-unknown-linux-gnu Thread model: posix clang: SemaTemplateInstantiateDecl.cpp:2885: clang::NamedDecl* clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, const clang::MultiLevelTemplateArgumentList&): Assertion `(Result || isa(D) || D->isInvalidDecl() || cast(ParentDC)->isInvalidDecl()) && "Unable to find instantiation of declaration!"' failed. 0 clang 0x00000000015b496f 1 clang 0x00000000015b54ba 2 libpthread.so.0 0x00007f1f4721db40 3 libc.so.6 0x00007f1f4651bba5 gsignal + 53 4 libc.so.6 0x00007f1f4651f6b0 abort + 384 5 libc.so.6 0x00007f1f46514a71 __assert_fail + 241 6 clang 0x0000000000aca647 clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&) + 391 ... 132 clang 0x000000000072aa84 clang::CodeGenAction::ExecuteAction() + 68 133 clang 0x0000000000623865 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 134 clang 0x000000000060052a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1098 135 clang 0x00000000005f6725 cc1_main(char const**, char const**, char const*, void*) + 549 136 clang 0x00000000005ff57c main + 4956 137 libc.so.6 0x00007f1f46506d8e __libc_start_main + 254 138 clang 0x00000000005f6319 Stack dump: 0. Program arguments: /var/lib/buildbot/instdirs/clang-trunk/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name fail.smaller.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51 -resource-dir /var/lib/buildbot/instdirs/clang-trunk/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 189 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o fail.smaller.o -x c++ fail.smaller.cpp 1. ../../testsuite/TestMCSIE.cpp:422:13: at annotation token 2. ../../testsuite/TestMCSIE.cpp:339:1: parsing function body 'main' 3. ../../testsuite/TestMCSIE.cpp:339:1: in compound statement ('{}') 4. ../../testsuite/TestMCSIE.cpp:421:3: in compound statement ('{}') clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) (full backtrace attached) I also attached the input "fail.smaller.cpp", it's reduced from 5MB to 3MB, sorry that it's still that large. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 14:58:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 14:58:42 -0600 (CST) Subject: [LLVMbugs] [Bug 8966] New: clang++ fails to compile static template member variable Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8966 Summary: clang++ fails to compile static template member variable Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: felix.ritter at mevis.fraunhofer.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang version 2.9 (trunk 123319) Target: x86_64-apple-darwin10 Thread model: posix clang++ fails to compile static template member variable. Small example attached. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 12 15:21:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 15:21:37 -0600 (CST) Subject: [LLVMbugs] [Bug 8938] wint_t definition clashes with GCC compiled c++ standard library In-Reply-To: References: Message-ID: <20110112212137.362E02A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8938 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Resolution| |FIXED --- Comment #3 from Douglas Gregor 2011-01-12 15:21:36 CST --- Fixed in Clang r123320. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 16:42:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 16:42:02 -0600 (CST) Subject: [LLVMbugs] [Bug 8960] Wrong end location for CXXNamedCastExpr In-Reply-To: References: Message-ID: <20110112224202.49B972A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8960 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-01-12 16:42:01 CST --- Fixed in Clang r123336. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 17:49:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 17:49:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8967] New: Assertion `outgoing && "expression emission cleared block!"' failed when compiling mozilla's jsinterp.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8967 Summary: Assertion `outgoing && "expression emission cleared block!"' failed when compiling mozilla's jsinterp.cpp Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ehsan at mozilla.com CC: rafael.espindola at gmail.com, llvmbugs at cs.uiuc.edu I've been experimenting to compile mozilla's trunk using clang/llvm trunk, and I hit an assertion: clang: /home/ehsan/src/llvm/tools/clang/lib/CodeGen/CGStmt.cpp:100: void clang::CodeGen::CodeGenFunction::EmitStmt(const clang::Stmt*): Assertion `outgoing && "expression emission cleared block!"' failed. 0 clang 0x000000000170af6f 1 clang 0x000000000170d1e2 2 libpthread.so.0 0x00007f667c987b40 3 libc.so.6 0x00007f667bc85ba5 gsignal + 53 4 libc.so.6 0x00007f667bc896b0 abort + 384 5 libc.so.6 0x00007f667bc7ea71 __assert_fail + 241 6 clang 0x000000000083f552 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 1362 7 clang 0x0000000000841f08 clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 264 8 clang 0x00000000008421a6 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 262 9 clang 0x000000000083f027 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 39 10 clang 0x0000000000841199 clang::CodeGen::CodeGenFunction::EmitDoStmt(clang::DoStmt const&) + 393 11 clang 0x0000000000841f08 clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 264 12 clang 0x00000000008421a6 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 262 13 clang 0x000000000083f027 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 39 14 clang 0x0000000000841199 clang::CodeGen::CodeGenFunction::EmitDoStmt(clang::DoStmt const&) + 393 15 clang 0x0000000000841f08 clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 264 16 clang 0x00000000008421a6 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 262 17 clang 0x000000000083f027 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 39 18 clang 0x00000000008631b9 clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl, llvm::Function*) + 617 19 clang 0x000000000075b765 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl) + 725 20 clang 0x000000000075c292 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl) + 194 21 clang 0x000000000075ce7d clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 845 22 clang 0x000000000075d43b clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 411 23 clang 0x000000000075d93b clang::CodeGen::CodeGenModule::EmitNamespace(clang::NamespaceDecl const*) + 59 24 clang 0x000000000075d5d5 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 821 25 clang 0x000000000074fb61 26 clang 0x000000000074dec1 27 clang 0x000000000087a906 clang::ParseAST(clang::Sema&, bool) + 166 28 clang 0x000000000074ef14 clang::CodeGenAction::ExecuteAction() + 68 29 clang 0x00000000006449c5 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 30 clang 0x000000000062248c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 31 clang 0x0000000000619f85 cc1_main(char const**, char const**, char const*, void*) + 693 32 clang 0x000000000062149b main + 4587 33 libc.so.6 0x00007f667bc70d8e __libc_start_main + 254 34 clang 0x0000000000618679 Stack dump: 0. Program arguments: /home/ehsan/src/build/Release+Asserts/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name jsinterp.cpp -pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51 -v -g -resource-dir /home/ehsan/src/build/Release+Asserts/bin/../lib/clang/2.9 -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -pedantic -ferror-limit 19 -fmessage-length 0 -pthread -fno-rtti -fgnu-runtime -fdiagnostics-show-option -o jsinterp.s -x c++-cpp-output tmp.ii 1. parser at end of file 2. tmp.ii:47169:11: LLVM IR generation of declaration 'js' 3. tmp.ii:47172:1: Generating code for declaration 'js::Interpret' 4. tmp.ii:47173:1: LLVM IR generation of compound statement ('{}') 5. tmp.ii:48250:8: LLVM IR generation of compound statement ('{}') 6. tmp.ii:48250:60: LLVM IR generation of compound statement ('{}') Aborted I'm attaching the preprocessed source 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 Jan 12 17:57:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 17:57:14 -0600 (CST) Subject: [LLVMbugs] [Bug 8958] Hit assertion in SelectionDAG.cpp for the attached code In-Reply-To: References: Message-ID: <20110112235714.0663A2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8958 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Dan Gohman 2011-01-12 17:57:13 CST --- Looks good. Applied in r123346. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 19:35:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 19:35:53 -0600 (CST) Subject: [LLVMbugs] [Bug 8968] New: assertion failure: "DecomposeGEPExpression and GetUnderlyingObject disagree!" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8968 Summary: assertion failure: "DecomposeGEPExpression and GetUnderlyingObject disagree!" Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Global Analyses AssignedTo: unassignedbugs at nondot.org ReportedBy: bob.wilson at apple.com CC: llvmbugs at cs.uiuc.edu I noticed this assertion failure while running the llvm testsuite. Bugpoint was able to reduce it partially, but the "simplified" version exposed a different failure, so I'm attached only the "blocks" version. To reproduce, run: opt bugpoint-reduced-blocks.bc -basicaa -internalize -inline -globalsmodref-aa -gvn -verify Assertion failed: (TD == 0 && "DecomposeGEPExpression and GetUnderlyingObject disagree!"), function aliasGEP, file /Volumes/LocalHD/bwilson/llvm/llvm/lib/Analysis/BasicAliasAnalysis.cpp, line 821. 0 opt 0x000000010065d785 PrintStackTrace(void*) + 53 1 opt 0x000000010065dd4b SignalHandler(int) + 379 2 libSystem.B.dylib 0x00007fff8900867a _sigtramp + 26 3 libSystem.B.dylib 0x000000010198fd08 _sigtramp + 2023257768 4 opt 0x00000001000910db raise + 27 5 opt 0x000000010009119a abort + 26 6 opt 0x0000000100091174 __assert_rtn + 132 7 opt 0x0000000100319712 (anonymous namespace)::BasicAliasAnalysis::aliasGEP(llvm::GEPOperator const*, unsigned long long, llvm::Value const*, unsigned long long, llvm::MDNode const*, llvm::Value const*, llvm::Value const*) + 562 8 opt 0x0000000100318df9 (anonymous namespace)::BasicAliasAnalysis::aliasCheck(llvm::Value const*, unsigned long long, llvm::MDNode const*, llvm::Value const*, unsigned long long, llvm::MDNode const*) + 1385 9 opt 0x00000001003141ef (anonymous namespace)::BasicAliasAnalysis::alias(llvm::AliasAnalysis::Location const&, llvm::AliasAnalysis::Location const&) + 287 10 opt 0x00000001003186da non-virtual thunk to (anonymous namespace)::BasicAliasAnalysis::alias(llvm::AliasAnalysis::Location const&, llvm::AliasAnalysis::Location const&) + 58 11 opt 0x00000001003061dc llvm::AliasAnalysis::alias(llvm::AliasAnalysis::Location const&, llvm::AliasAnalysis::Location const&) + 140 12 opt 0x00000001002f9d41 (anonymous namespace)::GlobalsModRef::alias(llvm::AliasAnalysis::Location const&, llvm::AliasAnalysis::Location const&) + 961 13 opt 0x00000001002fa3da non-virtual thunk to (anonymous namespace)::GlobalsModRef::alias(llvm::AliasAnalysis::Location const&, llvm::AliasAnalysis::Location const&) + 58 14 opt 0x0000000100384849 llvm::MemoryDependenceAnalysis::getPointerDependencyFrom(llvm::AliasAnalysis::Location const&, bool, llvm::ilist_iterator, llvm::BasicBlock*) + 889 15 opt 0x0000000100387f83 llvm::MemoryDependenceAnalysis::GetNonLocalInfoForBlock(llvm::AliasAnalysis::Location const&, bool, llvm::BasicBlock*, std::vector >*, unsigned int) + 1251 16 opt 0x0000000100386f4d llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(llvm::PHITransAddr const&, llvm::AliasAnalysis::Location const&, bool, llvm::BasicBlock*, llvm::SmallVectorImpl&, llvm::DenseMap, llvm::DenseMapInfo >&, bool) + 3181 17 opt 0x00000001003874b1 llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(llvm::PHITransAddr const&, llvm::AliasAnalysis::Location const&, bool, llvm::BasicBlock*, llvm::SmallVectorImpl&, llvm::DenseMap, llvm::DenseMapInfo >&, bool) + 4561 18 opt 0x00000001003861ee llvm::MemoryDependenceAnalysis::getNonLocalPointerDependency(llvm::AliasAnalysis::Location const&, bool, llvm::BasicBlock*, llvm::SmallVectorImpl&) + 334 19 opt 0x000000010014696d (anonymous namespace)::GVN::processNonLocalLoad(llvm::LoadInst*, llvm::SmallVectorImpl&) + 205 20 opt 0x00000001001439de (anonymous namespace)::GVN::processLoad(llvm::LoadInst*, llvm::SmallVectorImpl&) + 1422 21 opt 0x0000000100142fcb (anonymous namespace)::GVN::processInstruction(llvm::Instruction*, llvm::SmallVectorImpl&) + 331 22 opt 0x0000000100142b18 (anonymous namespace)::GVN::processBlock(llvm::BasicBlock*) + 168 23 opt 0x000000010013ffaf (anonymous namespace)::GVN::iterateOnFunction(llvm::Function&) + 271 24 opt 0x000000010013fcc2 (anonymous namespace)::GVN::runOnFunction(llvm::Function&) + 578 25 opt 0x00000001005d9ef5 llvm::FPPassManager::runOnFunction(llvm::Function&) + 405 26 opt 0x00000001005da293 llvm::FPPassManager::runOnModule(llvm::Module&) + 131 27 opt 0x00000001005da502 llvm::MPPassManager::runOnModule(llvm::Module&) + 530 28 opt 0x00000001005dad16 llvm::PassManagerImpl::run(llvm::Module&) + 182 29 opt 0x00000001005db1fd llvm::PassManager::run(llvm::Module&) + 29 30 opt 0x00000001000a78c9 main + 6825 31 opt 0x00000001000976e8 start + 52 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 20:03:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 20:03:41 -0600 (CST) Subject: [LLVMbugs] [Bug 8967] Assertion `outgoing && "expression emission cleared block!"' failed when compiling mozilla's jsinterp.cpp In-Reply-To: References: Message-ID: <20110113020341.805052A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8967 John McCall changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from John McCall 2011-01-12 20:03:40 CST --- Fixed in r123360. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 12 20:43:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 12 Jan 2011 20:43:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8969] New: linux x86-32 stack not kept 16-byte aligned Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8969 Summary: linux x86-32 stack not kept 16-byte aligned Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6003) --> (http://llvm.org/bugs/attachment.cgi?id=6003) testcase On 32-bit Linux, the stack is supposed to be 16-byte aligned. LLVM doesn't actually do that by default. The attached .bc file demonstrates: nlewycky at ducttape:~$ llvm/Debug+Asserts/bin/llc -O0 pp.bc -o - .file "pp.bc" .text .hidden prologProcessor .globl prologProcessor .align 16, 0x90 .type prologProcessor, at function prologProcessor: # @prologProcessor # BB#0: pushl %ebp pushl %ebx pushl %edi pushl %esi subl $68, %esp which is 8-byte aligned, not 16-byte aligned. This isn't ABI compliant. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 00:31:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 Jan 2011 00:31:49 -0600 (CST) Subject: [LLVMbugs] [Bug 8970] New: -Wmissing-noreturn produces a false positive on some constructors Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8970 Summary: -Wmissing-noreturn produces a false positive on some constructors Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: oliver at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6004) --> (http://llvm.org/bugs/attachment.cgi?id=6004) Test case If you compile the attched file: struct Wiffle { Wiffle(void* woffle) : m_woffle(woffle) { } private: void* m_woffle; }; with clang++ -c -Wmissing-noreturn foo.cpp You get an erroneous warning: foo.cpp:4:9: warning: function could be attribute 'noreturn' [-Wmissing-noreturn] { This of course breaks those projects using -Werror :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 Thu Jan 13 07:08:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 Jan 2011 07:08:12 -0600 (CST) Subject: [LLVMbugs] [Bug 8971] New: CPATH gets ignored Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8971 Summary: CPATH gets ignored Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mathias.krause at secunet.com CC: llvmbugs at cs.uiuc.edu The clang compiler ignores the CPATH environment variable, albeit the documentation states otherwise. It looks like this feature used to work but got lost somewhere after r86336. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 12:30:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 Jan 2011 12:30:44 -0600 (CST) Subject: [LLVMbugs] [Bug 7332] Assertion failed: (Arg < NumArgs && "Arg access out of range!") In-Reply-To: References: Message-ID: <20110113183044.0F9182A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7332 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Douglas Gregor 2011-01-13 12:30:42 CST --- This is fixed in top-of-tree Clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 13 12:32:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 Jan 2011 12:32:26 -0600 (CST) Subject: [LLVMbugs] [Bug 7464] clang c++ crash with extraneous "template<>" In-Reply-To: References: Message-ID: <20110113183226.87AAF2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7464 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2011-01-13 12:32:26 CST --- This no longer crashes: t2.cpp:2:1: warning: extraneous template parameter list in template specialization template<> template struct A {}; ^~~~~~~~~~ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 13 12:32:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 Jan 2011 12:32:47 -0600 (CST) Subject: [LLVMbugs] [Bug 7654] Assertion "Did not find a destructor!" on invalid code In-Reply-To: References: Message-ID: <20110113183247.AA2712A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7654 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2011-01-13 12:32:47 CST --- This is no longer crashing. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 13 13:32:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 Jan 2011 13:32:44 -0600 (CST) Subject: [LLVMbugs] [Bug 8972] New: Clean installation of LNT hits internal server error, python stack attached Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8972 Summary: Clean installation of LNT hits internal server error, python stack attached Product: Test Suite Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Nightly Tester AssignedTo: unassignedbugs at nondot.org ReportedBy: nadav.rotem at intel.com CC: llvmbugs at cs.uiuc.edu When installing a fresh DB of LNT (today's svn), and placing a sample input file, which is validated, (produced by example.py) we hit the internal server error below. Tested on Ubuntu 10.10 m_387 at ubuntu: * Running on http://localhost:8000/ ::1 - - [13/Jan/2011 16:19:21] "GET /" 200 - ::1 - - [13/Jan/2011 16:20:07] "GET /" 200 - ::1 - - [13/Jan/2011 16:25:42] "GET /submitRun" 200 - [2011-01-13 16:26:03] exception caught Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/quixote/publish.py", line 275, in process_request output = self.try_publish(request) File "/usr/local/lib/python2.6/dist-packages/quixote/publish.py", line 253, in try_publish output = self.root_directory._q_traverse(components) File "/usr/local/lib/python2.6/dist-packages/quixote/directory.py", line 67, in _q_traverse return obj() File "/usr/local/lib/python2.6/dist-packages/LNT-0.3.0dev-py2.6.egg/lnt/viewer/root.ptl", line 344, in submitRun self.config, self.dbName, db, path, '', commit) File "/usr/local/lib/python2.6/dist-packages/LNT-0.3.0dev-py2.6.egg/lnt/util/ImportData.py", line 80, in import_and_report email_config, toAddress, success, commit) File "/usr/local/lib/python2.6/dist-packages/LNT-0.3.0dev-py2.6.egg/lnt/util/NTEmailReport.py", line 47, in emailReport was_added, will_commit) File "/usr/local/lib/python2.6/dist-packages/LNT-0.3.0dev-py2.6.egg/lnt/util/NTEmailReport.py", line 451, in getReport return getSimpleReport(result, db, run, baseurl, was_added, will_commit) File "/usr/local/lib/python2.6/dist-packages/LNT-0.3.0dev-py2.6.egg/lnt/util/NTEmailReport.py", line 111, in getSimpleReport cur_id = run_summary.get_previous_run_on_machine(cur_id) File "/usr/local/lib/python2.6/dist-packages/LNT-0.3.0dev-py2.6.egg/lnt/db/perfdbsummary.py", line 205, in get_previous_run_on_machine machine_id = self.machine_id_by_run[run_id] KeyError: 1 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 13 15:49:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 Jan 2011 15:49:28 -0600 (CST) Subject: [LLVMbugs] [Bug 8973] New: remove llvm_unreachable Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8973 Summary: remove llvm_unreachable Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Support Libraries AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu llvm_reachable does two things: it prints an error message, and is marked noreturn to silence compiler warnings. It was added as a replacement for "assert(0 &&" for the second feature, but it has since pervaded the codebase. It would be really nice to eradicate almost all (or all) uses of this function, replacing them with proper assertions. We have lots of stuff like this: int foo() { switch (x) { case 1: .. case 2: .. case 3: return 27; default: llvm_unreachable("whatever"); } } This sort of thing should be turned into: int foo() { switch (x) { default: assert(0 && "whatever"); case 1: .. case 2: .. case 3: return 27; } } There are other similar patterns to remove uses of llvm_unreachable. One benefit of this is to get rid of all the ErrorHandling.h includes. In contrast to llvm_unreachable, report_fatal_error *is* useful. Those handle possible, but erroneous cases in the backend, such as inline asm constraint failures. -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 13 18:01:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 Jan 2011 18:01:17 -0600 (CST) Subject: [LLVMbugs] [Bug 8961] Wrong assembly is written for x86_64 target In-Reply-To: References: Message-ID: <20110114000117.6481B2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8961 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chris Lattner 2011-01-13 18:01:17 CST --- Fixed in r123414, thanks for the great testcase! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 13 19:20:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 13 Jan 2011 19:20:42 -0600 (CST) Subject: [LLVMbugs] [Bug 8974] New: dependency files absolutize paths such as -include ../path/foo.h on the command line Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8974 Summary: dependency files absolutize paths such as -include ../path/foo.h on the command line Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu In a very small difference between clang and gcc behaviour, the command: $(CC) -M -MF hello.d -c hello.c -include emptydir/../hello.h will produce a different hello.d for clang and for gcc. GCC always emits the value of the -include argument verbatim, while clang emits the absolute path. This breaks users who try to relocate their .d files. The way this happens in clang is that InitPreprocessor.cpp's AddImplicitInclude appends #include "..." to the file before we parse a file. Let me quote the relevant comment (in NormalizeDashIncludePath): // Implicit include paths should be resolved relative to the current // working directory first, and then use the regular header search // mechanism. The proper way to handle this is to have the // predefines buffer located at the current working directory, but // it has not file entry. For now, workaround this by using an // absolute path if we find the file here, and otherwise letting // header search handle it. so if it's found relative to '.' then we make the path absolute and then the FileEntry takes on that name when it's #include'd, and that's what goes out to dependency file 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 Fri Jan 14 06:31:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 Jan 2011 06:31:36 -0600 (CST) Subject: [LLVMbugs] [Bug 8975] New: llc should warn about invalid target triple Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8975 Summary: llc should warn about invalid target triple Product: tools Version: 2.8 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm at henning-thielemann.de CC: llvmbugs at cs.uiuc.edu When I write an invalid target triple into an LL file, then llc generates a CPP file without any warning. It should at least give a warning, but better fail. The message could also tell how to find out available target-triples. $ cat invalidtarget.ll target triple = "invalid" define i8 @func(i8) { _L1: ret i8 %0 } $ llc invalidtarget.ll $ ls -1 invalidtarget.* invalidtarget.cpp invalidtarget.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 Fri Jan 14 06:34:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 Jan 2011 06:34:26 -0600 (CST) Subject: [LLVMbugs] [Bug 8976] New: LangRef.html does not mention 'target triple' directive. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8976 Summary: LangRef.html does not mention 'target triple' directive. Product: Documentation Version: 2.8 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm at henning-thielemann.de CC: llvmbugs at cs.uiuc.edu The LLVM assembly language reference at http://llvm.org/docs/LangRef.html mentions the 'target datalayout' directive, but not 'target triple'. This would also be a good place to explain, how to find out the available target triples for the currently installed LLVM system. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 14 10:23:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 Jan 2011 10:23:27 -0600 (CST) Subject: [LLVMbugs] [Bug 8977] New: Assert on variadic template code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8977 Summary: Assert on variadic template code Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: andersca at mac.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com struct A { }; template void f(Args... args) { T t(args...); }; template void f(); Asserts with Assertion failed: (Exprs.size() != 0 && Exprs.get() && "missing expressions"), function AddCXXDirectInitializerToDecl, file SemaDeclCXX.cpp, line 5528. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 14 11:15:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 Jan 2011 11:15:02 -0600 (CST) Subject: [LLVMbugs] [Bug 8977] Assert on variadic template code In-Reply-To: References: Message-ID: <20110114171502.07DE82A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8977 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-01-14 11:15:01 CST --- Fixed in Clang r123449. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 14 11:17:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 14 Jan 2011 11:17:20 -0600 (CST) Subject: [LLVMbugs] [Bug 8591] Initializer lists not supported In-Reply-To: References: Message-ID: <20110114171720.364932A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8591 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Douglas Gregor 2011-01-14 11:17:19 CST --- *** This bug has been marked as a duplicate of bug 7069 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 15 01:29:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 01:29:38 -0600 (CST) Subject: [LLVMbugs] [Bug 8978] New: constmerge is order dependent Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8978 Summary: constmerge is order dependent Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu constmerge will optimize %struct.foobar = type { i32 } @bar.d = constant %struct.foobar zeroinitializer, align 4 @foo.d = internal constant %struct.foobar zeroinitializer, align 4 define i32 @main() nounwind ssp { entry: %call2 = tail call i32 @zed(%struct.foobar* @foo.d, %struct.foobar* @bar.d) nounwind ret i32 0 } but swapping the positions of bar.d and foo.d causes it to miss the opportunity. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 15 03:36:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 03:36:03 -0600 (CST) Subject: [LLVMbugs] [Bug 8979] New: "Can't deduce with depth > 0" assertion on invalid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8979 Summary: "Can't deduce with depth > 0" assertion on invalid code Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com (I hit this trying to reduce an other issue with delta) template < typename RT_ > class Root_of_2 { typedef __mpz_struct mpz_t[1]; template class __gmp_expr; template void __gmp_set_expr(mpf_ptr, const __gmp_expr &); typedef __gmp_expr mpz_class; template <> void __gmp_set_expr(mpz_ptr z, const mpz_class &w) {} }; $ clang++ -fsyntax-only a.cc [...] clang: /data/repos/llvm/tools/clang/lib/Sema/SemaTemplateDeduction.cpp:925: clang::Sema::TemplateDeductionResult DeduceTemplateArguments(clang::Sema&, clang::TemplateParameterList*, clang::QualType, clang::QualType, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl&, unsigned int, bool, llvm::SmallVectorImpl*): Assertion `TemplateTypeParm->getDepth() == 0 && "Can't deduce with depth > 0"' failed. [...] -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 15 09:55:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 09:55:43 -0600 (CST) Subject: [LLVMbugs] [Bug 8980] New: clang -O3 generates horrible code for std::bitset Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8980 Summary: clang -O3 generates horrible code for std::bitset Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: benny.kra at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6006) --> (http://llvm.org/bugs/attachment.cgi?id=6006) IR output from clang -O3 for this piece of c++ === #include bool foo(unsigned *a, size_t asize, unsigned *b, size_t bsize) { std::bitset<32> bits; for (unsigned i = 0; i != asize; ++i) bits[a[i]] = true; for (unsigned i = 0; i != bsize; ++i) if (bits[b[i]]) return true; return false; } === clang -O3 (with libstdc++ 4.2) generates much worse IR for the first loop than llvm-gcc -O3 does. It somehow manages to split the computation for each word into 3x and,or,and with large constants (or 7x with 64 bit words). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 15 11:25:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 11:25:35 -0600 (CST) Subject: [LLVMbugs] [Bug 8981] New: Cannot create FP integer constant! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8981 Summary: Cannot create FP integer constant! 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: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu (See b.cc below. The error doesn't appear with -O1) $ clang++ -O2 -c b.cc clang: /data/repos/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:925: llvm::SDValue llvm::SelectionDAG::getConstant(const llvm::ConstantInt&, llvm::EVT, bool): Assertion `VT.isInteger() && "Cannot create FP integer constant!"' failed. 0 clang 0x000000000175402f 1 clang 0x0000000001756292 2 libpthread.so.0 0x00007f360dac6f60 3 libc.so.6 0x00007f360cdd9165 gsignal + 53 4 libc.so.6 0x00007f360cddbf70 abort + 384 5 libc.so.6 0x00007f360cdd22b1 __assert_fail + 241 6 clang 0x0000000001191abb llvm::SelectionDAG::getConstant(llvm::ConstantInt const&, llvm::EVT, bool) + 1419 7 clang 0x0000000001191b76 llvm::SelectionDAG::getConstant(llvm::APInt const&, llvm::EVT, bool) + 54 8 clang 0x00000000011921f4 llvm::SelectionDAG::getConstant(unsigned long, llvm::EVT, bool) + 244 9 clang 0x00000000010fae54 llvm::X86TargetLowering::PerformDAGCombine(llvm::SDNode*, llvm::TargetLowering::DAGCombinerInfo&) const + 612 10 clang 0x0000000001165877 11 clang 0x00000000011682f4 llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AliasAnalysis&, llvm::CodeGenOpt::Level) + 756 12 clang 0x00000000011ec64e llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1118 13 clang 0x00000000011eed4e llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 270 14 clang 0x00000000011ef3f7 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1639 15 clang 0x00000000011f0433 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1075 16 clang 0x00000000016a4acd llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 17 clang 0x00000000016a4bcb llvm::FPPassManager::runOnModule(llvm::Module&) + 75 18 clang 0x00000000016a4657 llvm::MPPassManager::runOnModule(llvm::Module&) + 503 19 clang 0x00000000016a47d7 llvm::PassManagerImpl::run(llvm::Module&) + 167 20 clang 0x000000000077ec88 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 2376 21 clang 0x000000000077b54b 22 clang 0x000000000089b75d clang::ParseAST(clang::Sema&, bool) + 301 23 clang 0x000000000077c414 clang::CodeGenAction::ExecuteAction() + 68 24 clang 0x0000000000673205 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 25 clang 0x00000000006511dc clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 26 clang 0x0000000000648cb5 cc1_main(char const**, char const**, char const*, void*) + 677 27 clang 0x00000000006501e5 main + 4549 28 libc.so.6 0x00007f360cdc5c4d __libc_start_main + 253 29 clang 0x00000000006473b9 Stack dump: 0. Program arguments: /tmp/clang/inst/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name b.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /tmp/clang/inst/bin/../lib/clang/2.9 -O2 -ferror-limit 19 -fmessage-length 0 -fexceptions -fgnu-runtime -fdiagnostics-show-option -o b.o -x c++ b.cc 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'b.cc'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_ZNK1S1gEv' int sign ( double x ) { if ( x < 0. ) return - 1 ; if ( x > 0. ) return 1 ; return 0 ; } const double * h ( ) ; struct S { int f ( ) const ; int g ( ) const ; } ; int S :: g ( ) const { return f ( ) ? 1 : 2 ; } int S :: f ( ) const { const double * c = h ( ) ; int d = sign ( * c - * c ) ; if ( d == 0 ) return 0 ; return ( d == 0 ) ? 1 : - 1 ; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 15 11:57:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 11:57:29 -0600 (CST) Subject: [LLVMbugs] [Bug 8148] [fastcse] Inefficient code generated for rotate idiom due to instcombine without CSEs In-Reply-To: References: Message-ID: <20110115175729.617442A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8148 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Benjamin Kramer 2011-01-15 11:57:28 CST --- The new early-cse pass fixes this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 15 12:33:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 12:33:04 -0600 (CST) Subject: [LLVMbugs] [Bug 8978] constmerge is order dependent In-Reply-To: References: Message-ID: <20110115183304.D5FE22A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8978 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from Nick Lewycky 2011-01-15 12:33:04 CST --- Fixed in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110110/115247.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 15 17:01:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 17:01:11 -0600 (CST) Subject: [LLVMbugs] [Bug 8983] New: segfault in Combine redundant instructions pass Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8983 Summary: segfault in Combine redundant instructions pass 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: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu struct basic_ios { char widen ( char __c ) const ; } ; struct ostream : virtual basic_ios { } ; void endl ( ostream & __os ) { __os . widen ( '\n' ) ; } void f ( ) { ostream * m_os ; endl ( * m_os ) ; m_os = 0 ; } $ clang++ -O2 -c b.cc 0 clang 0x000000000175402f 1 clang 0x0000000001756292 2 libpthread.so.0 0x00007f8758dcff60 3 clang 0x000000000078b908 llvm::Value::getType() const + 8 4 clang 0x0000000001565a5b 5 clang 0x000000000156684e llvm::ConstantFoldInstOperands(unsigned int, llvm::Type const*, llvm::Constant* const*, unsigned int, llvm::TargetData const*) + 1854 6 clang 0x0000000001568102 llvm::ConstantFoldInstruction(llvm::Instruction*, llvm::TargetData const*) + 290 7 clang 0x00000000014b50a4 8 clang 0x00000000014b5dd7 9 clang 0x00000000016a4acd llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 10 clang 0x00000000015524ad 11 clang 0x00000000016a4657 llvm::MPPassManager::runOnModule(llvm::Module&) + 503 12 clang 0x00000000016a47d7 llvm::PassManagerImpl::run(llvm::Module&) + 167 13 clang 0x000000000077ec29 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 2281 14 clang 0x000000000077b54b 15 clang 0x000000000089b75d clang::ParseAST(clang::Sema&, bool) + 301 16 clang 0x000000000077c414 clang::CodeGenAction::ExecuteAction() + 68 17 clang 0x0000000000673205 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 18 clang 0x00000000006511dc clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 19 clang 0x0000000000648cb5 cc1_main(char const**, char const**, char const*, void*) + 677 20 clang 0x00000000006501e5 main + 4549 21 libc.so.6 0x00007f87580cec4d __libc_start_main + 253 22 clang 0x00000000006473b9 Stack dump: 0. Program arguments: /tmp/clang/inst/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name b.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /tmp/clang/inst/bin/../lib/clang/2.9 -O2 -ferror-limit 19 -fmessage-length 158 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o b.o -x c++ b.cc 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'b.cc'. 4. Running pass 'Combine redundant instructions' on function '@_Z1fv' clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 15 18:27:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 18:27:23 -0600 (CST) Subject: [LLVMbugs] [Bug 3757] partial specialization doesn't preserve attributes on call In-Reply-To: References: Message-ID: <20110116002723.AFA292A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3757 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #10 from Chris Lattner 2011-01-15 18:27:23 CST --- Thanks Andrew, removed in r123554. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 15 20:57:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 20:57:04 -0600 (CST) Subject: [LLVMbugs] [Bug 8981] Cannot create FP integer constant! In-Reply-To: References: Message-ID: <20110116025704.409712A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8981 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-01-15 20:57:03 CST --- Fixed in r123560, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 15 21:44:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 15 Jan 2011 21:44:10 -0600 (CST) Subject: [LLVMbugs] [Bug 8983] segfault in Combine redundant instructions pass In-Reply-To: References: Message-ID: <20110116034410.D7F4C2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8983 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-01-15 21:44:10 CST --- Fixed in r123562, thanks for the nice small testcase! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 16 00:18:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 00:18:51 -0600 (CST) Subject: [LLVMbugs] [Bug 8980] clang -O3 generates horrible code for std::bitset In-Reply-To: References: Message-ID: <20110116061851.E72282A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8980 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #10 from Chris Lattner 2011-01-16 00:18:51 CST --- Fixed in r123571, thanks for reporting 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 Sun Jan 16 02:09:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 02:09:38 -0600 (CST) Subject: [LLVMbugs] [Bug 8932] "opt -O3" goes into an infinite loop with the attached IR In-Reply-To: References: Message-ID: <20110116080938.F32292A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8932 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-01-16 02:09:38 CST --- Fixed in r123574, thanks for the report. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 16 02:14:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 02:14:24 -0600 (CST) Subject: [LLVMbugs] [Bug 8391] Dependency file name ".d" files In-Reply-To: References: Message-ID: <20110116081424.3BF052A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8391 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-01-16 02:14:23 CST --- Makes sense, applied in r123576. Thanks for the patch! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 16 02:48:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 02:48:25 -0600 (CST) Subject: [LLVMbugs] [Bug 8514] Assertion `isReg() && "This is not a register operand!"' failed. In-Reply-To: References: Message-ID: <20110116084825.842D82A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8514 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2011-01-16 02:48:24 CST --- Fixed in r123578, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 16 02:50:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 02:50:51 -0600 (CST) Subject: [LLVMbugs] [Bug 8561] LLVM miscompiles a function from Wine In-Reply-To: References: Message-ID: <20110116085051.CB5DB2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8561 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2011-01-16 02:50:50 CST --- Hi Charles. I'd like to investigate this, but the testcase is invalid. $ llc mmap.ll -o - llc: mmap.ll:64:1: error: expected instruction opcode } ^ after fixing that: $ llc mmap.ll -o - llc: mmap.ll:38:13: error: use of undefined value '@wine_mmap_add_reserved_area' call void @wine_mmap_add_reserved_area(i8* %addr, i32 %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 Sun Jan 16 11:33:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 11:33:03 -0600 (CST) Subject: [LLVMbugs] [Bug 8972] Clean installation of LNT hits internal server error, python stack attached In-Reply-To: References: Message-ID: <20110116173303.0862F2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8972 Daniel Dunbar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Daniel Dunbar 2011-01-16 11:33:02 CST --- Fixed here: http://llvm.org/viewvc/llvm-project?view=rev&revision=123588 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 12:23:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 12:23:04 -0600 (CST) Subject: [LLVMbugs] [Bug 8927] Invalid constant merging In-Reply-To: References: Message-ID: <20110116182304.7E3F22A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8927 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 16 12:47:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 12:47:20 -0600 (CST) Subject: [LLVMbugs] [Bug 8984] New: inline assembly warnings are treated as errors Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8984 Summary: inline assembly warnings are treated as errors Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: cdavis at mymail.mines.edu CC: llvmbugs at cs.uiuc.edu A simple test case with this unimplemented CFI directive: $ cat inline-asm.c asm(".cfi_adjust_cfa_offset 4\n\t"); produces this: $ clang -c inline-asm.c :1:1: error: warning: ignoring directive for now .cfi_adjust_cfa_offset 4 ^ 1 error generated. It's clearly a warning, yet clang reports it as an error. Aside from the obvious point that someone needs to finish up CFI support, I don't think that warnings should be reported as errors unless -Werror gets passed to the compiler. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 16 13:37:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 13:37:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8985] New: Shared library builds but doesn't work on Mac OS X 10.6 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8985 Summary: Shared library builds but doesn't work on Mac OS X 10.6 Product: Build scripts Version: 2.8 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Makefiles AssignedTo: unassignedbugs at nondot.org ReportedBy: ronaldoferraz at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6007) --> (http://llvm.org/bugs/attachment.cgi?id=6007) Makefile.rules patch for Mac OS X 10.6 Using ./configure --enable-shared compiles cleanly but as soon as one tries to load the library--for example, in Ruby using FFI--the following error is generated. dyld: loaded: /Users//llvm/2.8/lib/libLLVM-2.8.dylib dyld: lazy symbol binding failed: Symbol not found:__ZN4llvm2cl6Option11addArgumentEv Referenced from: /Users//llvm/2.8/lib/libLLVM-2.8.dylib Expected in: flat namespace dyld: Symbol not found: __ZN4llvm2cl6Option11addArgumentEv Referenced from: /Users//llvm/2.8/lib/libLLVM-2.8.dylib Expected in: flat namespace Trace/BPT trap Applying the attached patch fixes the problem. The modified options use the default two-level namespace on OS X and change name resolution to run time lookup. The library compiles cleanly and loads properly with those options. Using those options doesn't seem to have any ill effect but maybe there's a reason why the former options were used, although many dynamic libraries for Mac OS X are compiled with the latter--the former actually seems to be a legacy from pre-10.3 days. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 14:51:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 14:51:54 -0600 (CST) Subject: [LLVMbugs] [Bug 8561] LLVM miscompiles a function from Wine In-Reply-To: References: Message-ID: <20110116205154.6B45E2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8561 Charles Davis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #3 from Charles Davis 2011-01-16 14:51:54 CST --- The problem is still present in trunk, by the way. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 16 15:02:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 15:02:21 -0600 (CST) Subject: [LLVMbugs] [Bug 8986] New: earlyclobber is broken Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8986 Summary: earlyclobber is broken Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Register Allocator AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6009) --> (http://llvm.org/bugs/attachment.cgi?id=6009) Testcase Consider the attached testcase. Running "as" on the output file causes: /home/asl/test.s:2622: Rd and Rm should be different in mul and indeed the output and on of the input regs are same, however the output reg is marked as earlyclobber for the instruction (MULv5 in this case). Seems like the problem appears late, since initial register allocation 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 Sun Jan 16 15:04:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 15:04:04 -0600 (CST) Subject: [LLVMbugs] [Bug 8987] New: ARM ConstantIsland pass is not always correct Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8987 Summary: ARM ConstantIsland pass is not always correct Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6010) --> (http://llvm.org/bugs/attachment.cgi?id=6010) Testcase Consider the attached testcase. We're having: /home/asl/test.s:3096: Error: bad immediate value for offset (4096) /home/asl/test.s:3288: Error: bad immediate value for offset (4100) /home/asl/test.s:4094: Error: bad immediate value for offset (4100) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 15:29:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 15:29:10 -0600 (CST) Subject: [LLVMbugs] [Bug 8987] ARM ConstantIsland pass is not always correct In-Reply-To: References: Message-ID: <20110116212910.120BB2A6C139@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8987 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Anton Korobeynikov 2011-01-16 15:29:09 CST --- Fixed in r123598 Maybe we should assert on zero-sized pseudos? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 17:21:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 17:21:14 -0600 (CST) Subject: [LLVMbugs] [Bug 8988] New: opt -analyze -indvars -scalar-evolution crashes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8988 Summary: opt -analyze -indvars -scalar-evolution crashes Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6014) --> (http://llvm.org/bugs/attachment.cgi?id=6014) testcase The attached testcase crashes during SCEV printing because SCEV dereferences the LoopInfo* which has already been freed, even though it was declared as addRequiredTransitive. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 17:41:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 17:41:06 -0600 (CST) Subject: [LLVMbugs] [Bug 8989] New: Assertion `I != r2iMap_.end() && "Interval does not exist for register"' failed when -fcatch-undefined-behavior is used Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8989 Summary: Assertion `I != r2iMap_.end() && "Interval does not exist for register"' failed when -fcatch-undefined-behavior is used Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu regehr at home:~/volatile/bugs/tmp345$ clang -c -O1 -fcatch-undefined-behavior small.c -w clang: /mnt/z/z/compiler-build/llvm-r123579/include/llvm/CodeGen/LiveIntervalAnalysis.h:96: llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int): Assertion `I != r2iMap_.end() && "Interval does not exist for register"' failed. 0 clang 0x09492668 Stack dump: 0. Program arguments: /mnt/z/z/compiler-install/llvm-gcc-r123579-install/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.20.51 -resource-dir /mnt/z/z/compiler-install/llvm-gcc-r123579-install/bin/../lib/clang/2.9 -O1 -w -ferror-limit 19 -fmessage-length 80 -fcatch-undefined-behavior -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'small.c'. 4. Running pass 'Simple Register Coalescing' on function '@func_39' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) regehr at home:~/volatile/bugs/tmp345$ clang -v clang version 2.9 (trunk 123579) Target: i386-pc-linux-gnu Thread model: posix regehr at home:~/volatile/bugs/tmp345$ cat small.c struct S0 { int f1; int f3; unsigned char f5; }; int safe (int); struct S0 func_39 (const int * p_40, int * p_41, int * const const uint32p_43) { unsigned char l_46[1][10]; if (safe (0)) { } else { struct S0 l_60 = { 1L, 8L }; if (*p_40) return l_60; else for (l_60.f5 = 0; l_60.f5 < 1; l_60.f5 += 1) for (l_60.f1 = 0; l_60.f1 < 1; l_60.f1 += 1) l_46[l_60.f5][l_60.f1]; } struct S0 l_60 = { 1L, 8L }; return l_60; } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 19:51:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 19:51:15 -0600 (CST) Subject: [LLVMbugs] [Bug 8990] New: disabling plugin support on the configure stage (MSYS+MinGW) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8990 Summary: disabling plugin support on the configure stage (MSYS+MinGW) Product: clang Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: asmwarrior at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, my I run the configure command under MSYS and MinGW, I received a warning below: configure: WARNING: dlopen() not found - disabling plugin support I think it is true that dlopen is not found under windows system, there are some other functions like: LoadLibrary() under Windows. So, this is a bug. thanks. asmwarrior ollydbg from codeblocks' forum. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 19:53:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 19:53:57 -0600 (CST) Subject: [LLVMbugs] [Bug 8988] opt -analyze -indvars -scalar-evolution crashes In-Reply-To: References: Message-ID: <20110117015357.14D282A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8988 Tobias Grosser changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |grosser at fim.uni-passau.de Resolution| |DUPLICATE --- Comment #1 from Tobias Grosser 2011-01-16 19:53:56 CST --- This seems to be a duplicate. *** This bug has been marked as a duplicate of bug 8037 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 16 23:12:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 16 Jan 2011 23:12:08 -0600 (CST) Subject: [LLVMbugs] [Bug 8991] New: Early-CSE is not idempotent Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8991 Summary: Early-CSE is not idempotent Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Running the Early-CSE several times in succession results in more simplifications than running it once, for example: $ opt -disable-output -stats gcc.bc -early-cse ===-------------------------------------------------------------------------=== ... Statistics Collected ... ===-------------------------------------------------------------------------=== 24 early-cse - Number of call instructions CSE'd 190990 early-cse - Number of instructions CSE'd 68115 early-cse - Number of instructions simplified or DCE'd 44538 early-cse - Number of load instructions CSE'd 140 early-cse - Number of trivial dead stores removed 2 instsimplify - Number of expansions 31 instsimplify - Number of reassociations $ opt -disable-output -stats gcc.bc -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse -early-cse ===-------------------------------------------------------------------------=== ... Statistics Collected ... ===-------------------------------------------------------------------------=== 24 early-cse - Number of call instructions CSE'd 190993 early-cse - Number of instructions CSE'd 70166 early-cse - Number of instructions simplified or DCE'd 44587 early-cse - Number of load instructions CSE'd 176 early-cse - Number of trivial dead stores removed 18 instsimplify - Number of expansions 271 instsimplify - Number of reassociations That's about a 3% increase in "Number of instructions simplified or DCE'd" and a 25% increase in "Number of trivial dead stores removed". My guess is that when an instruction is CSE'd/simplified, its uses are not being revisited/recursively CSE'd/simplified. I think this can only occur in loops when uses occur before the 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 Mon Jan 17 04:26:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 Jan 2011 04:26:32 -0600 (CST) Subject: [LLVMbugs] [Bug 8992] New: cout destruction prints garbage Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8992 Summary: cout destruction prints garbage Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu This is on debian-x64 testing. Whenever I output anything through cout, at the end of the program, when running the global destructors, the program outputs a few lines of garbage. This happens whether I compile libc++ with g++ or clang++. #include int main(){std::cout<<'\n';} -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 17 04:34:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 Jan 2011 04:34:15 -0600 (CST) Subject: [LLVMbugs] [Bug 8993] New: Constant string codegen broken by r123585 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8993 Summary: Constant string codegen broken by r123585 Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: devlists at shadowlab.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6016) --> (http://llvm.org/bugs/attachment.cgi?id=6016) simple sample file ?123585 by rafael, 18:19 Only put unnamed_addr constants in mergeable sections. Fixes PR8297. Modified /llvm/trunk/lib/Target/TargetLoweringObjectFile.cpp? After this commit, most C string end up in the data segment instead of text segment, just like if the compiler was invoked with -fwritable-string. This is a important issue as it break CFString and constant obj-c string codegen with clang. When trying to link any object compiled after this change, the linker emit this warning for each object that contains constant CF/NSString. ld: warning: -fwritable-strings not compatible with literal CF/NSString in /WBAEFunctions.o And here is a sample of the assembly generated before and after this change: ----------- before: .section __TEXT,__cstring,cstring_literals L_.str: ## @.str .asciz "Hello World" ----------- after: .section __DATA,__data L_.str: ## @.str .asciz "Hello World" I attached a sample file used to generate this assembly and the result before and after the change. I simply use "clang -S" to compile this file. Note: the default target is x86_64-apple-darwin10 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 07:14:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 Jan 2011 07:14:29 -0600 (CST) Subject: [LLVMbugs] [Bug 8994] New: Constant prop fails on vector code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8994 Summary: Constant prop fails on vector code Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: boaz.ouriel at intel.com CC: llvmbugs at cs.uiuc.edu The instruction combine pass carshes when trying to fold a bitcast from a vector type to a scalar type. Reproduce with: define i48 @test(<3 x i1> %icmp1, <3 x i1> %icmp2, i16 addrspace(1)* %dst) nounwind { entry: %select1 = select <3 x i1> %icmp1, <3 x i16> zeroinitializer, <3 x i16> %select2 = select <3 x i1> %icmp2, <3 x i16> zeroinitializer, <3 x i16> %select1 %tmp2 = bitcast <3 x i16> %select2 to i48 ret i48 %tmp2 } here's a fix: Index: InstructionCombining.cpp =================================================================== --- InstructionCombining.cpp (revision xxx) +++ InstructionCombining.cpp (revision xxx) @@ -221,6 +221,12 @@ Instruction *InstCombiner::FoldOpIntoSelect(Instruction &Op, SelectInst *SI) { // Don't modify shared select instructions if (!SI->hasOneUse()) return 0; + + // we cannot fold bitcasts which transform a vector to scalars + if ( BitCastInst* BI = dyn_cast(&Op) ) { + if ( BI->getSrcTy()->isVectorTy() ) return 0; + } + Value *TV = SI->getOperand(1); Value *FV = SI->getOperand(2); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 17 08:39:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 Jan 2011 08:39:34 -0600 (CST) Subject: [LLVMbugs] [Bug 8995] New: Simple valid C++ program failing to compile Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8995 Summary: Simple valid C++ program failing to compile Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following program, reduced from many boost testcases, is currently failing to compile. I'm fairly sure it is simple valid code: namespace { struct ios_base { struct Init { Init(); }; }; ios_base::Init __ioinit; } Fails on a debug compile of: clang version 2.9 (trunk 123621) Target: x86_64-unknown-linux-gnu Thread model: posix With: clang: MachineFunction.cpp:569: unsigned int llvm::MachineJumpTableInfo::getEntryAlignment(const llvm::TargetData&) const: Assertion `0 && "Unknown jump table encoding!"' failed. 0 clang 0x0000000002314e21 1 clang 0x0000000002314c14 2 libpthread.so.0 0x00007f4074d928f0 3 libc.so.6 0x00007f4074081a75 gsignal + 53 4 libc.so.6 0x00007f40740855c0 abort + 384 5 libc.so.6 0x00007f407407a941 __assert_fail + 241 6 clang 0x0000000001e3905e llvm::MachineJumpTableInfo::getEntryAlignment(llvm::TargetData const&) const + 140 7 clang 0x0000000001da0c61 llvm::AsmPrinter::EmitJumpTableInfo() + 449 8 clang 0x0000000001d9f83f llvm::AsmPrinter::EmitFunctionBody() + 2475 9 clang 0x0000000001b461e1 10 clang 0x0000000001e3e7e9 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95 11 clang 0x000000000224109f llvm::FPPassManager::runOnFunction(llvm::Function&) + 407 12 clang 0x00000000022412bc llvm::FPPassManager::runOnModule(llvm::Module&) + 102 13 clang 0x00000000022415ef llvm::MPPassManager::runOnModule(llvm::Module&) + 459 14 clang 0x0000000002241aed llvm::PassManagerImpl::run(llvm::Module&) + 125 15 clang 0x0000000002242043 llvm::PassManager::run(llvm::Module&) + 39 16 clang 0x00000000010e292c 17 clang 0x00000000010e29fd clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 133 18 clang 0x00000000010de796 19 clang 0x00000000012364fb clang::ParseAST(clang::Sema&, bool) + 639 20 clang 0x0000000000fa88f5 clang::ASTFrontendAction::ExecuteAction() + 263 21 clang 0x00000000010df61d clang::CodeGenAction::ExecuteAction() + 951 22 clang 0x0000000000fa8546 clang::FrontendAction::Execute() + 320 23 clang 0x0000000000f91197 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 751 24 clang 0x0000000000f3eb19 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 854 25 clang 0x0000000000f30de9 cc1_main(char const**, char const**, char const*, void*) + 1032 26 clang 0x0000000000f3a0d4 main + 499 27 libc.so.6 0x00007f407406cc4d __libc_start_main + 253 28 clang 0x0000000000f30459 Stack dump: 0. Program arguments: /llvmdebug/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name t.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /llvmdebug/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 199 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 't.cc'. 4. Running pass 'X86 AT&T-Style Assembly Printer' on function '@__cxx_global_var_init' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 17 10:31:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 Jan 2011 10:31:50 -0600 (CST) Subject: [LLVMbugs] [Bug 8993] Constant string codegen broken by r123585 In-Reply-To: References: Message-ID: <20110117163150.A71862A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8993 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Rafael ?vila de Esp?ndola 2011-01-17 10:31:50 CST --- Fixed in 123658. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 16:12:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 Jan 2011 16:12:04 -0600 (CST) Subject: [LLVMbugs] [Bug 6394] Optimizer swaps bitcast and getelementptr in an invalid way In-Reply-To: References: Message-ID: <20110117221204.E340C2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6394 Henning Thielemann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | --- Comment #10 from Henning Thielemann 2011-01-17 16:12:03 CST --- I have snooped the calls to LLVM of my Haskell program using ltrace and turned the output into a stand-alone C program. Attached is this program that should work like 'opt -O1'. It reads a Bitcode file from stdin, sets target data and writes back to stdout. If I do not set target data, the optimized code is correct. I have not written the Haskell code that calls the LLVMAddTargetData function, but I could remove it, if this is wrong. Nevertheless I wonder, why setting the target data this way makes the optimizer go wrong and I wonder, why I can set arbitrary strings like "foobar" that yield the same optimizer misbehaviour. I think either LLVMCreateTargetData or LLVMAddTargetData should at least have an assert for nonsense strings. Here is how I get the results: $ cat opt64.ll %wrap = type { float, <4 x float>* } define void @_myfree(float*) { _L1: %1 = bitcast float* %0 to %wrap* %2 = getelementptr %wrap* %1, i32 0, i32 1 %3 = load <4 x float>** %2 free <4 x float>* %3 ret void } $ llvm-as -f opt64.ll $ gcc -lLLVM-2.8rc `llvm-config --cflags` -o opt64simplec opt64simplec.c $ opt64simplec opt64-opt.bc $ llvm-dis -o opt64-opt-dis.ll -f opt64-opt.bc $ cat pt64-opt-dis.ll ; ModuleID = 'opt64-opt.bc' define void @_myfree(float* nocapture) nounwind { _L1: %1 = getelementptr float* %0, i64 2 %2 = bitcast float* %1 to <4 x float>** %3 = load <4 x float>** %2, align 8 %4 = bitcast <4 x float>* %3 to i8* tail call void @free(i8* %4) ret void } declare void @free(i8* nocapture) nounwind -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 17 18:38:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 Jan 2011 18:38:32 -0600 (CST) Subject: [LLVMbugs] [Bug 6394] Optimizer swaps bitcast and getelementptr in an invalid way In-Reply-To: References: Message-ID: <20110118003832.AF3232A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6394 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #12 from Chris Lattner 2011-01-17 18:38:31 CST --- It is reasonable to expect frontends to provide a valid target triple. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 17 23:39:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 Jan 2011 23:39:54 -0600 (CST) Subject: [LLVMbugs] [Bug 8996] New: SPARC backend crashes when emitting dwarf debug information from dbg_value Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8996 Summary: SPARC backend crashes when emitting dwarf debug information from dbg_value Product: new-bugs Version: trunk Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: venkatra at cs.wisc.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6019) --> (http://llvm.org/bugs/attachment.cgi?id=6019) testcase When generating code for the attached file, SPARC backend crashes. (See below) The crash occurs because DwarfDebug::addVariableAddress calls TFI->getFrameIndexReference() with the immediate value from a DBG_VALUE instruction. But the frame index is already eliminated by the PEI pass. llc -march=sparc test/CodeGen/SPARC/bugpoint-reduced-simplified.ll llc: ../llvm/include/llvm/CodeGen/MachineFrameInfo.h:373: int64_t llvm::MachineFrameInfo::getObjectOffset(int) const: Assertion `unsigned(ObjectIdx+NumFixedObjects) < Objects.size() && "Invalid Object Idx!"' failed. 1 llc 0x000000000133fb0c 2 libpthread.so.0 0x000000344bc0eb10 3 libc.so.6 0x000000344b030265 gsignal + 53 4 libc.so.6 0x000000344b031d10 abort + 272 5 libc.so.6 0x000000344b0296e6 __assert_fail + 246 6 llc 0x0000000000a0b608 llvm::MachineFrameInfo::getObjectOffset(int) const + 94 7 llc 0x00000000011af86d llvm::TargetFrameLowering::getFrameIndexOffset(llvm::MachineFunction const&, int) const + 45 8 llc 0x00000000011af722 llvm::TargetFrameLowering::getFrameIndexReference(llvm::MachineFunction const&, int, unsigned int&) const + 112 9 llc 0x0000000000ebdf2d llvm::DwarfDebug::addVariableAddress(llvm::DbgVariable*&, llvm::DIE*, long) + 113 10 llc 0x0000000000ebe546 llvm::DwarfDebug::constructVariableDIE(llvm::DbgVariable*, llvm::DbgScope*) + 1424 11 llc 0x0000000000ebe99e llvm::DwarfDebug::constructScopeDIE(llvm::DbgScope*) + 604 12 llc 0x0000000000ebea02 llvm::DwarfDebug::constructScopeDIE(llvm::DbgScope*) + 704 13 llc 0x0000000000ebee64 llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) + 972 14 llc 0x0000000000eab6a4 llvm::AsmPrinter::EmitFunctionBody() + 2080 15 llc 0x0000000000a082e1 llvm::AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 47 16 llc 0x0000000000f41e8b llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85 17 llc 0x0000000001279ce2 llvm::FPPassManager::runOnFunction(llvm::Function&) + 350 18 llc 0x0000000001279eb7 llvm::FPPassManager::runOnModule(llvm::Module&) + 81 19 llc 0x00000000012799a3 llvm::MPPassManager::runOnModule(llvm::Module&) + 381 20 llc 0x000000000127b133 llvm::PassManagerImpl::run(llvm::Module&) + 111 21 llc 0x000000000127b195 llvm::PassManager::run(llvm::Module&) + 33 22 llc 0x00000000009970e7 main + 2201 23 libc.so.6 0x000000344b01d994 __libc_start_main + 244 24 llc 0x0000000000995949 Stack dump: 0. Program arguments: llc -march=sparc 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'Sparc Assembly Printer' on function '@CheckReliabilityOfRef' Aborted -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 17 23:58:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 17 Jan 2011 23:58:05 -0600 (CST) Subject: [LLVMbugs] [Bug 8997] New: grammatical error in Source Level Debugging doc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8997 Summary: grammatical error in Source Level Debugging doc Product: Documentation Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: eliben at gmail.com CC: llvmbugs at cs.uiuc.edu in http://llvm.org/docs/SourceLevelDebugging.html The last sentence of the Introduction says: Further, this document provides specific examples of what debug information for C/C++. Doesn't look grammatical :-) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 00:12:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 00:12:23 -0600 (CST) Subject: [LLVMbugs] [Bug 8997] grammatical error in Source Level Debugging doc In-Reply-To: References: Message-ID: <20110118061223.CF5DB2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8997 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-01-18 00:12:23 CST --- Fixed in r123750, thanks -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 18 04:57:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 04:57:33 -0600 (CST) Subject: [LLVMbugs] [Bug 8998] New: Assert valid target data string in LLVMCreateTargetData Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8998 Summary: Assert valid target data string in LLVMCreateTargetData Product: libraries Version: 2.8 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P Component: Target Description Classes AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm at henning-thielemann.de CC: llvmbugs at cs.uiuc.edu, llvm at henning-thielemann.de Please add an assert to LLVMCreateTargetData (i.e. the C++ function that it calls), that checks whether the input string is correct. It seems that there is no way to find out, if an input string is actually valid. If I pass "nonsense" I get a non-NULL pointer as result (that is, the TargetDataRef does not show me, that the input was wrong), and if I pass that to LLVMAddTargetData then things go silently wrong in a very awful way. See ticket #6394 for an example. http://llvm.org/bugs/show_bug.cgi?id=6394 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 05:15:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 05:15:23 -0600 (CST) Subject: [LLVMbugs] [Bug 8999] New: How to find out the target triple and target data of the host machine via C bindings? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8999 Summary: How to find out the target triple and target data of the host machine via C bindings? Product: Documentation Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm at henning-thielemann.de CC: llvmbugs at cs.uiuc.edu, llvm at henning-thielemann.de Please describe how to find out the information needed to let the optimizer work correct and adapted to the host machine when run via the C bindings to LLVM. I'll attach a C program that creates a small function, that shall be run in the JIT. As far as I understand, if I do not tell the target data to PassManager, then I get only generic optimizations. If I set the target data to something invalid (as in the outcommented AddTargetData) the optimizer even performs silently optimizations that are invalid for the host machine. (See http://llvm.org/bugs/show_bug.cgi?id=6394 for details.) Thus: How do I tell the LLVM optimizer to optimize with respect to the host, where I like to run the function in the JIT later? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 18 06:28:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 06:28:04 -0600 (CST) Subject: [LLVMbugs] [Bug 6394] Optimizer swaps bitcast and getelementptr in an invalid way In-Reply-To: References: Message-ID: <20110118122805.6401F2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6394 Henning Thielemann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #13 from Henning Thielemann 2011-01-18 06:28:04 CST --- > It is reasonable to expect frontends to provide a valid target triple. Why is it wrong to pass the result of LLVMGetDataLayout(module) to LLVMAddTargetData? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 11:11:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 11:11:43 -0600 (CST) Subject: [LLVMbugs] [Bug 6394] Optimizer swaps bitcast and getelementptr in an invalid way In-Reply-To: References: Message-ID: <20110118171143.47B5A2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6394 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #14 from Chris Lattner 2011-01-18 11:11:42 CST --- Because your module doesn't have target data, so you're passing an empty string. You need get get a valid target data string from somewhere, this is what the frontend is responsible for. Please don't keep reopening this bug. If you'd like to start a discussion, please take it to llvmdev. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 11:11:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 11:11:48 -0600 (CST) Subject: [LLVMbugs] [Bug 6394] Optimizer swaps bitcast and getelementptr in an invalid way In-Reply-To: References: Message-ID: <20110118171148.90BD82A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6394 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |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 Tue Jan 18 11:41:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 11:41:18 -0600 (CST) Subject: [LLVMbugs] [Bug 9000] New: enums are classified as unsigned ints instead of signed ones Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9000 Summary: enums are classified as unsigned ints instead of signed ones Product: clang Version: unspecified Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rdivacky at freebsd.org CC: llvmbugs at cs.uiuc.edu typedef enum { X, Y } foo; int main(int argc, char **argv) { foo z; return (z >= 0); } the LHS of (z >= 0) is (gdb) p E->getLHS()->dump() (ImplicitCastExpr 0x801897ee0 'unsigned int' (ImplicitCastExpr 0x801897ec0 'foo':'foo' (DeclRefExpr 0x801897e60 'foo':'foo' lvalue Var='z' 0x801897df0))) cast to "unsigned int" is wrong in my opinion. it should be "int". this has the side effect of this bogus warning: enum.c:9:13: warning: comparison of unsigned enum expression >= 0 is always 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 Tue Jan 18 11:52:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 11:52:03 -0600 (CST) Subject: [LLVMbugs] [Bug 9001] New: clang should warn if |= is used without parens in an if / while Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9001 Summary: clang should warn if |= is used without parens in an if / while Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Clang currently warns about if (a = b) and suggests parentheses if the assignment is really what the author intended. It should do the same for if (a |= b) This would have caught this bug: http://codereview.chromium.org/6320005/diff/1/chrome/browser/tab_contents/thumbnail_generator.cc -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 18 12:26:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 12:26:22 -0600 (CST) Subject: [LLVMbugs] [Bug 9002] New: llvm configure thinks clang is dragonegg Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9002 Summary: llvm configure thinks clang is dragonegg Product: Build scripts Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: autoconf AssignedTo: unassignedbugs at nondot.org ReportedBy: dpatel at apple.com CC: llvmbugs at cs.uiuc.edu If I configure llvm using --with-llvmgcc=clang --with-llvmgxx=clang++, the configuration scripts detects the clang compiler as dragonegg compiler! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 18 12:47:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 12:47:59 -0600 (CST) Subject: [LLVMbugs] [Bug 9000] enums are classified as unsigned ints instead of signed ones In-Reply-To: References: Message-ID: <20110118184759.405592A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9000 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Resolution| |INVALID --- Comment #1 from Douglas Gregor 2011-01-18 12:47:58 CST --- This is behaving correctly per C99 6.7.2.2p2, which allows the implementation to pick char or any signed or unsigned integer type as the underlying type. GCC and Clang pick "unsigned int" (which is fine), which ends up promoting to itself. In C++, it promotes to an int. See Clang's test/CodeGen/enum.c for a fun example where C and C++ produce different results because of the different promotion rules. Because of the (admittedly weird) behavior of C, this warning is not spurious: z really is treated as an unsigned value, and that can both be surprising and lead to bugs if the programmer doesn't understand it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 18 13:48:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 13:48:12 -0600 (CST) Subject: [LLVMbugs] [Bug 8995] Simple valid C++ program failing to compile In-Reply-To: References: Message-ID: <20110118194812.CBD432A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8995 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #6 from Christopher Jefferson 2011-01-18 13:48:12 CST --- I just totally blasted away my svn checkout of clang and started again from scratch. That seems to have cleared up the problem. I had previously done a 'make clean', and 'svn status' wasn't showing anything in either the base directory, or tools/clang, so I'm not sure what was causing the problem. Sorry for the time wasting. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 14:29:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 14:29:12 -0600 (CST) Subject: [LLVMbugs] [Bug 9003] New: Invalid code involving decltype causes assertion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9003 Summary: Invalid code involving decltype causes assertion Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 18 15:52:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 18 Jan 2011 15:52:54 -0600 (CST) Subject: [LLVMbugs] [Bug 8658] clang doesn't ignore '/' comments in assembler .s files In-Reply-To: References: Message-ID: <20110118215254.2795D2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8658 ojab changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #13 from ojab 2011-01-18 15:52:53 CST --- binutils docs was fixed (not behaviour), should this bug still be WONTFIX? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 19 09:25:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 09:25:28 -0600 (CST) Subject: [LLVMbugs] [Bug 9004] New: GVN correlated expressions handles the hard case but not the easy case! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9004 Summary: GVN correlated expressions handles the hard case but not the easy case! Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Run "opt -gvn" on the following testcase. It gets that "ret i1 %cond2" returns false, but it doesn't see that the a priori easier "ret i1 %cond" returns true! define i1 @foo(i32 %x) { %cond = icmp eq i32 %x, 0 br i1 %cond, label %iftrue, label %iffalse iftrue: ret i1 %cond iffalse: %cond2 = icmp eq i32 %x, 0 ret i1 %cond2 } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 10:56:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 10:56:32 -0600 (CST) Subject: [LLVMbugs] [Bug 9001] clang should warn if |= is used without parens in an if / while In-Reply-To: References: Message-ID: <20110119165632.6D9DA2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9001 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Hans Wennborg 2011-01-19 10:56:32 CST --- Fixed in r123836. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 12:04:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 12:04:40 -0600 (CST) Subject: [LLVMbugs] [Bug 9005] New: mangled docs for -fcolor-diagnostics Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9005 Summary: mangled docs for -fcolor-diagnostics Product: clang Version: trunk Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P Component: Documentation AssignedTo: unassignedclangbugs at nondot.org ReportedBy: zilla at kayari.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6023) --> (http://llvm.org/bugs/attachment.cgi?id=6023) demangle docs The online UsersManual has a missing example for -f[no-]color-diagnostics, caused by some bad markup, and part of the example is shown on the previous option. Fixed by the attached patch -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 19 16:18:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 16:18:04 -0600 (CST) Subject: [LLVMbugs] [Bug 5893] implement variadic templates In-Reply-To: References: Message-ID: <20110119221804.ABBA92A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=5893 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #10 from Douglas Gregor 2011-01-19 16:18:02 CST --- Implemented in Clang r123854. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 17:20:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 17:20:47 -0600 (CST) Subject: [LLVMbugs] [Bug 9006] New: Boost.Python def_readonly broken on trunk Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9006 Summary: Boost.Python def_readonly broken on trunk Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: luc_j_bourhis at mac.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6025) --> (http://llvm.org/bugs/attachment.cgi?id=6025) Preprocessed boost_python_ext.cpp ~/Developer/Tests/clang-def_readonly> clang++ --version clang version 2.9 (trunk 123848) Target: x86_64-apple-darwin10 Thread model: posix ~/Developer/Tests/clang-def_readonly> cat boost_python_ext.cpp #include using namespace boost::python; template struct simple { T x; }; void wrap() { class_ >("simple", no_init) .def_readonly("x", &simple<>::x) ; } ~/Developer/Tests/clang-def_readonly> clang++ -I$cctbxroot/boost -I/System/Library/Frameworks/Python.framework/Headers -c boost_python_ext.cpp In file included from boost_python_ext.cpp:1: /Users/luc/Developer/cctbx/boost/boost/python/class.hpp:469:22: error: call to member function 'add_property' is ambiguous return this->add_property(name, pm_, doc); ~~~~~~^~~~~~~~~~~~ /Users/luc/Developer/cctbx/boost/boost/python/class.hpp:282:16: note: in instantiation of function template specialization 'boost::python::class_, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>::def_readonly_impl >' requested here return this->def_readonly_impl(name, d, doc BOOST_PYTHON_DATA_MEMBER_HELPER(D)); ^ boost_python_ext.cpp:12:3: note: in instantiation of function template specialization 'boost::python::class_, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>::def_readonly::*>' requested here class_ >("simple", no_init) ^ In file included from boost_python_ext.cpp:1: /Users/luc/Developer/cctbx/boost/boost/python/class.hpp:306:11: note: candidate function [with Get = double simple::*] self& add_property(char const* name, Get fget, char const* docstr = 0) ^ /Users/luc/Developer/cctbx/boost/boost/python/class.hpp:313:11: note: candidate function [with Get = double simple::*, Set = const char *] self& add_property(char const* name, Get fget, Set fset, char const* docstr = 0) ^ 1 error generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 19 17:55:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 17:55:36 -0600 (CST) Subject: [LLVMbugs] [Bug 9006] Boost.Python def_readonly broken on trunk In-Reply-To: References: Message-ID: <20110119235536.876C62A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9006 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-01-19 17:55:36 CST --- Fixed in Clang r123861. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 20:06:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 20:06:42 -0600 (CST) Subject: [LLVMbugs] [Bug 9007] New: crash on invalid? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9007 Summary: crash on invalid? Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following testcase crashes clang: struct bar { enum xxx { yyy = sizeof(struct foo*) }; foo *xxx(); }; 0 clang 0x0000000100ff6e42 PrintStackTrace(void*) + 34 1 clang 0x0000000100ff73e9 SignalHandler(int) + 857 2 libSystem.B.dylib 0x00007fff80ed867a _sigtramp + 26 3 libSystem.B.dylib 0x00007fff5fbfb5d8 _sigtramp + 3738316664 4 clang 0x000000010001aa96 abort + 22 5 clang 0x000000010001aa58 __assert_rtn + 56 6 clang 0x0000000100271e43 HasAccess(clang::Sema&, (anonymous namespace)::EffectiveContext const&, clang::CXXRecordDecl const*, clang::AccessSpecifier, (anonymous namespace)::AccessTarget const&) + 1123 7 clang 0x000000010026e98c CheckEffectiveAccess(clang::Sema&, (anonymous namespace)::EffectiveContext const&, clang::SourceLocation, (anonymous namespace)::AccessTarget&) + 284 8 clang 0x000000010026ff52 CheckAccess(clang::Sema&, clang::SourceLocation, (anonymous namespace)::AccessTarget&) + 690 9 clang 0x0000000100271820 clang::Sema::CheckLookupAccess(clang::LookupResult const&) + 320 10 clang 0x0000000100274e03 clang::LookupResult::~LookupResult() + 83 .... -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 19 20:28:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 20:28:33 -0600 (CST) Subject: [LLVMbugs] [Bug 8884] Surprising behavior with 'friend' and 'extern "C"' In-Reply-To: References: Message-ID: <20110120022833.B2BB82A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8884 Rafael ?vila de Esp?ndola 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 Wed Jan 19 21:03:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 21:03:47 -0600 (CST) Subject: [LLVMbugs] [Bug 9007] crash on invalid? In-Reply-To: References: Message-ID: <20110120030347.6FDCB2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9007 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Rafael ?vila de Esp?ndola 2011-01-19 21:03:47 CST --- This was fixed by 123871 too. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 19 23:25:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 19 Jan 2011 23:25:45 -0600 (CST) Subject: [LLVMbugs] [Bug 9008] New: false unused variable warning when variable exclusively used within sizeof Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9008 Summary: false unused variable warning when variable exclusively used within sizeof Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: austinenglish at gmail.com CC: llvmbugs at cs.uiuc.edu // Compile with : // clang -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith test.c #include static const char *blah[] = {"foo"}; #define foobar sizeof(blah) int main(void) { printf("hello world, %lu", foobar); return 0; } Originally noticed when compiling Wine's regedit: clang -m32 -c -I. -I. -I../../include -I../../include -I../../include/msvcrt -DWINE_STRICT_PROTOTYPES -DNO_LIBWINE_PORT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -fno-builtin -o regproc.o regproc.c regproc.c:40:20: warning: unused variable 'reg_class_names' [-Wunused-variable] static const CHAR *reg_class_names[] = { ^ 1 warning generated. relevant code: static const CHAR *reg_class_names[] = { "HKEY_LOCAL_MACHINE", "HKEY_USERS", "HKEY_CLASSES_ROOT","HKEY_CURRENT_CONFIG", "HKEY_CURRENT_USER", "HKEY_DYN_DATA"}; #define REG_CLASS_NUMBER (sizeof(reg_class_names) / sizeof(reg_class_names[0])) austin at midna:~$ clang --version clang version 2.8 (branches/release_28) Target: x86_64-pc-linux-gnu Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 20 00:20:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 00:20:38 -0600 (CST) Subject: [LLVMbugs] [Bug 8989] Assertion `I != r2iMap_.end() && "Interval does not exist for register"' failed when -fcatch-undefined-behavior is used In-Reply-To: References: Message-ID: <20110120062038.4077A2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8989 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Jakob Stoklund Olesen 2011-01-20 00:20:37 CST --- Fixed in r123891. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 20 05:28:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 05:28:23 -0600 (CST) Subject: [LLVMbugs] [Bug 9009] New: Cannot select X86ISD::MOVLPS for v4:i32 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9009 Summary: Cannot select X86ISD::MOVLPS for v4:i32 Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: artiom.myaskouvskey at intel.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6027) --> (http://llvm.org/bugs/attachment.cgi?id=6027) Test for movlps failure In code generation there is missing selection for MOVLPS instruction when 2 sources are VREG and destination is V4I32. To reproduce it run llc from trunk on attached .ll file. Attached are bugpoint reduced test. The fix is rather simple and therefore inlined. Please note that it also addresses the same problem for movddup. Index: lib/Target/X86/X86InstrSSE.td =================================================================== --- lib/Target/X86/X86InstrSSE.td (revision 2546) +++ lib/Target/X86/X86InstrSSE.td (working copy) @@ -5963,6 +5963,9 @@ def : Pat<(v4f32 (X86Movlps VR128:$src1, VR128:$src2)), (MOVSDrr VR128:$src1, (EXTRACT_SUBREG (v4f32 VR128:$src2), sub_sd))>; +def : Pat<(v4i32 (X86Movlps VR128:$src1, VR128:$src2)), + (MOVSDrr VR128:$src1, (EXTRACT_SUBREG (v4i32 VR128:$src2), sub_sd))>; + // Shuffle with MOVLPD def : Pat<(v2f64 (X86Movlpd VR128:$src1, (load addr:$src2))), (MOVLPDrm VR128:$src1, addr:$src2)>; Index: lib/Target/X86/X86InstrSSE.td =================================================================== --- lib/Target/X86/X86InstrSSE.td (revision 2546) +++ lib/Target/X86/X86InstrSSE.td (working copy) @@ -5904,6 +5904,8 @@ (MOVLHPSrr VR128:$src, VR128:$src)>; def : Pat<(v4f32 (X86Movddup VR128:$src)), (MOVLHPSrr VR128:$src, VR128:$src)>; +def : Pat<(v4i32 (X86Movddup VR128:$src)), + (MOVLHPSrr VR128:$src, VR128:$src)>; def : Pat<(v2f64 (X86Movddup VR128:$src)), (UNPCKLPDrr VR128:$src, VR128:$src)>; -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 05:52:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 05:52:27 -0600 (CST) Subject: [LLVMbugs] [Bug 9010] New: Function parameter corruption when using tail call optimization in Windows 64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9010 Summary: Function parameter corruption when using tail call optimization in Windows 64 Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: artiom.myaskouvskey at intel.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6028) --> (http://llvm.org/bugs/attachment.cgi?id=6028) .ll and generated .s file Tail call optimization is erroneously applied in Windows 64. As result stack area which contains function parameters is released (RSP is updated) before the call (replaced by jump in tail call optimization). It may cause to wrong function behavior. See attached .s example. Specifically these 3 lines may explain the problem: lea R8, QWORD PTR [RSP + 32] ; using stack to for parameter storage ... add RSP, 232 ;; Stack is freed and allocated parameter with it jmp testcall # TAILCALL Attached are .ll and .s file generated with latest llc. The simple inlined fix is solves the problem. Index: lib/Target/X86/X86ISelLowering.cpp =================================================================== --- lib/Target/X86/X86ISelLowering.cpp (revision 2609) +++ lib/Target/X86/X86ISelLowering.cpp (working copy) @@ -2501,6 +2501,9 @@ SmallVector ArgLocs; CCState CCInfo(CalleeCC, isVarArg, getTargetMachine(), ArgLocs, *DAG.getContext()); + if (Subtarget->isTargetWin64()) { + CCInfo.AllocateStack(32, 8); + } CCInfo.AnalyzeCallOperands(Outs, CCAssignFnForNode(CalleeCC)); if (CCInfo.getNextStackOffset()) { MachineFunction &MF = DAG.getMachineFunction(); -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 06:08:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 06:08:28 -0600 (CST) Subject: [LLVMbugs] [Bug 9011] New: Constant folding cast for zero vectors is missing Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9011 Summary: Constant folding cast for zero vectors is missing Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: artiom.myaskouvskey at intel.com CC: llvmbugs at cs.uiuc.edu There is missing constant folding of casting operation for vector of 0's. Probably it is due to fact that vector of zeroes is described by ConstantAggregateZero and its handling is missing from ConstantFolding. As result some of the shaders when running with 'opt -std-compile-opts' may run infinitely long time. See attached .ll for example. To reproduce the bug just run attached .ll with 'opt -std-compile-opts' The fix is inlined (due to its simplicity) Index: lib/VMCore/ConstantFold.cpp =================================================================== --- lib/VMCore/ConstantFold.cpp (revision 2460) +++ lib/VMCore/ConstantFold.cpp (working copy) @@ -553,6 +553,9 @@ return ConstantVector::get(DestVecTy, res); } + if (ConstantAggregateZero *CZ = dyn_cast(V)) { + return Constant::getNullValue(DestTy); + } // We actually have to do a cast now. Perform the cast according to the // opcode specified. switch (opc) { -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 06:39:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 06:39:23 -0600 (CST) Subject: [LLVMbugs] [Bug 9012] New: "undef" in conditional branches may lead to assertion failure Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9012 Summary: "undef" in conditional branches may lead to assertion failure Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: philipp.legrum at daimler.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6029) --> (http://llvm.org/bugs/attachment.cgi?id=6029) Patch to fix "undef" in conditional branches may lead to assertion failure There seems to be an issue with the removal of dead blocks in SCCP.cpp. Given a branch/switch instruction with "undef" condition, SCCP takes the first available successor in the list as arbitrary target. In cases where this very target will be removed, an alternate (arbitrary) target should be chosen. Otherwise, this would lead to an assertion to fail later on. Please see the patch for exact code positions. Patch fixes the problem, needs review. Thanks. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 20 09:50:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 09:50:12 -0600 (CST) Subject: [LLVMbugs] [Bug 3652] [cellspu] Missing sign-extend patterns for i128 In-Reply-To: References: Message-ID: <20110120155012.1CA0F2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3652 Kalle Raiskila changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Kalle Raiskila 2011-01-20 09:50:11 CST --- Fixed in 123912. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 10:52:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 10:52:19 -0600 (CST) Subject: [LLVMbugs] [Bug 9013] New: clang hang Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9013 Summary: clang hang Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu This bug appeared during the last week or so. 'clang -O2' loops apparently forever when trying to compile the code below. This is r123879 on x86 Linux. static int foo (int si1, int si2) { return si1 - si2; } void bar (void) { unsigned char l_197; for (;; l_197 = foo (l_197, 1)) ; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 20 15:15:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 15:15:50 -0600 (CST) Subject: [LLVMbugs] [Bug 8037] Pass manager doesn't transitively preserve LoopInfo for ScalarEvolution In-Reply-To: References: Message-ID: <20110120211550.70B102A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8037 Tobias Grosser changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Tobias Grosser 2011-01-20 15:15:48 CST --- Fixed in: http://llvm.org/viewvc/llvm-project?rev=123942&view=rev -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 20 15:38:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 15:38:59 -0600 (CST) Subject: [LLVMbugs] [Bug 9014] New: cannot build ctypes module from Python Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9014 Summary: cannot build ctypes module from Python Product: clang Version: 2.8 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: brett at python.org CC: llvmbugs at cs.uiuc.edu As of LLVM 2.8, clang can no longer build the ctypes module from Python (this has been verified as an issue for Python 2.7, 3.1, and the in-development 3.2). There were no issues with LLVM 2.7. The relevant Python bug is http://bugs.python.org/issue10238 (although there is currently nothing enlightening there). The error output is:: /var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-Sf4aFl.s:153:2: error: unrecognized instruction cmovnz %rax, %rdx ^ /var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-Sf4aFl.s:154:2: error: unrecognized instruction cmovnz %r10, %rax ^ /var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-Sf4aFl.s:156:2: error: unrecognized instruction cmovnz %r10, %rdx ^ /var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-Sf4aFl.s:158:2: error: unrecognized instruction cmovnz %r10, %rax ^ /var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-Sf4aFl.s:159:2: error: unrecognized instruction cmovnz %r11, %rdx ^ /var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-Sf4aFl.s:166:2: error: unrecognized instruction rep movsb ^ /var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-Sf4aFl.s:281:2: error: unrecognized instruction cmovnz %rdx, %rcx ^ /var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-Sf4aFl.s:285:2: error: unrecognized instruction cmovnz %rdx, %rax -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 20 16:22:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 16:22:18 -0600 (CST) Subject: [LLVMbugs] [Bug 9014] cannot build ctypes module from Python In-Reply-To: References: Message-ID: <20110120222218.C98DF2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9014 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-01-20 16:22:18 CST --- This is fixed in LLVM mainline. A workaround for 2.8 is to build with -no-integrated-as. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 16:32:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 16:32:05 -0600 (CST) Subject: [LLVMbugs] [Bug 8970] -Wmissing-noreturn produces a false positive on some constructors In-Reply-To: References: Message-ID: <20110120223205.822332A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8970 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |andersca at mac.com Resolution| |FIXED --- Comment #2 from Anders Carlsson 2011-01-20 16:32:04 CST --- This particular example works fine in ToT now and there is a test case added to the regression test suite. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 20 19:58:53 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 19:58:53 -0600 (CST) Subject: [LLVMbugs] [Bug 9011] Constant folding cast for zero vectors is missing In-Reply-To: References: Message-ID: <20110121015853.B97332A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9011 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Nick Lewycky 2011-01-20 19:58:53 CST --- Fixed in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110117/115540.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 20 20:32:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 20:32:49 -0600 (CST) Subject: [LLVMbugs] [Bug 8994] Constant prop fails on vector code In-Reply-To: References: Message-ID: <20110121023249.9A6142A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8994 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Nick Lewycky 2011-01-20 20:32:49 CST --- Your patch is good but overly aggressive: it would forbid optimizing a select between two <4 x i32>s that are then casted to a <4 x float>. Fixed in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110117/115543.html . Thanks for the bug report, especially with testcase! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 20 21:36:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 21:36:03 -0600 (CST) Subject: [LLVMbugs] [Bug 9015] New: module linking crash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9015 Summary: module linking crash Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Linker AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: dpatel at apple.com, llvmbugs at cs.uiuc.edu Created an attachment (id=6030) --> (http://llvm.org/bugs/attachment.cgi?id=6030) testcase $ llvm-ld -link-as-library -disable-opt gdevmem.bc -o linked.rbc Program received signal SIGSEGV, Segmentation fault. 0x00000000007eaf6e in llvm::PATypeHolder::get (this=Cannot access memory at address 0x7fffff5feff8 ) at /usr/local/google/home/nlewycky/llvm/include/llvm/Type.h:506 506 inline Type* PATypeHolder::get() const { (gdb) bt #0 0x00000000007eaf6e in llvm::PATypeHolder::get (this=Cannot access memory at address 0x7fffff5feff8 ) at /usr/local/google/home/nlewycky/llvm/include/llvm/Type.h:506 #1 0x000000000080db7e in llvm::PATypeHolder::operator-> (this=0x11c13b0) at /usr/local/google/home/nlewycky/llvm/include/llvm/AbstractTypeUser.h:163 #2 0x0000000000c16ab2 in llvm::Value::getContext (this=0x11c13a0) at Value.cpp:434 #3 0x0000000000c16c5f in llvm::ValueHandleBase::AddToUseList ( this=0x7fffff5ff1b8) at Value.cpp:469 #4 0x000000000080e6b9 in llvm::ValueHandleBase::ValueHandleBase ( this=0x7fffff5ff1b8, Kind=llvm::ValueHandleBase::Callback, V=0x11c13a0) at /usr/local/google/home/nlewycky/llvm/include/llvm/Support/ValueHandle.h:65 #5 0x000000000080e960 in llvm::CallbackVH::CallbackVH (this=0x7fffff5ff1b0, P=0x11c13a0) at /usr/local/google/home/nlewycky/llvm/include/llvm/Support/ValueHandle.h:369 #6 0x000000000081254f in llvm::ValueMapCallbackVH, llvm::ValueMapConfig, llvm::DenseMapInfo > >::ValueMapCallbackVH (this=0x7fffff5ff1b0, Key=0x11c13a0, Map=0x7fffffffde10) at /usr/local/google/home/nlewycky/llvm/include/llvm/ADT/ValueMap.h:204 #7 0x0000000000810dea in llvm::ValueMap, llvm::ValueMapConfig, llvm::DenseMapInfo > >::Wrap (this=0x7fffffffde10, key=0x11c13a0) at /usr/local/google/home/nlewycky/llvm/include/llvm/ADT/ValueMap.h:187 #8 0x000000000080f8bf in llvm::ValueMap, llvm::ValueMapConfig, llvm::DenseMapInfo > >::find (this=0x7fffffffde10, Val=@0x7fffff5ff238) at /usr/local/google/home/nlewycky/llvm/include/llvm/ADT/ValueMap.h:120 #9 0x00000000009fac8a in llvm::MapValue (V=0x11c13a0, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:25 #10 0x00000000009faee1 in llvm::MapValue (V=0x11e3ad0, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:44 #11 0x00000000009faee1 in llvm::MapValue (V=0x11e0120, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:44 #12 0x00000000009faee1 in llvm::MapValue (V=0x11e3880, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:44 #13 0x00000000009faee1 in llvm::MapValue (V=0x11e36b0, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:44 #14 0x00000000009faee1 in llvm::MapValue (V=0x11e05a0, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:44 #15 0x00000000009faee1 in llvm::MapValue (V=0x11e02f0, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:44 #16 0x00000000009faee1 in llvm::MapValue (V=0x11dfb50, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:44 [...] #26207 0x00000000009faee1 in llvm::MapValue (V=0x11dea70, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:44 #26208 0x00000000009fafbc in llvm::MapValue (V=0x11d9d50, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:54 #26209 0x00000000009fb5ef in llvm::RemapInstruction (I=0x1224e00, VMap=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:117 #26210 0x000000000080c4f1 in LinkFunctionBody (Dest=0x11b76c0, Src=0x11c02f0, ValueMap=..., Err=0x7fffffffe250) at LinkModules.cpp:1007 #26211 0x000000000080c6a8 in LinkFunctionBodies (Dest=0x11b6150, Src=0x11b63d0, ValueMap=..., Err=0x7fffffffe250) at LinkModules.cpp:1034 #26212 0x000000000080d950 in llvm::Linker::LinkModules (Dest=0x11b6150, Src=0x11b63d0, ErrorMsg=0x7fffffffe250) at LinkModules.cpp:1277 #26213 0x000000000080784d in llvm::Linker::LinkInModule (this=0x7fffffffe220, Src=0x11b63d0, ErrorMsg=0x7fffffffe250) at /usr/local/google/home/nlewycky/llvm/include/llvm/Linker.h:248 #26214 0x00000000008075d7 in llvm::Linker::LinkInFile (this=0x7fffffffe220, File=..., is_native=@0x7fffffffe1bf) at LinkItems.cpp:202 #26215 0x00000000008077ea in llvm::Linker::LinkInFiles (this=0x7fffffffe220, Files=std::vector of length 1, capacity 1 = {...}) at LinkItems.cpp:238 #26216 0x00000000007d9f83 in main (argc=6, argv=0x7fffffffe758, envp=0x7fffffffe790) at llvm-ld.cpp:582 (gdb) up 100 #100 0x00000000009faee1 in llvm::MapValue (V=0x11dfb30, VM=..., Flags=llvm::RF_IgnoreMissingEntries) at ValueMapper.cpp:44 44 if (OP == 0 || MapValue(OP, VM, Flags) == OP) continue; (gdb) p V $1 = (const llvm::Value *) 0x11dfb30 (gdb) p V->dump() Cannot access memory at address 0x7fffff5fef58 (gdb) p OP $2 = (llvm::Value *) 0x11e01f0 (gdb) p OP->dump() Cannot access memory at address 0x7fffff5fef58 (gdb) p i $3 = 10 (gdb) list 39 return VM[V] = const_cast(V); 40 41 // Check all operands to see if any need to be remapped. 42 for (unsigned i = 0, e = MD->getNumOperands(); i != e; ++i) { 43 Value *OP = MD->getOperand(i); 44 if (OP == 0 || MapValue(OP, VM, Flags) == OP) continue; 45 46 // Ok, at least one operand needs remapping. Create a dummy node in case 47 // we have a metadata cycle. 48 MDNode *Dummy = MDNode::getTemporary(V->getContext(), 0, 0); (gdb) p MD->dump() Cannot access memory at address 0x7fffff5fef58 The infinite loop is in the "MapValue(OP, VM, Flags) == OP" expression on line 44. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 20 23:30:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 20 Jan 2011 23:30:16 -0600 (CST) Subject: [LLVMbugs] [Bug 9013] clang hang In-Reply-To: References: Message-ID: <20110121053016.D7E0B2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9013 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2011-01-20 23:30:16 CST --- Fixed in r123968, thanks John! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 03:55:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 03:55:30 -0600 (CST) Subject: [LLVMbugs] [Bug 9016] New: Assertion `D->isInvalidDecl() && "declaration was not instantiated in this scope!"' failed in many boost examples Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9016 Summary: Assertion `D->isInvalidDecl() && "declaration was not instantiated in this scope!"' failed in many boost examples Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code causes an assertion in a current svn head. It only appeared recently. I can reproduce this in an asserts+debug build. The code appears valid, and is accepted by g++. template struct allocator ; template struct less ; template class = less> struct interval_type_default ; template class Compare = less, class = typename interval_type_default<_T,Compare>::type, template class = allocator> class IntervalSet> int int40() { IntervalSet IntervalSetT; } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 10:00:03 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 10:00:03 -0600 (CST) Subject: [LLVMbugs] [Bug 9017] New: Assertion `New != this && "this->replaceAllUsesWith(this) is NOT valid!"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9017 Summary: Assertion `New != this && "this->replaceAllUsesWith(this) is NOT valid!"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu regehr at home:~/volatile/bugs/tmp349$ clang -O2 -c small.c clang: Value.cpp:312: void llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `New != this && "this->replaceAllUsesWith(this) is NOT valid!"' failed. 0 clang 0x09498118 Stack dump: 0. Program arguments: /mnt/z/z/compiler-install/llvm-gcc-r123968-install/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.20.51 -resource-dir /mnt/z/z/compiler-install/llvm-gcc-r123968-install/bin/../lib/clang/2.9 -O2 -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Scalar Replacement of Aggregates (SSAUp)' on function '@int322' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) regehr at home:~/volatile/bugs/tmp349$ clang -v clang version 2.9 (trunk 123968) Target: i386-pc-linux-gnu Thread model: posix regehr at home:~/volatile/bugs/tmp349$ cat small.c int g_85; int func_75 (void) { lbl_95: g_85 ^= 0; goto lbl_95; } int *func_80 (int **p_82) { return *p_82; } void int322 (void) { int l_34; int *l_72 = &l_34; if (func_75 ()) for (;;) { int **l_144 = &l_72; *l_144 = func_80 (&l_72); } } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 12:54:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 12:54:57 -0600 (CST) Subject: [LLVMbugs] [Bug 9012] "undef" in conditional branches may lead to assertion failure In-Reply-To: References: Message-ID: <20110121185457.E29252A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9012 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Chris Lattner 2011-01-21 12:54:57 CST --- I don't think that the scenario you are suggesting is possible. Here's a trivial testcase that should show the issue: define void @test() { br i1 1, label %Out, label %Loop Loop: br i1 undef, label %Loop, label %Out Out: ret void } This is not a problem, because dead blocks are run through DeleteInstructionInBlock before the deletion loop happens. If this is a real problem that manifests, please reopen with a testcase. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 21 13:07:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 13:07:22 -0600 (CST) Subject: [LLVMbugs] [Bug 9018] New: Documentation of function attributes in a 'call' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9018 Summary: Documentation of function attributes in a 'call' Product: Documentation Version: 2.8 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm at henning-thielemann.de CC: llvmbugs at cs.uiuc.edu http://llvm.org/docs/LangRef.html says, that the allowed function attributes for 'call' are 'noreturn', 'nounwind', 'readonly' and 'readnone', but it does not tell how these attributes interact with the ones given in the according 'declare'. The description of function attributes says, that function attributes are attributes of the function - so how can function attributes be part of a function call? Is there a difference between define double @arith(double, double) { _L1: %2 = call double @llvm.sin.f64(double %0) %3 = call double @llvm.exp.f64(double %2) %4 = fadd double %3, %1 ret double %4 } declare double @llvm.sin.f64(double) readnone declare double @llvm.exp.f64(double) readnone and define double @arith(double, double) { _L1: %2 = call double @llvm.sin.f64(double %0) readnone %3 = call double @llvm.exp.f64(double %2) readnone %4 = fadd double %3, %1 ret double %4 } declare double @llvm.sin.f64(double) declare double @llvm.exp.f64(double) and define double @arith(double, double) { _L1: %2 = call double @llvm.sin.f64(double %0) readnone %3 = call double @llvm.exp.f64(double %2) readnone %4 = fadd double %3, %1 ret double %4 } declare double @llvm.sin.f64(double) readnone declare double @llvm.exp.f64(double) readnone ? I guess that the union of the sets of attributes of 'declare' and 'call' is considered when calling a function. If this is true, then the above functions should be 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 Jan 21 13:26:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 13:26:20 -0600 (CST) Subject: [LLVMbugs] [Bug 9019] New: __builtin_fabs shouldn't lower to libm call Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9019 Summary: __builtin_fabs shouldn't lower to libm call Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu This program: float f(float x) { return __builtin_fabsf(x); } requires -lm when built by clang -O0 but not when built by gcc or clang -O2. GCC emits this code at -O2 levels (-O0 has no call either): f: .LFB0: .cfi_startproc movss .LC0(%rip), %xmm1 andps %xmm1, %xmm0 ret .cfi_endproc [...] .LC0: .long 2147483647 .long 0 .long 0 .long 0 without -fno-errno or -ffast-math or any other such flags. Clang -O2 will emit this IR: define float @f(float %x) nounwind readnone { entry: %call = tail call float @fabsf(float %x) ret float %call } but in llc -O0 we emit the call as written and in llc -O2 we replace it with an andps like gcc. Either llc -O0 should learn to lower fabs/fabsf calls to 'and', or clang should lower __builtin_fabs differently. I think I prefer the latter, but the backend would need to be improved first. The lowering in LLVM IR would be: define float @f(float %x) { %cast = bitcast float %x to i32 %abs.i = and i32 %cast, 2147483647 %abs = bitcast i32 %abs.i to float ret float %abs } which produces this sub-optimal code through llc -O2: movd %xmm0, %eax andl $2147483647, %eax # imm = 0x7FFFFFFF movd %eax, %xmm0 ret -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 21 13:34:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 13:34:24 -0600 (CST) Subject: [LLVMbugs] [Bug 9020] New: Pack expansion that was already expanded treated as a non-deduced context. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9020 Summary: Pack expansion that was already expanded treated as a non-deduced context. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following generates a suspicious warning for the partial specialization. While the partial specialization member of A has an argument list containing a pack expansion in the middle, the pack is already expanded when A is instantiated, so U can be deduced. template struct A { template struct B; // warns "non-deducible context" ... template struct B { }; }; // ... but works fine. A::B a; Similar to http://llvm.org/bugs/show_bug.cgi?id=7094 . -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 14:04:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 14:04:25 -0600 (CST) Subject: [LLVMbugs] [Bug 9021] New: Pack expansion into a template-argument-list corresponding to no parameter packs fails Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9021 Summary: Pack expansion into a template-argument-list corresponding to no parameter packs fails Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following fails. template struct A { }; template struct B { A a1; }; int main() { B c; } Errors: main1.cpp:6:3: error: too few template arguments for class template 'A' A a1; ^ main1.cpp:2:8: note: template is declared here struct A { }; ^ 1 error generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 21 14:11:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 14:11:34 -0600 (CST) Subject: [LLVMbugs] [Bug 9022] New: How to set call attributes via C binding? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9022 Summary: How to set call attributes via C binding? Product: Documentation Version: 2.8 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm at henning-thielemann.de CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6031) --> (http://llvm.org/bugs/attachment.cgi?id=6031) attempt to set ReadNone attribute at call I wonder how to set an attribute like readnone to a call. Attached is a C program where I try to do add the readnone attribute using LLVMAddInstrAttribute, which seems to be wrong, since this adds the attribute to the result of the call. The verifier pass thus complains: Attribute readnone only applies to the function! %2 = call readnone double @llvm.exp.f64(double %0) Attribute readnone only applies to the function! %3 = call readnone double @llvm.sin.f64(double %1) Broken module found, compilation aborted! Stack dump: 0. Running pass 'Function Pass Manager' on module '_module'. 1. Running pass 'Module Verifier' on function '@arithmetic' Aborted I also tried LLVMAddAttribute (but as far as I understand this is for parameters of the surrounding function) and LLVMAddFunctionAttr (but I want to add to a call, not a function). Both do not work. How can I add an attribute to a call? Or is this not necessary at all? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 21 15:19:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 15:19:56 -0600 (CST) Subject: [LLVMbugs] [Bug 9022] How to set call attributes via C binding? In-Reply-To: References: Message-ID: <20110121211956.EA7482A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9022 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |asl at math.spbu.ru Resolution| |INVALID --- Comment #1 from Anton Korobeynikov 2011-01-21 15:19:56 CST --- According to http://llvm.org/docs/LangRef.html 'readnone' is a function attribute, thus you can apply this to function only, not to call. Please next time forward such questions to llvmdev ML, not to bugzilla, this is not a bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 21 15:55:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 15:55:31 -0600 (CST) Subject: [LLVMbugs] [Bug 9023] New: Prematurely diagnoses unexpanded parameter packs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9023 Summary: Prematurely diagnoses unexpanded parameter packs Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com It looks to me that assuming resolution of core issue #778 is accepted, the following is valid code template struct A { template class ...> struct B { }; }; template struct C { }; template struct D { }; int main() { A::B e; } Clang errors out (only showing the first relevant error message): main1.cpp:3:22: error: non-type template parameter type contains unexpanded parameter pack 'T' template class ...> -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 21 16:16:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 16:16:27 -0600 (CST) Subject: [LLVMbugs] [Bug 9024] New: "Missing default argument" assertion on invalid code. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9024 Summary: "Missing default argument" assertion on invalid code. Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following invalid code: template struct S {}; S x; Causes the following backtrace: t.cc:1:26: error: template parameter missing a default argument template ^ t.cc:1:19: note: previous default template argument defined here template ^ clang: SemaTemplate.cpp:2550: bool clang::Sema::CheckTemplateArgumentList(clang::TemplateDecl*, clang::SourceLocation, const clang::TemplateArgumentListInfo&, bool, llvm::SmallVectorImpl&): Assertion `(Invalid || PartialTemplateArgs) && "Missing default argument"' failed. 0 clang 0x0000000002320b41 1 clang 0x0000000002320934 2 libpthread.so.0 0x00007fa09077d8f0 3 libc.so.6 0x00007fa08fa6ca75 gsignal + 53 4 libc.so.6 0x00007fa08fa705c0 abort + 384 5 libc.so.6 0x00007fa08fa65941 __assert_fail + 241 6 clang 0x000000000141a067 clang::Sema::CheckTemplateArgumentList(clang::TemplateDecl*, clang::SourceLocation, clang::TemplateArgumentListInfo const&, bool, llvm::SmallVectorImpl&) + 2023 7 clang 0x0000000001416c2b clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation, clang::TemplateArgumentListInfo const&) + 201 8 clang 0x00000000014171d7 clang::Sema::ActOnTemplateIdType(clang::OpaquePtr, clang::SourceLocation, clang::SourceLocation, clang::ASTTemplateArgsPtr, clang::SourceLocation) + 167 9 clang 0x0000000001282164 clang::Parser::AnnotateTemplateIdTokenAsType(clang::CXXScopeSpec const*) + 280 10 clang 0x000000000125c463 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 3573 11 clang 0x00000000012536e3 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 93 12 clang 0x0000000001253b01 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 113 13 clang 0x0000000001253482 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2170 14 clang 0x0000000001252b78 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 210 15 clang 0x000000000123c354 clang::ParseAST(clang::Sema&, bool) + 328 16 clang 0x0000000000fa9a19 clang::ASTFrontendAction::ExecuteAction() + 263 17 clang 0x00000000010e6e85 clang::CodeGenAction::ExecuteAction() + 951 18 clang 0x0000000000fa966a clang::FrontendAction::Execute() + 320 19 clang 0x0000000000f922bb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 751 20 clang 0x0000000000f3f839 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 854 21 clang 0x0000000000f31b09 cc1_main(char const**, char const**, char const*, void*) + 1032 22 clang 0x0000000000f3adf4 main + 499 23 libc.so.6 0x00007fa08fa57c4d __libc_start_main + 253 24 clang 0x0000000000f31179 Stack dump: 0. Program arguments: /llvmdebug/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name t.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /llvmdebug/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 172 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 1. t.cc:4:1: at annotation token clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 21 18:45:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 18:45:43 -0600 (CST) Subject: [LLVMbugs] [Bug 9025] New: Crash when emitting err_member_reference_needs_call for overloaded function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9025 Summary: Crash when emitting err_member_reference_needs_call for overloaded function Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matthewbg at google.com CC: llvmbugs at cs.uiuc.edu This input causes Clang to segfault: int fun(int i); float fun(float f); void g() { fun.x; } The problem is near the end of Sema::LookupMemberExpr, where BaseType == Context.OverloadTy but Fun is null. So, we try to output the function type in the diagnostic, but haven't gotten a 0-arg overload out of the overload set (if it even exists). -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 19:34:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 19:34:32 -0600 (CST) Subject: [LLVMbugs] [Bug 9026] New: Assertion about "conversion sequence " Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9026 Summary: Assertion about "conversion sequence " Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang fails on ------------------------ class InfallibleTArray { }; class Variant; class CompVariant { operator const InfallibleTArray&() const; }; class Variant { operator const CompVariant&() const; }; void Write( const Variant& __v); void Write( const InfallibleTArray& __v); Variant x; void Write2() { Write(x); } ------------------------ with Assertion failed: (false && "Can only end up with a standard conversion sequence or failure"), function AddConversionCandidate, file /Users/espindola/llvm/clang/lib/Sema/SemaOverload.cpp, line 4024. 0 clang 0x0000000101001992 PrintStackTrace(void*) + 34 1 clang 0x0000000101001f39 SignalHandler(int) + 857 2 libSystem.B.dylib 0x00007fff80ed867a _sigtramp + 26 3 clang 0x00000001005be33a clang::CXXBasePaths::lookupInBases(clang::ASTContext&, clang::CXXRecordDecl const*, bool (*)(clang::CXXBaseSpecifier const*, clang::CXXBasePath&, void*), void*) + 234 4 clang 0x0000000100019e26 abort + 22 5 clang 0x0000000100019de8 __assert_rtn + 56 6 clang 0x00000001003b0ea2 clang::Sema::AddConversionCandidate(clang::CXXConversionDecl*, clang::DeclAccessPair, clang::CXXRecordDecl*, clang::Expr*, clang::QualType, clang::OverloadCandidateSet&) + 2178 7 clang 0x00000001003c5f97 clang::FindConversionForRefInit(clang::Sema&, clang::ImplicitConversionSequence&, clang::QualType, clang::Sou -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 21 19:54:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 21 Jan 2011 19:54:51 -0600 (CST) Subject: [LLVMbugs] [Bug 9027] New: volatile struct bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9027 Summary: volatile struct bug Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu The struct member needs to be loaded and stored. regehr at home:~$ clang -v clang version 2.9 (trunk 123968) Target: i386-pc-linux-gnu Thread model: posix regehr at home:~$ clang -O vol.c -S -o - -fomit-frame-pointer foo: # @foo ret regehr at home:~$ cat vol.c struct s2 { volatile int x; }; struct s2 s; void foo (void) { s = s; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 22 05:13:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 Jan 2011 05:13:18 -0600 (CST) Subject: [LLVMbugs] [Bug 9022] How to set call attributes via C binding? In-Reply-To: References: Message-ID: <20110122111318.0E0012A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9022 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |baldrick at free.fr Resolution|INVALID | --- Comment #4 from Duncan Sands 2011-01-22 05:13:17 CST --- Then the docs are wrong. It is perfectly possible (and useful) to apply readnone to a call. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 22 09:36:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 Jan 2011 09:36:02 -0600 (CST) Subject: [LLVMbugs] [Bug 9026] Assertion about "conversion sequence " In-Reply-To: References: Message-ID: <20110122153602.5A71A2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9026 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Rafael ?vila de Esp?ndola 2011-01-22 09:36:01 CST --- Fixed by reverting r123977 and r123978. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 22 11:24:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 Jan 2011 11:24:25 -0600 (CST) Subject: [LLVMbugs] [Bug 9028] New: Assertion on valid code when optimization is turned on Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9028 Summary: Assertion on valid code when optimization is turned on Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6032) --> (http://llvm.org/bugs/attachment.cgi?id=6032) Asserting testcase The attached file (sorry for the length) produces the following backtrace when compiled with -O. It compiles fine with no optimization. clang: SelectionDAG.cpp:916: llvm::SDValue llvm::SelectionDAG::getConstant(uint64_t, llvm::EVT, bool): Assertion `(EltVT.getSizeInBits() >= 64 || (uint64_t)((int64_t)Val >> EltVT.getSizeInBits()) + 1 < 2) && "getConstant with a uint64_t value that doesn't fit in the type!"' failed. 0 clang 0x0000000002320b41 1 clang 0x0000000002320934 2 libpthread.so.0 0x00007f0c632f68f0 3 libc.so.6 0x00007f0c625e5a75 gsignal + 53 4 libc.so.6 0x00007f0c625e95c0 abort + 384 5 libc.so.6 0x00007f0c625de941 __assert_fail + 241 6 clang 0x0000000001c6d0c5 7 clang 0x0000000001d929e7 8 clang 0x0000000001d9c2dc 9 clang 0x0000000001d91cce 10 clang 0x0000000001d3d83d 11 clang 0x0000000001d42e78 llvm::SelectionDAG::LegalizeTypes() + 74 12 clang 0x0000000001ce9615 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1055 13 clang 0x0000000001ce8d90 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 258 14 clang 0x0000000001ceb292 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2008 15 clang 0x0000000001ce82fd llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 731 16 clang 0x0000000001e4b229 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95 17 clang 0x000000000224cb2d llvm::FPPassManager::runOnFunction(llvm::Function&) + 407 18 clang 0x000000000224cd4a llvm::FPPassManager::runOnModule(llvm::Module&) + 102 19 clang 0x000000000224d07d llvm::MPPassManager::runOnModule(llvm::Module&) + 459 20 clang 0x000000000224d57b llvm::PassManagerImpl::run(llvm::Module&) + 125 21 clang 0x000000000224dad1 llvm::PassManager::run(llvm::Module&) + 39 22 clang 0x00000000010ea194 23 clang 0x00000000010ea265 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 133 24 clang 0x00000000010e5ffe 25 clang 0x000000000123c48b clang::ParseAST(clang::Sema&, bool) + 639 26 clang 0x0000000000fa9a19 clang::ASTFrontendAction::ExecuteAction() + 263 27 clang 0x00000000010e6e85 clang::CodeGenAction::ExecuteAction() + 951 28 clang 0x0000000000fa966a clang::FrontendAction::Execute() + 320 29 clang 0x0000000000f922bb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 751 30 clang 0x0000000000f3f839 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 854 31 clang 0x0000000000f31b09 cc1_main(char const**, char const**, char const*, void*) + 1032 32 clang 0x0000000000f3adf4 main + 499 33 libc.so.6 0x00007f0c625d0c4d __libc_start_main + 253 34 clang 0x0000000000f31179 Stack dump: 0. Program arguments: /llvmdebug/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name t.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /llvmdebug/bin/../lib/clang/2.9 -O2 -ferror-limit 19 -fmessage-length 172 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 't.cc'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_Z1av' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 22 12:00:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 22 Jan 2011 12:00:21 -0600 (CST) Subject: [LLVMbugs] [Bug 8907] [meta] build firefox 4 In-Reply-To: References: Message-ID: <20110122180021.8E8302A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8907 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Rafael ?vila de Esp?ndola 2011-01-22 12:00:21 CST --- With a current clang and the firefox 4 side of the issue patched I can build it and "make check" is clean :-) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 02:09:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 02:09:11 -0600 (CST) Subject: [LLVMbugs] [Bug 9029] New: No typo correction after new Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9029 Summary: No typo correction after new Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com $ cat t.cc class MyClassIsReallyCool {}; void foo() { new myClassIsReallyCool(); } $ clang t.cc t.cc:5:7: error: expected a type new myClassIsReallyCool(); ^ This should say "did you mean..." and recover. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 09:27:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 09:27:30 -0600 (CST) Subject: [LLVMbugs] [Bug 9030] New: ARM disassembler failed to disassemble "mov pc, lr" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9030 Summary: ARM disassembler failed to disassemble "mov pc, lr" Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: crabtw at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6033) --> (http://llvm.org/bugs/attachment.cgi?id=6033) Possible fix Debug message $ echo '0x0e 0xf0 0xa0 0xe1' | Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug Args: Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug Opcode=179 Name=MOVPCLR Format=ARM_FORMAT_BRMISCFRM(3) 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ------------------------------------------------------------------------------------------------- | 1: 1: 1: 0| 0: 0: 0: 1| 1: 0: 1: 0| 0: 0: 0: 0| 1: 1: 1: 1| 0: 0: 0: 0| 0: 0: 0: 0| 1: 1: 1: 0| ------------------------------------------------------------------------------------------------- :1:1: warning: invalid instruction encoding 0x0e 0xf0 0xa0 0xe1 ^ The attached patch could fix the problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 23 12:00:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 12:00:02 -0600 (CST) Subject: [LLVMbugs] [Bug 8762] Clang's integrated-as doesn't support --noexecstack In-Reply-To: References: Message-ID: <20110123180002.737922A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8762 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Rafael ?vila de Esp?ndola 2011-01-23 12:00:01 CST --- Fixed in r124078. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 13:11:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 13:11:57 -0600 (CST) Subject: [LLVMbugs] [Bug 9031] New: Small gcc bug fixes from the FSF under GPLv2 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9031 Summary: Small gcc bug fixes from the FSF under GPLv2 Product: tools Version: 2.8 Platform: PC OS/Version: FreeBSD Status: NEW Severity: enhancement Priority: P Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: giffunip at tutopia.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6034) --> (http://llvm.org/bugs/attachment.cgi?id=6034) Initial FSF patch to gcc 4.2.1 The switch to GPLv3 in FSF sources was done after r127959 (gcc-4.2.2-Prerelease), this left a set of bug fixes and enhancements that are still under GPLv2 and that can be applied to llvm-gcc. A first set of changes that applies cleanly is included in the attached patch. FreeBSD, which will also not adopt GPL3 code, has some rather small of bug fixes that would be good to have in order to be able to build FreeBSD with llvm-gcc. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 23 15:38:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 15:38:37 -0600 (CST) Subject: [LLVMbugs] [Bug 8969] linux x86-32 stack not kept 16-byte aligned In-Reply-To: References: Message-ID: <20110123213837.4E6F82A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8969 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #6 from Nick Lewycky 2011-01-23 15:38:36 CST --- Fixed! Thanks Eric! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 16:41:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 16:41:26 -0600 (CST) Subject: [LLVMbugs] [Bug 9032] New: clang gives different results than gcc wrt array element modification evaluation order Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9032 Summary: clang gives different results than gcc wrt array element modification evaluation order Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: juli at clockworksquid.com CC: llvmbugs at cs.uiuc.edu With this code: %%% static int bar[1] = { 1 }; static int churn(void) { return (bar[0]++); } static int seed(void) { bar[0] += churn(); return (bar[0]); } %%% With GCC the first call to seed() will return 2. With Clang the first call to seed() will return 3. If the += is expanded in seed like: %%% static int seed(void) { bar[0] = bar[0] + churn(); return (bar[0]); } %%% Both GCC and Clang will return 2. It isn't clear to me if the behavior of the former is undefined, but neither GCC nor Clang warns that it might be if it is. (The latter could more obviously be undefined if a function were called with bar[0] and churn()'s return value, but I don't know whether that's the case with arithmetic operators.) Clang and GCC yield the same results if bar is not an array. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 18:24:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 18:24:51 -0600 (CST) Subject: [LLVMbugs] [Bug 9033] New: AsmPrinter doesn't quite section name when necessary Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9033 Summary: AsmPrinter doesn't quite section name when necessary Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: LLVM assembly language parser AssignedTo: unassignedbugs at nondot.org ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Consider the following input: .section "foo bar" With the patch from PR 8948, llvm-mc gives the following output: .section __TEXT,__text,regular,pure_instructions .section foo bar,"", at progbits This is not equivalent to the original input and can't be parsed. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 18:47:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 18:47:23 -0600 (CST) Subject: [LLVMbugs] [Bug 6996] vtables marked weak_odr instead of linkonce_odr In-Reply-To: References: Message-ID: <20110124004723.761832A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6996 Anders Carlsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Anders Carlsson 2011-01-23 18:47:22 CST --- Committed revision 124089. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 18:50:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 18:50:25 -0600 (CST) Subject: [LLVMbugs] [Bug 9032] clang gives different results than gcc wrt array element modification evaluation order In-Reply-To: References: Message-ID: <20110124005025.7549A2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9032 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Chris Lattner 2011-01-23 18:50:24 CST --- As you guess, this *is* undefined behavior. The compilers try their best to warn about this sort of thing, but there are always cases they will miss. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 23 20:28:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 20:28:19 -0600 (CST) Subject: [LLVMbugs] [Bug 8294] Obvious inline missed In-Reply-To: References: Message-ID: <20110124022819.D5F702A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8294 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-01-23 20:28:19 CST --- good news, this is now fully devirtualized on mainline with clang -O2 or -O3: define i32 @main() nounwind readnone ssp { entry: ret i32 0 } define unnamed_addr void @_ZN7DerivedC2Ev(%struct.Derived* nocapture %this) nounwind ssp align 2 { entry: %0 = bitcast %struct.Derived* %this to i8*** store i8** getelementptr inbounds ([5 x i8*]* @_ZTV7Derived, i64 0, i64 2), i8*** %0, align 8 ret void } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 23 21:18:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 21:18:36 -0600 (CST) Subject: [LLVMbugs] [Bug 9015] module linking crash In-Reply-To: References: Message-ID: <20110124031836.3E2632A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9015 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-01-23 21:18:35 CST --- Fixed in r124099, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 23 21:29:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 21:29:18 -0600 (CST) Subject: [LLVMbugs] [Bug 9017] Assertion `New != this && "this->replaceAllUsesWith(this) is NOT valid!"' failed. In-Reply-To: References: Message-ID: <20110124032918.0AC752A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9017 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2011-01-23 21:29:17 CST --- Fixed in r124100, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 23 21:43:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 21:43:30 -0600 (CST) Subject: [LLVMbugs] [Bug 9009] Cannot select X86ISD::MOVLPS for v4:i32 In-Reply-To: References: Message-ID: <20110124034330.B93722A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9009 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2011-01-23 21:43:30 CST --- I applied the first patch and testcase in r124102. It looks like you're working with an out of date tree, I can't find where the second patch is supposed to go. If it is still an issue, please update to mainline and send a patch against it. Thanks for reporting and fixing this! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Jan 23 21:48:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 23 Jan 2011 21:48:17 -0600 (CST) Subject: [LLVMbugs] [Bug 9005] mangled docs for -fcolor-diagnostics In-Reply-To: References: Message-ID: <20110124034817.D54E02A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9005 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Chris Lattner 2011-01-23 21:48:17 CST --- Applied in r124104,124105, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 24 04:59:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 04:59:04 -0600 (CST) Subject: [LLVMbugs] [Bug 9034] New: [MC-COFF] Cascaded alias is not emitted correctly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9034 Summary: [MC-COFF] Cascaded alias is not emitted correctly Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: ASSIGNED Severity: normal Priority: P Component: Backend: X86 AssignedTo: bigcheesegs at gmail.com ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu Blocks: 8390 @baz = alias void ()* @bar @bar = alias void ()* @foo define void @foo() nounwind align 2 { ret void } ;; llc -mtriple=i686-win32 -filetype=asm .text .globl _foo _foo: ret .globl _baz _baz = _bar .globl _bar _bar = _foo ;; llc -mtriple=i686-win32 -filetype=obj && (llvm-)nm 00000000 t .text 00000000 T _bar U _baz ;;; It should be defined 00000000 T _foo ;;;; It works well if the line "@baz = " is moved below "@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 Jan 24 05:31:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 05:31:36 -0600 (CST) Subject: [LLVMbugs] [Bug 9035] New: x86 backend double load/store generating bad code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9035 Summary: x86 backend double load/store generating bad code Product: new-bugs Version: 2.8 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: garrofi at hotmail.com CC: llvmbugs at cs.uiuc.edu This code is based on lua TValues. It generates bad code typedef union { int p; double aux; } Value; Value* chanka2(Value* aux, Value* aux2) { *aux = *aux2; return aux; } IR code with -O2 define %union.Value* @chanka2(%union.Value* %aux, %union.Value* nocapture %aux2) nounwind { entry: %aux2.0 = getelementptr inbounds %union.Value* %aux2, i32 0, i32 0 %tmp2 = load double* %aux2.0, align 8 %aux.0 = getelementptr inbounds %union.Value* %aux, i32 0, i32 0 store double %tmp2, double* %aux.0, align 8 ret %union.Value* %aux } with SSE disable llc.exe -O2 -march=x86 -filetype=asm chanka.o -mattr=-sse,-sse2 -o chanka.s movl 8(%esp), %eax fldl (%eax) movl 4(%esp), %eax fstpl (%eax) ret I get this code, and this code doesn't work if the input number is a NaN visual studio or gcc compiler when it's a simple load/store with no math involved genererates movs instead x87 fpu modifies the value when the input number is a nan is there a way to fix that? how can I modify the backend for that case? when it's just a load/store I would like to use a different path -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 08:08:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 08:08:30 -0600 (CST) Subject: [LLVMbugs] [Bug 9036] New: Variadic base-specifier-list of union rejected Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9036 Summary: Variadic base-specifier-list of union rejected Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang rejects this code: template union A : T... { }; A<> a; Clang says at parse time "error: unions cannot have base classes", but it can't know for sure until we instantiate 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 Jan 24 12:08:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 12:08:49 -0600 (CST) Subject: [LLVMbugs] [Bug 9037] New: explicit virtual keywords (override/final/new) not support on inline members Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9037 Summary: explicit virtual keywords (override/final/new) not support on inline members Product: clang Version: trunk Platform: All 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 Actually, clang does not support usage of the keywords defined by the "Explicit virtual function overrides" language extension on members defined inline. ----------- test.cpp class A { virtual void foo(); }; class B : public A { virtual void foo() override {} }; ----------- > clang++ -fsyntax-only test.cpp test.cpp:2:49: error: expected ';' at end of declaration list class B : public A { virtual void foo() override {} }; ^ ; 1 error generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 24 12:34:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 12:34:30 -0600 (CST) Subject: [LLVMbugs] [Bug 9038] New: llvm/Target/TargetOptions.h should become an immutablepass Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9038 Summary: llvm/Target/TargetOptions.h should become an immutablepass Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu llvm/Target/TargetOptions.h contains a bunch of global variables that affect the code generator. Global variables are obviously bad and prevent things like running multiple different code generators on different threads etc. While some of the individual flags can be refactored, a very reasonable right short term solution for this is to make TargetOptions be an ImmutablePass that codegen can "getAnalysis<>" on, and llc/clang etc can explicitly schedule it if they want to fiddle with the flags. -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 24 12:37:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 12:37:05 -0600 (CST) Subject: [LLVMbugs] [Bug 8928] Assertion failed: (T && "getTerminator returned null!"), function SuccIterator, file /data/home/rdivacky/llvm/include/llvm/Support/CFG.h, line 105. In-Reply-To: References: Message-ID: <20110124183705.DD80E2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8928 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Lattner 2011-01-24 12:37:05 CST --- Ok, applied in r124132, thanks Jakub! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 12:53:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 12:53:52 -0600 (CST) Subject: [LLVMbugs] [Bug 8968] assertion failure: "DecomposeGEPExpression and GetUnderlyingObject disagree!" In-Reply-To: References: Message-ID: <20110124185353.098F02A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8968 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Dan Gohman 2011-01-24 12:53:52 CST --- Fixed in r124134. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 13:01:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 13:01:32 -0600 (CST) Subject: [LLVMbugs] [Bug 8755] "class X" where X names a typedef has a worse error when X is templated In-Reply-To: References: Message-ID: <20110124190132.E7F6C2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8755 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Nick Lewycky 2011-01-24 13:01:32 CST --- Fixed in r124136 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 13:16:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 13:16:15 -0600 (CST) Subject: [LLVMbugs] [Bug 8295] clang doesn't complain about partial template function specializations In-Reply-To: References: Message-ID: <20110124191615.66DB32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8295 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from Hans Wennborg 2011-01-24 13:16:15 CST --- Fixed in r124135. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 14:25:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 14:25:59 -0600 (CST) Subject: [LLVMbugs] [Bug 9039] New: Use after free in reassociate Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9039 Summary: Use after free in reassociate Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu $ valgrind opt use_after_free.ll -reassociate ... Invalid read of size 1 at 0x87AD6E: llvm::Value::getValueID() const (Value.h:245) by 0x87AE07: llvm::isa_impl::doit(llvm::Value const&) (Value.h:348) by 0x87BF6D: llvm::isa_impl_wrap::doit(llvm::Value const&) (Casting.h:73) by 0x87BE13: bool llvm::isa_impl_cl::isa(llvm::Value const&) (Casting.h:85) by 0x89ED15: bool llvm::isa_impl_cl::isa(llvm::Value const&) (Casting.h:94) by 0x89B597: bool llvm::isa_impl_cl::isa(llvm::Value const*) (Casting.h:103) by 0x898C08: bool llvm::isa(llvm::Value const* const&) (Casting.h:118) by 0x92EF25: llvm::BinaryOperator::classof(llvm::Value const*) (InstrTypes.h:431) by 0x93285F: llvm::isa_impl::doit(llvm::Value const&) (Casting.h:55) by 0x93272D: llvm::isa_impl_wrap::doit(llvm::Value const&) (Casting.h:73) by 0x93254B: bool llvm::isa_impl_cl::isa(llvm::Value const&) (Casting.h:85) by 0x93211B: bool llvm::isa_impl_cl::isa(llvm::Value*) (Casting.h:103) Address 0x5ba8598 is 56 bytes inside a block of size 136 free'd at 0x4C26D7F: operator delete(void*) (vg_replace_malloc.c:387) by 0xCCEF50: llvm::User::operator delete(void*) (User.cpp:79) by 0xC8F395: llvm::BinaryOperator::~BinaryOperator() (InstrTypes.h:141) by 0x8B1C97: llvm::ilist_node_traits::deleteNode(llvm::Instruction*) (in /usr/local/bin/opt) by 0x8B085C: llvm::iplist >::erase(llvm::ilist_iterator) (ilist.h:463) by 0xC7E74F: llvm::Instruction::eraseFromParent() (Instruction.cpp:72) by 0x977BDB: (anonymous namespace)::Reassociate::RemoveFactorFromExpression(llvm::Value*, llvm::Value*) (Reassociate.cpp:589) by 0x978951: (anonymous namespace)::Reassociate::OptimizeAdd(llvm::Instruction*, llvm::SmallVectorImpl<(anonymous namespace)::ValueEntry>&) (Reassociate.cpp:820) by 0x978E8E: (anonymous namespace)::Reassociate::OptimizeExpression(llvm::BinaryOperator*, llvm::SmallVectorImpl<(anonymous namespace)::ValueEntry>&) (Reassociate.cpp:924) by 0x979367: (anonymous namespace)::Reassociate::ReassociateExpression(llvm::BinaryOperator*) (Reassociate.cpp:1025) by 0x979223: (anonymous namespace)::Reassociate::ReassociateBB(llvm::BasicBlock*) (Reassociate.cpp:1002) by 0x9796B8: (anonymous namespace)::Reassociate::runOnFunction(llvm::Function&) (Reassociate.cpp:1070) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 15:43:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 15:43:11 -0600 (CST) Subject: [LLVMbugs] [Bug 9040] New: Can't create an "unsigned Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9040 Summary: Can't create an "unsigned Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mclow at qualcomm.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 24 16:21:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 16:21:16 -0600 (CST) Subject: [LLVMbugs] [Bug 9041] New: __sync* macros not equivalent to GCC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9041 Summary: __sync* macros not equivalent to GCC Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: manuel.holtgrewe at fu-berlin.de CC: llvmbugs at cs.uiuc.edu Hi, the following simple test program generates the errors below while gcc compiles the program. --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- template void test() { T volatile x = 0; T y = 0; T z = 0; __sync_fetch_and_add(&x, y, z); __sync_fetch_and_or(&x, y, z); __sync_fetch_and_xor(&x, y, z); __sync_val_compare_and_swap(&x, y, z); } int main() { test(); test(); test(); test(); test(); test(); test(); test(); test(); test(); return 0; } --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- $ g++-4.3 --version g++-4.3 (Debian 4.3.2-1.1) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-4.3 main.cpp $ clang++-trunk --version clang version 2.9 (trunk 122567) Target: x86_64-unknown-linux-gnu Thread model: posix $ clang++-trunk -ferror-limit=1000 main.cpp main.cpp:7:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned char volatile *' __sync_fetch_and_add(&x, y, z); ^~ main.cpp:16:3: note: in instantiation of function template specialization 'test' requested here test(); ^ main.cpp:8:23: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned char volatile *' __sync_fetch_and_or(&x, y, z); ^~ main.cpp:9:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned char volatile *' __sync_fetch_and_xor(&x, y, z); ^~ main.cpp:10:31: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned char volatile *' __sync_val_compare_and_swap(&x, y, z); ^~ main.cpp:7:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'int volatile *' __sync_fetch_and_add(&x, y, z); ^~ main.cpp:17:3: note: in instantiation of function template specialization 'test' requested here test(); ^ main.cpp:8:23: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'int volatile *' __sync_fetch_and_or(&x, y, z); ^~ main.cpp:9:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'int volatile *' __sync_fetch_and_xor(&x, y, z); ^~ main.cpp:10:31: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'int volatile *' __sync_val_compare_and_swap(&x, y, z); ^~ main.cpp:7:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned int volatile *' __sync_fetch_and_add(&x, y, z); ^~ main.cpp:18:3: note: in instantiation of function template specialization 'test' requested here test(); ^ main.cpp:8:23: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned int volatile *' __sync_fetch_and_or(&x, y, z); ^~ main.cpp:9:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned int volatile *' __sync_fetch_and_xor(&x, y, z); ^~ main.cpp:10:31: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned int volatile *' __sync_val_compare_and_swap(&x, y, z); ^~ main.cpp:7:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'short volatile *' __sync_fetch_and_add(&x, y, z); ^~ main.cpp:19:3: note: in instantiation of function template specialization 'test' requested here test(); ^ main.cpp:8:23: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'short volatile *' __sync_fetch_and_or(&x, y, z); ^~ main.cpp:9:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'short volatile *' __sync_fetch_and_xor(&x, y, z); ^~ main.cpp:10:31: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'short volatile *' __sync_val_compare_and_swap(&x, y, z); ^~ main.cpp:7:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned short volatile *' __sync_fetch_and_add(&x, y, z); ^~ main.cpp:20:3: note: in instantiation of function template specialization 'test' requested here test(); ^ main.cpp:8:23: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned short volatile *' __sync_fetch_and_or(&x, y, z); ^~ main.cpp:9:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned short volatile *' __sync_fetch_and_xor(&x, y, z); ^~ main.cpp:10:31: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned short volatile *' __sync_val_compare_and_swap(&x, y, z); ^~ main.cpp:7:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'long volatile *' __sync_fetch_and_add(&x, y, z); ^~ main.cpp:21:3: note: in instantiation of function template specialization 'test' requested here test(); ^ main.cpp:8:23: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'long volatile *' __sync_fetch_and_or(&x, y, z); ^~ main.cpp:9:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'long volatile *' __sync_fetch_and_xor(&x, y, z); ^~ main.cpp:10:31: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'long volatile *' __sync_val_compare_and_swap(&x, y, z); ^~ main.cpp:7:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned long volatile *' __sync_fetch_and_add(&x, y, z); ^~ main.cpp:22:3: note: in instantiation of function template specialization 'test' requested here test(); ^ main.cpp:8:23: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned long volatile *' __sync_fetch_and_or(&x, y, z); ^~ main.cpp:9:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned long volatile *' __sync_fetch_and_xor(&x, y, z); ^~ main.cpp:10:31: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned long volatile *' __sync_val_compare_and_swap(&x, y, z); ^~ main.cpp:7:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'long long volatile *' __sync_fetch_and_add(&x, y, z); ^~ main.cpp:23:3: note: in instantiation of function template specialization 'test' requested here test(); ^ main.cpp:8:23: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'long long volatile *' __sync_fetch_and_or(&x, y, z); ^~ main.cpp:9:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'long long volatile *' __sync_fetch_and_xor(&x, y, z); ^~ main.cpp:10:31: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'long long volatile *' __sync_val_compare_and_swap(&x, y, z); ^~ main.cpp:7:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned long long volatile *' __sync_fetch_and_add(&x, y, z); ^~ main.cpp:24:3: note: in instantiation of function template specialization 'test' requested here test(); ^ main.cpp:8:23: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned long long volatile *' __sync_fetch_and_or(&x, y, z); ^~ main.cpp:9:24: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned long long volatile *' __sync_fetch_and_xor(&x, y, z); ^~ main.cpp:10:31: error: cannot initialize a parameter of type 'volatile char *' with an rvalue of type 'unsigned long long volatile *' __sync_val_compare_and_swap(&x, y, z); ^~ 36 errors generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 24 17:49:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 17:49:01 -0600 (CST) Subject: [LLVMbugs] [Bug 9042] New: Improving reuse of registers across loop iterations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9042 Summary: Improving reuse of registers across loop iterations Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: teoryn at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6043) --> (http://llvm.org/bugs/attachment.cgi?id=6043) Two examples showing partial and no reuse of registers between iterations Overview: Certain access patterns are able to reuse more registers between iterations of the inner loop than llvm now finds. Steps to Reproduce: The included .c files show two similar examples (three.c is just one.c unrolled three times) which could reuse registers across iterations of the loop. hist.txt shows the steps used to generate the .ll files in question. Actual Results: At most one register is reused between iterations of the loop, although in both cases there is opportunity to reuse two registers. The opt passes done for *.pre-gvn.ll and *.post-gvn.ll are all the passes shown in 'opt -O3 -debug-pass=Arguments one.ll' up to (and including for post-gvn) the -gvn pass, which enables the reuse of one register in one.c (and none in three.c). This might be the pass which could be modified to meet the expected results. Expected Results: Ideally two registers would be reused across iterations, not just one (in the case of one.c) or zero (in the case of three.c). Build Date & Platform: $ opt --version Low Level Virtual Machine (http://llvm.org/): llvm version 2.8 (Ubuntu 2.8-0ubuntu1) Optimized build. Built Oct 6 2010 (13:24:23). Host: x86_64-pc-linux-gnu Host CPU: i686 Registered Targets: (none) $ clang --version clang version 2.8 (branches/release_28) Target: x86_64-pc-linux-gnu Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 24 18:55:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 18:55:57 -0600 (CST) Subject: [LLVMbugs] [Bug 9040] Can't create an "unsigned Foo_t" In-Reply-To: References: Message-ID: <20110125005557.9AD762A6C131@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9040 Marshall Clow (work) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Marshall Clow (work) 2011-01-24 18:55:57 CST --- After more investigation; I now believe that clang is correct here and gcc is wrong. This information should probably go into some "gcc compatibility" document. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 19:43:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 19:43:54 -0600 (CST) Subject: [LLVMbugs] [Bug 9043] New: -Waddress should produce some warnings Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9043 Summary: -Waddress should produce some warnings Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matthewbg at google.com CC: llvmbugs at cs.uiuc.edu Here's some code that GCC warns on but Clang does not: void f(bool b); void g() { int a[1]; f(a); } $ g++ -fsyntax-only -Waddress address-warn.cc address-warn.cc: In function 'void g()': address-warn.cc:4: warning: the address of 'a' will always evaluate as 'true' $ clang -fsyntax-only -Waddress address-warn.cc $ See r123864 and the ensuing r123866 for an example of this in the wild. See also the GCC manpage for some other examples of constructs which GCC's -Waddress catches. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 20:31:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 20:31:07 -0600 (CST) Subject: [LLVMbugs] [Bug 9044] New: Clang doesn't treat rvalue refs specially during deduction in a declarative context Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9044 Summary: Clang doesn't treat rvalue refs specially during deduction in a declarative context Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang should accept the following template void f(T&&); template<> void f(int&) { } void (*fp)(int&) = &f; Based on 14.8.2.5p10 of n3225. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 20:59:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 20:59:27 -0600 (CST) Subject: [LLVMbugs] [Bug 9045] New: memory unsafety Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9045 Summary: memory unsafety Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 24 20:59:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 20:59:41 -0600 (CST) Subject: [LLVMbugs] [Bug 9045] memory unsafety In-Reply-To: References: Message-ID: <20110125025941.EEE672A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9045 John Regehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |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 Mon Jan 24 21:13:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 21:13:11 -0600 (CST) Subject: [LLVMbugs] [Bug 9046] New: memory unsafety bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9046 Summary: memory unsafety bug Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu Created an attachment (id=6044) --> (http://llvm.org/bugs/attachment.cgi?id=6044) failure-inducing C code We've been seeing some odd compiler hangs and reports of heap corruption from glibc; valgrind says it's a use-after-free problem. Sorry for the not-reduced testcase. regehr at home:~$ valgrind -q --trace-children=yes clang -O2 -w small.c ==30005== Invalid read of size 4 ==30005== at 0x948B53E: llvm::FoldingSetImpl::InsertNode(llvm::FoldingSetImpl::Node*, void*) (in /mnt/z/z/compiler-install/llvm-gcc-r124171-install/bin/clang) ==30005== by 0x4B9DD63: ??? ==30005== Address 0x465e064 is 124 bytes inside a block of size 260 free'd ==30005== at 0x40257ED: free (vg_replace_malloc.c:366) ==30005== by 0x948B4B3: llvm::FoldingSetImpl::GrowHashTable() (in /mnt/z/z/compiler-install/llvm-gcc-r124171-install/bin/clang) ==30005== ==30005== Invalid write of size 4 ==30005== at 0x948B54C: llvm::FoldingSetImpl::InsertNode(llvm::FoldingSetImpl::Node*, void*) (in /mnt/z/z/compiler-install/llvm-gcc-r124171-install/bin/clang) ==30005== by 0x4B9DD63: ??? ==30005== Address 0x465e064 is 124 bytes inside a block of size 260 free'd ==30005== at 0x40257ED: free (vg_replace_malloc.c:366) ==30005== by 0x948B4B3: llvm::FoldingSetImpl::GrowHashTable() (in /mnt/z/z/compiler-install/llvm-gcc-r124171-install/bin/clang) ==30005== regehr at home:~$ regehr at home:~$ regehr at home:~$ regehr at home:~$ clang -v clang version 2.9 (trunk 124171) Target: i386-pc-linux-gnu Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 24 22:40:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 24 Jan 2011 22:40:04 -0600 (CST) Subject: [LLVMbugs] [Bug 9047] New: Poor handling of erroneous return type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9047 Summary: Poor handling of erroneous return type Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com $ cat t2.cc const foo *Bar() { return 42; } $ clang t2.cc t2.cc:3:7: error: unknown type name 'foo' const foo *Bar() { return 42; } ^ t2.cc:3:27: error: cannot initialize return object of type 'const int *' with an rvalue of type 'int' const foo *Bar() { return 42; } ^~ What is this "const int?*" that you speak of?? -Chris -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 25 00:23:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 00:23:34 -0600 (CST) Subject: [LLVMbugs] [Bug 9048] New: Analyzer crash Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9048 Summary: Analyzer crash Product: clang Version: trunk Platform: PC OS/Version: DragonFly BSD Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: swildner at erpicon.de CC: llvmbugs at cs.uiuc.edu Hello, the static analyzer crashes on one of DragonFly's kernel files. See http://yoyodyne.ath.cx/tmp/scan-build-2011-01-24-1/failures/ I've included the offending source file, too. Regards, Sascha -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 04:01:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 04:01:34 -0600 (CST) Subject: [LLVMbugs] [Bug 9049] New: type-dependent attribute evaluated during template definition Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9049 Summary: type-dependent attribute evaluated during template definition Product: clang Version: trunk Platform: Macintosh OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: devlists at shadowlab.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=6045) --> (http://llvm.org/bugs/attachment.cgi?id=6045) Simple test case When using type dependent 'attribute' on a template function, clang checks the type while parsing the template, and not at instantiation, and so may emit invalid diagnostics. For example, in the following case, we are using the 'cf_returns_retained' attribute, which require a pointer return type. As the type is undefined in template definition, the check fails, and clang emits a warning. ----------- attr.cpp extern const void *CFRetain(const void *ref); template __attribute__((cf_returns_retained)) inline T WBCFRetain(T aValue) { return aValue ? (T)CFRetain(aValue) : (T)0; } ------------ > clang++ -fsyntax-only attr.cpp attr.cpp:5:10: warning: 'cf_returns_retained' attribute only applies to functions that return a pointer inline T WBCFRetain(T aValue) { return aValue ? (T)CFRetain(aValue) : (T)0; } ^ 1 warning generated. Note that this problem also occurs if you use attributes on a type-dependent arguments. ----------- attr.cpp extern void CFRelease(const void *ref); template inline void WBCFRelease(__attribute__((cf_consumed)) T aValue) { if(aValue) CFRelease(aValue); } ----------- > clang++ -fsyntax-only attr.cpp attr.cpp:5:54: warning: 'cf_consumed' attribute only applies to pointer parameters inline void WBCFRelease(__attribute__((cf_consumed)) T aValue) { if(aValue) CFRelease(aValue); } ~~~~~~~~~~~ ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 08:49:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 08:49:05 -0600 (CST) Subject: [LLVMbugs] [Bug 9050] New: access specifier ignored for destructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9050 Summary: access specifier ignored for destructor Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: adl at gnu.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang version 2.9 (trunk 123315) Target: i386-pc-linux-gnu % cat test.cc class a { public: void killme() const { delete this; } protected: ~a() { } }; int main() { const a* x = new a; delete x; } % clang++ -Wall -W test.cc % clang++ seems to ignore that "protected:" specifier. Here is the output from g++, for comparison: % g++ -Wall -W test.cc test.cc: In function ?int main()?: test.cc:10: error: ?a::~a()? is protected test.cc:19: error: within this context -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 11:19:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 11:19:21 -0600 (CST) Subject: [LLVMbugs] [Bug 9044] Clang doesn't treat rvalue refs specially during deduction in a declarative context In-Reply-To: References: Message-ID: <20110125171921.296502A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9044 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2011-01-25 11:19:20 CST --- Implemented in r124197. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 11:52:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 11:52:18 -0600 (CST) Subject: [LLVMbugs] [Bug 8629] clang++ fails an assertion In-Reply-To: References: Message-ID: <20110125175218.D7EB42A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8629 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #7 from Douglas Gregor 2011-01-25 11:52:17 CST --- Fixed in r124199. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 13:39:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 13:39:20 -0600 (CST) Subject: [LLVMbugs] [Bug 9031] Small gcc bug fixes from the FSF under GPLv2 In-Reply-To: References: Message-ID: <20110125193920.F0F8D2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9031 Pedro Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #14 from Pedro Giffuni 2011-01-25 13:39:20 CST --- Thnaks! I'll work on the FreeBSD specific issues (mostly configuration changes and I'll submit a new Bug report when I'm done. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 25 13:46:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 13:46:21 -0600 (CST) Subject: [LLVMbugs] [Bug 9051] New: SCEV use after free Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9051 Summary: SCEV use after free Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu $ valgrind opt bugpoint-reduced-simplified.bc -inline -scalarrepl-ssa -early-cse -loop-rotate -loop-unswitch -instcombine -indvars -loop-unroll -constmerge -disable-output ... Invalid read of size 8 at 0x8EED72: llvm::FoldingSetImpl::InsertNode(llvm::FoldingSetImpl::Node*, void*) (FoldingSet.cpp:318) by 0x7589BD: llvm::ScalarEvolution::getTruncateExpr(llvm::SCEV const*, llvm::Type const*) (ScalarEvolution.cpp:870) by 0x757673: llvm::ScalarEvolution::createSCEV(llvm::Value*) (ScalarEvolution.cpp:3510) by 0x75836A: llvm::ScalarEvolution::getSCEV(llvm::Value*) (ScalarEvolution.cpp:2475) by 0x7681AC: llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExitCondICmp(llvm::Loop const*, llvm::ICmpInst*, llvm::BasicBlock*, llvm::BasicBlock*) (ScalarEvolution.cpp:4134) by 0x768C4B: llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExitCond(llvm::Loop const*, llvm::Value*, llvm::BasicBlock*, llvm::BasicBlock*) (ScalarEvolution.cpp:3990) by 0x769122: llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExit(llvm::Loop const*, llvm::BasicBlock*) (ScalarEvolution.cpp:3904) by 0x753C7F: llvm::ScalarEvolution::ComputeBackedgeTakenCount(llvm::Loop const*) (ScalarEvolution.cpp:3818) by 0x753EF6: llvm::ScalarEvolution::getBackedgeTakenInfo(llvm::Loop const*) (ScalarEvolution.cpp:3687) by 0x766398: llvm::ScalarEvolution::getBackedgeTakenCount(llvm::Loop const*) (ScalarEvolution.cpp:3653) by 0x526FCF: (anonymous namespace)::IndVarSimplify::runOnLoop(llvm::Loop*, llvm::LPPassManager&) (IndVarSimplify.cpp:501) by 0x6FFB66: llvm::LPPassManager::runOnFunction(llvm::Function&) (LoopPass.cpp:268) Address 0x5c08a18 is 8 bytes inside a block of size 520 free'd at 0x4C2706D: free (vg_replace_malloc.c:366) by 0x8EEF49: llvm::FoldingSetImpl::GrowHashTable() (FoldingSet.cpp:272) by 0x8EEDC4: llvm::FoldingSetImpl::InsertNode(llvm::FoldingSetImpl::Node*, void*) (FoldingSet.cpp:308) by 0x7589BD: llvm::ScalarEvolution::getTruncateExpr(llvm::SCEV const*, llvm::Type const*) (ScalarEvolution.cpp:870) by 0x7588CD: llvm::ScalarEvolution::getTruncateExpr(llvm::SCEV const*, llvm::Type const*) (ScalarEvolution.cpp:842) by 0x757673: llvm::ScalarEvolution::createSCEV(llvm::Value*) (ScalarEvolution.cpp:3510) by 0x75836A: llvm::ScalarEvolution::getSCEV(llvm::Value*) (ScalarEvolution.cpp:2475) by 0x7681AC: llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExitCondICmp(llvm::Loop const*, llvm::ICmpInst*, llvm::BasicBlock*, llvm::BasicBlock*) (ScalarEvolution.cpp:4134) by 0x768C4B: llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExitCond(llvm::Loop const*, llvm::Value*, llvm::BasicBlock*, llvm::BasicBlock*) (ScalarEvolution.cpp:3990) by 0x769122: llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExit(llvm::Loop const*, llvm::BasicBlock*) (ScalarEvolution.cpp:3904) by 0x753C7F: llvm::ScalarEvolution::ComputeBackedgeTakenCount(llvm::Loop const*) (ScalarEvolution.cpp:3818) by 0x753EF6: llvm::ScalarEvolution::getBackedgeTakenInfo(llvm::Loop const*) (ScalarEvolution.cpp:3687) -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 14:06:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 14:06:36 -0600 (CST) Subject: [LLVMbugs] [Bug 9052] New: Kaleidoscope tutorial: JITed code fails to resolve functions defined in toy.cpp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9052 Summary: Kaleidoscope tutorial: JITed code fails to resolve functions defined in toy.cpp Product: Documentation Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: b42-ml at srck.net CC: llvmbugs at cs.uiuc.edu In chapter 4 (and onwards) of the tutorial, when compiling as suggested: % cd llvm/examples/Kaleidoscope/Chapter4 % g++ -g toy.cpp `llvm-config --cppflags --ldflags --libs core jit native` -O3 -o toy % ./toy ready> extern putchard(x); ready> putchard(42); LLVM ERROR: Program used external function 'putchard' which could not be resolved! When compiled using llvm build system by typing "make" in the directory, the program works as expected. If I add -rdynamic to the g++ command line above, the example also works, however I'm not sure if this is the right solution. SVN revision: 124206 % gcc --version gcc (Debian 4.4.5-8) 4.4.5 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 25 15:10:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 15:10:02 -0600 (CST) Subject: [LLVMbugs] [Bug 9048] Analyzer crash when symbolicating union values In-Reply-To: References: Message-ID: <20110125211002.1CC842A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9048 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Ted Kremenek 2011-01-25 15:10:01 CST --- Fixed here: r124228 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 17:05:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 17:05:20 -0600 (CST) Subject: [LLVMbugs] [Bug 6884] Clang fails to account for no-return destructors in warnings In-Reply-To: References: Message-ID: <20110125230520.CED4C2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6884 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #8 from Ted Kremenek 2011-01-25 17:05:17 CST --- This has become recently unfixed. Turns out test/SemaCXX/return-noreturn.cpp was passing the wrong test flag, so the regression wasn't caught. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 25 21:15:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 21:15:31 -0600 (CST) Subject: [LLVMbugs] [Bug 9054] New: Clang should recognize 'foo-bar' as a typo for 'foo->bar' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9054 Summary: Clang should recognize 'foo-bar' as a typo for 'foo->bar' Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu This would be gravy. struct foo { int bar; }; void test(struct foo *foo) { foo-bar = 0; } Currently this is just an unrecoverable error. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Jan 25 22:04:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 22:04:01 -0600 (CST) Subject: [LLVMbugs] [Bug 8743] Register allocation is invalid with Win64 tailcall jump In-Reply-To: References: Message-ID: <20110126040401.9D4922A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8743 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED AssignedTo|unassignedbugs at nondot.org |geek4civic at gmail.com --- Comment #3 from NAKAMURA Takumi 2011-01-25 22:04:01 CST --- Fixed in r124272. Jakob, thank you! I added a testcase for this, test/CodeGen/X86/tailcall-ri64.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 Tue Jan 25 22:27:26 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 22:27:26 -0600 (CST) Subject: [LLVMbugs] [Bug 7521] [dagcombine] Node was deleted but visit returned new node! In-Reply-To: References: Message-ID: <20110126042726.64EF12A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7521 John Regehr 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 Tue Jan 25 22:44:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 25 Jan 2011 22:44:50 -0600 (CST) Subject: [LLVMbugs] [Bug 9055] New: Node was deleted but visit returned new node! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9055 Summary: Node was deleted but visit returned new node! Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu regehr at home:~/volatile/bugs/tmp350$ clang -O2 small.c clang: DAGCombiner.cpp:980: void::DAGCombiner::Run(llvm::CombineLevel): Assertion `N->getOpcode() != ISD::DELETED_NODE && RV.getNode()->getOpcode() != ISD::DELETED_NODE && "Node was deleted but visit returned new node!"' failed. 0 clang 0x094ab5a8 Stack dump: 0. Program arguments: /mnt/z/z/compiler-install/llvm-gcc-r124277-install/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.20.51 -resource-dir /mnt/z/z/compiler-install/llvm-gcc-r124277-install/bin/../lib/clang/2.9 -O2 -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-vweHAm.o -x c small.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'small.c'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@foo' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) regehr at home:~/volatile/bugs/tmp350$ clang -v clang version 2.9 (trunk 124277) Target: i386-pc-linux-gnu Thread model: posix regehr at home:~/volatile/bugs/tmp350$ cat small.c struct S0 { int f0; signed f1 : 13; signed f2 : 30; }; struct S0 g_98; void func_12 (int p_14, unsigned char p_15); void func_4(struct S0 p_5) { func_12(p_5.f1, g_98.f1); } void foo(void) { func_4(g_98); } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 02:40:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 02:40:57 -0600 (CST) Subject: [LLVMbugs] [Bug 9051] SCEV use after free In-Reply-To: References: Message-ID: <20110126084057.A97592A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9051 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Nick Lewycky 2011-01-26 02:40:57 CST --- Thanks for the report! Fixed in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110124/115722.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 26 02:50:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 02:50:25 -0600 (CST) Subject: [LLVMbugs] [Bug 9056] New: -Wuninitialized false positive with foreach objc construct. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9056 Summary: -Wuninitialized false positive with foreach objc construct. Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: devlists at shadowlab.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6051) --> (http://llvm.org/bugs/attachment.cgi?id=6051) Test case The recent merge of -Wuninitialized-experimental with -Wuninitialized introduces a very annoying false positive. When using the "for in" objc syntax, clang emits a warning. ------------ foreach.m void test() { id collection = 0; for (id obj in collection) { if (0 == obj) break; } } ------------ clang -fsyntax-only -Wuninitialized foreach.m foreach.m:4:8: warning: use of uninitialized variable 'obj' [-Wuninitialized] for (id obj in collection) { ^~~~~~ foreach.m:5:11: note: variable 'obj' is possibly uninitialized when used here if (0 == obj) ^~~ foreach.m:4:14: note: add initialization to silence this warning for (id obj in collection) { ^ = 0 1 warning generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 26 03:39:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 03:39:44 -0600 (CST) Subject: [LLVMbugs] [Bug 9057] New: [REGRESSION] Assertion failed: (AR && "Analysis Resolver is not set"), function initializeAnalysisImpl, file PassManager.cpp, line 1045. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9057 Summary: [REGRESSION] Assertion failed: (AR && "Analysis Resolver is not set"), function initializeAnalysisImpl, file PassManager.cpp, line 1045. 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: ismail at namtrac.org CC: llvmbugs at cs.uiuc.edu This is an interesting problem, to reproduce you will need an exact command line replayed else it won't crash: clang -MD -MP -D_ISOC99_SOURCE -D_BSD_SOURCE -O2 -march=core2 -pipe -D_ISOC99_SOURCE -D_BSD_SOURCE -O2 -march=core2 -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4 -mdynamic-no-pic -I. -Iffmpeg -DPIC -I/usr/X11/include -I/usr/X11/include/freetype2 -I/usr/X11/include -DFF_API_MAX_STREAMS=0 -c -o decode.o decode.c Assertion failed: (AR && "Analysis Resolver is not set"), function initializeAnalysisImpl, file PassManager.cpp, line 1045. 0 clang 0x0000000101509e32 llvm::SmallVectorTemplateBase::grow(unsigned long) + 754 1 clang 0x000000010150ac83 llvm::SmallVectorTemplateBase::grow(unsigned long) + 4419 2 libSystem.B.dylib 0x00007fff885db67a _sigtramp + 26 3 libSystem.B.dylib 0x0000000101e558c0 _sigtramp + 2038932064 4 clang 0x000000010001a762 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 3474 5 clang 0x000000010143746e llvm::BasicBlockPass::~BasicBlockPass() + 13678 6 clang 0x00000001012f1697 llvm::LoopInfoBase::ConsiderForLoop(llvm::BasicBlock*, llvm::DominatorTreeBase&) + 9159 7 clang 0x000000010143bcf0 llvm::BasicBlockPass::~BasicBlockPass() + 32240 8 clang 0x000000010143be0b llvm::BasicBlockPass::~BasicBlockPass() + 32523 9 clang 0x000000010143d98f llvm::BasicBlockPass::~BasicBlockPass() + 39567 10 clang 0x000000010143dc83 llvm::BasicBlockPass::~BasicBlockPass() + 40323 11 clang 0x000000010143dd5d llvm::BasicBlockPass::~BasicBlockPass() + 40541 12 clang 0x0000000100182dfa clang::PCHGenerator::~PCHGenerator() + 5866 13 clang 0x00000001002ace3e clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 286 14 clang 0x00000001002dfc29 llvm::IRBuilder >::CreateAdd(llvm::Value*, llvm::Value*, llvm::Twine const&) + 1033 15 clang 0x00000001002abb8c llvm::IRBuilder >::CreateIsNull(llvm::Value*, llvm::Twine const&) + 3292 16 clang 0x00000001000533b9 llvm::DenseMap, llvm::DenseMapInfo >::grow(unsigned int) + 7673 17 clang 0x0000000100024972 std::_Rb_tree, std::less, std::allocator >::_M_insert_unique(std::string const&) + 2002 18 clang 0x000000010001c5ba std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 11242 19 clang 0x00000001000239a4 std::vector >::operator=(std::vector > const&) + 12196 20 clang 0x000000010001aee4 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 5396 21 clang 0x0000000000000046 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::PassRegistrationListener* const&) + 4294862454 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name decode.c -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17 -resource-dir /usr/local/bin/../lib/clang/2.9 -dependency-file decode.d -MT decode.o -sys-header-deps -MP -D _ISOC99_SOURCE -D _BSD_SOURCE -D _ISOC99_SOURCE -D _BSD_SOURCE -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -D _LARGEFILE64_SOURCE -D PIC -D FF_API_MAX_STREAMS=0 -I libdvdread4 -I . -I ffmpeg -I /usr/X11/include -I /usr/X11/include/freetype2 -I /usr/X11/include -O2 -ferror-limit 19 -fmessage-length 120 -stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -o decode.o -x c decode.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'decode.c'. 4. Running pass 'Loop Pass Manager' on function '@mpeg2_parse' clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) Since I am unable to reproduce the problem with the just preprocessed source I'll be uploading the decode.c and dependencies. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 04:09:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 04:09:54 -0600 (CST) Subject: [LLVMbugs] [Bug 9039] Use after free in reassociate In-Reply-To: References: Message-ID: <20110126100954.565F22A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9039 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Duncan Sands 2011-01-26 04:09:53 CST --- Fixed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110124/115730.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 26 13:09:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 13:09:17 -0600 (CST) Subject: [LLVMbugs] [Bug 9058] New: warn on pointless qualifiers with fixit to remove them Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9058 Summary: warn on pointless qualifiers with fixit to remove them Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu We'd like a warning on the qualifier in code like: bool const f(); void f(const int x); with fixit to remove the dead qualifier. The one use case we want to not break is: void f(int *ptr); void f(int * const ptr) { *ptr++; // the const prevents the typo "ptr++;" } I'm proposing the warning name -Wpointless-qualifier. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 16:19:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 16:19:51 -0600 (CST) Subject: [LLVMbugs] [Bug 9059] New: Attached C++ file crashes clang in SmallVectorTemplateBase code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9059 Summary: Attached C++ file crashes clang in SmallVectorTemplateBase code Product: clang Version: 2.8 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: llvm-bugzilla at larrygritz.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The attachment has a repro case. The code is an excerpt from the Ptex open source project -- http://ptex.us I was running clang/llvm 2.8, direct from the svn repository. Running on OSX (10.6). tar xzvf test.tgz cd test clang -c PtexCache.cpp The stack trace I get is: $ clang -c PtexCache.cpp 0 libLLVM-2.8.dylib 0x000000010113aa12 PrintStackTrace(void*) + 34 1 libLLVM-2.8.dylib 0x000000010113b533 SignalHandler(int) + 531 2 libSystem.B.dylib 0x00007fff8853467a _sigtramp + 26 3 libSystem.B.dylib 0x0000000000000001 _sigtramp + 2007808417 4 clang 0x00000001001976e6 llvm::SmallVectorTemplateBase::grow(unsigned long) + 52022 5 clang 0x00000001001965d5 llvm::SmallVectorTemplateBase::grow(unsigned long) + 47653 6 clang 0x0000000100199a66 llvm::SmallVectorTemplateBase::grow(unsigned long) + 61110 7 clang 0x00000001001cbc5f std::vector >::operator=(std::vector > const&) + 76495 8 clang 0x00000001001c53fd std::vector >::operator=(std::vector > const&) + 49773 9 clang 0x00000001001c5f9e std::vector >::operator=(std::vector > const&) + 52750 10 clang 0x000000010017c7b3 std::vector, std::allocator > >::_M_insert_aux(__gnu_cxx::__normal_iterator*, std::vector, std::allocator > > >, llvm::TrackingVH const&) + 22755 11 clang 0x0000000100226d2b llvm::SmallVectorTemplateBase, false>::grow(unsigned long) + 7019 12 clang 0x000000010022ce6e llvm::SmallVectorTemplateBase, false>::grow(unsigned long) + 31918 13 clang 0x000000010022a5b7 llvm::SmallVectorTemplateBase, false>::grow(unsigned long) + 21495 14 clang 0x000000010022cc9b llvm::SmallVectorTemplateBase, false>::grow(unsigned long) + 31451 15 clang 0x000000010022cf8c llvm::SmallVectorTemplateBase, false>::grow(unsigned long) + 32204 16 clang 0x000000010022a5b7 llvm::SmallVectorTemplateBase, false>::grow(unsigned long) + 21495 17 clang 0x00000001002541da clang::EmitObjAction::~EmitObjAction() + 26554 18 clang 0x000000010025a38f llvm::SmallVectorTemplateBase::grow(unsigned long) + 24607 19 clang 0x000000010025e5eb llvm::SmallVectorTemplateBase::grow(unsigned long) + 41595 20 clang 0x000000010025fdde llvm::SmallVectorTemplateBase::grow(unsigned long) + 47726 21 clang 0x000000010025fe03 llvm::SmallVectorTemplateBase::grow(unsigned long) + 47763 22 clang 0x000000010024c10a void std::__introsort_loop*, long>(std::pair*, std::pair*, long) + 2170 23 clang 0x000000010028a04c llvm::GetElementPtrInst* llvm::GetElementPtrInst::Create(llvm::Value*, llvm::Value**, llvm::Value**, llvm::Twine const&, llvm::Instruction*) + 2252 24 clang 0x000000010024d11d void std::__introsort_loop*, long>(std::pair*, std::pair*, long) + 6285 25 clang 0x000000010002f5a9 std::vector, std::allocator > >::_M_insert_aux(__gnu_cxx::__normal_iterator*, std::vector, std::allocator > > >, std::pair const&) + 11257 26 clang 0x00000001000095e7 std::_Rb_tree, std::less, std::allocator >::_M_erase(std::_Rb_tree_node*) + 2343 27 clang 0x0000000100002440 28 clang 0x00000001000083dd std::vector >::operator=(std::vector > const&) + 10461 29 clang 0x0000000100000f78 30 clang 0x0000000000000024 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name PtexCache.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.14 -resource-dir /usr/local/lib/clang/2.8 -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o PtexCache.o -x c++ PtexCache.cpp 1. parser at end of file 2. Per-file LLVM IR generation 3. ./PtexDict.h:196:14: Generating code for declaration 'PtexDict::erase' 4. ./PtexDict.h:567:1: LLVM IR generation of compound statement ('{}') clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 26 16:36:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 16:36:37 -0600 (CST) Subject: [LLVMbugs] [Bug 9060] New: Late-specified return type accepted for parenthesized declarator Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9060 Summary: Late-specified return type accepted for parenthesized declarator Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub.johannes at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following is not well-formed C++0x according to n3225 auto (n() -> int); You can use late specified return types only on the top-level. So the thing above, and the thing below are not valid auto (*(f() -> int))[1]; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Jan 26 18:49:29 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 18:49:29 -0600 (CST) Subject: [LLVMbugs] [Bug 9061] New: -Wuninitialized false positive Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9061 Summary: -Wuninitialized false positive Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu >From chrome code: bool did_work; for (int i = 0; i < 100; ++i) { DeletePendingTasks(); ReloadWorkQueue(); // If we end up with empty queues, then break out of the loop. did_work = DeletePendingTasks(); if (!did_work) break; } DCHECK(!did_work); clang complains: /Volumes/MacintoshHD2/src/chrome-git/src/base/message_loop.cc:168:3: error: use of uninitialized variable 'did_work' [-Wuninitialized] bool did_work; ^~~~~~~~~~~~~ In file included from /Volumes/MacintoshHD2/src/chrome-git/src/base/message_loop.cc:5: In file included from ../base/message_loop.h:13: In file included from ../base/message_pump.h:9: In file included from ../base/ref_counted.h:9: In file included from ../base/atomic_ref_count.h:15: In file included from ../base/atomicops.h:139: In file included from ../base/atomicops_internals_x86_macosx.h:11: In file included from /Developer/SDKs/MacOSX10.5.sdk/usr/include/libkern/OSAtomic.h:30: /Volumes/MacintoshHD2/src/llvm-svn/Release+Asserts/bin/../lib/clang/2.9/include/stdbool.h:37:15: note: instantiated from: #define bool bool ^ /Volumes/MacintoshHD2/src/chrome-git/src/base/message_loop.cc:177:3: note: variable 'did_work' is possibly uninitialized when used here DCHECK(!did_work); ^~~~~~~~~~~~~~~~~ and suggests adding `= 0`. Two bugs: a) The warning is a false positive b) clang should suggest `= false;` -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 18:54:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 18:54:20 -0600 (CST) Subject: [LLVMbugs] [Bug 9062] New: -Wuninitialized false positive Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9062 Summary: -Wuninitialized false positive Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu chrome code: bool found = false; const char *pair; for (unsigned i = 0; env[i]; i++) { pair = env[i]; const char *const equals = strchr(pair, '='); if (!equals) continue; const unsigned keylen = equals - pair; if (keylen == j->first.size() && memcmp(pair, j->first.data(), keylen) == 0) { found = true; break; } } // if found, we'll either be deleting or replacing this element. if (found) { count--; size -= strlen(pair) + 1; if (j->second.size()) found = false; } clang complains: /Volumes/MacintoshHD2/src/chrome-git/src/base/process_util_posix.cc:378:11: error: use of uninitialized variable 'pair' [-Wuninitialized] const char *pair; ^~~~~~~~~~ /Volumes/MacintoshHD2/src/chrome-git/src/base/process_util_posix.cc:396:22: note: variable 'pair' is possibly uninitialized when used here size -= strlen(pair) + 1; ^~~~ /Volumes/MacintoshHD2/src/chrome-git/src/base/process_util_posix.cc:378:21: note: add initialization to silence this warning const char *pair; ^ = 0 1 error generated. ?but the access happens only if |found| is true, and in that case the pointer is always initialized. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 18:58:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 18:58:05 -0600 (CST) Subject: [LLVMbugs] [Bug 9063] New: -Wuninitialized false positive due to |int var; if (get(&var)) use(var); | pattern Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9063 Summary: -Wuninitialized false positive due to |int var; if (get(&var)) use(var);| pattern Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu In many places, chrome uses code that looks like this: for(..) { double expiry; if (!state->GetReal("expiry", &expiry)) { continue; } base::Time expiry_time = base::Time::FromDoubleT(expiry); } GetReal will write to expiry if it returns true. clang complains: /Volumes/MacintoshHD2/src/chrome-git/src/net/base/transport_security_state.cc:316:5: error: use of uninitialized variable 'expiry' [-Wuninitialized] double expiry; ^~~~~~~~~~~~~ /Volumes/MacintoshHD2/src/chrome-git/src/net/base/transport_security_state.cc:337:54: note: variable 'expiry' is possibly uninitialized when used here base::Time expiry_time = base::Time::FromDoubleT(expiry); ^~~~~~ /Volumes/MacintoshHD2/src/chrome-git/src/net/base/transport_security_state.cc:316:18: note: add initialization to silence this warning double expiry; ^ = 0.0 1 error generated. This causes many many false positives in the chrome codebase. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 19:01:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 19:01:12 -0600 (CST) Subject: [LLVMbugs] [Bug 9064] New: -Wuninitialized doesn't understand ObjC2 loops Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9064 Summary: -Wuninitialized doesn't understand ObjC2 loops Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu code: for (NSString* mime_type in [mime_types allKeys]) { NSDictionary* mime_dict = [mime_types objectForKey:mime_type]; NSString* mime_desc = [mime_dict objectForKey:@"WebPluginTypeDescription"]; NSArray* mime_exts = [mime_dict objectForKey:@"WebPluginExtensions"]; WebPluginMimeType mime; mime.mime_type = base::SysNSStringToUTF8([mime_type lowercaseString]); // Remove PDF from the list of types handled by QuickTime, since it provides // a worse experience than just downloading the PDF. if (mime.mime_type == "application/pdf" && StartsWithASCII(filename.BaseName().value(), "QuickTime", false)) { continue; } } clang suggests: /Volumes/MacintoshHD2/src/chrome-git/src/webkit/support/../plugins/npapi/plugin_lib_mac.mm:88:8: error: use of uninitialized variable 'mime_type' [-Wuninitialized] for (NSString* mime_type in [mime_types allKeys]) { ^~~~~~~~~~~~~~~~~~~ /Volumes/MacintoshHD2/src/chrome-git/src/webkit/support/../plugins/npapi/plugin_lib_mac.mm:89:56: note: variable 'mime_type' is possibly uninitialized when used here NSDictionary* mime_dict = [mime_types objectForKey:mime_type]; ^~~~~~~~~ /Volumes/MacintoshHD2/src/chrome-git/src/webkit/support/../plugins/npapi/plugin_lib_mac.mm:88:27: note: add initialization to silence this warning for (NSString* mime_type in [mime_types allKeys]) { ^ = nil Yikes! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 19:47:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 19:47:17 -0600 (CST) Subject: [LLVMbugs] [Bug 9064] -Wuninitialized doesn't understand ObjC2 loops In-Reply-To: References: Message-ID: <20110127014717.480002A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9064 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Ted Kremenek 2011-01-26 19:47:17 CST --- *** This bug has been marked as a duplicate of bug 9056 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 26 20:02:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 20:02:12 -0600 (CST) Subject: [LLVMbugs] [Bug 9056] -Wuninitialized false positive with foreach objc construct. In-Reply-To: References: Message-ID: <20110127020212.1E42F2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9056 Ted Kremenek 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 Wed Jan 26 23:39:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 26 Jan 2011 23:39:32 -0600 (CST) Subject: [LLVMbugs] [Bug 9065] New: Small incompatibility in "#pragma GCC visibility push" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9065 Summary: Small incompatibility in "#pragma GCC visibility push" Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Compiling ----------------------------------- //void bar(void); #pragma GCC visibility push(hidden) //void bar(void); void foo() { bar(); } ---------------------------------- with -fPIC, both clang and gcc will produce a R_X86_64_PLT32 relocation if the first declaration in uncommented and a R_X86_64_PC32 if the second one. They disagree if both are commented, gcc will produce a R_X86_64_PLT32 and clang a R_X86_64_PC32. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 00:01:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 00:01:09 -0600 (CST) Subject: [LLVMbugs] [Bug 9066] New: visibility of declarations not being output Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9066 Summary: visibility of declarations not being output Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Running llc on ----------------------------- define hidden void @foo() nounwind { entry: call void @bar() ret void } declare hidden void @bar() --------------------------- will produce an assembly file with a ".hidden foo", but no ".hidden 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 Thu Jan 27 01:19:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 01:19:25 -0600 (CST) Subject: [LLVMbugs] [Bug 9067] New: call to stdcall-named function causes AsmParser to choke Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9067 Summary: call to stdcall-named function causes AsmParser to choke 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: pawel.kunio at gmail.com CC: llvmbugs at cs.uiuc.edu Hello, Recently there has been revision 114154 - MC/AsmParser: Add support for 'a + 4 at GOTPCREL' added to the trunk. The submitted patch adds check whether @ suffix is one of list of predefined ones (done in lib/MC/MCParser/AsmParser.cpp around line 512). Code (reformated for bugzilla) goes like this: MCSymbol *Sym = getContext().GetOrCreateSymbol(Split.first); ... MCSymbolRefExpr::VariantKind Variant = MCSymbolRefExpr::getVariantKindForName(Split.second); if (Variant == MCSymbolRefExpr::VK_Invalid) { Variant = MCSymbolRefExpr::VK_None; return TokError("invalid variant '" + Split.second + "'"); } .... Problem is when stdcall function on wincoff gets called from assembly with similar assembly line: calll *_GetTickCount at 0, the '0' after '@' will obviously cause VK_Invalid to be set on Variant, user gets: ... invalid variant '0'. I propose to add a reference to MCAsmInfo to AsmParser, initialize it in constructor and add check for MAI.hasMicrosoftFastStdCallMangling() to AsmParser::ParsePrimaryExpr, then call GetOrCreateSymbol on whole Identifier without splitting it around '@' for wincoff case. I can send patch for revision in around 10 hours. I can then try to support with extensions for cc1as for Wincoff (1 .section doesnt get parsed, 2 zerofill from coffasmparser causes llvm_unreachable). What do You guys think of proposed change? Regards, -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 08:12:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 08:12:54 -0600 (CST) Subject: [LLVMbugs] [Bug 8915] Assertion failure when instantiating member class of class template. In-Reply-To: References: Message-ID: <20110127141254.DF68E2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8915 Enea Zaffanella changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Enea Zaffanella 2011-01-27 08:12:54 CST --- Seems to be fixed in r124358. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 09:14:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 09:14:42 -0600 (CST) Subject: [LLVMbugs] [Bug 9068] New: clang++ crash after instantiation failure in dependently-typed non-type template parameter Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9068 Summary: clang++ crash after instantiation failure in dependently-typed non-type template parameter Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com $ echo 'template struct s {}; int main() { s(); }' | clang++ -xc++ - :1:24: error: a non-type template parameter cannot have type 'double' template struct s {}; int main() { s(); } ^ :1:53: note: while substituting prior template arguments into non-type template parameter 'a' [with T = double] template struct s {}; int main() { s(); } ^~~~~~~~~~~~~ clang: llvm/src/tools/clang/lib/Sema/DeclSpec.cpp:298: bool clang::DeclSpec::SetTypeSpecType(clang::TypeSpecifierType, clang::SourceLocation, const char*&, unsigned int&, clang::ParsedType): Assertion `Rep && "no type provided!"' failed. 0 libLLVM-2.9svn.so 0x00007feaa539f2af 1 libLLVM-2.9svn.so 0x00007feaa53a1522 2 libpthread.so.0 0x00007feaa449c8f0 3 libc.so.6 0x00007feaa378ba75 gsignal + 53 4 libc.so.6 0x00007feaa378f5c0 abort + 384 5 libc.so.6 0x00007feaa3784941 __assert_fail + 241 6 clang 0x00000000007c40e0 clang::DeclSpec::SetTypeSpecType(clang::TypeSpecifierType, clang::SourceLocation, char const*&, unsigned int&, clang::OpaquePtr) + 144 7 clang 0x00000000007ae6d9 clang::Parser::ParseCXXSimpleTypeSpecifier(clang::DeclSpec&) + 921 8 clang 0x00000000007a7485 clang::Parser::ParseCastExpression(bool, bool, bool&, clang::OpaquePtr) + 261 9 clang 0x00000000007a847a clang::Parser::ParseCastExpression(bool, bool, clang::OpaquePtr) + 42 10 clang 0x00000000007a926e clang::Parser::ParseAssignmentExpression() + 30 11 clang 0x00000000007a9749 clang::Parser::ParseExpression() + 9 12 clang 0x000000000078304a clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 442 13 clang 0x0000000000783b24 clang::Parser::ParseCompoundStatementBody(bool) + 404 14 clang 0x0000000000784166 clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 118 15 clang 0x000000000078dd56 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 678 16 clang 0x0000000000794a09 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 1497 17 clang 0x000000000078ca09 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 201 18 clang 0x000000000078cde4 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 372 19 clang 0x000000000078eee5 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList, clang::Parser::ParsingDeclSpec*) + 1493 20 clang 0x000000000078f152 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 114 21 clang 0x0000000000776beb clang::ParseAST(clang::Sema&, bool) + 139 22 clang 0x000000000064b0c4 clang::CodeGenAction::ExecuteAction() + 68 23 clang 0x00000000005420b5 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 24 clang 0x000000000052032c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 25 clang 0x0000000000517e55 cc1_main(char const**, char const**, char const*, void*) + 693 26 clang 0x000000000051f377 main + 4599 27 libc.so.6 0x00007feaa3776c4d __libc_start_main + 253 28 clang 0x0000000000516569 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 09:54:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 09:54:35 -0600 (CST) Subject: [LLVMbugs] [Bug 9069] New: clang_tokenize() returns token for one-past-end token Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9069 Summary: clang_tokenize() returns token for one-past-end token Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: stefan.seefeld at gmail.com CC: llvmbugs at cs.uiuc.edu The clang_tokenize() function returns all tokens falling into a range, but seems to ignore the fact that the range's endpoint is actually outside the ROI. Thus, the generated token-list is one element too long. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 10:05:42 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 10:05:42 -0600 (CST) Subject: [LLVMbugs] [Bug 9070] New: Incorrect code generated from shuffles Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9070 Summary: Incorrect code generated from shuffles Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: zvi.rackover at intel.com CC: llvmbugs at cs.uiuc.edu Running llc on the following test (also attached) gives incorrect generated code: target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i686-pc-win32" define void @test1(<8 x i32>* %source, <2 x i32>* %dest) nounwind { %a149 = getelementptr inbounds <8 x i32>* %source %a150 = load <8 x i32>* %a149, align 32 %a151 = shufflevector <8 x i32> %a150, <8 x i32> undef, <2 x i32> %a152 = shufflevector <2 x i32> %a151, <2 x i32> undef, <2 x i32> %a153 = getelementptr inbounds <2 x i32>* %dest store <2 x i32> %a152, <2 x i32>* %a153, align 8 ret void } The test reads an <8 x i32> source vector from memory and writes a <2 x i32> dest vector to memory. The two shuffles do: temp.0 = source.0 temp.1 = source.5 dest.0 = temp.1 dest.1 = temp.0 Which is equivalent to: dest.0 = source.5 dest.1 = source.0 Output: llc < test-repro.ll .def _test1; .scl 2; .type 32; .endef .text .globl _test1 .align 16, 0x90 _test1: # @test1 # BB#0: movl 4(%esp), %eax movaps 16(%eax), %xmm0 movlps (%eax), %xmm0 pshufd $1, %xmm0, %xmm0 # xmm0 = xmm0[1,0,0,0] movl 8(%esp), %eax pextrd $1, %xmm0, 4(%eax) movd %xmm0, (%eax) ret After the 'movaps': XMM0 = [source.4 source.5 source.6 source.7] After the 'movlps': XMM0 = [source.0 source.1 source.6 source.7] After the 'pshufd': XMM0 = [source.1 source.0 source.0 source.0] The 'pextrd' writes: dest.1 = source.0 The 'movd' writes: dest.0 = source.1 <== This is not correct see explanation of test above. Removing the following pattern from X86InstrSSE.td gives correct (but inefficient) code: def : Pat<(X86Movss VR128:$src1, (bc_v4i32 (v2i64 (load addr:$src2)))), (MOVLPSrm VR128:$src1, addr:$src2)>; -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 10:57:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 10:57:28 -0600 (CST) Subject: [LLVMbugs] [Bug 9071] New: Crash using -Wuninitialized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9071 Summary: Crash using -Wuninitialized Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: abramobagnara at tin.it CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6058) --> (http://llvm.org/bugs/attachment.cgi?id=6058) Source file to be used to reproduce the crash. This is reproducible with clang r124358 $ clang -cc1 -Wuninitialized bug.c clang: UninitializedValuesV2.cpp:162: llvm::BitVector&::CFGBlockValues::getBitVector(const clang::CFGBlock*, const clang::CFGBlock*): Assertion `block->getTerminator()' failed. 0 clang 0x09affbef 1 clang 0x09aff97c 2 0x00f12400 __kernel_sigreturn + 0 3 libc.so.6 0x00255a82 abort + 386 4 libc.so.6 0x0024b718 __assert_fail + 248 5 clang 0x0913653d 6 clang 0x09137934 7 clang 0x09137b71 clang::runUninitializedVariablesAnalysis(clang::DeclContext const&, clang::CFG const&, clang::AnalysisContext&, clang::UninitVariablesHandler&) + 272 8 clang 0x08fd1f7b clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy, clang::Decl const*, clang::QualType) + 701 9 clang 0x08fd2077 clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy, clang::FunctionDecl const*) + 61 10 clang 0x08df3728 clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 1966 11 clang 0x08df2f73 clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*) + 59 12 clang 0x08d46b9e clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 394 13 clang 0x08d4dd77 clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 911 14 clang 0x08d53c3d clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 467 15 clang 0x08d4d954 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 954 16 clang 0x08d4d9c9 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 99 17 clang 0x08d4d378 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2062 18 clang 0x08d4cac7 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 223 19 clang 0x08d357d2 clang::ParseAST(clang::Sema&, bool) + 306 20 clang 0x08ab0201 clang::ASTFrontendAction::ExecuteAction() + 253 21 clang 0x08aafe5c clang::FrontendAction::Execute() + 316 22 clang 0x08a9a23f clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 779 23 clang 0x08a482bf clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 785 24 clang 0x08a3b077 cc1_main(char const**, char const**, char const*, void*) + 1064 25 clang 0x08a43d99 main + 521 26 libc.so.6 0x0023ebd6 __libc_start_main + 230 27 clang 0x08a3a721 Stack dump: 0. Program arguments: clang -cc1 -Wuninitialized bug.c 1. parser at end of file 2. bug.c:2:1: parsing function body 'f' Aborted -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 27 11:44:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 11:44:06 -0600 (CST) Subject: [LLVMbugs] [Bug 9072] New: MinGW-w64 issues Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9072 Summary: MinGW-w64 issues Product: new-bugs Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6059) --> (http://llvm.org/bugs/attachment.cgi?id=6059) patch for the issues listed in the report When compiling LLVM with MinGW-w64, several easy to fix/workaround issues popped up: 1. _WIN32_WINNT redefined 2. lib/support/Windows/DynamicLibrary.inc: bad ifdef for mingw-w64 which needs the function ifdef'ed out 3. explicit symbol declaration for functions not meant to be present on win64 MinGW platforms. 4. tblgen.exe crashes on CellSPU *.inc files I have attached a patch for these issues (except 3). I would be much obliged if applied to trunk. I do not have a clue about number 4, and already opened a bug report about this here: http://llvm.org/bugs/show_bug.cgi?id=8850 Disabling the target in question lets the build continue and finish happily. I will update the bug report with "make check" results. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 11:53:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 11:53:12 -0600 (CST) Subject: [LLVMbugs] [Bug 9073] New: Create corrupted PCH if it includes libc++ file Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9073 Summary: Create corrupted PCH if it includes libc++ file Product: clang Version: trunk Platform: All OS/Version: MacOS X 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=6060) --> (http://llvm.org/bugs/attachment.cgi?id=6060) Test files Precompiling a header that includes from libc++ in c++0x mode generate a 'corrupted' file. When trying to use the generated file, clang assert with the following error: fatal error: malformed or corrupted PCH file: 'incorrect encoding of pack expansion type' The crash append when serializing this variadic template: ------------------------------- memory:3105 template template shared_ptr<_Tp> shared_ptr<_Tp>::make_shared(_Args&& ...__args) { typedef __shared_ptr_emplace<_Tp, allocator<_Tp> > _CntrlBlk; typedef allocator<_CntrlBlk> _A2; typedef __allocator_destructor<_A2> _D2; _A2 __a2; unique_ptr<_CntrlBlk, _D2> __hold2(__a2.allocate(1), _D2(__a2, 1)); ::new(__hold2.get()) _CntrlBlk(__a2, std::__1::forward<_Args>(__args)...); shared_ptr<_Tp> __r; __r.__ptr_ = __hold2.get()->get(); __r.__cntrl_ = __hold2.release(); __r.__enable_weak_this(__r.__ptr_); return __r; } -------------------------------- memory:3121 To reproduce this issue, you can use the attached file: clang version 2.9 (trunk 124376) $ clang -x objective-c++-header -std=c++0x -stdlib=libc++ -c SharedPrefix.h -o SharedPrefix.h.pth $ clang -x objective-c++ -std=c++0x -stdlib=libc++ -include SharedPrefix.h -c src.mm -o src.o fatal error: malformed or corrupted PCH file: 'incorrect encoding of pack expansion type' Assertion failed: (!isNull() && "Cannot retrieve a NULL type pointer"), function getCommonPtr, file /Volumes/MacPro/Projects/OpenSource/llvm/tools/clang/lib/AST/../../include/clang/AST/Type.h, line 388. I also attach SharedPrefix.ii, the preprocessed version of SharedPrefix.h -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 12:51:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 12:51:54 -0600 (CST) Subject: [LLVMbugs] [Bug 9071] Crash using -Wuninitialized when using computed goto In-Reply-To: References: Message-ID: <20110127185154.46E742A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9071 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Ted Kremenek 2011-01-27 12:51:53 CST --- Fixed: r124394 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 15:26:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 15:26:09 -0600 (CST) Subject: [LLVMbugs] [Bug 9074] New: Spurious complaint about discarding attributes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9074 Summary: Spurious complaint about discarding attributes Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tjw at omnigroup.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 Thu Jan 27 16:07:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 16:07:56 -0600 (CST) Subject: [LLVMbugs] [Bug 9075] New: ns_consumed should work with void* pointers. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9075 Summary: ns_consumed should work with void* pointers. Product: clang Version: unspecified Platform: Macintosh OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: bugzilla.llvm.j at ayton.se CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6064) --> (http://llvm.org/bugs/attachment.cgi?id=6064) Test case Many C libraries allow clients to store void * pointers with arbitrary data or pass them through to callbacks. It would be helpful if __attribute__((ns_consumed)) worked in such cases. However, it has no effect on void * pointers in checker-254. I posted an example of such a case here: http://stackoverflow.com/questions/4822178/telling-clang-static-analyzer-about-third-party-libraries-owning-references/ . Ted Kremeneck assumed that ns_consumed would work in this case, but in fact it does not; however, it works in the analogous case using id pointers. The attached test case includes a model of the pattern, once with a void * pointer, once with an id pointer. The checker complains about the void * case, but not the id 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 Thu Jan 27 16:18:22 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 16:18:22 -0600 (CST) Subject: [LLVMbugs] [Bug 9076] New: Spurious warning about uninitialized variable when assigned in condition Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9076 Summary: Spurious warning about uninitialized variable when assigned in condition Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tjw at omnigroup.com CC: llvmbugs at cs.uiuc.edu This construct produces a warning in clang ToT (r124408): int identifier; if ((strcmp(name, "foo") == 0 && (identifier = 1)) || (strcmp(name, "bar") == 0 && (identifier = 2))) { return identifier; } return 0; But the variable is only used on conditional paths were it has been assigned. Obviously this is a little bit of a "clever" use of C and we can restructure our use to avoid it, but it might be nice to handle this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 27 16:32:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 16:32:35 -0600 (CST) Subject: [LLVMbugs] [Bug 8909] explicit move in move_iterator::operator* In-Reply-To: References: Message-ID: <20110127223235.E3DAA2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8909 Marc Glisse changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Marc Glisse 2011-01-27 16:32:35 CST --- I believe this was fixed in r124255. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 27 17:21:07 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 17:21:07 -0600 (CST) Subject: [LLVMbugs] [Bug 9077] New: Obj-C properties named newFoo are treated as returning an owned reference Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9077 Summary: Obj-C properties named newFoo are treated as returning an owned reference 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: kevin at sb.org CC: llvmbugs at cs.uiuc.edu If an Obj-C property is named newFoo, any access to it (e.g. `self.newFoo`) is treated by the static analyzer as returning an owned reference. Properties, by definition, do not return owned references. The SA should be smart enough to implicitly assume any properties are ns_returns_not_retained. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 27 17:25:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 17:25:15 -0600 (CST) Subject: [LLVMbugs] [Bug 9078] New: Plug-in mechanism broken on Windows Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9078 Summary: Plug-in mechanism broken on Windows Product: clang Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: John.Thompson.JTSoftware at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6066) --> (http://llvm.org/bugs/attachment.cgi?id=6066) llvm side In loading a Windows plug-in DLL, the DLL will have it's own copy of the clang library code and data, such that the plug-in registry node list ends up in the DLL and not the Clang executable's data space. Making the Clang library a DLL might make it work. Alternatively, if nothing in clang references changed static data, perhaps it might work if the plug-in can get to the data it needs by the references given to it. The plug-in still needs some way to get the registry info into clang, perhaps by Clang calling a function it looks up in the DLL. As a quick and dirty experiment, I hacked some things (see the attachments up to see if just getting the PrintFunctionNames node into the registry would let the plug-in work, and it seemed to work. Perhaps with some macro magic that defines a unique function based on the plug-in name, the connection could be made that way. Anyway, that's the extent of what I know about it. How does this work on Linux? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 27 17:40:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 17:40:59 -0600 (CST) Subject: [LLVMbugs] [Bug 9079] New: Spurious uninitialized variable warning Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9079 Summary: Spurious uninitialized variable warning Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tjw at omnigroup.com CC: llvmbugs at cs.uiuc.edu If a local is initialized within some 'if' guarded by a condition and later is accessed only if that same condition is true, clang emits a warning. The case I just hit in my code has structure similar to this: int x(int y) { int value; if (y != 0) { value = 0; } switch (y) { case 0: return 1; // handles the uninitialized case default: return value; // can only get here if the value=0 line was executed } } This is probably a duplicate, but this test case may be different enough. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 27 19:24:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 19:24:23 -0600 (CST) Subject: [LLVMbugs] [Bug 9080] New: miscompile under -fomit-frame-pointer on x86-64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9080 Summary: miscompile under -fomit-frame-pointer on x86-64 Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu This C testcase from ffmpeg: #include int avcodec_alloc_context2() { return 123; } int avcodec_alloc_context(void) { return avcodec_alloc_context2(); } int main(void) { int ctx = avcodec_alloc_context(); return printf("%d\n", ctx); } demonstrates some impressive brokenness: nlewycky at ducttape:~$ clang x.c -o x -fomit-frame-pointer nlewycky at ducttape:~$ ./x -1094017336 nlewycky at ducttape:~$ ./x -1472549176 nlewycky at ducttape:~$ ./x 1205477064 The reason is the avcodec_alloc_context function stomping on the return value: avcodec_alloc_context: # @avcodec_alloc_context .Leh_func_begin1: # BB#0: # %entry pushq %rax .Ltmp1: callq avcodec_alloc_context2 popq %rax ret -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 27 20:13:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 20:13:24 -0600 (CST) Subject: [LLVMbugs] [Bug 8948] [MC] .section parsed incorrectly In-Reply-To: References: Message-ID: <20110128021324.EA9372A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8948 J?rg Sonnenberger 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 Jan 27 21:05:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 21:05:18 -0600 (CST) Subject: [LLVMbugs] [Bug 8951] Support for .equiv in integrated assembler In-Reply-To: References: Message-ID: <20110128030518.1E9B72A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8951 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nicolasweber at gmx.de Resolution| |FIXED --- Comment #5 from Nico Weber 2011-01-27 21:05:17 CST --- Patch landed in r124467. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Jan 27 21:22:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 27 Jan 2011 21:22:49 -0600 (CST) Subject: [LLVMbugs] [Bug 9066] visibility of declarations not being output In-Reply-To: References: Message-ID: <20110128032249.E07462A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9066 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Rafael ?vila de Esp?ndola 2011-01-27 21:22:49 CST --- Fixed in 124468. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 00:07:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 00:07:49 -0600 (CST) Subject: [LLVMbugs] [Bug 9037] explicit virtual keywords (override/final/new) not support on inline members In-Reply-To: References: Message-ID: <20110128060749.533C02A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9037 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nicolasweber at gmx.de Resolution| |FIXED --- Comment #3 from Nico Weber 2011-01-28 00:07:49 CST --- r124477 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 03:14:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 03:14:44 -0600 (CST) Subject: [LLVMbugs] [Bug 9081] New: Build failure on arm Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9081 Summary: Build failure on arm Product: libraries Version: trunk Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: scoopr at iki.fi CC: llvmbugs at cs.uiuc.edu I'm compiling llvm on a Tegra2 system, with Ubuntu 10.10 ( gcc 4.4.5). Compiling llvm gives this compile failure: llvm[3]: Compiling ARMInstrInfo.cpp for Release+Asserts build llvm[3]: Compiling ARMJITInfo.cpp for Release+Asserts build /tmp/ccn7l1UL.s: Assembler messages: /tmp/ccn7l1UL.s:31: Error: LR and PC should not both be in register list -- `ldmia sp!,{r0,r1,r2,r3,lr,pc}' make[3]: *** [/home/scoopr/Code/llvm-build/lib/Target/ARM/Release+Asserts/ARMJITInfo.o] Error 1 make[3]: Leaving directory `/home/scoopr/Code/llvm-build/lib/Target/ARM' make[2]: *** [ARM/.makeall] Error 2 make[2]: Leaving directory `/home/scoopr/Code/llvm-build/lib/Target' make[1]: *** [Target/.makeall] Error 2 make[1]: Leaving directory `/home/scoopr/Code/llvm-build/lib' make: *** [all] Error 1 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 03:20:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 03:20:28 -0600 (CST) Subject: [LLVMbugs] [Bug 9082] New: Clang should emit pedantic warnings for conversions to/from pointers to qualifier arrays Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9082 Summary: Clang should emit pedantic warnings for conversions to/from pointers to qualifier arrays Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu According to the C standard, conversions like the following are technically casting away const-ness, because array types are never qualified: qualifiers apply only to the element type. const void * -> const int (*)[5] const int * -> const int (*)[5] Similarly, this is not supposed to be a valid qualification conversion: int (*)[10] -> const int (*)[10] These are kindof arbitrary restrictions that do make life unnecessarily difficult for real users; I think clang's model (where the array and element are simultaneously qualified) really makes a lot more sense. Nonetheless, we should at the very least provide -pedantic warnings about these conversions not being permitted by the standard(s). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 08:20:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 08:20:45 -0600 (CST) Subject: [LLVMbugs] [Bug 8734] [MC assembler] .float not supported In-Reply-To: References: Message-ID: <20110128142045.62DF42A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8734 Roman Divacky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Roman Divacky 2011-01-28 08:20:44 CST --- fixed in 124485. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 09:09:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 09:09:32 -0600 (CST) Subject: [LLVMbugs] [Bug 9083] New: clang_getCursorLexicalParent() doesn't yield translation unit for global declarations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9083 Summary: clang_getCursorLexicalParent() doesn't yield translation unit for global declarations Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: stefan.seefeld at gmail.com CC: llvmbugs at cs.uiuc.edu The documentation for clang_getCursorLexicalParent() states that, for declarations in the global scope, the lexical parent is the translation unit itself. I couldn't reproduce this with any input. Specifically, I tried: CXChildVisitResult my_visitor(CXCursor parent, CXCursor cursor, CXClientData d) { ASGTranslator *translator = static_cast(d); CXCursor tu = clang_getTranslationUnitCursor(translator->tu_); CXCursor lp = clang_getCursorLexicalParent(c); std::cout << "lexical parent equals TU :" << clang_equalCursors(lp, tu) << std::endl; } -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 10:16:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 10:16:27 -0600 (CST) Subject: [LLVMbugs] [Bug 9084] New: building libc++ on Windows with MinGW-w64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9084 Summary: building libc++ on Windows with MinGW-w64 Product: libc++ Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu This bug will depend on all bugs I encounter building libc++ on Windows through CMake with mingw-w64 (GCC 4.5.2) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 10:17:45 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 10:17:45 -0600 (CST) Subject: [LLVMbugs] [Bug 9085] New: "-fPIC" compiler option is used, but has no effect Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9085 Summary: "-fPIC" compiler option is used, but has no effect Product: libc++ Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu The CMake generated makefiles use -fPIC which serves no purpose on Windows. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 10:26:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 10:26:41 -0600 (CST) Subject: [LLVMbugs] [Bug 9086] New: CMake detects wrong Windows/MinGW triplets Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9086 Summary: CMake detects wrong Windows/MinGW triplets Product: libc++ Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu Just like LLVM/Clang, CMake detects the wrong triplets for MinGW-w64 (and others too, looking at the simplicity of the CMake script.) Would it be possible to sync this to the LLVM/Clang version, which works better, as it should? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 10:33:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 10:33:08 -0600 (CST) Subject: [LLVMbugs] [Bug 9087] New: mingw-w64: __include/config tries to include endian.h, which is not present on Windows Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9087 Summary: mingw-w64: __include/config tries to include endian.h, which is not present on Windows Product: libc++ Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6073) --> (http://llvm.org/bugs/attachment.cgi?id=6073) Patch to set Windows to be little endian Title says it all. Wikipedia claims Windows is little endian on all platforms: http://en.wikipedia.org/wiki/Endianness#Bi-endian_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 Fri Jan 28 10:37:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 10:37:14 -0600 (CST) Subject: [LLVMbugs] [Bug 9088] New: Instcombine fails to clear NSW/NUW flags when updating binops in place Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9088 Summary: Instcombine fails to clear NSW/NUW flags when updating binops in place Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu I noticed that InstCombiner::SimplifyAssociativeOrCommutative turns (A * B) * C into A * (B * C) if it can simplify B * C. Rather than creating a new instruction it modifies "A * B" in place, replacing B with whatever "B * C" simplified to. Thus if A * B was marked as not overflowing then the modified instruction will also be marked as not overflowing since the flags are not touched. But as far as I can see that is wrong: the modified instruction could overflow even if the original one could not. This update-in-place scheme seems to be used in a bunch of places in instcombine, so it looks like instcombine needs to be audited and nsw/nuw flags cleared in situations like this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 10:41:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 10:41:39 -0600 (CST) Subject: [LLVMbugs] [Bug 9089] New: mingw-w64: native threading implementation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9089 Summary: mingw-w64: native threading implementation Product: libc++ Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu libc++ can use pthreads, but that would be inefficient on Windows in the long run. Since Vista (NT6), Windows has native support for all the POSIX default multi-threading API that pretty much makes up the C++0x threading support. See for example: http://msdn.microsoft.com/en-us/library/ms682052%28v=vs.85%29.aspx Alternatively, the mingw-w64 project is working on a new pthreads for windows internal library, because pthreads-win32 is awfully old and stale. Mailing list discussion: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-January/012770.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 11:01:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 11:01:09 -0600 (CST) Subject: [LLVMbugs] [Bug 9090] New: mingw-w64: locale implementation depends on POSIX headers and extensions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9090 Summary: mingw-w64: locale implementation depends on POSIX headers and extensions Product: libc++ Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu Windows does not provide nl_types.h and compilation fails because of this. Perhaps a solution is to provide an implementation for Windows, for example KDEWin's: http://lxr.kde.org/source/kdesupport/kdewin-git/include/mingw/nl_types.h MinGW-w64 does not provide xlocale.h. I have contacted the project about 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 Jan 28 11:12:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 11:12:43 -0600 (CST) Subject: [LLVMbugs] [Bug 9081] Build failure on arm In-Reply-To: References: Message-ID: <20110128171243.309602A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9081 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Bob Wilson 2011-01-28 11:12:42 CST --- Mikko, as far as I can tell from your description, this is a bug in the compiler you're using to build llvm, which you say is gcc-4.4.5. Having both LR and PC in the register list for an LDM instruction is either totally invalid (Thumb mode) or deprecated (ARM mode). The compiler should never generate that instruction. Just in case, I took a quick look at LLVM's handling of this, and I don't see any possibility of such an instruction being generated. If you still think this is a bug in LLVM, you'll need to provide a reproducible testcase so we can figure out where it's going wrong. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 11:24:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 11:24:37 -0600 (CST) Subject: [LLVMbugs] [Bug 9081] Build failure on arm In-Reply-To: References: Message-ID: <20110128172437.746942A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9081 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #3 from Anton Korobeynikov 2011-01-28 11:24:37 CST --- Bob, this is a bug in the inline assembler inside ARMJITInfo.cpp -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 11:33:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 11:33:06 -0600 (CST) Subject: [LLVMbugs] [Bug 9091] New: mingw-w64: errno.h misses lots of defines Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9091 Summary: mingw-w64: errno.h misses lots of defines Product: libc++ Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu When including libc++'s , lots of macros aren't defined. LLVM/Clang had the same issue, but that went away with this revision of a file, in which the missing symbols were defined: http://llvm.org/viewvc/llvm-project/llvm/trunk/utils/KillTheDoctor/system_error.h?r1=116597&r2=116596&pathrev=116597 The file has been removed since, and I guess the way of error reporting was changed. Are these really necessary in libc++ anyway? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 11:36:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 11:36:55 -0600 (CST) Subject: [LLVMbugs] [Bug 9092] New: GCC 4.5 build failure in Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9092 Summary: GCC 4.5 build failure in Product: libc++ Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: vanboxem.ruben at gmail.com CC: llvmbugs at cs.uiuc.edu My GCC 4.5.2 fails on this file: M:\Development\Source\libcxx\include/exception: In member function 'std::exception_ptr::operator bool() const': M:\Development\Source\libcxx\include/exception:134:49: error: no match for 'operator!=' in '((const std::exception_ptr*)this)->std::exception_ptr::__ptr_ != std::__1::__get_nullptr_t()' M:\Development\Source\libcxx\include/cstddef:76:39: note: candidate is: bool std::__1::operator!=(std::__1::nullptr_t, std::__1::nullptr_t) In file included from M:\Development\Source\libcxx\include/__locale:23:0, from M:\Development\Source\libcxx\include/ios:216, from M:\Development\Source\libcxx\include/ostream:130, from M:\Development\Source\libcxx\include/istream:156, from M:\Development\Source\libcxx\include/random:1645, from M:\Development\Source\libcxx\src\algorithm.cpp:11: -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 11:51:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 11:51:00 -0600 (CST) Subject: [LLVMbugs] [Bug 9030] ARM disassembler failed to disassemble "mov pc, lr" In-Reply-To: References: Message-ID: <20110128175100.D5F422A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9030 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bob.wilson at apple.com Resolution| |FIXED --- Comment #1 from Bob Wilson 2011-01-28 11:51:00 CST --- Patch applied in svn 124492 (along with a testcase for this). Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 13:30:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 13:30:19 -0600 (CST) Subject: [LLVMbugs] [Bug 9093] New: error in hello world Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9093 Summary: error in hello world Product: Documentation Version: 2.7 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: physci at gmail.com CC: llvmbugs at cs.uiuc.edu Hi, at this page in the docs: http://llvm.org/docs/LangRef.html#highlevel There is a hello world program. On line two I think there should be a space between 'internal' and 'constant'. @.LC0 = internalconstant[13 x i8] c"hello world\0A\00" ; [13 x i8]* -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 13:37:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 13:37:32 -0600 (CST) Subject: [LLVMbugs] [Bug 9094] New: Assigning to self twice in init provokes spurious warning about not assigning at all Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9094 Summary: Assigning to self twice in init provokes spurious warning about not assigning at all Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tjw at omnigroup.com CC: llvmbugs at cs.uiuc.edu A common pattern in classes with multiple initializers (for example NSView with -initWithFrame: and -initWithCoder:) is to put the subclass's common initialization bits into a static function. If you structure this so that the common init can fail and return nil, then you can end up with something like this: - init; { if (!(self = [super init])) return nil; if (!(self = _commonInit(self))) return nil; return self; } This provokes a warning about never having assigned self before returning it, which is not true: double-assign-self.m:28:5: warning: Returning 'self' before setting it to the result of '[(super or self) init...]' -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 14:09:16 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 14:09:16 -0600 (CST) Subject: [LLVMbugs] [Bug 9095] New: Most vexing parse only reported on local variables Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9095 Summary: Most vexing parse only reported on local variables Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In ------------------- struct foo { }; struct bar { bar(foo x); }; bar y(foo()); int main(void) { bar x(foo()); return 0; } ----------------- clang reports: -------------------- test.cc:11:8: warning: parentheses were disambiguated as a function declarator bar x(foo()); ^~~~~~~ -------------------- but no warning is printed for y. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 14:25:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 14:25:54 -0600 (CST) Subject: [LLVMbugs] [Bug 9059] Attached C++ file crashes clang in SmallVectorTemplateBase code In-Reply-To: References: Message-ID: <20110128202554.232E72A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9059 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 15:38:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 15:38:36 -0600 (CST) Subject: [LLVMbugs] [Bug 9096] New: list::iterator not default constructible Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9096 Summary: list::iterator not default constructible Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu Hello, I believe list::iterator is supposed to be a forward iterator and thus default constructible. However, that doesn't seem to be the case currently in libc++ (__list_iterator has a constructor specified, so the default one isn't 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 Jan 28 16:38:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 16:38:31 -0600 (CST) Subject: [LLVMbugs] [Bug 8734] [MC assembler] .float not supported In-Reply-To: References: Message-ID: <20110128223831.14CCC2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8734 Pawel Worach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Pawel Worach 2011-01-28 16:38:30 CST --- This still has issues with .float as used in Mesa. clang -c -I../../include -I../../src/mesa -I../../src/mesa/main -I/usr/local/include -O2 -pipe -fno-strict-aliasing -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING x86-64/xform4.S -o x86-64/xform4.o /tmp/cc-qEQXDZ.s:99:9: error: unexpected token in directive .float 0f+1.0 ^ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 16:50:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 16:50:59 -0600 (CST) Subject: [LLVMbugs] [Bug 9097] New: FreeBSD updates and enhancements Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9097 Summary: FreeBSD updates and enhancements Product: tools Version: 2.8 Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: giffunip at tutopia.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6075) --> (http://llvm.org/bugs/attachment.cgi?id=6075) Patchset based on the BSD trees. The patch contains updates taken mostly from FreeBSD's source tree. Other platforms shouldn't be affected. The main new feature is the addition of -fformat-extensions, required to build the FreeBSD kernel and also available on clang. The FreeBSD specs also required some twitches for building kernels but that it confirmed to work. FreeBSD will now use the Solaris threading model, as was done upstream (in both FreeBSD and gcc). I also added the -Wtrampolines and some bug fixes from OpenBSD. Also, while here, I added a couple of really minor fixes that were left out of bug 9031. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 17:05:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 17:05:04 -0600 (CST) Subject: [LLVMbugs] [Bug 9098] New: diagnose obvious array out of bounds access Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9098 Summary: diagnose obvious array out of bounds access Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Code like this: char foo[100]; foo[100] = '\0'; should win a diagnostic about the array out of bounds access. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 17:47:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 17:47:00 -0600 (CST) Subject: [LLVMbugs] [Bug 9096] list::iterator not default constructible In-Reply-To: References: Message-ID: <20110128234700.CE2FD2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9096 Howard Hinnant changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Howard Hinnant 2011-01-28 17:47:00 CST --- Thanks Marc. Committed revision 124508. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 19:10:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 19:10:30 -0600 (CST) Subject: [LLVMbugs] [Bug 9093] error in hello world In-Reply-To: References: Message-ID: <20110129011030.8CECC2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9093 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nlewycky at google.com Resolution| |FIXED --- Comment #1 from Nick Lewycky 2011-01-28 19:10:30 CST --- Fixed. Thanks for the bug report! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 20:28:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 20:28:40 -0600 (CST) Subject: [LLVMbugs] [Bug 7838] unable to generate code for llvm.smul.with.overflow.i64 on x86-32 In-Reply-To: References: Message-ID: <20110129022840.190042A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7838 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |evan.cheng at apple.com Resolution| |FIXED --- Comment #12 from Evan Cheng 2011-01-28 20:28:38 CST --- I believe Eric C. fixed it recently. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 28 22:25:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 22:25:27 -0600 (CST) Subject: [LLVMbugs] [Bug 9099] New: [META][Win] Testing issues for LLVM on Windows hosts Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9099 Summary: [META][Win] Testing issues for LLVM on Windows hosts Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: ASSIGNED Severity: normal Priority: P Component: new bugs AssignedTo: geek4civic at gmail.com ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu, vanboxem.ruben at gmail.com Depends on: 3739,6745,8311 Blocks: 8390,9072 Some issues are here; - X86(esp. X86-64) CodeGen (and triplet inference) - MSVCRT stuff - Win32 API specific issues - lit with python/w32 I have several patches for this, though, I have to open this till all my patches would be committed. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Jan 28 23:03:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 28 Jan 2011 23:03:50 -0600 (CST) Subject: [LLVMbugs] [Bug 9100] New: [META][Win64] Selfhosting clang/llvm on/for Windows x64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9100 Summary: [META][Win64] Selfhosting clang/llvm on/for Windows x64 Product: new-bugs Version: trunk Platform: PC OS/Version: Windows XP Status: ASSIGNED Severity: normal Priority: P Component: new bugs AssignedTo: geek4civic at gmail.com ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu Depends on: 5005,8390,8777,8778,8787,8833,8922,9010,9072 Known issues(clang); - LLP64 stuff - Noncommittal "MinGW32" and "MinGW64". - toolchain - include and library path - when will we get rid of G++'s libstdc++? - compatibility to mingw64-gcc(predefined macros, ABI, ...) Known issues(llvm); - X86-64 CodeGen - stack frame - tailcall - varargs - JIT - stub - symbol resolution in JIT - Debugging (eg. stack frame dump) stuff -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 29 08:41:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 Jan 2011 08:41:52 -0600 (CST) Subject: [LLVMbugs] [Bug 9101] New: Missing 'thiscall' calling convention in LangRef.html Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9101 Summary: Missing 'thiscall' calling convention in LangRef.html Product: new-bugs Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: eugeny.grishul at gmail.com CC: llvmbugs at cs.uiuc.edu In new features I saw "The X86 backend now supports the Microsoft 'thiscall' calling convention, and a calling convention to support ghc." But http://llvm.org/docs/LangRef.html#callingconv has no mention about it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 29 10:05:52 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 Jan 2011 10:05:52 -0600 (CST) Subject: [LLVMbugs] [Bug 9102] New: [analyzer] set-xcode-analyzer requires sudo Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9102 Summary: [analyzer] set-xcode-analyzer requires sudo Product: Documentation Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: publicposting at lapcatsoftware.com CC: llvmbugs at cs.uiuc.edu The documentation on http://clang-analyzer.llvm.org/xcode.html tells how to use a static analyzer build in Xcode. However, the instructions for using set-xcode-analyzer do not work. The problem is that "/Developer/Library/Xcode/Plug-ins/Clang LLVM 1.0.xcplugin/Contents/Resources/Clang LLVM 1.0.xcspec" is owned by root. Thus, you need to call "sudo set-xcode-analyzer". -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 29 11:13:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 Jan 2011 11:13:49 -0600 (CST) Subject: [LLVMbugs] [Bug 9103] New: encapsulation and friend functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9103 Summary: encapsulation and friend functions Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: tim at klingt.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com this code does not compile with clang++, although it does with g++, icc and comeau's online compiler: struct base { protected: static void foo(void) {} }; struct cls: base { friend void bar(void) { base::foo(); } }; clang++ complains with: x.cpp:11:15: error: 'foo' is a protected member of 'base' base::foo(); ^ x.cpp:4:17: note: declared protected here static void foo(void) {} ^ 1 error generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Jan 29 15:38:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 Jan 2011 15:38:35 -0600 (CST) Subject: [LLVMbugs] [Bug 9104] New: DwarfDebug no longer allows 16-bit language IDs Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9104 Summary: DwarfDebug no longer allows 16-bit language IDs 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: viridia at gmail.com CC: llvmbugs at cs.uiuc.edu My frontend specifies a language ID of DW_LANG_lo_user, which has the value of 0x8000. However, when I do this, I get the following assertion failure: llc: /home/talin/Projects/llvm/lib/MC/MCStreamer.cpp:52: virtual void llvm::MCStreamer::EmitIntValue(uint64_t, unsigned int, unsigned int): Assertion `(isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) && "Invalid size"' failed. This appears to be new behavior, as the code was working before. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 29 15:54:54 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 Jan 2011 15:54:54 -0600 (CST) Subject: [LLVMbugs] [Bug 9105] New: incomplete inline namespace Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9105 Summary: incomplete inline namespace Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Hello, I believe inline namespaces are supposed to allow specialization. (noticed with libc++ in code that specializes std::swap (yes it should overload instead)) inline namespace N { template void f(T&); } template<> void f(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 Sat Jan 29 16:10:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 Jan 2011 16:10:57 -0600 (CST) Subject: [LLVMbugs] [Bug 9106] New: qualify calls to addressof Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9106 Summary: qualify calls to addressof Product: libc++ Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: All Bugs AssignedTo: hhinnant at apple.com ReportedBy: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu libc++ calls addressof without explicitly qualifying it as std::addressof. This causes ambiguities with boost::addressof. Arguably boost should just (and probably does in recent enough versions) use the std version instead of providing its own, but I don't think it is illegal to have addressof functions in other namespaces. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 29 18:11:34 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 29 Jan 2011 18:11:34 -0600 (CST) Subject: [LLVMbugs] [Bug 9107] New: addressof(enum) assertion failure Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9107 Summary: addressof(enum) assertion failure Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: marc.glisse at normalesup.org CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com enum E {}; template inline _Tp* addressof(_Tp& __x) { return (_Tp*)&(char&)__x; } void test () { E a; addressof(a); } $ clang++ -std=c++0x -c a.cc clang: /data/repos/llvm/tools/clang/lib/Sema/SemaCXXCast.cpp:612: TryCastResult TryStaticCast(clang::Sema&, clang::Expr*&, clang::QualType, bool, const clang::SourceRange&, unsigned int&, clang::CastKind&, clang::CXXCastPath&): Assertion `SrcType->getAs()->getDecl()->isScoped()' failed. 0 clang 0x000000000177ebcf 1 clang 0x0000000001780e32 2 libpthread.so.0 0x00007f886d8b0f60 3 libc.so.6 0x00007f886cbc3165 gsignal + 53 4 libc.so.6 0x00007f886cbc5f70 abort + 384 5 libc.so.6 0x00007f886cbbc2b1 __assert_fail + 241 6 clang 0x0000000000914943 7 clang 0x0000000000914bf8 clang::Sema::CXXCheckCStyleCast(clang::SourceRange, clang::QualType, clang::ExprValueKind&, clang::Expr*&, clang::CastKind&, llvm::SmallVector&, bool) + 680 8 clang 0x00000000009f6109 clang::Sema::CheckCastTypes(clang::SourceRange, clang::QualType, clang::Expr*&, clang::CastKind&, clang::ExprValueKind&, llvm::SmallVector&, bool) + 329 9 clang 0x00000000009f687d clang::Sema::BuildCStyleCastExpr(clang::SourceLocation, clang::TypeSourceInfo*, clang::SourceLocation, clang::Expr*) + 157 10 clang 0x0000000000ae5e93 11 clang 0x0000000000ad450d 12 clang 0x0000000000ae9613 13 clang 0x0000000000ad3c3d 14 clang 0x0000000000ae5e6d 15 clang 0x0000000000ad450d 16 clang 0x0000000000ae05b8 17 clang 0x0000000000ae11d4 18 clang 0x0000000000ae0860 19 clang 0x0000000000ae1b4d clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) + 45 20 clang 0x0000000000af63f1 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 1073 21 clang 0x0000000000af693d clang::Sema::PerformPendingInstantiations(bool) + 365 22 clang 0x00000000008ffe22 clang::Sema::ActOnEndOfTranslationUnit() + 306 23 clang 0x00000000008c40f8 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 200 24 clang 0x00000000008ab153 clang::ParseAST(clang::Sema&, bool) + 147 25 clang 0x000000000078a4e4 clang::CodeGenAction::ExecuteAction() + 68 26 clang 0x000000000067a405 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 27 clang 0x0000000000657fbc clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 28 clang 0x000000000064f915 cc1_main(char const**, char const**, char const*, void*) + 677 29 clang 0x0000000000656fc5 main + 4549 30 libc.so.6 0x00007f886cbafc4d __libc_start_main + 253 31 clang 0x000000000064df79 Stack dump: 0. Program arguments: /tmp/clang/inst/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name a.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /tmp/clang/inst/bin/../lib/clang/2.9 -std=c++0x -ferror-limit 19 -fmessage-length 0 -fexceptions -fgnu-runtime -fdiagnostics-show-option -o a.o -x c++ a.cc 1. parser at end of file 2. a.cc:2:34: instantiating function definition 'addressof' -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 14:40:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 Jan 2011 14:40:40 -0600 (CST) Subject: [LLVMbugs] [Bug 9108] New: Assertion in thumb mode Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9108 Summary: Assertion in thumb mode Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: asl at math.spbu.ru CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6079) --> (http://llvm.org/bugs/attachment.cgi?id=6079) Testcase This is a reduction from llvm-gcc compilation for arm-linux. We're having: ./llc bugpoint-reduced-simplified.bc Assertion failed: (!isDeadObjectIndex(ObjectIdx) && "Getting frame offset for a dead object?"), function getObjectOffset, file /Users/asl/Projects/llvm/src-git/include/llvm/CodeGen/MachineFrameInfo.h, line 371. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 17:20:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 Jan 2011 17:20:51 -0600 (CST) Subject: [LLVMbugs] [Bug 9109] New: [patch] FIx of the shared library link on Solaris Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9109 Summary: [patch] FIx of the shared library link on Solaris Product: libraries Version: trunk Platform: PC OS/Version: Solaris Status: NEW Severity: normal Priority: P Component: System Library AssignedTo: unassignedbugs at nondot.org ReportedBy: yuri at tsoft.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6081) --> (http://llvm.org/bugs/attachment.cgi?id=6081) Patch Please check in this patch that fixes Solaris shared library linking. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 30 17:58:58 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 30 Jan 2011 17:58:58 -0600 (CST) Subject: [LLVMbugs] [Bug 9110] New: clang_getCursorExtent(clang_getTranslationUnitCursor(tu)) yields invalid (empty) range Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9110 Summary: clang_getCursorExtent(clang_getTranslationUnitCursor(t u)) yields invalid (empty) range Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: stefan.seefeld at gmail.com CC: llvmbugs at cs.uiuc.edu Just what the summary implies: Constructing a range from an entire translation unit yields a range with start and end position set to '0'. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 31 10:53:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 Jan 2011 10:53:46 -0600 (CST) Subject: [LLVMbugs] [Bug 9008] false unused variable warning when variable exclusively used within sizeof In-Reply-To: References: Message-ID: <20110131165346.670732A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9008 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #4 from Argyrios Kyrtzidis 2011-01-31 10:53:45 CST --- The warning is valid, the array should be removed since it is not actually used. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 31 12:21:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 Jan 2011 12:21:08 -0600 (CST) Subject: [LLVMbugs] [Bug 9111] New: SystemZ assembly syntax problem Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9111 Summary: SystemZ assembly syntax problem Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: SystemZ AssignedTo: unassignedbugs at nondot.org ReportedBy: bagel99 at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=6082) --> (http://llvm.org/bugs/attachment.cgi?id=6082) minimal test case The output from the SystemZ backend gives fatal errors when trying to assemble with the GNU binutils 2.20.51.20100224 assembler for s390x. This happens when assembling the output of the distributed test cases for SystemZ. A minimal test case is attached. I'll attach the -debug output from llc next. $ llc -march=systemz RetImm16LL.ll $ s390x-as -m64 -march=z900 RetImm16LL.s RetImm16LL.s: Assembler messages: RetImm16LL.s:8: Error: operand out of range (0xffffffffffffffff is not between 0x0000000000000000 and 0x000000000000ffff) In RetImm16LL.s the line llill %r2, -1 should be llill %r2, 65535 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 13:51:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 Jan 2011 13:51:08 -0600 (CST) Subject: [LLVMbugs] [Bug 9079] Spurious uninitialized variable warning In-Reply-To: References: Message-ID: <20110131195108.719692A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9079 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Chris Lattner 2011-01-31 13:51:08 CST --- The compilers uninitialized variable stuff should never catch this case. It should be simple, predictable, and stable across revisions of the compiler. The static analyzer is where the intelligence should go. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 14:21:14 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 Jan 2011 14:21:14 -0600 (CST) Subject: [LLVMbugs] [Bug 8575] Change canonical form of multiple-return functions to have a single ret. In-Reply-To: References: Message-ID: <20110131202114.E1C122A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8575 Evan Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Evan Cheng 2011-01-31 14:21:14 CST --- Yep. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 14:59:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 Jan 2011 14:59:01 -0600 (CST) Subject: [LLVMbugs] [Bug 9102] [analyzer] set-xcode-analyzer requires sudo In-Reply-To: References: Message-ID: <20110131205901.BB4C22A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=9102 Ted Kremenek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Ted Kremenek 2011-01-31 14:59:01 CST --- Documentation added here: r124602 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Jan 31 15:46:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 Jan 2011 15:46:20 -0600 (CST) Subject: [LLVMbugs] [Bug 9112] New: Assertion `(KnownZero2 & KnownOne2) == 0 && "Bits known to be one AND zero?"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9112 Summary: Assertion `(KnownZero2 & KnownOne2) == 0 && "Bits known to be one AND zero?"' failed. Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu [regehr at gamow tmp446]$ clang -O2 -c small.c clang: ValueTracking.cpp:410: void llvm::ComputeMaskedBits(llvm::Value*, const llvm::APInt&, llvm::APInt&, llvm::APInt&, const llvm::TargetData*, unsigned int): Assertion `(KnownZero2 & KnownOne2) == 0 && "Bits known to be one AND zero?"' failed. 0 clang 0x00000000017e44df 1 clang 0x00000000017e6752 2 libpthread.so.0 0x00007ffff7bd2190 3 libc.so.6 0x00007ffff6ed74b5 gsignal + 53 4 libc.so.6 0x00007ffff6edaf50 abort + 384 5 libc.so.6 0x00007ffff6ed0481 __assert_fail + 241 6 clang 0x0000000001674027 llvm::ComputeMaskedBits(llvm::Value*, llvm::APInt const&, llvm::APInt&, llvm::APInt&, llvm::TargetData const*, unsigned int) + 12199 7 clang 0x000000000167625e llvm::ComputeSignBit(llvm::Value*, bool&, bool&, llvm::TargetData const*, unsigned int) + 622 8 clang 0x0000000001607158 9 clang 0x0000000001608d26 10 clang 0x0000000001607205 11 clang 0x0000000001608681 llvm::SimplifyInstruction(llvm::Instruction*, llvm::TargetData const*, llvm::DominatorTree const*) + 1313 12 clang 0x00000000015ad7e1 llvm::SimplifyInstructionsInBlock(llvm::BasicBlock*, llvm::TargetData const*) + 193 13 clang 0x00000000014db7d5 14 clang 0x00000000014dd9b5 15 clang 0x00000000014de3bd 16 clang 0x000000000172dbad llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 17 clang 0x00000000015dbeab 18 clang 0x00000000015dc605 19 clang 0x000000000172f3d4 llvm::MPPassManager::runOnModule(llvm::Module&) + 500 20 clang 0x000000000172f547 llvm::PassManagerImpl::run(llvm::Module&) + 167 21 clang 0x00000000008136a9 clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&, clang::TargetOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1625 22 clang 0x0000000000810a1b clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251 23 clang 0x000000000092c403 clang::ParseAST(clang::Sema&, bool) + 291 24 clang 0x0000000000810194 clang::CodeGenAction::ExecuteAction() + 68 25 clang 0x00000000006ff815 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 26 clang 0x00000000006d9c8c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 27 clang 0x00000000006d147b cc1_main(char const**, char const**, char const*, void*) + 539 28 clang 0x00000000006d8dcd main + 4605 29 libc.so.6 0x00007ffff6ec2abd __libc_start_main + 253 30 clang 0x00000000006cfc59 Stack dump: 0. Program arguments: /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r124573-install/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20 -resource-dir /uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r124573-install/bin/../lib/clang/2.9 -O2 -ferror-limit 19 -fmessage-length 99 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Jump Threading' on function '@func' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) [regehr at gamow tmp446]$ clang -v clang version 2.9 (trunk 124573) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp446]$ cat small.c int safe (void); static unsigned short foo (unsigned short ui1, unsigned char ui2) { return ui1 + ui2; } struct S0 { unsigned char f3; unsigned char f9; }; struct S2 { short f5; }; struct S0 g_4 = { 0, 0 }; volatile struct S0 g_93 = { 0, 0 }; unsigned char *g_211 = &g_4.f3; unsigned char **g = &g_211; struct S2 g_412 = { 0 }; int func_37 (void) { lbl_510: if (foo (0, 1)) goto lbl_510; return 0; } void func (void) { if (func_37 ()) for (;; g_93.f9) for (g_412.f5 = 0; g_412.f5 < 0; g_412.f5 = foo (g_412.f5, 0)) { } } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 31 15:50:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 Jan 2011 15:50:21 -0600 (CST) Subject: [LLVMbugs] [Bug 9113] New: likely integer wrong code bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9113 Summary: likely integer wrong code bug Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: regehr at cs.utah.edu CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu [regehr at gamow tmp447]$ clang -O0 small.c -o small [regehr at gamow tmp447]$ ./small 1 [regehr at gamow tmp447]$ clang -O1 small.c -o small [regehr at gamow tmp447]$ ./small 169 [regehr at gamow tmp447]$ clang -v clang version 2.9 (trunk 124573) Target: x86_64-unknown-linux-gnu Thread model: posix [regehr at gamow tmp447]$ cat small.c int printf(const char *format, ...); char g_14 = 0; int main(void) { unsigned int l_1 = 0; unsigned char l_2 = 0; l_1 = (g_14 / 5) != (unsigned char)g_14; l_2 = l_1 + ((1 + g_14) ^ g_14); printf("%d\n", l_2); return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Jan 31 17:30:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 31 Jan 2011 17:30:59 -0600 (CST) Subject: [LLVMbugs] [Bug 9114] New: Clang a bit too strict about types being complete Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9114 Summary: Clang a bit too strict about types being complete Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code is accepted by gcc but rejected by clang. Uncommenting the declaration of ~baz causes clang to accept it. Uncommenting the definition of ~baz causes gcc to reject it. template struct foo { T* p; ~foo() { p->x(); } }; struct bar{ virtual ~bar(); }; struct zed; struct baz : public bar { virtual void x(); //virtual ~baz(); //virtual ~baz() {} foo m; }; void f() { foo s; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.