From bugzilla-daemon at llvm.org Tue Nov 1 00:11:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 05:11:41 +0000 Subject: [LLVMbugs] [Bug 11201] LLVM_ETCDIR (used in Path.cpp) results in path being hard-coded into object file In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11201 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Eli Friedman 2011-11-01 00:11:41 CDT --- r143452. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 05:45:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 10:45:19 +0000 Subject: [LLVMbugs] [Bug 11282] New: ExplodedGraph.h:95 -- void clang::ento::ExplodedNode::NodeGroup::setFlag(): Assertion `P == 0' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11282 Bug #: 11282 Summary: ExplodedGraph.h:95 -- void clang::ento::ExplodedNode::NodeGroup::setFlag(): Assertion `P == 0' failed. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: dimhen at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ clang --version clang version 3.1 (trunk 143455) Target: x86_64-unknown-linux-gnu Thread model: posix compiled by $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/dim/src/gcc-current/configure --prefix=/usr/local/gcc_current --with-multilib-list=m64 --enable-__cxa_atexit --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=df,rtl,fold,yes --with-system-zlib --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,lto --enable-plugin --with-tune=generic --enable-version-specific-runtime-libs Thread model: posix gcc version 4.7.0 20111031 (experimental) [trunk revision 180696] (GCC) $ uname -a Linux dim.cp.ru 2.6.40.6-0.fc15.x86_64 #1 SMP Tue Oct 4 00:39:50 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux $ cat tsts.c extern int foo(); extern int* baz(); extern int n; void bar(int *x) { int *pm; if(n*2) { int *pk = baz(); pm = pk; } do { *x = foo(); } while (0); } $ clang -cc1 -analyze -analyzer-checker=core tsts.c clang: /home/dim/src/llvm/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h:95: void clang::ento::ExplodedNode::NodeGroup::setFlag(): Assertion `P == 0' failed. 0 clang 0x00000000019c39cf 1 clang 0x00000000019c3eb9 2 libpthread.so.0 0x00000035a4e0eef0 3 libc.so.6 0x00000035a4a352d5 gsignal + 53 4 libc.so.6 0x00000035a4a36beb abort + 379 5 libc.so.6 0x00000035a4a2dc5e 6 libc.so.6 0x00000035a4a2dd02 7 clang 0x0000000000daa8bc clang::ento::NodeBuilder::generateNodeImpl(clang::ProgramPoint const&, clang::ento::ProgramState const*, clang::ento::ExplodedNode*, bool) + 236 8 clang 0x0000000000cd825d 9 clang 0x0000000000cd90cf 10 clang 0x0000000000d9f7eb clang::ento::CheckerManager::runCheckersForLocation(clang::ento::ExplodedNodeSet&, clang::ento::ExplodedNodeSet const&, clang::ento::SVal, bool, clang::Stmt const*, clang::ento::ExprEngine&) + 1307 11 clang 0x0000000000dbd51b clang::ento::ExprEngine::evalLocation(clang::ento::ExplodedNodeSet&, clang::Stmt const*, clang::ento::ExplodedNode*, clang::ento::ProgramState const*, clang::ento::SVal, clang::ProgramPointTag const*, bool) + 699 12 clang 0x0000000000dbe447 clang::ento::ExprEngine::evalStore(clang::ento::ExplodedNodeSet&, clang::Expr const*, clang::Expr const*, clang::ento::ExplodedNode*, clang::ento::ProgramState const*, clang::ento::SVal, clang::ento::SVal, clang::ProgramPointTag const*) + 279 13 clang 0x0000000000dc750a clang::ento::ExprEngine::VisitBinaryOperator(clang::BinaryOperator const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 3738 14 clang 0x0000000000dbf1c7 clang::ento::ExprEngine::Visit(clang::Stmt const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 1447 15 clang 0x0000000000dc1343 clang::ento::ExprEngine::ProcessStmt(clang::CFGStmt, clang::ento::ExplodedNode*) + 1299 16 clang 0x0000000000dc1a5f clang::ento::ExprEngine::processCFGElement(clang::CFGElement, clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) + 239 17 clang 0x0000000000daa427 clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int, clang::ento::ExplodedNode*) + 135 18 clang 0x0000000000dab5bb clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned int, clang::ento::ProgramState const*) + 731 19 clang 0x0000000000ccd428 20 clang 0x0000000000ccdd8d 21 clang 0x0000000000cce141 22 clang 0x0000000000ccec1e 23 clang 0x00000000009da13a clang::ParseAST(clang::Sema&, bool) + 394 24 clang 0x00000000007858a5 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 373 25 clang 0x000000000076c136 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1158 26 clang 0x00000000007670ec cc1_main(char const**, char const**, char const*, void*) + 524 27 clang 0x00000000007599b4 main + 8084 28 libc.so.6 0x00000035a4a2139d __libc_start_main + 237 29 clang 0x000000000076306d Stack dump: 0. Program arguments: clang -cc1 -analyze -analyzer-checker=core tsts.c 1. parser at end of file 2. tsts.c:14:2: Error evaluating statement 3. tsts.c:14:2: Error evaluating statement -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 07:45:46 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 12:45:46 +0000 Subject: [LLVMbugs] [Bug 11022] Debug output might be endian-unaware In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11022 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from NAKAMURA Takumi 2011-11-01 07:45:46 CDT --- Applied in r143449 on release_30. I close this, though I know it might be partial fix. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 08:39:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 13:39:56 +0000 Subject: [LLVMbugs] [Bug 11198] [3.0 regression] llvm-ld can't find libc on debian testing In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11198 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Duncan Sands 2011-11-01 08:39:56 CDT --- Fixed by not passing -lc to llvm-ld, and indeed removing all uses of llvm-ld from the testsuite: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111031/131007.html -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 08:49:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 13:49:55 +0000 Subject: [LLVMbugs] [Bug 11284] New: Does not pick up std::shared_ptr templated copy constructor from libstdc++ 4.6.1. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11284 Bug #: 11284 Summary: Does not pick up std::shared_ptr templated copy constructor from libstdc++ 4.6.1. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bjornms at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified As stated by David Rodriguez in a stackoverflow post it should pickup this templated constructor: http://stackoverflow.com/questions/7964360/using-stdshared-ptr-with-clang-and-libstdc I made some code which should compile but doesn't. It is also in the question of the stackoverflow post. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 09:19:11 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 14:19:11 +0000 Subject: [LLVMbugs] [Bug 11285] New: Exception handling broken on Windows (MinGW) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11285 Bug #: 11285 Summary: Exception handling broken on Windows (MinGW) 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 Classification: Unclassified Created attachment 7565 --> http://llvm.org/bugs/attachment.cgi?id=7565 g++ (4.6.3 sjlj) output As it stands, there is no functional exception handling in LLVM/Clang for Windows. On MinGW, functions like "__cxa_allocate_exception" and "__cxa_throw" are generated. Linking succeeds, but exception handling does not work. Attached is "-S" output for clang++ and g++ (sjlj). MSVC-based Clang is even more broken due to name mangling and the missing abovementioned functions. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 09:34:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 14:34:24 +0000 Subject: [LLVMbugs] [Bug 11284] Does not pick up std::shared_ptr templated copy constructor from libstdc++ 4.6.1. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11284 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Douglas Gregor 2011-11-01 09:34:24 CDT --- This is a GCC/libstdc++ bug, as noted on stack overflow and in our compatibility document: http://clang.llvm.org/compatibility.html#deleted-special-func -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 10:56:04 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 15:56:04 +0000 Subject: [LLVMbugs] [Bug 11286] New: Vector code is being scalarized by the backend when using <16 x i8> vectors Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11286 Bug #: 11286 Summary: Vector code is being scalarized by the backend when using <16 x i8> vectors Product: compiler-rt Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt AssignedTo: unassignedbugs at nondot.org ReportedBy: diego.l.caballero at gmail.com CC: bruno.cardoso at gmail.com, grosser at fim.uni-passau.de, llvmbugs at cs.uiuc.edu, nadav.rotem at intel.com Classification: Unclassified Created attachment 7567 --> http://llvm.org/bugs/attachment.cgi?id=7567 Test case I'm attaching a test case that uses <16 x i8> vectors. For any reason, the x86 assembler code is being scalarized. However, if I use <8 x i8> vectors, the emitted assembler contains vectors accordingly. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 11:01:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 16:01:56 +0000 Subject: [LLVMbugs] [Bug 11287] New: Assertion when using analysis results from a CallGraphSCCPass in a ModulePass Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11287 Bug #: 11287 Summary: Assertion when using analysis results from a CallGraphSCCPass in a ModulePass Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Interprocedural Analyses AssignedTo: unassignedbugs at nondot.org ReportedBy: jobnoorman at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7568 --> http://llvm.org/bugs/attachment.cgi?id=7568 Example that produces the assertion When trying to add a CallGraphSCCPass as a required pass for a ModulePass, the following assertion is raised: opt: /.../llvm/lib/Analysis/IPA/CallGraphSCCPass.cpp:535: virtual void llvm::CallGraphSCCPass::assignPassManager(llvm::PMStack&, llvm::PassManagerType): Assertion `!PMS.empty() && "Unable to handle Call Graph Pass"' failed. I've attached an example file. Since I'm not completely sure if this is a bug, I tried asking on the mailing list (http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043987.html) first but didn't get any responses. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 15:09:55 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 20:09:55 +0000 Subject: [LLVMbugs] [Bug 11289] New: Inefficient x86 vector code generation for compare less than 0 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11289 Bug #: 11289 Summary: Inefficient x86 vector code generation for compare less than 0 Product: libraries Version: trunk Platform: Macintosh OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: fbossen at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Code generated for a vector comparison to zero is inefficient. For example the C code below creates mask where each result vector element is equal to -1 if the input vector element is negative, and 0 otherwise. #include void test(__m128i* p) { *p = _mm_cmplt_epi8(*p, _mm_setzero_si128()); } Using http://llvm.org/demo/index.cgi the generated LLVM assembly is ; ModuleID = '/tmp/webcompile/_11830_0.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" define void @test(<2 x i64>* nocapture %p) nounwind { %1 = load <2 x i64>* %p, align 16, !tbaa !0 %2 = bitcast <2 x i64> %1 to <16 x i8> %.lobit.i.i = ashr <16 x i8> %2, %3 = bitcast <16 x i8> %.lobit.i.i to <2 x i64> store <2 x i64> %3, <2 x i64>* %p, align 16, !tbaa !0 ret void } !0 = metadata !{metadata !"omnipotent char", metadata !1} !1 = metadata !{metadata !"Simple C/C++ TBAA", null} where the comparison < 0 is replaced by >> 7 Alternatively the vector comparison could also be written as define <16 x i8> @test(<16 x i8> %a) { %b = icmp sgt <16 x i8> zeroinitializer, %a %c = sext <16 x i1> %b to <16 x i8> ret <16 x i8> %c } In both cases the generated code is convoluted where individual vector elements are extracted using pextrb instructions, shifted using sarb instructions, and reinserted using pinsrb instructions. This was tested using r143475 from trunk. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 15:34:17 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 20:34:17 +0000 Subject: [LLVMbugs] [Bug 11258] ARM-Linux: compilation of llvm-2.9 fails: SPUISelDAGToDAG.cpp:222:60: error: 'SelectCode' was not declared in this scope In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11258 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #6 from Anton Korobeynikov 2011-11-01 15:34:17 CDT --- (In reply to comment #5) > I got compilation working with: > CC=/opt/gcc-4.6/bin/gcc CPP=/opt/gcc-4.6/bin/cpp CXX=/opt/gcc-4.6/bin/g++ > ../configure --prefix=/opt/llvm --with-optimize-option=-O0 Ok. Your gcc is broken then. > ./Fibonacci > [same code than amd64] > starting fibonacci(24) with JIT... > LLVM ERROR: Not supported instr: %SP = LDMIA_RET %SP, pred:13, > pred:%CPSR, %R4, %R5, %R11, %PC, %R0, > %R4 > > > ./HowToUseJIT > [same code than amd64] > Running foo: LLVM ERROR: Not supported instr: %SP = LDMIA_RET %SP, > pred:14, pred:%noreg, %R11, %PC, %R0 ARM JIT is well-known to be broken. Migration to MCJIT is WIP. There are enough PRs for this already. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 16:19:15 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 21:19:15 +0000 Subject: [LLVMbugs] [Bug 11289] Inefficient x86 vector code generation for compare less than 0 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11289 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #1 from Eli Friedman 2011-11-01 16:19:15 CDT --- r143498. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 16:37:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 21:37:01 +0000 Subject: [LLVMbugs] [Bug 10924] Failed assertion: `Access != AS_none && "Access specifier is AS_none inside a record decl"' In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10924 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2011-11-01 16:37:01 CDT --- Fixed in Clang r143504. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 17:46:21 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 22:46:21 +0000 Subject: [LLVMbugs] [Bug 11282] ExplodedGraph.h:95 -- void clang::ento::ExplodedNode::NodeGroup::setFlag(): Assertion `P == 0' failed. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11282 Anna Zaks changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Anna Zaks 2011-11-01 17:46:21 CDT --- Dmitry, Thank you for reporting this! Fix committed in r143516. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 18:10:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Nov 2011 23:10:56 +0000 Subject: [LLVMbugs] [Bug 11244] Objective-C - readonly attribute in property declaration In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11244 Fariborz Jahanian changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |fjahanian at apple.com Resolution| |FIXED --- Comment #2 from Fariborz Jahanian 2011-11-01 18:10:56 CDT --- Fixed in TOT: http://llvm.org/viewvc/llvm-project?view=rev&revision=143518 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Nov 1 20:31:27 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 01:31:27 +0000 Subject: [LLVMbugs] [Bug 11290] New: Alignment of loads over conservative in CodeGenFunction::EmitCall. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11290 Bug #: 11290 Summary: Alignment of loads over conservative in CodeGenFunction::EmitCall. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ahatanak at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The alignment of the load instruction created in line CGCall.cpp:1701 is always set to 1 in line 1704. 01700 for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) { 01701 llvm::Value *EltPtr = Builder.CreateConstGEP2_32(SrcPtr, 0, i); 01702 llvm::LoadInst *LI = Builder.CreateLoad(EltPtr); 01703 // We don't know what we're loading from. 01704 LI->setAlignment(1); The alignment is overconservative and can be made stricter since the alignment of the underlying object and the sizes of its fields are known here. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Nov 2 00:11:48 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 05:11:48 +0000 Subject: [LLVMbugs] [Bug 11291] New: LLVM 3.0rc2: popcnt instruction fails on OSX (invalid suffix) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11291 Bug #: 11291 Summary: LLVM 3.0rc2: popcnt instruction fails on OSX (invalid suffix) Product: new-bugs Version: 2.9 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: davidterei at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7570 --> http://llvm.org/bugs/attachment.cgi?id=7570 testcase I've attached a small test case that produces assembly code that the assemblers on OSX can't handle. OSX doesn't handle the length suffixes on the popcnt instruction (e.g. {w,l,q}). Here is a related GCC bug for this issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497#c14 I believe they fixed it by not adding the suffix on OSX, which works fine. Indeed changing instruction definition in lib/Target/X86/X86InstrSSE.td to drop the suffix, works fine. The integrated assembler of llc works fine but GHC which uses LLVM can't use the integrated assembler at this stage as we do some assembly post processing. == To Reproduce == 1. llc testcase.ll -o testcase.s 2. gcc -m32 -c testcase.s -o b.o (or as -arch i386 testcase.s) == Expected Output == Shiny object file == Actual Output == testcase.s:7:suffix or operands invalid for `popcnt' -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 01:38:19 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 06:38:19 +0000 Subject: [LLVMbugs] [Bug 11292] New: Objective-C - incompatible pointer type assignment not detected when used with init method Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11292 Bug #: 11292 Summary: Objective-C - incompatible pointer type assignment not detected when used with init method Product: new-bugs Version: unspecified Platform: Macintosh OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: muthuveerappan.al at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7571 --> http://llvm.org/bugs/attachment.cgi?id=7571 example showing incompatible pointer type assignment not detected when used with init method Objective-C - incompatible pointer type assignment not detected when used with init method When an init method returns a pointer type and when that pointer is assigned to another incompatible pointer variable, the compiler doesn't throw an error / warning Note - When tested with a method that doesn't have the prefix as "init", compiler manages to detect the error / warning Actual Behavior ============ The compiler doesn't throw an error / warning, when pointer type returned by an init method is assigned to an incompatible variable. Expected Behavior ============== The compiler should throw an error / warning, when pointer type returned by an init method is assigned to an incompatible variable. Example (Sample Objective-C program) ================================= Sample program showing incompatible pointer assignment by init method is attached -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Nov 2 01:59:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 06:59:47 +0000 Subject: [LLVMbugs] [Bug 11293] New: Objective-C init method with return type id unable to return parent object type pointer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11293 Bug #: 11293 Summary: Objective-C init method with return type id unable to return parent object type pointer Product: new-bugs Version: unspecified Platform: Macintosh OS/Version: All Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: muthuveerappan.al at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7572 --> http://llvm.org/bugs/attachment.cgi?id=7572 Objective-C example showing that the init method with return type id is unable to return parent object type pointer Objective-C init method with return type id unable to return parent object type pointer id type can represent the pointer to any object When an init method (with a return type "id") of a subclass returns a parent class pointer, the compiler throws a warning / error. However when another method without the prefix "init" does the same no compilation error / warning is thrown. Actual Behavior ============ When an init method (with a return type "id") of a subclass returns a parent class pointer, the compiler throws a warning / error Expected Behavior =============== When an init method (with a return type "id") of a subclass returns a parent class pointer, the compiler should not throw a warning / error Example (Sample Objective-C program explaining the problem) =============================================== Pls see the attached Objective-C program that explains the problem Reference: ========== The Objective?C Programming Language (Page 14) Quoted from the document: "In Objective-C, object identifiers are of a distinct data type: id. This type is the general type for any kind of object regardless of class and can be used for instances of a class and for class objects themselves." -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 02:03:02 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 07:03:02 +0000 Subject: [LLVMbugs] [Bug 11282] ExplodedGraph.h:95 -- void clang::ento::ExplodedNode::NodeGroup::setFlag(): Assertion `P == 0' failed. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11282 Dmitry G. Dyachenko changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #5 from Dmitry G. Dyachenko 2011-11-02 02:03:02 CDT --- rev.143530 fix error for me. Thank You, Anna! -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 02:55:00 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 07:55:00 +0000 Subject: [LLVMbugs] [Bug 11294] New: Expr.h:1311: llvm::StringRef clang::StringLiteral::getString() const: Assertion `CharByteWidth==1 && "This function is used in places that assume strings use char"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11294 Bug #: 11294 Summary: Expr.h:1311: llvm::StringRef clang::StringLiteral::getString() const: Assertion `CharByteWidth==1 && "This function is used in places that assume strings use char"' failed. Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: dimhen at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ clang -v clang version 3.1 (trunk 143530) Target: x86_64-unknown-linux-gnu Thread model: posix compiled F15 native gcc-4.6.1, optimized build $ cat tst_wchar.c typedef int wchar_t; struct s { wchar_t *name; }; void baz (struct s* p); void baz (struct s* p) { p->name = L"a"; } $ clang -cc1 -analyze -analyzer-checker=core tst_wchar.c clang: /home/dim/src/llvm/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/AST/Expr.h:1311: llvm::StringRef clang::StringLiteral::getString() const: Assertion `CharByteWidth==1 && "This function is used in places that assume strings use char"' failed. 0 clang 0x00000000019963af 1 clang 0x0000000001996899 2 libpthread.so.0 0x00000035a4e0eef0 3 libc.so.6 0x00000035a4a352d5 gsignal + 53 4 libc.so.6 0x00000035a4a36beb abort + 379 5 libc.so.6 0x00000035a4a2dc5e 6 libc.so.6 0x00000035a4a2dd02 7 clang 0x0000000000dbe867 8 clang 0x0000000000dbf1bb 9 clang 0x0000000000da6a69 clang::ento::ProgramState::getSValAsScalarOrLoc(clang::ento::MemRegion const*) const + 153 10 clang 0x0000000000da9796 clang::ento::ScanReachableSymbols::scan(clang::ento::MemRegion const*) + 246 11 clang 0x0000000000da9ab8 clang::ento::ScanReachableSymbols::scan(clang::ento::SVal) + 152 12 clang 0x0000000000d6eebd clang::ento::EnvironmentManager::removeDeadBindings(clang::ento::Environment, clang::ento::SymbolReaper&, clang::ento::ProgramState const*) + 3213 13 clang 0x0000000000dabf6a clang::ento::ProgramStateManager::removeDeadBindings(clang::ento::ProgramState const*, clang::StackFrameContext const*, clang::ento::SymbolReaper&) + 74 14 clang 0x0000000000d80a46 clang::ento::ExprEngine::ProcessStmt(clang::CFGStmt, clang::ento::ExplodedNode*) + 502 15 clang 0x0000000000d8197a clang::ento::ExprEngine::processCFGElement(clang::CFGElement, clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) + 202 16 clang 0x0000000000d6a121 clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int, clang::ento::ExplodedNode*) + 145 17 clang 0x0000000000d6b36d clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned int, clang::ento::ProgramState const*) + 733 18 clang 0x0000000000c8d2d6 19 clang 0x0000000000c8dc95 20 clang 0x0000000000c8e1bc 21 clang 0x0000000000c8ecfe 22 clang 0x000000000097ecaf clang::ParseAST(clang::Sema&, bool) + 415 23 clang 0x0000000000719835 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 373 24 clang 0x00000000006ff756 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1174 25 clang 0x00000000006f5b17 cc1_main(char const**, char const**, char const*, void*) + 535 26 clang 0x00000000006e9c84 main + 708 27 libc.so.6 0x00000035a4a2139d __libc_start_main + 237 28 clang 0x00000000006f577d Stack dump: 0. Program arguments: clang -cc1 -analyze -analyzer-checker=core tst_wchar.c 1. parser at end of file 2. tst_wchar.c:10:5: Error evaluating statement Aborted (core dumped) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Nov 2 08:09:50 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 13:09:50 +0000 Subject: [LLVMbugs] [Bug 11295] New: An explicitly defaulted constructor makes the class non-trivial Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11295 Bug #: 11295 Summary: An explicitly defaulted constructor makes the class non-trivial Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: max at duempel.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The following example should render a trivial type, because the constructor is explicitly defaulted, which should be equal to the constructor not being mentioned at all: struct Foo { Foo() = default; }; #include static_assert(std::is_trivial::value, "Foo"); Renders: test.cxx:3:1: error: static_assert failed "Foo" static_assert(std::is_trivial::value, "Foo"); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Nov 2 10:00:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 15:00:36 +0000 Subject: [LLVMbugs] [Bug 11296] New: -ffreestanding no longer recognizes auto-returns_twice Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11296 Bug #: 11296 Summary: -ffreestanding no longer recognizes auto-returns_twice Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: rafael.espindola at gmail.com ReportedBy: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu, rdivacky at freebsd.org Classification: Unclassified Recently, the name matching in LLVM for functions like setjmp, savectx etc was removed and replaced by corresponding builtins in the C frontend. Consequence 1: Functions need a proper, consistent prototype for this to work. This is not the case for savectx, which depending on the architecture and BSD returns either void or int. It is also used only in kernel and returns_twice semantic seems to only apply for FreeBSD. Consequence 2: Since the kernel and modules are built with -ffreestanding, they no longer provides the returns_twice attribute for them. Compile the attached test case with and without -ffreestanding and compare IR: w/ -ffreestanding: declare i32 @savectx(%struct.__jmp_buf_tag*) w/o -ffreestanding: declare i32 @savectx(%struct.__jmp_buf_tag*) returns_twice This bug is about tracking this change. I do not consider (2) a regression by itself, but it might be nice to detect and warn for this case specifically. The old behavior is certainly wrong and hides the real issue. Based on (2), I would like to see savectx dropped from the list. It is non-standard and inconsistently defined and the only users don't benefit from the behavior anyway. For FreeBSD it should be trivial to add the attributes for the ports that need 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 Nov 2 12:19:56 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 17:19:56 +0000 Subject: [LLVMbugs] [Bug 11297] New: Bad diagnostic for range for loop with non-declaration Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11297 Bug #: 11297 Summary: Bad diagnostic for range for loop with non-declaration Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jyasskin at google.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat test.cc #include #include #include int foo(const std::map& foo) { std::string key; int value = 0; for ( std::tie(key, value) : foo ) { } return value; } $ clang++ -stdlib=libc++ -std=c++0x -c test.cc test.cc:8:32: error: expected ';' in 'for' statement specifier for ( std::tie(key, value) : foo ) { ^ test.cc:8:32: error: expected expression 2 errors generated. This should say something like "for-range-declaration must be a declaration", with the whole non-declaration underlined. Complaining about the missing semicolon is particularly strange since valid range-based for loops don't need a semicolon. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 12:22:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 17:22:08 +0000 Subject: [LLVMbugs] [Bug 11279] Assertion `!IVLimit->getType()->isPointerTy() && "Should not expand pointer types"' failed. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11279 Andrew Trick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from Andrew Trick 2011-11-02 12:22:08 CDT --- r143522 is a quick fix that broadens the assert to handle this case. r143546 is a general rewrite of LFTR to handle the problem more systematically. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 12:40:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 17:40:59 +0000 Subject: [LLVMbugs] [Bug 11298] New: unable to find crtbegin.o, lgcc, lgcc_s on my host/platform Gentoo Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11298 Bug #: 11298 Summary: unable to find crtbegin.o, lgcc, lgcc_s on my host/platform Gentoo Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jreidthompson at nc.rr.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified unable to find crtbegin.o, lgcc, lgcc_s on my host/platform Gentoo $ clang --version clang version 3.1 (trunk) Target: x86_64-pc-linux-gnu Thread model: posix [13:34:59] rthompso at raker2>~ $ uname -a Linux raker2 2.6.39-gentoo-r3 #6 SMP Wed Aug 31 20:32:00 EDT 2011 x86_64 Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz GenuineIntel GNU/Linux [13:35:11] rthompso at raker2>~ $ cat /etc/lsb-release DISTRIB_ID="Gentoo" [13:35:14] rthompso at raker2>~ $ cat /etc/gentoo-release Gentoo Base System release 2.0.3 [13:35:20] rthompso at raker2>~ $ clang query-gcal-updated-events.c query-gcal-updated-events.c:24:13: warning: comparison between pointer and integer ('int' and 'void *') if (result != NULL) ~~~~~~ ^ ~~~~ query-gcal-updated-events.c:31:13: warning: comparison between pointer and integer ('int' and 'void *') if (result != NULL) ~~~~~~ ^ ~~~~ 2 warnings generated. /usr/bin/x86_64-pc-linux-gnu-ld: cannot find crtbegin.o: No such file or directory /usr/bin/x86_64-pc-linux-gnu-ld: cannot find -lgcc /usr/bin/x86_64-pc-linux-gnu-ld: cannot find -lgcc_s clang: error: linker command failed with exit code 1 (use -v to see invocation) $ locate crtbegin.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/crtbegin.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/crtbegin.o $ locate libgcc /lib32/libgcc_s.so.1 /lib64/libgcc_s.so.1 /usr/lib64/libgccpp.a /usr/lib64/libgccpp.la /usr/lib64/libgccpp.so /usr/lib64/libgccpp.so.1 /usr/lib64/libgccpp.so.1.0.3 /usr/lib64/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1.debug /usr/lib64/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_s.so.1.debug /usr/lib64/debug/usr/lib64/libreoffice/ure/lib/libgcc3_uno.so.debug /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc.a /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_eh.a /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc.a /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_eh.a /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_s.so /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_s.so.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 Nov 2 13:46:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 18:46:32 +0000 Subject: [LLVMbugs] [Bug 11293] Objective-C init method with return type id unable to return parent object type pointer In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11293 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #1 from Eli Friedman 2011-11-02 13:46:32 CDT --- This is working as intended; see http://clang.llvm.org/docs/LanguageExtensions.html#objc_instancetype . -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 13:46:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 18:46:44 +0000 Subject: [LLVMbugs] [Bug 11292] Objective-C - incompatible pointer type assignment not detected when used with init method In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11292 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |INVALID --- Comment #1 from Eli Friedman 2011-11-02 13:46:44 CDT --- This is working as intended; see http://clang.llvm.org/docs/LanguageExtensions.html#objc_instancetype . -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 15:11:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 20:11:59 +0000 Subject: [LLVMbugs] [Bug 11298] unable to find crtbegin.o, lgcc, lgcc_s on my host/platform Gentoo In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11298 Chandler Carruth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #9 from Chandler Carruth 2011-11-02 15:11:59 CDT --- (In reply to comment #8) > > > If this is the case, using it turns off most of the clever GCC installation > > auto-detection. Is there a reason you're using that? It's all a bit of a hack, > > and really poorly tested. If without it you have problems finding libraries or > > headers, we can just fix the underlying code. > > I'm not intentionally defining it. I'm emerging the default 9999 ebuild. > Would this be the offending param? > > --with-cxx-include-root=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4 That sounds quite likely. You should file a bug with Gentoo (or wherever you got the 9999 ebuild) and have them stop doing that. Instead, when a new GCC version comes out that Clang doesn't support, they should file bugs / patch the Clang source code to support them; specifically InitHeaderSearch.cpp. We've fixed Clang to automatically detect and use newer GCC installations when linking, but not the libstdc++ headers. I'd love to see us eventually have an easy way to at configure time hard code all the relevant paths, but more than that I'd like the Clang binary by default to Just Work on most distros and even as GCC gets upgraded. Thus, I've focused most of my efforts there. I've added support to Clang for finding and using GCC 4.5.3 headers on Gentoo in r143567. Let me know if you need any additional paths added. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 15:17:32 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 20:17:32 +0000 Subject: [LLVMbugs] [Bug 11298] unable to find crtbegin.o, lgcc, lgcc_s on my host/platform Gentoo In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11298 Reid changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #10 from Reid 2011-11-02 15:17:32 CDT --- (In reply to comment #9) > > I'm not intentionally defining it. I'm emerging the default 9999 ebuild. > > Would this be the offending param? > > > > --with-cxx-include-root=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4 > > That sounds quite likely. You should file a bug with Gentoo (or wherever you > got the 9999 ebuild) and have them stop doing that. > > Instead, when a new GCC version comes out that Clang doesn't support, they > should file bugs / patch the Clang source code to support them; specifically > InitHeaderSearch.cpp. We've fixed Clang to automatically detect and use newer > GCC installations when linking, but not the libstdc++ headers. > > I'd love to see us eventually have an easy way to at configure time hard code > all the relevant paths, but more than that I'd like the Clang binary by default > to Just Work on most distros and even as GCC gets upgraded. Thus, I've focused > most of my efforts there. I've added support to Clang for finding and using GCC > 4.5.3 headers on Gentoo in r143567. Let me know if you need any additional > paths added. OK -- thanks for your help. i'll continue to work with it tomorrow and see if I can get the above to not be passed. I'll try to get a bug into gentoo bugzilla noting this also. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 15:25:39 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 20:25:39 +0000 Subject: [LLVMbugs] [Bug 11298] unable to find crtbegin.o, lgcc, lgcc_s on my host/platform Gentoo In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11298 Reid changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Nov 2 16:10:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Nov 2011 21:10:47 +0000 Subject: [LLVMbugs] [Bug 11299] New: clang rejects nested struct-member-access-typeof Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11299 Bug #: 11299 Summary: clang rejects nested struct-member-access-typeof Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: sharparrow1 at yahoo.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified (This is a copy-paste of a message from Jan Engelhardt to cfe-dev.) == Compiler info (clang -v) == [openSUSE 12.1 RC] SUSE Linux clang version 3.0 (trunk 140782) (based on LLVM 3.0) Target: x86_64-unknown-linux-gnu Thread model: posix == Source == int main(void) { void *p = 0; typeof((struct { typeof((struct { void *m; }){p}.m) n; }){0}.n) q = 0; return 0; } == Description == I was giving clang a spin on libHX [http://libhx.sf.net/] when it errored out on libHX's "type-checking casts" macros. The above source snippet is the distilled minimal test case. ../../src/format.c:34:29: error: initializer element is not a compile-time constant return const_cast1(void *, static_cast(const void *, t)); ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [...] == Observed output == $ clang test.c t.c:4:47: error: initializer element is not a compile-time constant typeof((struct { typeof((struct { void *m; }){p}.m) n; }){0}.n) q = 0; ^~~ t.c:4:63: error: member reference base type 'void' is not a structure or union typeof((struct { typeof((struct { void *m; }){p}.m) n; }){0}.n) q = 0; ~~~ ^ 2 errors generated. == Expected output == That no errors be output. GCC 4.5/4.6/4.x compiles the very same file fine, because it sees that we are really only doing type inspection. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 2 20:15:06 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 01:15:06 +0000 Subject: [LLVMbugs] [Bug 11292] Objective-C - incompatible pointer type assignment not detected when used with init method In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11292 muthuveerappan.al at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from muthuveerappan.al at gmail.com 2011-11-02 20:15:06 CDT --- Expected Behavior: =========== The compiler should enforce that all init methods to have the return type as "id". (see documentation) otherwise should throw a warning / error. Enforcing this would mean that would mean that the init methods would no longer return an parent class pointer type. Actual Behavior: ============ Presently the compiler allows init methods to have the return type of the class (class pointer type) that implements it. Documentation: =========== The Objective?C Programming Language (Page 51) "The return type of an initializer method should be id. The return type should be id because id gives an indication that the class is purposely not considered?that the class is unspecified and subject to change, depending on context of invocation. For example, NSString provides the method initWithFormat:. When sent to an instance of NSMutableString (a subclass of NSString), however, the message returns an instance of NSMutableString, not NSString." Present Scenario: =========== Assignment of a parent class pointer to a derived class pointer variable is incorrect This is currently being allowed in clang when the init method returns a parent class pointer (as shown in example). The problem would be solved if the compiler should enforce that all init methods to have the return type as id. (see documentation) otherwise should throw a warning / 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 Wed Nov 2 20:21:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 01:21:10 +0000 Subject: [LLVMbugs] [Bug 11300] New: llvm produces a AT_specification that is a forward reference Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11300 Bug #: 11300 Summary: llvm produces a AT_specification that is a forward reference Product: libraries Version: trunk Platform: PC OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P Component: Common Code Generator Code AssignedTo: rafael.espindola at gmail.com ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Given struct foo { void bar() {} }; void zed(foo *x) { x->bar(); } gcc produces the following dwarf: ----------------------------------- 0x00000071: TAG_subprogram [3] * AT_external( 0x01 ) AT_name( "bar" ) AT_decl_file( "/Users/espindola/llvm/test.cc" ) AT_decl_line( 2 ) AT_MIPS_linkage_name( "_ZN3foo3barEv" ) AT_declaration( 0x01 ) .... 0x0000008c: TAG_subprogram [6] * AT_specification( {0x00000071} ( "_ZN3foo3barEv" ) ) AT_low_pc( 0x0000000000000370 ) AT_high_pc( 0x000000000000037a ) AT_frame_base( 0x00000000 0x0000000000000370 - 0x0000000000000371: rsp+8 0x0000000000000371 - 0x0000000000000374: rsp+16 0x0000000000000374 - 0x000000000000037a: rbp+16 ) AT_sibling( {0x000000b8} ) --------------------------------- we produce ------------------------------------- 0x00000059: TAG_subprogram [4] * AT_sibling( {0x00000089} ) AT_MIPS_linkage_name( "_ZN3foo3barEv" ) AT_specification( {0x00000099} ( "_ZN3foo3barEv" ) ) AT_low_pc( 0x0000000000000270 ) AT_high_pc( 0x0000000000000276 ) AT_frame_base( rsp ) AT_APPLE_omit_frame_ptr( 0x01 ) .... 0x00000099: TAG_subprogram [8] * AT_MIPS_linkage_name( "_ZN3foo3barEv" ) AT_name( "bar" ) AT_decl_file( "/Users/espindola/llvm/test.cc" ) AT_decl_line( 2 ) AT_prototyped( 0x01 ) AT_declaration( 0x01 ) AT_external( 0x01 ) AT_accessibility( DW_ACCESS_public ) --------------------------------------- Two interesting things to notice: * AT_MIPS_linkage_name is duplicated. * AT_specification is a forward reference The dwarf standard says ----------------- A debugging information entry that represents a declaration that completes another (earlier) non- defining declaration may have a DW_AT_specification attribute whose value is a reference to the debugging information entry representing the non-defining declaration. ------------------ So I think that the second point actually makes our debug info invalid. In any case, it breaks breakpad: http://code.google.com/p/google-breakpad/issues/detail?id=441 The link is being created by if (SPDecl.isSubprogram()) // Refer function declaration directly. SPCU->addDIEEntry(SPDie, dwarf::DW_AT_specification, dwarf::DW_FORM_ref4, SPCU->getOrCreateSubprogramDIE(SPDecl)); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Nov 3 01:56:40 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 06:56:40 +0000 Subject: [LLVMbugs] [Bug 11291] LLVM 3.0rc2: popcnt instruction fails on OSX (invalid suffix) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11291 David Terei changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #6 from David Terei 2011-11-03 01:56:40 CDT --- Hi Chris, Yes using clang works fine. Thanks! Sorry for the noise. I'll switch GHC over to using clang. You can close this bug. Cheeers, David -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Nov 3 03:22:18 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 08:22:18 +0000 Subject: [LLVMbugs] [Bug 11200] [3.0] Non-determinism in self-host on x86-32 linux In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11200 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #21 from Duncan Sands 2011-11-03 03:22:18 CDT --- Exactly the same problem occurs in rc2. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Nov 3 03:59:44 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 08:59:44 +0000 Subject: [LLVMbugs] [Bug 11301] New: Firefox build fails with -O4 during linking of libxul on Linux Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11301 Bug #: 11301 Summary: Firefox build fails with -O4 during linking of libxul on Linux Product: tools Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: lto AssignedTo: unassignedbugs at nondot.org ReportedBy: markus at trippelsdorf.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The latest Firefox builds fine with -O3 on my machine. With -O4 I get the following error during the final libxul link: rm -f libxul.so /usr/bin/python2.7 /var/tmp/mozilla-central/config/pythonpath.py -I../../config /var/tmp/mozilla-central/config/expandlibs_exec.py --uselist -- clang++ -fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -use-gold-plugin -B/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2 -march=native -ffunction-sections -fdata-sections -fvisibility-inlines-hidden -fno-exceptions -fno-strict-aliasing -std=gnu++0x -fno-tree-vrp -pipe -DNDEBUG -DTRIMMED -O4 -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsRDFResource.o -lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory,--gc-sections -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin -Wl,-rpath-link,/usr/lib ../../toolkit/xre/libxulapp_s.a ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libstartupcache.a ../../staticlib/components/libpref.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libgkgfx.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libjsreflect.a ../../staticlib/components/libcomposer.a ../../staticlib/components/libjetpack_s.a ../../staticlib/components/libtelemetry.a ../../staticlib/components/libjsdebugger.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/libjsctypes.a ../../staticlib/components/libjsperf.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libjsd.a ../../staticlib/components/libautoconfig.a ../../staticlib/components/libauth.a ../../staticlib/components/libcookie.a ../../staticlib/components/libpermissions.a ../../staticlib/components/libuniversalchardet.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libfileview.a ../../staticlib/components/libplaces.a ../../staticlib/components/libtkautocomplete.a ../../staticlib/components/libsatchel.a ../../staticlib/components/libpippki.a ../../staticlib/components/libwidget_gtk2.a ../../staticlib/components/libsystem-pref.a ../../staticlib/components/libimgicon.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../staticlib/components/libservices-crypto.a ../../staticlib/libjsipc_s.a ../../staticlib/libdomipc_s.a ../../staticlib/libdomplugins_s.a ../../staticlib/libmozipc_s.a ../../staticlib/libmozipdlgen_s.a ../../staticlib/libipcshell_s.a ../../staticlib/libgfx2d.a ../../staticlib/libgfxipc_s.a ../../staticlib/libhal_s.a ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a ../../staticlib/libchromium_s.a ../../staticlib/libmozreg_s.a ../../staticlib/libgtkxtbin.a ../../staticlib/libthebes.a ../../staticlib/libycbcr.a ../../staticlib/libangle.a -L../../dist/bin -L../../dist/lib -ljpeg ../../media/libpng/libmozpng.a ../../gfx/qcms/libmozqcms.a /var/tmp/mozilla-central/moz-build-dir/dist/lib/libjs_static.a -Wl,-R/usr/lib64 -L/usr/lib64 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lcrmf -lcairo -lpixman-1 -lfreetype -lfontconfig -L/usr/lib64 -lXrender -lcairo -lX11 ../../gfx/harfbuzz/src/libmozharfbuzz.a ../../gfx/ots/src/libmozots.a ../../dist/lib/libmozsqlite3.a -lz -L/usr/lib -levent -lasound -L../../dist/bin -L../../dist/lib -Wl,-R/usr/lib64 -L/usr/lib64 -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../../dist/lib/libmozalloc.a -ldbus-1 -lpthread -lrt -L/usr/lib64 -lX11 -lXext -pthread -lpangoft2-1.0 -lfreetype -lfontconfig -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -pthread -lgtk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lfreetype -lfontconfig -lgdk-x11-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lcairo -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lXt -lgthread-2.0 -lfreetype -lz -lbz2 -lstartup-notification-1 -ldl -lrt clang: warning: argument unused during compilation: '-std=gnu++0x' Global is external, but doesn't have external or dllimport or weak linkage! %"class.IPC::Message.226497"* (%"class.std::map.226896"*, i64*)* @_ZNSt3mapImN3IPC7MessageESt4lessImESaISt4pairIKmS1_EEEixEOm invalid linkage type for function declaration %"class.IPC::Message.226497"* (%"class.std::map.226896"*, i64*)* @_ZNSt3mapImN3IPC7MessageESt4lessImESaISt4pairIKmS1_EEEixEOm Global is external, but doesn't have external or dllimport or weak linkage! i1 (%"class.mozilla::ipc::RPCChannel.226903"*)* @_ZNK7mozilla3ipc10RPCChannel27ShouldDeferNotifyMaybeErrorEv invalid linkage type for function declaration i1 (%"class.mozilla::ipc::RPCChannel.226903"*)* @_ZNK7mozilla3ipc10RPCChannel27ShouldDeferNotifyMaybeErrorEv Global is external, but doesn't have external or dllimport or weak linkage! void (%"class.std::deque.16.226889"*, %"class.IPC::Message.226497"*)* @_ZNSt5dequeIN3IPC7MessageESaIS1_EE9push_backERKS1_ invalid linkage type for function declaration void (%"class.std::deque.16.226889"*, %"class.IPC::Message.226497"*)* @_ZNSt5dequeIN3IPC7MessageESaIS1_EE9push_backERKS1_ invalid linkage type for global declaration [49 x i8]* @.str53683 invalid linkage type for global declaration [24 x i8]* @.str153684 invalid linkage type for global declaration [36 x i8]* @.str253685 invalid linkage type for global declaration [4 x i8]* @.str353686 invalid linkage type for global declaration [17 x i8]* @.str453687 invalid linkage type for global declaration [17 x i8]* @.str553688 invalid linkage type for global declaration [25 x i8]* @.str653689 invalid linkage type for global declaration [36 x i8]* @.str753690 invalid linkage type for global declaration [14 x i8]* @.str853691 invalid linkage type for global declaration [34 x i8]* @.str953692 invalid linkage type for global declaration [11 x i8]* @.str1053693 invalid linkage type for global declaration [17 x i8]* @.str1153694 invalid linkage type for global declaration [36 x i8]* @.str1253695 invalid linkage type for global declaration [15 x i8]* @.str1353696 invalid linkage type for global declaration [7 x i8]* @.str1453697 invalid linkage type for global declaration [18 x i8]* @.str1553698 invalid linkage type for global declaration [18 x i8]* @.str1653699 invalid linkage type for global declaration [99 x i8]* @.str1753700 invalid linkage type for global declaration [23 x i8]* @.str1853701 invalid linkage type for global declaration [26 x i8]* @.str1953702 invalid linkage type for global declaration [53 x i8]* @.str2053703 invalid linkage type for global declaration [61 x i8]* @.str2153704 invalid linkage type for global declaration [18 x i8]* @.str2253705 invalid linkage type for global declaration [27 x i8]* @.str2353706 invalid linkage type for global declaration [23 x i8]* @__FUNCTION__._ZN7mozilla3ipc10RPCChannel22EnqueuePendingMessagesEv invalid linkage type for global declaration [34 x i8]* @.str2453707 invalid linkage type for global declaration [19 x i8]* @.str2553708 invalid linkage type for global declaration [29 x i8]* @.str2853709 invalid linkage type for global declaration [12 x i8]* @.str2953710 invalid linkage type for global declaration [28 x i8]* @.str3353711 invalid linkage type for global declaration [30 x i8]* @.str3453712 invalid linkage type for global declaration [49 x i8]* @.str3553713 invalid linkage type for global declaration [79 x i8]* @.str3653714 invalid linkage type for global declaration [6 x i8]* @.str3753715 invalid linkage type for global declaration [7 x i8]* @.str3853716 invalid linkage type for global declaration [6 x i8]* @.str3953717 invalid linkage type for global declaration [1 x i8]* @.str4053718 invalid linkage type for global declaration [3 x i8]* @.str4153719 invalid linkage type for global declaration [31 x i8]* @.str4253720 invalid linkage type for global declaration [28 x i8]* @.str4353721 invalid linkage type for global declaration [43 x i8]* @.str4453722 invalid linkage type for global declaration [43 x i8]* @.str4553723 invalid linkage type for global declaration [14 x i8]* @.str4653724 invalid linkage type for global declaration [5 x i8]* @.str4753725 invalid linkage type for global declaration [6 x i8]* @.str4853726 invalid linkage type for global declaration [27 x i8]* @.str4953727 invalid linkage type for global declaration [30 x i8]* @.str5053728 invalid linkage type for global declaration [18 x i8]* @__FUNCTION__._ZN7mozilla3ipc10RPCChannel17OnMessageReceivedERKN3IPC7MessageE invalid linkage type for global declaration [27 x i8]* @.str5153729 invalid linkage type for global declaration [6 x i8*]* @_ZTV14RunnableMethodIN7mozilla3ipc10RPCChannelEMS2_FbvE6Tuple0E invalid linkage type for global declaration [3 x i8]* @.str5253730 invalid linkage type for global declaration [4 x i8]* @.str5353731 invalid linkage type for global declaration [4 x i8]* @.str5453732 invalid linkage type for global declaration [4 x i8*]* @_ZTVN12_GLOBAL__N_119UnblockChildMessageE invalid linkage type for global declaration [4 x i8*]* @_ZTVN12_GLOBAL__N_117BlockChildMessageE invalid linkage type for global declaration [5 x i8*]* @_ZTVN7mozilla3ipc10RPCChannel11DequeueTaskE Broken module found, compilation aborted! Stack dump: 0. Running pass 'Function Pass Manager' on module 'ld-temp.o'. clang: error: unable to execute command: Aborted clang: error: linker command failed due to signal 2 (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated clang: note: diagnostic msg: Error generating preprocessed source(s). make[5]: *** [libxul.so] Error 254 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Nov 3 11:40:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 16:40:23 +0000 Subject: [LLVMbugs] [Bug 11005] Core dump on invalid code In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11005 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Resolution| |FIXED --- Comment #5 from Douglas Gregor 2011-11-03 11:40:23 CDT --- Fixed in Clang r 143614. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Nov 3 14:11:23 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 19:11:23 +0000 Subject: [LLVMbugs] [Bug 11295] An explicitly defaulted constructor makes the class non-trivial In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11295 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |DUPLICATE --- Comment #2 from Eli Friedman 2011-11-03 14:11:23 CDT --- *** This bug has been marked as a duplicate of bug 10442 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Nov 3 15:02:49 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 20:02:49 +0000 Subject: [LLVMbugs] [Bug 11139] FTBFS unrecognizable insn in InitHeaderSearch.cpp:195 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11139 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Eli Friedman 2011-11-03 15:02:49 CDT --- This isn't a clang bug; unless you want to come up with a workaround of some sort, there isn't anything we can do here. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Nov 3 15:31:35 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 20:31:35 +0000 Subject: [LLVMbugs] [Bug 11254] Reparsing crashes for files that use pragmas when precompiled preamble is enabled In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11254 Argyrios Kyrtzidis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |akyrtzi at gmail.com Resolution| |FIXED --- Comment #2 from Argyrios Kyrtzidis 2011-11-03 15:31:35 CDT --- Fixed on r143644, thanks for the report! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Nov 3 17:56:41 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Nov 2011 22:56:41 +0000 Subject: [LLVMbugs] [Bug 11302] New: quadratic compile time in SUnit::ComputeHeight and SUnit::setHeightDirty Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11302 Bug #: 11302 Summary: quadratic compile time in SUnit::ComputeHeight and SUnit::setHeightDirty 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: kcc at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The attached test cases have N calls of the following kind: bar(16981, 6504, "11844"); compiling a test with 2*N such calls takes 4x more time than compiling N calls. I am using r143407 % for n in 8 16 32 64; do echo n=${n}000; time ./my_clang++ -c -O2 manycalls$n.cc ; done n=8000 TIME: real: 2.432; user: 2.300; system: 0.060 n=16000 TIME: real: 11.824; user: 11.570; system: 0.120 n=32000 TIME: real: 59.008; user: 58.650; system: 0.230 n=64000 TIME: real: 151.948; user: 150.950; system: 0.670 Profile looks like this: 45.11% llvm::SUnit::ComputeHeight() 34.51% llvm::SUnit::setHeightDirty() 1.52% llvm::MachineInstr::addRegisterDead(unsigned int, llvm::TargetRegisterInfo const*, bool) 0.75% llvm::SelectionDAG::AssignTopologicalOrder() gcc is much faster and does not look quadratic % for n in 8 16 32 64; do echo n=${n}000; time g++ -c -O2 manycalls$n.cc ; done n=8000 TIME: real: 1.682; user: 1.620; system: 0.060 n=16000 TIME: real: 3.618; user: 3.550; system: 0.060 n=32000 TIME: real: 7.685; user: 7.410; system: 0.250 n=64000 TIME: real: 16.265; user: 15.810; system: 0.380 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Nov 3 20:06:36 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 01:06:36 +0000 Subject: [LLVMbugs] [Bug 11303] New: Objective - C - instance method "copyWithZone" being allowed to be invoked using a non-root class object Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11303 Bug #: 11303 Summary: Objective - C - instance method "copyWithZone" being allowed to be invoked using a non-root class object Product: new-bugs Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: muthuveerappan.al at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7573 --> http://llvm.org/bugs/attachment.cgi?id=7573 example showing that the instance method "copyWithZone" is allowed to be invoked using a non-root class object Overview ============== copyWithZone is an instance method belonging to the protocol NSCopying with the following spec: - (id)copyWithZone:(NSZone *)zone Non-root class objects shouldn't be allowed to invoke instance methods Actual Behavior: ============= Invoking an instance method "copyWithZone" with non-root class object doesn't throw a compiler warning / error Expected Behavior: =============== Invoking an instance method copyWithZone with non-root class object should throw a compiler warning / error Documentation reference: =================== Document - The Objective-?C Programming Language (page 32) "The only instance methods that a class object can perform are those defined in the root class, and only if there?s no class method that can do the job." Example: (attached below shows the problem) =================================== To replicate a similar environment I have created a protocol P1 with an instance method f1 class "A" is a non-root class, it inherits from NSObject, when the class object of "A" tries to invoke f1, the compiler throws an error as expected. When class object of "A" invokes "copyWithZone", no compilation warning / error is thrown -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 00:18:28 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 05:18:28 +0000 Subject: [LLVMbugs] [Bug 11304] New: [x86 disassembler] Certain VEX instructions ignore the W-bit that shouldn't Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11304 Bug #: 11304 Summary: [x86 disassembler] Certain VEX instructions ignore the W-bit that shouldn't Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: craig.topper at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified All of the instructions that are specified in the Intel developer manuals with W0 and have no corresponding W1 form will still disassemble with VEX.W=1. Examples: VEXTRACTF128 VINSERTF128 VPERMILPD VPERMILPS VPERM2F128 VBROADCAST* VTESTPD VTESTPS -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 00:23:01 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 05:23:01 +0000 Subject: [LLVMbugs] [Bug 11305] New: int_x86_sse42_pcmpistri*128 and int_x86_sse42_pcmpestri*128 instrinsics don't work correctly Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11305 Bug #: 11305 Summary: int_x86_sse42_pcmpistri*128 and int_x86_sse42_pcmpestri*128 instrinsics don't work correctly Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: craig.topper at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following intrinsics are supposed to return a certain bit from EFLAGS, but instead return ECX just like the form of the intrinsics that doesn't specify a flag bit. int_x86_sse42_pcmpistria128 int_x86_sse42_pcmpistric128 int_x86_sse42_pcmpistrio128 int_x86_sse42_pcmpistris128 int_x86_sse42_pcmpistriz128 int_x86_sse42_pcmpistrea128 int_x86_sse42_pcmpistrec128 int_x86_sse42_pcmpistreo128 int_x86_sse42_pcmpistres128 int_x86_sse42_pcmpistrez128 -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 06:49:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 11:49:13 +0000 Subject: [LLVMbugs] [Bug 11306] New: Variadic template fix-it suggestion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11306 Bug #: 11306 Summary: Variadic template fix-it suggestion Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified A few times I have written (note the ... in the wrong place on the template) template int f(Args...) { } The current error is the not very helpful: t.cc:1:23: error: expected ',' or '>' in template-parameter-list template ^ t.cc:1:26: error: expected unqualified-id template ^ Something nicer, with a fix-it, would be nice. The similar: template int f(Args args...) { } Produces the nicer (but still no fixit) t.cc:2:5: error: declaration type contains unexpanded parameter pack 'Args' int f(Args args...) ^ ~~~~ -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 07:30:20 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 12:30:20 +0000 Subject: [LLVMbugs] [Bug 11307] New: Template parameter candidate incorrectly ignored Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11307 Bug #: 11307 Summary: Template parameter candidate incorrectly ignored Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bradley.hughes at nokia.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7574 --> http://llvm.org/bugs/attachment.cgi?id=7574 SSCCE to show the problem. When declaring a template function with a function pointer template parameter, clang fails to substitute a static function that is used as the template parameter. A non-inline, non-static function works, as does a non-static inline function. See the attached templatefunc.cpp for the reproduction case. Reproduced using the llvm 3.0 and clang 3.0 branches: clang version 3.0 (http://llvm.org/git/clang.git 464779576943466ae532d9c17443a534837f6c28) Target: x86_64-apple-darwin11.2.0 Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Nov 4 07:46:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 12:46:25 +0000 Subject: [LLVMbugs] [Bug 11307] Template parameter candidate incorrectly ignored In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11307 Bradley T. Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Bradley T. Hughes 2011-11-04 07:46:25 CDT --- After a discussion with my colleagues, I read 14.3.2 of the C++ standard: A template-argument for a non-type, non-template template-parameter shall be one of: - an integral constant-expression of integral or enumeration type; or - the name of a non-type template-parameter; or - the address of an object or function with external linkage, including function templates and function template-ids but excluding non-static class members, expressed as & id-expression where the & is optional if the name refers to a function or array, or if the corresponding template-parameter is a refer- ence; or - a pointer to member expressed as described in 5.3.1 . A static function does not have external linkage, and thus isn't a valid non-type template parameter. Sorry for the noise. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Nov 4 08:06:59 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 13:06:59 +0000 Subject: [LLVMbugs] [Bug 11308] New: [3.0] Autoupgrade doesn't handle old style MRV functions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11308 Bug #: 11308 Summary: [3.0] Autoupgrade doesn't handle old style MRV functions Product: new-bugs Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified There seems to be no way to auto-upgrade IR containing the following kind of thing to LLVM 3.0. This kind of stuff was produced by LLVM 2.9 llvm-gcc for example. %empty = type {} define %empty @foo() { ret void } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Nov 4 08:42:12 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 13:42:12 +0000 Subject: [LLVMbugs] [Bug 11309] New: move constructor does not suppress copy constructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11309 Bug #: 11309 Summary: move constructor does not suppress copy constructor Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The following code is used in g++'s std::shared_ptr, which currently does not build with clang (at least in g++ 4.6.2). The following code compiles in g++, but not in clang++. g++'s reasoning is (I think): 1) The T(T&&) constructor stops automatic generation of the copy constructor. 2) When looking for a copy constructor, use the templated one. However, this an area I feel a bit dodgy on, I lost track of how the rules were changing as the standard was finalised. Looking at the most recent draft I have access to (n3242), shared_ptr should have a constructor: shared_ptr(const shared_ptr& r) noexcept; which g++ seems to be currently missing, and would clean this problem up. struct S { S(const S&) = delete; S() {}; }; template struct T : public S { template T(const T<_Tp1>& __r) { } T(T&&) { } T() {} }; int main(void) { T i; T j(i); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Nov 4 09:05:10 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 14:05:10 +0000 Subject: [LLVMbugs] [Bug 11310] New: const pointers to instances is allowed to modify the instance it points Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11310 Bug #: 11310 Summary: const pointers to instances is allowed to modify the instance it points Product: new-bugs Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: muthuveerappan.al at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7575 --> http://llvm.org/bugs/attachment.cgi?id=7575 example showing that the const pointers are allowed to modify the instance it points to It happens in the following 2 cases: 1) even if you explicitly specify the class type and specify "const" 2) when you you "cons id" as the data type Overview ======= const pointer should not be allowed to be modify the instance it points to Actual Behavior ============ const pointer is allowed to be modify the instance it points to Expected Behavior ============= const pointer shouldn't be allowed to be modify the instance it points to. Example: ======== The example attached shows the 3 cases of using const pointers. In 2 cases, no error is thrown and in 1 case error is thrown and seems inconsistent -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 09:46:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 14:46:13 +0000 Subject: [LLVMbugs] [Bug 11309] move constructor does not suppress copy constructor In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11309 Sean Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |scshunt at csclub.uwaterloo.ca Resolution| |INVALID --- Comment #1 from Sean Hunt 2011-11-04 09:46:13 CDT --- This is a library bug, not a clang bug. The explicit move constructor does not suppress generation of the implicit copy constructor, but instead causes it to be deleted [class.copy]/7, which clang correctly diagnoses, albeit rather obtusely. You are quite correct that shared_ptr should have an explicit copy constructor; this is a library bug, not a compiler 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 Nov 4 10:05:31 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 15:05:31 +0000 Subject: [LLVMbugs] [Bug 11268] CPP backend not support some new instructions (such as atomicrmw) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11268 eXtremal changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #2 from eXtremal 2011-11-04 10:05:31 CDT --- r143406 contains error - instructions creation without linking it with basic block. This patch may fix it: diff --git a/src/lib/Target/CppBackend/CPPBackend.cpp b/src/lib/Target/CppBackend/CPPBackend.cpp index 17ca23a..394ea2b 100644 --- a/src/lib/Target/CppBackend/CPPBackend.cpp +++ b/src/lib/Target/CppBackend/CPPBackend.cpp @@ -1492,7 +1492,7 @@ void CppWriter::printInstruction(const Instruction *I, StringRef CrossThread = ConvertAtomicSynchScope(fi->getSynchScope()); Out << "FenceInst* " << iName << " = new FenceInst(mod->getContext(), " - << Ordering << ", " << CrossThread + << Ordering << ", " << CrossThread << ", " << bbname << ");"; break; } @@ -1503,7 +1503,7 @@ void CppWriter::printInstruction(const Instruction *I, Out << "AtomicCmpXchgInst* " << iName << " = new AtomicCmpXchgInst(" << opNames[0] << ", " << opNames[1] << ", " << opNames[2] << ", " - << Ordering << ", " << CrossThread + << Ordering << ", " << CrossThread << ", " << bbname << ");"; nl(Out) << iName << "->setName(\""; printEscapedString(cxi->getName()); @@ -1533,7 +1533,7 @@ void CppWriter::printInstruction(const Instruction *I, << " = new AtomicRMWInst(" << Operation << ", " << opNames[0] << ", " << opNames[1] << ", " - << Ordering << ", " << CrossThread + << Ordering << ", " << CrossThread << ", " << bbname << ");"; nl(Out) << iName << "->setName(\""; printEscapedString(rmwi->getName()); This is recommendation only, not fully tested. What about adding atomics support to CppBackEnd in llvm 3.0 before final release? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 11:01:09 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 16:01:09 +0000 Subject: [LLVMbugs] [Bug 11311] New: Range checking on builtins before template instantiation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11311 Bug #: 11311 Summary: Range checking on builtins before template instantiation Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: marton78 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hi, The following code doesn't compile: #include template void test(float32x4_t& a, float32x4_t&b) { a = vextq_f32(a,b,Ofs); } int main() { float32x4_t a, b; test<1>(a, b); } Compilation fails with the following error: bug.cpp:8:9: error: argument should be a value from 0 to 3 a = vextq_f32(a,b,Ofs); ^~~~~~~~~~~~~~~~~~ Replacing Ofs -> 1 by hand resolves the error. Seems like clang performs range checking even on templates that are not yet instantiated. Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin10.8.0 Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Nov 4 11:44:13 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 16:44:13 +0000 Subject: [LLVMbugs] [Bug 11312] New: Reparsing crashes for certain template-code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11312 Bug #: 11312 Summary: Reparsing crashes for certain template-code Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: matthias_kleine at gmx.de CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7576 --> http://llvm.org/bugs/attachment.cgi?id=7576 Initial test case that crashes The attached test tries to reparse code that contains templates in a PCH and crashes. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 11:52:57 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 16:52:57 +0000 Subject: [LLVMbugs] [Bug 11311] Range checking on builtins before template instantiation In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11311 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bob.wilson at apple.com Resolution| |DUPLICATE --- Comment #1 from Bob Wilson 2011-11-04 11:52:57 CDT --- *** This bug has been marked as a duplicate of bug 11074 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 12:30:37 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 17:30:37 +0000 Subject: [LLVMbugs] [Bug 11310] const pointers to instances is allowed to modify the instance it points In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11310 muthuveerappan.al at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from muthuveerappan.al at gmail.com 2011-11-04 12:30:37 CDT --- Sorry I made a mistake with the example and the bug raised is invalid. Thanks, Muthu -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 12:30:43 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 17:30:43 +0000 Subject: [LLVMbugs] [Bug 11268] CPP backend not support some new instructions (such as atomicrmw) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11268 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |wendling at apple.com Resolution| |FIXED --- Comment #3 from Eli Friedman 2011-11-04 12:30:43 CDT --- I committed your suggested fix in r143712. Bill, what do you think of merging 143406 and 143712 into the 3.0 release? -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 13:05:47 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 18:05:47 +0000 Subject: [LLVMbugs] [Bug 8156] LegalizeOp incorrect node updates! In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8156 Dan Gohman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #5 from Dan Gohman 2011-11-04 13:05:47 CDT --- Reapplied in r143660. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 13:12:08 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 18:12:08 +0000 Subject: [LLVMbugs] [Bug 11257] "Unused parameter" warnings when compiling headers with gcc 4.5.3 and -Wall In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11257 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Eli Friedman 2011-11-04 13:12:08 CDT --- r143715. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 13:15:38 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 18:15:38 +0000 Subject: [LLVMbugs] [Bug 11313] New: warning with conditional operator and printf Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11313 Bug #: 11313 Summary: warning with conditional operator and printf Product: clang Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: enhancement Priority: P Component: Frontend AssignedTo: unassignedclangbugs at nondot.org ReportedBy: loox at e-shell.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The is a false positive in the format checker, when using conditional operator and parameters get promoted. There is more info in this thread: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-November/018464.html -- clang -Wall -o ntohs2 ntohs2.c ntohs2.c:10:12: warning: conversion specifies type 'unsigned short' but the argument has type 'int' [-Wformat] printf("%hu\n", x < 0 ? x : y); ~~^ ~~~~~~~~~~~~~ %d 1 warning generated. -- #include #include int main() { uint16_t x = htons(80); uint16_t y = ntohs(80); x = x < 0 ? x : y; printf("%hu\n", y); printf("%hu\n", x < 0 ? x : y); return (0); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Nov 4 14:25:05 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 19:25:05 +0000 Subject: [LLVMbugs] [Bug 11303] Objective - C - instance method "copyWithZone" being allowed to be invoked using a non-root class object In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11303 muthuveerappan.al at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from muthuveerappan.al at gmail.com 2011-11-04 14:25:05 CDT --- Sorry this works as expected. This is not a bug. I didn't realize that there is a class method copyWithZone defined in NSObject. -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 14:46:33 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 19:46:33 +0000 Subject: [LLVMbugs] [Bug 11296] -ffreestanding no longer recognizes auto-returns_twice In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11296 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 Fri Nov 4 14:47:25 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 19:47:25 +0000 Subject: [LLVMbugs] [Bug 11296] -ffreestanding no longer recognizes auto-returns_twice In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11296 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Rafael ?vila de Esp?ndola 2011-11-04 14:47:25 CDT --- sorry, bugzilla tricked me into closing the wrong 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 Nov 4 14:49:24 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 19:49:24 +0000 Subject: [LLVMbugs] [Bug 11300] llvm produces a AT_specification that is a forward reference In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11300 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |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 Nov 4 16:16:30 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 21:16:30 +0000 Subject: [LLVMbugs] [Bug 11314] New: Assertion `BestRC && "Couldn't find the register class" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11314 Bug #: 11314 Summary: Assertion `BestRC && "Couldn't find the register class" Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: pdox at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 7577 --> http://llvm.org/bugs/attachment.cgi?id=7577 reproducer After r143660, the attached bitcode triggers an assertion when compiled with: $ llc -march=x86 -mcpu=pentium4 -mtriple=i686-none-linux bug.ll llvm/lib/Target/TargetRegisterInfo.cpp:68: const llvm::TargetRegisterClass* llvm::TargetRegisterInfo::getMinimalPhysRegClass(unsigned int, llvm::EVT) const: Assertion `BestRC && "Couldn't find the register class"' failed. 0 llc 0x0000000000d9a01f 1 llc 0x0000000000d9c292 2 libpthread.so.0 0x00007fdd4a1118f0 3 libc.so.6 0x00007fdd49400a75 gsignal + 53 4 libc.so.6 0x00007fdd494045c0 abort + 384 5 libc.so.6 0x00007fdd493f9941 __assert_fail + 241 6 llc 0x0000000000c3d034 llvm::TargetRegisterInfo::getMinimalPhysRegClass(unsigned int, llvm::EVT) const + 324 7 llc 0x00000000007d67b4 8 llc 0x00000000007d714f 9 llc 0x0000000000a5ad71 llvm::ScheduleDAG::Run(llvm::MachineBasicBlock*, llvm::ilist_iterator) + 1617 10 llc 0x0000000000855ebb llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1403 11 llc 0x0000000000856c9e llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 270 12 llc 0x0000000000859b19 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2265 13 llc 0x000000000085f430 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1024 14 llc 0x0000000000cf00bb llvm::FPPassManager::runOnFunction(llvm::Function&) + 587 15 llc 0x0000000000cf01a3 llvm::FPPassManager::runOnModule(llvm::Module&) + 51 16 llc 0x0000000000cefbb7 llvm::MPPassManager::runOnModule(llvm::Module&) + 503 17 llc 0x0000000000cefd4b llvm::PassManagerImpl::run(llvm::Module&) + 187 18 llc 0x000000000052f5da main + 4234 19 libc.so.6 0x00007fdd493ebc4d __libc_start_main + 253 20 llc 0x000000000052cb99 Stack dump: 0. Program arguments: llvm-install/bin/llc -march=x86 -mcpu=pentium4 -mtriple=i686-none-linux bug.ll -o bug.s 1. Running pass 'Function Pass Manager' on module 'bug.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@sscanf' -- Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 4 18:56:51 2011 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Nov 2011 23:56:51 +0000 Subject: [LLVMbugs] [Bug 11315] New: Bug in clang with throwing exceptions with noreturn functions? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11315 Bug #: 11315 Summary: Bug in clang with throwing exceptions with noreturn functions? Product: clang Version: 2.9 Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: mamaich at pisem.net CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The following program: #include int main() { try { throw "hello world"; } catch(const char *aaa) { puts(aaa); } catch(...) { puts("unknown exception"); } } when compiled with GCC on MinGW outputs "hello world". While when compiled with "clang++.exe prog.cpp" - it crashes with the error "terminate called after throwing an instance of 'char const*'". I've examined the code obtained with "llc -march=c prog.o" from a generated LLVM code: unsigned int main(void) { unsigned int llvm_cbe_tmp__1; /* Address-exposed local */ unsigned char *llvm_cbe_tmp__2; /* Address-exposed local */ unsigned char *llvm_cbe_aaa; /* Address-exposed local */ unsigned char *llvm_cbe_tmp__3; CODE_FOR_MAIN(); *(&llvm_cbe_tmp__1) = 0u; llvm_cbe_tmp__3 = __cxa_allocate_exception(4u); *(((unsigned char **)llvm_cbe_tmp__3)) = ((&_OC_str.array[((signed int )0u)])); __cxa_throw(llvm_cbe_tmp__3, ((unsigned char *)(&_ZTIPKc)), ((unsigned char *)/*NULL*/0)); /*UNREACHABLE*/; } there is no "catch" block code at all. LLVM code seems to be corect (i'm not familiar with it): define i32 @main() { %1 = alloca i32, align 4 %2 = alloca i8* %aaa = alloca i8*, align 4 store i32 0, i32* %1 %3 = call i8* @__cxa_allocate_exception(i32 4) nounwind %4 = bitcast i8* %3 to i8** store i8* getelementptr inbounds ([18 x i8]* @.str, i32 0, i32 0), i8** %4 invoke void @__cxa_throw(i8* %3, i8* bitcast (i8** @_ZTIPKc to i8*), i8* null) noreturn to label %22 unwind label %5 ;