From bugzilla-daemon at llvm.org Wed Apr 1 02:28:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 09:28:51 +0000 Subject: [LLVMbugs] [Bug 23096] New: opt -gvn crash Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23096 Bug ID: 23096 Summary: opt -gvn crash Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: bruce.mitchener at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14130 --> https://llvm.org/bugs/attachment.cgi?id=14130&action=edit Minimized test case to reproduce crash When running "opt -gvn" against the attached IR, it crashes with infinite recursion: frame #9000: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9001: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9002: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9003: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9004: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9005: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9006: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9007: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9008: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9009: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9010: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbfa7d0, V=0x0000000103405b80, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220 frame #9011: 0x000000010051468e opt`llvm::PHITransAddr::PHITranslateValue(this=0x00007fff5fbfa7d0, CurBB=0x00000001034044e0, PredBB=0x00000001034044e0, DT=0x0000000000000000) + 158 at PHITransAddr.cpp:322 frame #9012: 0x00000001004fcce4 opt`llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(this=0x0000000103401f10, Pointer=0x00007fff5fbfc030, Loc=0x00007fff5fbfb198, isLoad=true, StartBB=0x00000001034044e0, Result=0x00007fff5fbfd100, Visited=0x00007fff5fbfc778, SkipFirstBlock=false) + 7620 at MemoryDependenceAnalysis.cpp:1240 frame #9013: 0x00000001004fd00f opt`llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(this=0x0000000103401f10, Pointer=0x00007fff5fbfc7b8, Loc=0x00007fff5fbfc890, isLoad=true, StartBB=0x00000001034047b0, Result=0x00007fff5fbfd100, Visited=0x00007fff5fbfc778, SkipFirstBlock=false) + 8431 at MemoryDependenceAnalysis.cpp:1301 frame #9014: 0x00000001004fae3f opt`llvm::MemoryDependenceAnalysis::getNonLocalPointerDependency(this=0x0000000103401f10, Loc=0x00007fff5fbfc890, isLoad=true, FromBB=0x00000001034047b0, Result=0x00007fff5fbfd100) + 367 at MemoryDependenceAnalysis.cpp:876 frame #9015: 0x0000000100f77230 opt`(anonymous namespace)::GVN::processNonLocalLoad(this=0x0000000103402dc0, LI=0x0000000103406258) + 192 at GVN.cpp:1711 frame #9016: 0x0000000100f73cb8 opt`(anonymous namespace)::GVN::processLoad(this=0x0000000103402dc0, L=0x0000000103406258) + 1432 at GVN.cpp:1905 frame #9017: 0x0000000100f72f3f opt`(anonymous namespace)::GVN::processInstruction(this=0x0000000103402dc0, I=0x0000000103406258) + 367 at GVN.cpp:2227 frame #9018: 0x0000000100f72b8b opt`(anonymous namespace)::GVN::processBlock(this=0x0000000103402dc0, BB=0x00000001034047b0) + 251 at GVN.cpp:2402 frame #9019: 0x0000000100f6cc51 opt`(anonymous namespace)::GVN::iterateOnFunction(this=0x0000000103402dc0, F=0x0000000103404050) + 1361 at GVN.cpp:2657 frame #9020: 0x0000000100f6c5c2 opt`(anonymous namespace)::GVN::runOnFunction(this=0x0000000103402dc0, F=0x0000000103404050) + 626 at GVN.cpp:2360 frame #9021: 0x0000000100b5429b opt`llvm::FPPassManager::runOnFunction(this=0x0000000103408a30, F=0x0000000103404050) + 427 at LegacyPassManager.cpp:1541 frame #9022: 0x0000000100b545a8 opt`llvm::FPPassManager::runOnModule(this=0x0000000103408a30, M=0x0000000103401410) + 104 at LegacyPassManager.cpp:1561 frame #9023: 0x0000000100b54fb4 opt`(anonymous namespace)::MPPassManager::runOnModule(this=0x00000001034041f0, M=0x0000000103401410) + 1412 at LegacyPassManager.cpp:1619 frame #9024: 0x0000000100b5485e opt`llvm::legacy::PassManagerImpl::run(this=0x0000000103401770, M=0x0000000103401410) + 302 at LegacyPassManager.cpp:1726 frame #9025: 0x0000000100b55731 opt`llvm::legacy::PassManager::run(this=0x00007fff5fbfeca0, M=0x0000000103401410) + 33 at LegacyPassManager.cpp:1763 frame #9026: 0x000000010003a946 opt`main(argc=3, argv=0x00007fff5fbff9b8) + 12630 at opt.cpp:716 frame #9027: 0x00007fff87ac35c9 libdyld.dylib`start + 1 frame #9028: 0x00007fff87ac35c9 libdyld.dylib`start + 1 This happens with: LLVM 3.6.0 release, trunk as of earlier this week and the emscripten-fastcomp branch. (That means it probably also happens with current PNaCl.) The crash in our codebase happens in the implementation of wcsstr() which comes from the MUSL libc as used by emscripten. I will attach the IR for that function in case it helps to see that in addition to the minimized test case. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 09:12:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 16:12:32 +0000 Subject: [LLVMbugs] [Bug 23097] New: Invalid code generation (regression) in pass-by-value on PowerPC Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23097 Bug ID: 23097 Summary: Invalid code generation (regression) in pass-by-value on PowerPC Product: clang Version: 3.6 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: andyg1001 at hotmail.co.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14132 --> https://llvm.org/bugs/attachment.cgi?id=14132&action=edit Simplified test case I've spotted a regression between clang 3.4.1 and 3.6.0 when compiling for powerpc (compiling for x86 is ok). A simplified test case is attached. The problem occurs on return from test() where the copies of A are destructed. Compiling the test case with clang 3.4.1 produces this output: 1 [0xbf896c08::0x10012008] 1 2 [0xbf896c00::0x10012018] 1 1 [0xbf896bf0::0x10012008] 2 2 [0xbf896be8::0x10012018] 2 1 [0xbf896bf0::0x10012018] 3 2 [0xbf896be8::0x10012018] 3 1 [0xbf896c08::0x10012008] 1 2 [0xbf896c00::0x10012018] 1 Compiling with clang 3.6.0 produces this output: 1 [0xbf969b38::0x10012008] 1 2 [0xbf969b30::0x10012018] 1 1 [0xbf969b08::0x10012008] 2 2 [0xbf969b0c::0x10012018] 2 1 [0xbf969b08::0x10012018] 3 2 [0xbf969b0c::0x10012018] 3 1 [0xbf969b38::0x10012008] 0 2 [0xbf969b30::0x10012018] 2 Also attached are the outputs from the compiler in both llvm and ppc assembly code, in case this is useful. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 09:52:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 16:52:24 +0000 Subject: [LLVMbugs] [Bug 22963] clang++ release 3.6 fails to compile a file when using -target i386-pc-windows-msvc-elf In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22963 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- I made the 32-bit data layouts match in r233819. We can roll it into the next point release. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 09:56:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 16:56:06 +0000 Subject: [LLVMbugs] [Bug 23098] New: Less efficient encoding of shl using direct object emission Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23098 Bug ID: 23098 Summary: Less efficient encoding of shl using direct object emission Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedbugs at nondot.org Reporter: russell_gallop at sn.scee.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified For the following source a less efficient instruction encoding is generated for direct object emission than outputting asm (with -via-file-asm). Using r232944. This is the case as -O0/-O1/-O2/-O3. $ cat test.c int a; void fn1() { a = a << 1 & 255; } $ clang -c test.c -O3 -o test.o && objdump -d test.o test.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 6: 83 e0 7f and $0x7f,%eax 9: c1 e0 01 shl $0x1,%eax c: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 12 12: c3 retq $ clang -c test.c -O3 -via-file-asm -o tests.o && objdump -d tests.o tests.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 6: 83 e0 7f and $0x7f,%eax 9: d1 e0 shl %eax b: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 11 11: c3 retq -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 12:09:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 19:09:30 +0000 Subject: [LLVMbugs] [Bug 23098] Less efficient encoding of shl using direct object emission In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23098 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution|--- |FIXED --- Comment #1 from Benjamin Kramer --- This is not really an assembler problem, we were emitting a suboptimal instruction from the instruction selector. That is fixed in r233832, we're now emitting an addl which as small as the smaller version of shl but has higher throughput on some microarchs. $ clang -c test.c -O3 -o test.o && objdump -d test.o test.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 6: 83 e0 7f and $0x7f,%eax 9: 01 c0 add %eax,%eax b: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 11 11: c3 retq -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 12:28:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 19:28:18 +0000 Subject: [LLVMbugs] [Bug 23099] New: std::future regression Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23099 Bug ID: 23099 Summary: std::future regression Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: dirk.ribbrock at mathematik.tu-dortmund.de CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Since using clang 3.6.0, the following code crashes with "Illegal instruction (core dumped)" Whereas clang 3.5.0 returns the correct output value "1" //file future.cpp #include #include #include int bla() { return 1; } int main() { std::future f = std::async(std::launch::async, bla); f.wait(); std::cout< From bugzilla-daemon at llvm.org Wed Apr 1 13:01:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 20:01:55 +0000 Subject: [LLVMbugs] [Bug 23100] New: Suboptimal encoding of 64 bit and with small immediate Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23100 Bug ID: 23100 Summary: Suboptimal encoding of 64 bit and with small immediate Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: benny.kra at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat t.c long long foo(long long x) { return x & 42; } $ clang -S -o - t.c -O3|grep and|llvm-mc -show-encoding andq $42, %rdi # encoding: [0x48,0x83,0xe7,0x2a] $ gcc -S -o - t.c -O3|grep and|llvm-mc -show-encoding andl $42, %eax # encoding: [0x83,0xe0,0x2a] We have a pattern for this in X86InstrCompiler.td but it's not getting selected for some reason. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 13:05:59 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 20:05:59 +0000 Subject: [LLVMbugs] [Bug 23101] New: Clang crash with -Wdocumentation during delayed typo correction Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23101 Bug ID: 23101 Summary: Clang crash with -Wdocumentation during delayed typo correction Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: Yunzhong_Gao at playstation.sony.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hi, The following buggy test causes clang to crash with -Wdocumentation. could someone take a look? // bug.c //typedef long long __v2di __attribute__ ((__vector_size__ (16))); // missing typedef typedef long long __m128i __attribute__((__vector_size__(16))); /// \param __xx /// yes, this is a typo int test(__m128i __x) { return foo((__v2di)__x); } // end bug.c $ build/Debug+Asserts/bin/clang -cc1 -Wdocumentation -S -o /dev/null bug.c bug.c:4:12: warning: parameter '__xx' not found in the function declaration /// \param __xx ^~~~ bug.c:4:12: note: did you mean '__x'? /// \param __xx ^~~~ __x bug.c:8:10: warning: implicit declaration of function 'foo' is invalid in C99 return foo((__v2di)__x); ^ bug.c:8:22: error: expected ')' return foo((__v2di)__x); ^ bug.c:8:13: note: to match this '(' return foo((__v2di)__x); ^ clang: llvm/tools/clang/lib/Sema/Sema.cpp:273: clang::Sema::~Sema(): Assertion `DelayedTypos.empty() && "Uncorrected typos!"' failed. 0 clang 0x000000000443ef80 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 44 1 clang 0x000000000443f295 2 clang 0x000000000443dd95 3 libpthread.so.0 0x00007f90c2781340 4 libc.so.6 0x00007f90c19bdf79 gsignal + 57 5 libc.so.6 0x00007f90c19c1388 abort + 328 6 libc.so.6 0x00007f90c19b6e36 7 libc.so.6 0x00007f90c19b6ee2 8 clang 0x00000000019e05d2 clang::Sema::~Sema() + 500 9 clang 0x00000000012e5f84 std::default_delete::operator()(clang::Sema*) const + 34 10 clang 0x00000000012ddf2c std::unique_ptr >::reset(clang::Sema*) + 80 11 clang 0x00000000012fdb8f clang::CompilerInstance::setSema(clang::Sema*) + 39 12 clang 0x000000000133c4a3 clang::FrontendAction::EndSourceFile() + 283 13 clang 0x000000000130172c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 784 14 clang 0x00000000012c31eb clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 993 15 clang 0x00000000012af2a8 cc1_main(llvm::ArrayRef, char const*, void*) + 770 16 clang 0x00000000012bcab8 17 clang 0x00000000012bd09a main + 1069 18 libc.so.6 0x00007f90c19a8ec5 __libc_start_main + 245 19 clang 0x00000000012ada09 Stack dump: 0. Program arguments: build/Debug+Asserts/bin/clang -cc1 -Wdocumentation -S -o /dev/null bug.c Aborted (core dumped) $ build/Debug+Asserts/bin/clang --version clang version 3.7.0 (trunk 233464) Target: x86_64-unknown-linux-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 13:31:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 20:31:55 +0000 Subject: [LLVMbugs] [Bug 23102] New: Typeinfo references not merged Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23102 Bug ID: 23102 Summary: Typeinfo references not merged Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Given test.cpp: ------------------------ void f(); void g() { try { f(); } catch (int x) { } } ------------------------- test2.cpp: -------------------------- void f(); void h() { try { f(); } catch (int x) { } } ------------------------------ With gcc $ gcc test.cpp test2.cpp -O3 -fPIC -shared -o test.so $ readelf -r test.so | grep ZTI 000000001c88 000b00000001 R_X86_64_64 0000000000000000 _ZTIi + 0 with clang: $ clang test.cpp test2.cpp -O3 -fPIC -shared -o test.so $ readelf -r test.so | grep ZTI 000000001bf0 000700000001 R_X86_64_64 0000000000000000 _ZTIi + 0 000000001bf8 000700000001 R_X86_64_64 0000000000000000 _ZTIi + 0 The difference is that gcc puts the reference to the typeinfo in a comdat section: .section .data.DW.ref._ZTIi,"awG", at progbits,DW.ref._ZTIi,comdat ... .quad _ZTIi -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 14:47:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 21:47:11 +0000 Subject: [LLVMbugs] [Bug 23103] New: Crash in Register Scavenger Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23103 Bug ID: 23103 Summary: Crash in Register Scavenger Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: sunil_srivastava at playstation.sony.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 16:55:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 23:55:15 +0000 Subject: [LLVMbugs] [Bug 21292] __attribute__((used)) possibly ignored for static function with inline assembler? In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21292 Dan Albert changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #2 from Dan Albert --- I just checked and it's still affecting Android (reverting https://android-review.googlesource.com/#/c/110170/ and trying to build libc++ for the generic ARM target is enough to repro). Will have to do some more digging to figure out what we do differently that is causing this though. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 16:55:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 01 Apr 2015 23:55:17 +0000 Subject: [LLVMbugs] [Bug 21420] [Meta] Android+Clang platform support In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21420 Bug 21420 depends on bug 21292, which changed state. Bug 21292 Summary: __attribute__((used)) possibly ignored for static function with inline assembler? https://llvm.org/bugs/show_bug.cgi?id=21292 What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 17:13:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 00:13:36 +0000 Subject: [LLVMbugs] [Bug 23104] New: Copy relocation against protected symbol doesn't work Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23104 Bug ID: 23104 Summary: Copy relocation against protected symbol doesn't work Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: hjl.tools at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Protected data symbol means that it can't be preempted. It doesn't mean its address won't be external. This is true for pointer to protected function. With copy relocation, address of protected data defined in the shared library may also be external. We only know that for sure at run-time. On Linux/x86-64, with linker from binutils master branch: [hjl at gnu-6 pr65248]$ cat bar.c int a; __attribute__((visibility("protected"))) int a; void bar () { a = 30; } [hjl at gnu-6 pr65248]$ make CC=/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang libbar.so /export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -O3 -fpic -c -o bar.o bar.c /export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -shared -o libbar.so bar.o /usr/local/bin/ld: bar.o: relocation R_X86_64_PC32 against protected symbol `a' can not be used when making a shared object /usr/local/bin/ld: final link failed: Bad value clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [libbar.so] Error 1 [hjl at gnu-6 pr65248]$ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 23:14:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 06:14:26 +0000 Subject: [LLVMbugs] [Bug 21421] relocations for new removed when optimization turned on In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21421 Kevin Qin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kevinqindev at gmail.com Resolution|--- |INVALID --- Comment #1 from Kevin Qin --- As discussed in https://groups.google.com/forum/#!topic/llvm-dev/hRO_qRHFst4, this is valid optimization from llvm instruction combining. To avoid llvm optimizing this, please compile it with -ffreestanding. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 1 23:14:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 06:14:27 +0000 Subject: [LLVMbugs] [Bug 21420] [Meta] Android+Clang platform support In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21420 Bug 21420 depends on bug 21421, which changed state. Bug 21421 Summary: relocations for new removed when optimization turned on https://llvm.org/bugs/show_bug.cgi?id=21421 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 00:33:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 07:33:28 +0000 Subject: [LLVMbugs] [Bug 23105] New: C: allow conversion of pointer to arrays to pointers to const arrays Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23105 Bug ID: 23105 Summary: C: allow conversion of pointer to arrays to pointers to const arrays Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: uecker at eecs.berkeley.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Starting with version 5, gcc will not warn anymore about incompatible pointer types when converting a pointer to an array to a pointer to a const array. (The underlying issue in the C standard is that the qualifier is attached to the element type, so the usual rule which allows addition of a qualifier to a pointer target does not apply). Please also consider this change for clang. This would allow reasonable code such as the following to work without warnings: void foo(const double input[3][3]); double b[3][3]; foo(b); -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 05:43:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 12:43:24 +0000 Subject: [LLVMbugs] [Bug 23106] New: Division followed by modulo generates longer machine code than vice versa Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23106 Bug ID: 23106 Summary: Division followed by modulo generates longer machine code than vice versa Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: ed at 80386.nl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider the following piece of C code: #include struct tv { int64_t tv_sec; int32_t tv_usec; }; void convert1(uint64_t ts, struct tv *tv) { tv->tv_sec = ts / 1000000000; tv->tv_usec = (ts % 1000000000) / 1000; } void convert2(uint64_t ts, struct tv *tv) { ts /= 1000; tv->tv_sec = ts / 1000000; tv->tv_usec = ts % 1000000; } Essentially they are functions that convert a UNIX timestamp in nanoseconds to a struct timeval-like structure (with microseconds precision). Both functions should be identical. Anyway, if I compare the machine code generated by Clang r233700 with -O3, it generates the following machine code: 0000000000000000 : 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 89 f8 mov %rdi,%rax 7: 48 c1 e8 09 shr $0x9,%rax b: 48 b9 53 5a 9b a0 2f mov $0x44b82fa09b5a53,%rcx 12: b8 44 00 15: 48 f7 e1 mul %rcx 18: 48 c1 ea 0b shr $0xb,%rdx 1c: 48 89 16 mov %rdx,(%rsi) 1f: 48 69 c2 00 ca 9a 3b imul $0x3b9aca00,%rdx,%rax 26: 48 29 c7 sub %rax,%rdi 29: 48 c1 ef 03 shr $0x3,%rdi 2d: 48 b9 cf f7 53 e3 a5 mov $0x20c49ba5e353f7cf,%rcx 34: 9b c4 20 37: 48 89 f8 mov %rdi,%rax 3a: 48 f7 e1 mul %rcx 3d: 48 c1 ea 04 shr $0x4,%rdx 41: 89 56 08 mov %edx,0x8(%rsi) 44: 5d pop %rbp 45: c3 retq 0000000000000000 : 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 89 f8 mov %rdi,%rax 7: 48 c1 e8 03 shr $0x3,%rax b: 48 b9 cf f7 53 e3 a5 mov $0x20c49ba5e353f7cf,%rcx 12: 9b c4 20 15: 48 f7 e1 mul %rcx 18: 48 89 d1 mov %rdx,%rcx 1b: 48 c1 e9 04 shr $0x4,%rcx 1f: 48 c1 ef 09 shr $0x9,%rdi 23: 48 ba 53 5a 9b a0 2f mov $0x44b82fa09b5a53,%rdx 2a: b8 44 00 2d: 48 89 f8 mov %rdi,%rax 30: 48 f7 e2 mul %rdx 33: 48 c1 ea 0b shr $0xb,%rdx 37: 48 89 16 mov %rdx,(%rsi) 3a: 48 ba db 34 b6 d7 82 mov $0x431bde82d7b634db,%rdx 41: de 1b 43 44: 48 89 c8 mov %rcx,%rax 47: 48 f7 e2 mul %rdx 4a: 48 c1 ea 12 shr $0x12,%rdx 4e: 69 c2 40 42 0f 00 imul $0xf4240,%edx,%eax 54: 29 c1 sub %eax,%ecx 56: 89 4e 08 mov %ecx,0x8(%rsi) 59: 5d pop %rbp 5a: c3 As a 30% increase in code size is not negligible, I thought it would make sense to file a bug. Maybe there room for an optimization here? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 07:09:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 14:09:03 +0000 Subject: [LLVMbugs] [Bug 23107] New: Constructor inheritance on template not working correctly Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23107 Bug ID: 23107 Summary: Constructor inheritance on template not working correctly Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: jbreitbart at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14140 --> https://llvm.org/bugs/attachment.cgi?id=14140&action=edit Minimal test case Hi, the attached code does not compile with clang trunk (build a few days ago). It compiles fine with g++ and my understanding is, that it is valid code (but I may be wrong here). Here is the error message: $ clang++ -std=c++14 constructor_inh.cpp constructor_inh.cpp:4:19: error: dependent using declaration resolved to type without 'typename' using myBase::a; ^ constructor_inh.cpp:11:19: note: in instantiation of template class 'a' requested here a b; ^ constructor_inh.cpp:8:8: note: target of using declaration struct a { ^ 1 error generated. If I add a typename to the using declaration the error message changes to constructor_inh.cpp:4:28: error: target of using declaration conflicts with declaration already in scope [...] $ clang -v clang version 3.7.0 (trunk 233370) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.1 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.1 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Selected multilib: .;@m64 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 12:28:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 19:28:36 +0000 Subject: [LLVMbugs] [Bug 23073] [AVX] bloated vector constant loads In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23073 Sanjay Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Sanjay Patel --- Fix checked in: http://reviews.llvm.org/rL233931 The question of why we're generating blends universally is still open (at least in my mind), and I've followed up on the commit mail where those were introduced: http://reviews.llvm.org/rL219022 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 13:56:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 20:56:39 +0000 Subject: [LLVMbugs] [Bug 22685] making zeros the hard way: scalar load into zero vector (AVX) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22685 Sanjay Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Sanjay Patel --- http://reviews.llvm.org/rL233704 http://reviews.llvm.org/rL233724 http://reviews.llvm.org/rL233931 http://reviews.llvm.org/rL233941 After those, I think we can declare victory. The AVX2 codegen for the test cases in comment 4 is ideal: _mov_v8f32: ## @mov_v8f32 .cfi_startproc ## BB#0: vmovss (%rdi), %xmm1 ## xmm1 = mem[0],zero,zero,zero vaddps %ymm0, %ymm1, %ymm0 retq .cfi_endproc .globl _mov_v4f64 .align 4, 0x90 _mov_v4f64: ## @mov_v4f64 .cfi_startproc ## BB#0: vmovsd (%rdi), %xmm1 ## xmm1 = mem[0],zero vaddpd %ymm0, %ymm1, %ymm0 retq .cfi_endproc .globl _mov_v4i64 .align 4, 0x90 _mov_v4i64: ## @mov_v4i64 .cfi_startproc ## BB#0: vmovq (%rdi), %xmm1 ## xmm1 = mem[0],zero vpaddq %ymm0, %ymm1, %ymm0 retq .cfi_endproc .globl _mov_v8i32 .align 4, 0x90 _mov_v8i32: ## @mov_v8i32 .cfi_startproc ## BB#0: vmovd (%rdi), %xmm1 ## xmm1 = mem[0],zero,zero,zero vpaddd %ymm0, %ymm1, %ymm0 retq .cfi_endproc .globl _mov_v16i16 .align 4, 0x90 _mov_v16i16: ## @mov_v16i16 .cfi_startproc ## BB#0: movzwl (%rdi), %eax vmovd %eax, %xmm0 vpaddw %ymm0, %ymm1, %ymm0 retq .cfi_endproc .globl _mov_v32i8 .align 4, 0x90 _mov_v32i8: ## @mov_v32i8 .cfi_startproc ## BB#0: movzbl (%rdi), %eax vmovd %eax, %xmm1 vpaddb %ymm0, %ymm1, %ymm0 retq ------------------------------------------------------------------------------- There's still something screwy with AVX1 and the integer cases, but this will be a separate bug: vmovd (%rdi), %xmm1 ## xmm1 = mem[0],zero,zero,zero vpaddd %xmm0, %xmm1, %xmm1 vextractf128 $1, %ymm0, %xmm0 vinsertf128 $1, %xmm0, %ymm1, %ymm0 retq -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 15:17:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 22:17:36 +0000 Subject: [LLVMbugs] [Bug 23018] clang claims an inherited constructor protected when declared public with using In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23018 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- An inheriting constructor has the same access as the corresponding original constructor. See [class.inhctor]p4. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 15:18:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 22:18:35 +0000 Subject: [LLVMbugs] [Bug 23107] Constructor inheritance on template not working correctly In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23107 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |DUPLICATE --- Comment #1 from Richard Smith --- The C++ committee have discussed this case and did not intend for that syntax to be valid. Use using myBase::myBase; instead to declare an inheriting constructor. *** This bug has been marked as a duplicate of bug 22242 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 16:10:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 02 Apr 2015 23:10:43 +0000 Subject: [LLVMbugs] [Bug 23108] New: Potential bad code generation with TLS and PowerPC Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23108 Bug ID: 23108 Summary: Potential bad code generation with TLS and PowerPC Product: new-bugs Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: matt.davis at pgroup.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hello, I have discovered a potential inconsistency with LLVM and TLS code generation for PowerPC, specifically Power8. This test program exists as two object files, test.o which references an external TLS variable "y", which belongs to test_a.o. These two .o files are linked together to create my test application. I am not compiling this example with -relocation-model=pic The variable in question, "y", is located in the initialized data section of the resulting executable. Now, on to my issue: I have an external TLS integer variable, "y" which is declared as the following from my test.c source file. @y = external thread_local global i32 ,section ".comm" , align 4 When my code first tries to access this external variable, my compiler emits the following code sequence in llvm to access and then add the value of another int to 'y': Build: llc ./test.ll -mcpu=native -o ./test.s Result: %41 = load i32* @y, align 4, !dbg !20 ... %57 = add i32 %41, %56, !dbg !20 This generates the following asm: Build: /usr/bin/as ./test.s -mpower8 -o test.o Result: ld 0, y at got@tprel at l(6) addis 7, 2, x at got@tprel at ha lwz 30, -120(1) lwz 29, -116(1) add 28, 0, y at tls lwz 0, -96(1) lwz 28, 0(28) ld 27, x at got@tprel at l(7) lwz 26, -76(1) lwz 25, -80(1) lwz 24, -84(1) lwz 23, -88(1) add 26, 26, 25 Since GNU-ld can manipulate TLS instructions (for optimization purposes) the following is the resulting object code after linking: <+360>: addis r7,r13,0 <+364>: lwz r8,-112(r1) <+368>: lwz r11,-124(r1) <+372>: addi r7,r7,-28664 <+376>: lwz r12,0(r7) <+380>: addis r0,r13,0 <+384>: nop <+388>: lwz r30,-120(r1) <+392>: lwz r29,-116(r1) <+396>: li r28,-28668 <+400>: lwz r0,-96(r1) <+404>: lwz r28,0(r28) What concerns me, and is causing a segfault is offset +396 to +400. The linker transforms the asm to object code: add 28, 0, y at tls transformed--> li r28,-28668 The following lwz at +404 in the object code will try to load r28 (which is a negative value/not-an-address). This segfaults my application. Looking at the Power8 ABI for TLS and the specific "add 28, 0, y at tls" instruction. 1) This appears to be the following relocation: R_PPC64_TLS (y + 0) 2) The Power8 ABI specifies that the "add" and "r9" registers are to be used. It is not clear to me if the explicit register values as noted in the ABI have to be used, but it would seem that way. I have noticed there appears to be a clobber of a register if I specify PIC compilation. So is there a code generation fault on behalf of LLVM, or is there something I have missed? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 18:37:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 01:37:00 +0000 Subject: [LLVMbugs] [Bug 23109] New: clang-cl does not recognize -fno-color-diagnostics Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23109 Bug ID: 23109 Summary: clang-cl does not recognize -fno-color-diagnostics Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: bernard.solomon at siemens.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified while clang-cl.exe will handle -fcolor-diagnostics which is the default it would not take -fno-color-diagnostics which I prefer for my color schemes. I attach a patch which enables it. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 2 21:57:59 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 04:57:59 +0000 Subject: [LLVMbugs] [Bug 23110] New: ICE when using malformed raw string literal as default parameter Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23110 Bug ID: 23110 Summary: ICE when using malformed raw string literal as default parameter Product: new-bugs Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: adamschwalm at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14142 --> https://llvm.org/bugs/attachment.cgi?id=14142&action=edit stack trace for the sample program When using a malformed raw string literal as a default argument to a member function template, an internal compiler error occurs. LLVM installed from the arch linux packages. Here is a small example case, named test1.cpp and compiled with 'clang++ -std=c++11 test1.cpp' it produces the attached stacktrace: #include #include struct S { template void foo(std::string s = R"\S+") {} }; int main() { S{}.foo(); } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 02:43:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 09:43:08 +0000 Subject: [LLVMbugs] [Bug 23112] New: clang-cl: /fp is not supported Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23112 Bug ID: 23112 Summary: clang-cl: /fp is not supported Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: david.majnemer at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified It looks like /fp:fast should map to -ffast-math and /fp:except should map to -ftrapping-math. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 02:43:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 09:43:17 +0000 Subject: [LLVMbugs] [Bug 23113] New: [instcombine] crash with (Assertion `SrcElemBitWidth && "vector elements must have a bitwidth"' failed) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23113 Bug ID: 23113 Summary: [instcombine] crash with (Assertion `SrcElemBitWidth && "vector elements must have a bitwidth"' failed) Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: Hao.Liu at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14143 --> https://llvm.org/bugs/attachment.cgi?id=14143&action=edit patch to fix the instcombine crash on pointer vector The instcombine came across an assertion failure in when visiting shufflevector and checking if the shuffle extracting from LHS as follows: llvm::Instruction* llvm::InstCombiner::visitShuffleVectorInst(llvm::ShuffleVectorInst&): Assertion `SrcElemBitWidth && "vector elements must have a bitwidth"' failed. The root cause is getPrimitiveSizeInBits returns 0 for pointer vector. So I created a patch to disable such check for pointer vectors. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 03:19:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 10:19:22 +0000 Subject: [LLVMbugs] [Bug 23114] New: Usage of attribute address_space causes error in backend Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23114 Bug ID: 23114 Summary: Usage of attribute address_space causes error in backend Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: svenk.public at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14144 --> https://llvm.org/bugs/attachment.cgi?id=14144&action=edit run script Casting to a pointer with the 'address_space' attribute causes a fatal error in the backend. Error message: fatal error: error in backend: Cannot select: 0x38752a0: i64 = addrspacecast 0x3875190[0 -> 257] [ORD=8] [ID=12] 0x3875190: i64,ch = load 0x3875080, 0x3874910, 0x3874b30 [ORD=7] [ID=11] 0x3874910: i64 = FrameIndex<0> [ID=2] 0x3874b30: i64 = undef [ID=3] In function: func clang-3.7: error: clang frontend command failed with exit code 70 (use -v to see invocation) Example code to reproduce error: #define FS_RELATIVE __attribute__((address_space(257))) void func(char * p1, char * p2) { FS_RELATIVE char * p11 = (FS_RELATIVE char *) p1; /* 01 */ *p11 = *p2; } Possible workaround is to introduce a cast to a non-pointer-type, i.e. replace line marked /* 01 */ with: FS_RELATIVE char * p11 = (FS_RELATIVE char *)(unsigned long)p1; -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 10:11:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 17:11:17 +0000 Subject: [LLVMbugs] [Bug 23115] New: LLVM opt and ordering of floating point conversions with potential overflow Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23115 Bug ID: 23115 Summary: LLVM opt and ordering of floating point conversions with potential overflow Product: new-bugs Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: matt.davis at pgroup.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hello, I found a potential reordering of instructions produced by llvm's optimizer, that is unfavorable to floating point expressions. Our compiler will unroll the loop in the case that we are examining. With that said, the llvm code we intentionally generate is the following: OpenACC c code: int useVLA (int useacc, long size,const int n1, float avla[n1]) { #pragma acc kernels pcopy(avla[0:n1]) if (useacc) { #pragma acc loop independent for (int i=0; i < n1; ++i1) { avla[i] = (float) (1) + (float) (i + 1) ; } } The code I care about is specifically the ordering of the integer additions and float conversion: (float)(1) + (float)(i + 1) What we generate as llvm (and this is correct): %16 load i32* %.ndi0002.addr, align 4, !dbg !28 %17 = add i32 %16, 1, !dbg !28 %18 = sitofp i32 %17 to float, !dbg !28 %19 = load float* %.r1.0018.addr, align 4, !dbg !28 %20 = fadd float %18, %19, !dbg !28 %21 = load i8** %.G0001.addr, align 8, !dbg !28 %22 = getelementptr i8* %21, i64 -28, !dbg !28 %23 = bitcast i8* %22 to float*, !dbg !28 store float %20, float* %23, align 4, !dbg !28 %16 and %17 perform the integer add for (i + 1). %18 converts the result to a single precision float. %19 loads a constant (this is fine) as a floating point %20 - %23 perform the floating point addition and store into the array. That is fine. However, after llvm optimization, opt generates the transformed code: %13 = or i32 %.ndi0002.addr.0, 1, !dbg !14 %addconv = add nsw i32 %13, 1, !dbg !14 %14 = sitofp i32 %addconv to float, !dbg !14 %15 = getelementptr i8* %.G0001.addr.0, i64 -28, !dbg !14 %16 = bitcast i8* %15 to float*, !dbg !14 store float %14, float* %16, align 4, !dbg !14 %13 and the %addconv perform the (i + 1) + 1 and then convert that combined result as a single precision float. Ideally, to avoid overflow, we wanted the semantics similar to the original llvm code in the previous example, whereby we perform i + 1 and then convert to float, and fadd that result to a floating point value of 1.0. This seems to happen when we use the following optimizations: -sroa and -instcombine Thanks, -Matt -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 10:34:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 17:34:43 +0000 Subject: [LLVMbugs] [Bug 23116] New: Missed optimisation - horizontal max for vectors is not optimised. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23116 Bug ID: 23116 Summary: Missed optimisation - horizontal max for vectors is not optimised. Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: nick at indigorenderer.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Computing the horizontal max (or min etc..) of a vector is not optimised to faster code. For example, the C code: #include inline float max(float a, float b) { return a > b ? a : b; } float findMax(__m256 v) { return max(max(max(max(max(max(max(v[0], v[1]), v[2]), v[3]), v[4]), v[5]), v[6]), v[7]); } Is compiled to by Clang 3.7/trunk to: findMax(float __vector(8)): # @findMax(float __vector(8)) vmovshdup %xmm0, %xmm1 # xmm1 = xmm0[1,1,3,3] vmaxss %xmm1, %xmm0, %xmm1 vpermilpd $1, %xmm0, %xmm2 # xmm2 = xmm0[1,0] vmaxss %xmm2, %xmm1, %xmm1 vpermilps $231, %xmm0, %xmm2 # xmm2 = xmm0[3,1,2,3] vmaxss %xmm2, %xmm1, %xmm1 vextractf128 $1, %ymm0, %xmm0 vmaxss %xmm0, %xmm1, %xmm1 vmovshdup %xmm0, %xmm2 # xmm2 = xmm0[1,1,3,3] vmaxss %xmm2, %xmm1, %xmm1 vpermilpd $1, %xmm0, %xmm2 # xmm2 = xmm0[1,0] vmaxss %xmm2, %xmm1, %xmm1 vpermilps $231, %xmm0, %xmm0 # xmm0 = xmm0[3,1,2,3] vmaxss %xmm0, %xmm1, %xmm0 vzeroupper retq Which is basically 7 vmaxss's in serial (slow). It could be optimised to something like: float findMax(__m256 v) { __m128 a = _mm256_extractf128_ps(v, 0); __m128 b = _mm256_extractf128_ps(v, 1); __m128 c = _mm_max_ps(a, b); return max(max(c[0], c[1]), max(c[2], c[3])); } Which compiles to: findMax(float __vector(8)): # @findMax(float __vector(8)) vextractf128 $1, %ymm0, %xmm1 vmaxps %xmm1, %xmm0, %xmm0 vmovshdup %xmm0, %xmm1 # xmm1 = xmm0[1,1,3,3] vmaxss %xmm1, %xmm0, %xmm1 vpermilpd $1, %xmm0, %xmm2 # xmm2 = xmm0[1,0] vpermilps $231, %xmm0, %xmm0 # xmm0 = xmm0[3,1,2,3] vmaxss %xmm0, %xmm2, %xmm0 vmaxss %xmm0, %xmm1, %xmm0 vzeroupper retq See http://goo.gl/jM3KNz for the code. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 10:47:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 17:47:31 +0000 Subject: [LLVMbugs] [Bug 23117] New: Assertion failure parsing block expressions with nonnull attributes Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23117 Bug ID: 23117 Summary: Assertion failure parsing block expressions with nonnull attributes Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: thonermann at coverity.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified An assertion failure occurs in Clang 3.5 through trunk (r234011) when a nonnull attribute appears on a Block expression. Clang 3.4 issues a warning for these cases. The check for a non-function declaration that previously resulted in the warning was removed in r199387. $ cat t.c void(^bp1)(int *) = ^(int *p1) __attribute__((nonnull(1))) {}; $ clang-trunk --version clang version 3.7.0 (trunk 234011) Target: x86_64-unknown-linux-gnu Thread model: posix $ clang-trunk -c -fblocks t.c clang: /nfs/thonermann/src/llvm-trunk/tools/clang/lib/Sema/SemaDeclAttr.cpp:260: bool checkFunctionOrMethodParameterIndex(clang::Sema &, const clang::Decl *, const clang::AttributeList &, unsigned int, const clang::Expr *, uint64_t &): Assertion `isFunctionOrMethod(D)' failed. ... $ clang-3.4 --version clang version 3.4 (tags/RELEASE_34/final) Target: x86_64-unknown-linux-gnu Thread model: posix $ clang-3.4 -c -fblocks t.c t.c:1:47: warning: 'nonnull' attribute only applies to functions [-Wignored-attributes] void(^bp1)(int *) = ^(int *p1) __attribute__((nonnull(1))) {}; ^ 1 warning generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 12:06:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 19:06:57 +0000 Subject: [LLVMbugs] [Bug 23118] New: Poor error message for incompatible member function reference qualifiers Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23118 Bug ID: 23118 Summary: Poor error message for incompatible member function reference qualifiers Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: david at doublewise.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified struct S { void f() & {} }; int main() { S{}.f(); } source/main.cpp:6:2: error: cannot initialize object parameter of type 'S' with an expression of type 'S' S{}.f(); ^~~ The error message should probably reference qualify the S. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 13:19:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 20:19:02 +0000 Subject: [LLVMbugs] [Bug 23113] [instcombine] crash with (Assertion `SrcElemBitWidth && "vector elements must have a bitwidth"' failed) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23113 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Component|new bugs |Scalar Optimizations Resolution|--- |FIXED Product|new-bugs |libraries --- Comment #2 from David Majnemer --- Fixed in r234046. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 16:47:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 03 Apr 2015 23:47:50 +0000 Subject: [LLVMbugs] [Bug 23119] New: RegisterScavenger ignores kill flags on predicated instructions Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23119 Bug ID: 23119 Summary: RegisterScavenger ignores kill flags on predicated instructions Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: tobias at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The RegisterScavenger explicitly ignores flags on operands of predicated instructions and therefore assumes that such registers remain live. When it then scavenges such a register, it inserts a spill of this (killed) register. This is invalid code and gets flagged up by the verifier. RegisterScavenging.cpp includes a comment that explains why it ignores flags on predicated instructions: // FIXME: The scavenger is not predication aware. If the instruction is // predicated, conservatively assume "kill" markers do not actually kill the // register. Similarly ignores "dead" markers. Is this still needed for any target? Just removing the special handling of predicated instructions would seem an easy way to fix this. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 3 19:24:44 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 04 Apr 2015 02:24:44 +0000 Subject: [LLVMbugs] [Bug 23100] Suboptimal encoding of 64 bit and with small immediate In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23100 Craig Topper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Craig Topper --- Fixed in r234075. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 4 11:56:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 04 Apr 2015 18:56:54 +0000 Subject: [LLVMbugs] [Bug 23120] New: clang segfault involving diagnostics, constexpr default initialization, and user-defined literals Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23120 Bug ID: 23120 Summary: clang segfault involving diagnostics, constexpr default initialization, and user-defined literals Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: systems2029 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14145 --> https://llvm.org/bugs/attachment.cgi?id=14145&action=edit Somewhat-reduced test code. Odd crash involving constexpr default initialization, diagnostics, and possibly user-defined literals (couldn't remove them from the code that crashes at least). Segfault goes away if the value in main is correctly initialized, or if basically any other lines in the code are changed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 4 12:13:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 04 Apr 2015 19:13:07 +0000 Subject: [LLVMbugs] [Bug 23121] New: clang segfaults when processing macro code Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23121 Bug ID: 23121 Summary: clang segfaults when processing macro code Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: ryan.burn at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Attached code and script to reproduce. Here is the stack trace: 0 clang-3.7 0x0000000001382fba llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 42 1 clang-3.7 0x000000000138465b 2 libpthread.so.0 0x00007fae16924b10 3 clang-3.7 0x00000000025ce07f clang::TokenLexer::ExpandFunctionArguments() + 2431 4 clang-3.7 0x00000000025cd68f clang::TokenLexer::Init(clang::Token&, clang::SourceLocation, clang::MacroInfo*, clang::MacroArgs*) + 319 5 clang-3.7 0x00000000025b0a2a clang::Preprocessor::EnterMacro(clang::Token&, clang::SourceLocation, clang::MacroInfo*, clang::MacroArgs*) + 154 6 clang-3.7 0x00000000025b3f33 clang::Preprocessor::HandleMacroExpandedIdentifier(clang::Token&, clang::MacroDirective*) + 2179 7 clang-3.7 0x00000000025cbb6d clang::Preprocessor::HandleIdentifier(clang::Token&) + 1293 8 clang-3.7 0x00000000025ce951 clang::TokenLexer::Lex(clang::Token&) + 849 9 clang-3.7 0x00000000025cbbe6 clang::Preprocessor::Lex(clang::Token&) + 102 10 clang-3.7 0x00000000025cffeb clang::MacroArgs::getPreExpArgument(unsigned int, clang::MacroInfo const*, clang::Preprocessor&) + 331 11 clang-3.7 0x00000000025cd8c8 clang::TokenLexer::ExpandFunctionArguments() + 456 12 clang-3.7 0x00000000025cd68f clang::TokenLexer::Init(clang::Token&, clang::SourceLocation, clang::MacroInfo*, clang::MacroArgs*) + 319 13 clang-3.7 0x00000000025b0a2a clang::Preprocessor::EnterMacro(clang::Token&, clang::SourceLocation, clang::MacroInfo*, clang::MacroArgs*) + 154 14 clang-3.7 0x00000000025b3f33 clang::Preprocessor::HandleMacroExpandedIdentifier(clang::Token&, clang::MacroDirective*) + 2179 15 clang-3.7 0x00000000025cbb6d clang::Preprocessor::HandleIdentifier(clang::Token&) + 1293 16 clang-3.7 0x00000000025ce951 clang::TokenLexer::Lex(clang::Token&) + 849 17 clang-3.7 0x00000000025cbbe6 clang::Preprocessor::Lex(clang::Token&) + 102 18 clang-3.7 0x0000000001c3e042 clang::Parser::ParseExpressionList(llvm::SmallVectorImpl&, llvm::SmallVectorImpl&, std::__1::function) + 98 19 clang-3.7 0x0000000001c105a0 clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) + 2976 20 clang-3.7 0x0000000001c0e613 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2915 21 clang-3.7 0x0000000001bfe16d clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) + 733 22 clang-3.7 0x0000000001bfdc70 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) + 384 23 clang-3.7 0x0000000001bfd1a6 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 2854 24 clang-3.7 0x0000000001bfc5b8 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 360 25 clang-3.7 0x0000000001bf9320 clang::ParseAST(clang::Sema&, bool, bool) + 256 26 clang-3.7 0x00000000014fa539 clang::FrontendAction::Execute() + 57 27 clang-3.7 0x00000000014cfcd3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 803 28 clang-3.7 0x000000000156b115 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3381 29 clang-3.7 0x000000000070cd2f cc1_main(llvm::ArrayRef, char const*, void*) + 719 30 clang-3.7 0x000000000070bf0a main + 11226 31 libc.so.6 0x00007fae15e62b95 __libc_start_main + 245 32 clang-3.7 0x0000000000709201 Stack dump: 0. Program arguments: /usr/local/bin/clang-3.7 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name t.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -resource-dir /usr/local/bin/../lib/clang/3.7.0 -I /home/rnburn/proj -internal-isystem /usr/local/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /usr/local/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++1y -fdeprecated-macro -fdebug-compilation-dir /home/rnburn/bugs -ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/t-5f1fa8.o -x c++ t.cpp 1. t.cpp:97:9 >: unknown current parser token clang-3.7: error: unable to execute command: Segmentation fault clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 233507) Target: x86_64-unknown-linux-gnu Thread model: posix clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.7: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.7: note: diagnostic msg: /tmp/t-3fb1e2.cpp clang-3.7: note: diagnostic msg: /tmp/t-3fb1e2.sh clang-3.7: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 4 14:31:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 04 Apr 2015 21:31:50 +0000 Subject: [LLVMbugs] [Bug 23115] LLVM opt and ordering of floating point conversions with potential overflow In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23115 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from David Majnemer --- Matt, I ran the following IR through trunk opt -O2 and nothing happened: define void @f(i32 %.ndi0002.addr.0, i8* %.G0001.addr.0) { %add = add i32 %.ndi0002.addr.0, 1 %sitofp = sitofp i32 %add to float %fadd = fadd float %sitofp, 1.000000e+00 %gep = getelementptr i8, i8* %.G0001.addr.0, i64 -28 %bitcast = bitcast i8* %gep to float* store float %fadd, float* %bitcast, align 4 ret void } My guess is that we fixed this a long time ago. Please reopen if you can reproduce on trunk and attach the reproduction to the report, thanks. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 4 14:43:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 04 Apr 2015 21:43:42 +0000 Subject: [LLVMbugs] [Bug 23122] New: frameescape intrinsic leads to the backend crashing Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23122 Bug ID: 23122 Summary: frameescape intrinsic leads to the backend crashing Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: david.majnemer at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified this C++ crashes the backend: void g(); void f(bool b) { try { g(); } catch (int x) { while (true) { if (b) goto out; } } out: ; } compile with: clang -cc1 -triple x86_64-pc-win32 t.cpp -S -o - -fexceptions -fcxx-exceptions -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 4 16:55:59 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 04 Apr 2015 23:55:59 +0000 Subject: [LLVMbugs] [Bug 23123] New: Detection of RHEL and variants in clang is incomplete Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23123 Bug ID: 23123 Summary: Detection of RHEL and variants in clang is incomplete Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: mlampe0 at googlemail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14149 --> https://llvm.org/bugs/attachment.cgi?id=14149&action=edit Proper detection of EHEL and variants Attached patch fixes: - el7 isn't detected at all - centos & scientific linux are not properly detected - Only add --no-add-needed to the linker flags for fedora and el7 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 4 22:34:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 05 Apr 2015 05:34:00 +0000 Subject: [LLVMbugs] [Bug 23120] clang segfault involving diagnostics, constexpr default initialization, and user-defined literals In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23120 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Component|-New Bugs |C++11 Resolution|--- |FIXED --- Comment #3 from David Majnemer --- Fixed in r234110. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 4 22:49:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 05 Apr 2015 05:49:09 +0000 Subject: [LLVMbugs] [Bug 23121] clang segfaults when processing macro code In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23121 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |WORKSFORME --- Comment #3 from David Majnemer --- Hi Ryan, I can't reproduce with trunk clang (r234090). Please reopen if you can reproduce with r234090 or newer. Thanks. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 5 01:59:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 05 Apr 2015 08:59:24 +0000 Subject: [LLVMbugs] [Bug 23128] New: Instructions for obtaining clang in the LibTooling and LibASTMatchers tutorial are confusing and out of date Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23128 Bug ID: 23128 Summary: Instructions for obtaining clang in the LibTooling and LibASTMatchers tutorial are confusing and out of date Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Documentation Assignee: unassignedclangbugs at nondot.org Reporter: llvm-bugs at justinbogner.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The tutorial at http://clang.llvm.org/docs/LibASTMatchersTutorial.html begins with instructions on obtaining clang. In these instructions, the user is told to configure with "cmake -G Ninja ../llvm -DLLVM_BUILD_TESTS=ON", then install this compiler and use it to bootstrap clang. There are a couple of problems here: 1. Most distributions have clang packages these days, so if we really just need the user to use a clang host compiler we should probably say that, rather than explaining how to bootstrap. 1a. Do we even need clang as a host compiler? Any compiler that can build llvm and clang should be fine, shouldn't it? 2. This builds clang without any optimizations, making the rest of the steps of the tutorial *horribly slow*. At least set CMAKE_BUILD_TYPE=Release. 3. What's up with mentioning LLVM_BUILD_TESTS? It's not necessary for anything in this tutorial, and the check targets build the tests regardless. It's also kind of dated that we explain how to build make and ninja and claim that you should build them yourself because current cmake doesn't support ninja. That hasn't been true for quite a while. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 5 13:55:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 05 Apr 2015 20:55:11 +0000 Subject: [LLVMbugs] [Bug 23129] New: Instrumentation-based PGO doesn't work on OS X (?) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23129 Bug ID: 23129 Summary: Instrumentation-based PGO doesn't work on OS X (?) Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I'm trying to follow the http://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization instructions for building ninja. I can't seem to get it to work -- either I'm holding it wrong, or it broke when it got reshuffled. I'm doing: $ git clone https://github.com/martine/ninja.git Cloning into 'ninja'... remote: Counting objects: 8458, done. remote: Compressing objects: 100% (36/36), done. remote: Total 8458 (delta 15), reused 0 (delta 0), pack-reused 8422 Receiving objects: 100% (8458/8458), 1.86 MiB | 635.00 KiB/s, done. Resolving deltas: 100% (5974/5974), done. Checking connectivity... done. $ cd ninja $ CXX=/Users/thakis/src/llvm-build/bin/clang++ CFLAGS="-stdlib=libstdc++ -fprofile-instr-generate -isysroot $(xcrun -show-sdk-path)" LDFLAGS='-stdlib=libstdc++ -fprofile-instr-generate' ./configure.py warning: A compatible version of re2c (>= 0.11.3) was not found; changes to src/*.in.cc will not affect your build. wrote build.ninja. $ ninja -v [1/24] /Users/thakis/src/llvm-build/bin/clang++ -MMD -MT build/build.o -MF build/build.o.d -g -Wall -Wextra -Wno-deprecated -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe -Wno-missing-field-initializers '-DNINJA_PYTHON="python"' -O2 -DNDEBUG -fdiagnostics-color -DNINJA_HAVE_BROWSE -stdlib=libstdc++ -fprofile-instr-generate -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -c src/build.cc -o build/build.o # ... (omitted, just wanted to show that the flags are there) [24/24] /Users/thakis/src/llvm-build/bin/clang++ -Lbuild -stdlib=libstdc++ -fprofile-instr-generate -o ninja build/ninja.o -lninja $ ./ninja manifest_parser_perftest [2/2] LINK manifest_parser_perftest Nicos-MBP-8:ninja thakis$ ./manifest_parser_perftest Creating manifest data...done. 1128ms (hash: c617022) 1117ms (hash: c617022) 1145ms (hash: c617022) 1131ms (hash: c617022) 1148ms (hash: c617022) min 1117ms max 1148ms avg 1133.8ms $ ls -l default.profraw -rw-r--r-- 1 thakis staff 0 Apr 5 13:56 default.profraw Note that default.profraw is getting generated, but it ends up empty. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 5 15:51:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 05 Apr 2015 22:51:14 +0000 Subject: [LLVMbugs] [Bug 22890] .strtab and .symtab present when --strip-all is used In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22890 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Davide Italiano --- r234130 should help. Thanks for the report. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 5 19:32:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 02:32:34 +0000 Subject: [LLVMbugs] [Bug 23131] New: std::function constructor unable to take std::allocator Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23131 Bug ID: 23131 Summary: std::function constructor unable to take std::allocator Product: libc++ Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: donutydonuts+clang at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified #include #include int main() { // Error on this line // std::function test_fn(std::allocator_arg, std::allocator(), []() { }); // This line works. When changed to std::allocator // std::function test_fn(std::allocator_arg, std::allocator(), []() { }); return 0; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 5 21:56:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 04:56:50 +0000 Subject: [LLVMbugs] [Bug 23121] clang segfaults when processing macro code In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23121 ryan.burn at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME |--- --- Comment #4 from ryan.burn at gmail.com --- I tried with 234142. This still crashes. Here's stack trace 0 clang-3.7 0x00000000012d6b9a llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 42 1 clang-3.7 0x00000000012d7f5b 2 libpthread.so.0 0x00007fe6c8fe9b10 3 clang-3.7 0x000000000245f04f clang::TokenLexer::ExpandFunctionArguments() + 2383 4 clang-3.7 0x000000000245e68f clang::TokenLexer::Init(clang::Token&, clang::SourceLocation, clang::MacroInfo*, clang::MacroArgs*) + 319 5 clang-3.7 0x000000000244337a clang::Preprocessor::EnterMacro(clang::Token&, clang::SourceLocation, clang::MacroInfo*, clang::MacroArgs*) + 154 6 clang-3.7 0x00000000024466c9 clang::Preprocessor::HandleMacroExpandedIdentifier(clang::Token&, clang::MacroDirective*) + 2185 7 clang-3.7 0x000000000245cb7d clang::Preprocessor::HandleIdentifier(clang::Token&) + 1293 8 clang-3.7 0x000000000245f8a2 clang::TokenLexer::Lex(clang::Token&) + 850 9 clang-3.7 0x000000000245cbf6 clang::Preprocessor::Lex(clang::Token&) + 102 10 clang-3.7 0x0000000002460f1b clang::MacroArgs::getPreExpArgument(unsigned int, clang::MacroInfo const*, clang::Preprocessor&) + 331 11 clang-3.7 0x000000000245e8c1 clang::TokenLexer::ExpandFunctionArguments() + 449 12 clang-3.7 0x000000000245e68f clang::TokenLexer::Init(clang::Token&, clang::SourceLocation, clang::MacroInfo*, clang::MacroArgs*) + 319 13 clang-3.7 0x000000000244337a clang::Preprocessor::EnterMacro(clang::Token&, clang::SourceLocation, clang::MacroInfo*, clang::MacroArgs*) + 154 14 clang-3.7 0x00000000024466c9 clang::Preprocessor::HandleMacroExpandedIdentifier(clang::Token&, clang::MacroDirective*) + 2185 15 clang-3.7 0x000000000245cb7d clang::Preprocessor::HandleIdentifier(clang::Token&) + 1293 16 clang-3.7 0x000000000245f8a2 clang::TokenLexer::Lex(clang::Token&) + 850 17 clang-3.7 0x000000000245cbf6 clang::Preprocessor::Lex(clang::Token&) + 102 18 clang-3.7 0x0000000001b2db52 clang::Parser::ParseExpressionList(llvm::SmallVectorImpl&, llvm::SmallVectorImpl&, std::__1::function) + 98 19 clang-3.7 0x0000000001b017b9 clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) + 2361 20 clang-3.7 0x0000000001affc88 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2872 21 clang-3.7 0x0000000001aefb3d clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) + 733 22 clang-3.7 0x0000000001aef640 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) + 384 23 clang-3.7 0x0000000001aeea54 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 2404 24 clang-3.7 0x0000000001aee028 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 360 25 clang-3.7 0x0000000001aead90 clang::ParseAST(clang::Sema&, bool, bool) + 256 26 clang-3.7 0x0000000001441f39 clang::FrontendAction::Execute() + 57 27 clang-3.7 0x00000000014188e3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 803 28 clang-3.7 0x00000000014adb0c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3020 29 clang-3.7 0x000000000070b17f cc1_main(llvm::ArrayRef, char const*, void*) + 719 30 clang-3.7 0x000000000070a6a1 main + 10865 31 libc.so.6 0x00007fe6c8527b95 __libc_start_main + 245 32 clang-3.7 0x0000000000707b0d Stack dump: 0. Program arguments: /usr/local/bin/clang-3.7 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name t.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -resource-dir /usr/local/bin/../lib/clang/3.7.0 -internal-isystem /usr/local/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1 -internal-isystem /usr/local/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/x86_64-unknown-linux-gnu -internal-isystem /usr/local/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/backward -internal-isystem /usr/local/include -internal-isystem /usr/local/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/rnburn/bugs/preprocessor -ferror-limit 19 -fmessage-length 125 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/t-394668.o -x c++ t.cpp 1. t.cpp:97:9 >: unknown current parser token clang-3.7: error: unable to execute command: Segmentation fault clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 234142) Target: x86_64-unknown-linux-gnu Thread model: posix clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.7: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.7: note: diagnostic msg: /tmp/t-48fc05.cpp clang-3.7: note: diagnostic msg: /tmp/t-48fc05.sh clang-3.7: note: diagnostic msg: -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 5 22:32:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 05:32:31 +0000 Subject: [LLVMbugs] [Bug 23133] New: crash in function tryCaptureVariable Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23133 Bug ID: 23133 Summary: crash in function tryCaptureVariable Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: ryan.burn at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified attached script and source. Here is the stack trace: #0 0x12d6b9a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/bin/clang-3.7+0x12d6b9a) #1 0x12d7f5b SignalHandler(int) (/usr/local/bin/clang-3.7+0x12d7f5b) #2 0x7fedf6d59b10 __restore_rt (/lib64/libpthread.so.0+0x10b10) #3 0x1e26360 clang::Sema::tryCaptureVariable(clang::VarDecl*, clang::SourceLocation, clang::Sema::TryCaptureKind, clang::SourceLocation, bool, clang::QualType&, clang::QualType&, unsigned int const*) (/usr/local/bin/clang-3.7+0x1e26360) #4 0x1df5733 clang::Sema::BuildDeclRefExpr(clang::ValueDecl*, clang::QualType, clang::ExprValueKind, clang::DeclarationNameInfo const&, clang::CXXScopeSpec const*, clang::NamedDecl*, clang::TemplateArgumentListInfo const*) (/usr/local/bin/clang-3.7+0x1df5733) #5 0x1df9f99 clang::Sema::BuildDeclarationNameExpr(clang::CXXScopeSpec const&, clang::DeclarationNameInfo const&, clang::NamedDecl*, clang::NamedDecl*, clang::TemplateArgumentListInfo const*, bool) (/usr/local/bin/clang-3.7+0x1df9f99) #6 0x2009334 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDeclRefExpr(clang::DeclRefExpr*) (/usr/local/bin/clang-3.7+0x2009334) #7 0x1ffb4e4 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExprs(clang::Expr**, unsigned int, bool, llvm::SmallVectorImpl&, bool*) (/usr/local/bin/clang-3.7+0x1ffb4e4) #8 0x200883f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) (/usr/local/bin/clang-3.7+0x200883f) #9 0x1ffa3d0 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) (/usr/local/bin/clang-3.7+0x1ffa3d0) #10 0x1ff1dfd clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff1dfd) #11 0x1ff431f clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName, clang::CXXRecordDecl*, unsigned int) (/usr/local/bin/clang-3.7+0x1ff431f) #12 0x201c698 clang::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*, llvm::SmallVectorImpl&) (/usr/local/bin/clang-3.7+0x201c698) #13 0x2019f2d clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*, clang::TemplateParameterList*, bool) (/usr/local/bin/clang-3.7+0x2019f2d) #14 0x201cec8 clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) (/usr/local/bin/clang-3.7+0x201cec8) #15 0x1fcaf4a clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*, bool) (/usr/local/bin/clang-3.7+0x1fcaf4a) #16 0x1fcca3e clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool) (/usr/local/bin/clang-3.7+0x1fcca3e) #17 0x1f2afd4 clang::Sema::AddMethodTemplateCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::CXXRecordDecl*, clang::TemplateArgumentListInfo*, clang::QualType, clang::Expr::Classification, llvm::ArrayRef, clang::OverloadCandidateSet&, bool, bool) (/usr/local/bin/clang-3.7+0x1f2afd4) #18 0x1f40a03 clang::Sema::BuildCallToObjectOfClassType(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation) (/usr/local/bin/clang-3.7+0x1f40a03) #19 0x1df15ee clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) (/usr/local/bin/clang-3.7+0x1df15ee) #20 0x20088b7 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) (/usr/local/bin/clang-3.7+0x20088b7) #21 0x1ffa3d0 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) (/usr/local/bin/clang-3.7+0x1ffa3d0) #22 0x1ff1dfd clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff1dfd) #23 0x1ff089f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) (/usr/local/bin/clang-3.7+0x1ff089f) #24 0x2007b12 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&) (/usr/local/bin/clang-3.7+0x2007b12) #25 0x2006278 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) (/usr/local/bin/clang-3.7+0x2006278) #26 0x1ff242a clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff242a) #27 0x1ff1f2e clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff1f2e) #28 0x1ff431f clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName, clang::CXXRecordDecl*, unsigned int) (/usr/local/bin/clang-3.7+0x1ff431f) #29 0x201c698 clang::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*, llvm::SmallVectorImpl&) (/usr/local/bin/clang-3.7+0x201c698) #30 0x2019f2d clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*, clang::TemplateParameterList*, bool) (/usr/local/bin/clang-3.7+0x2019f2d) #31 0x201cec8 clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) (/usr/local/bin/clang-3.7+0x201cec8) #32 0x1fcaf4a clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*, bool) (/usr/local/bin/clang-3.7+0x1fcaf4a) #33 0x1fcca3e clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool) (/usr/local/bin/clang-3.7+0x1fcca3e) #34 0x1f2afd4 clang::Sema::AddMethodTemplateCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::CXXRecordDecl*, clang::TemplateArgumentListInfo*, clang::QualType, clang::Expr::Classification, llvm::ArrayRef, clang::OverloadCandidateSet&, bool, bool) (/usr/local/bin/clang-3.7+0x1f2afd4) #35 0x1f3f679 clang::Sema::BuildCallToMemberFunction(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation) (/usr/local/bin/clang-3.7+0x1f3f679) #36 0x1df16d6 clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) (/usr/local/bin/clang-3.7+0x1df16d6) #37 0x20088b7 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) (/usr/local/bin/clang-3.7+0x20088b7) #38 0x1ffa3d0 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) (/usr/local/bin/clang-3.7+0x1ffa3d0) #39 0x1ff1dfd clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff1dfd) #40 0x1ff089f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) (/usr/local/bin/clang-3.7+0x1ff089f) #41 0x2007b12 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&) (/usr/local/bin/clang-3.7+0x2007b12) #42 0x2006278 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) (/usr/local/bin/clang-3.7+0x2006278) #43 0x2005caf clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTSIInObjectScope(clang::TypeLoc, clang::QualType, clang::NamedDecl*, clang::CXXScopeSpec&) (/usr/local/bin/clang-3.7+0x2005caf) #44 0x1ffbb6f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformNestedNameSpecifierLoc(clang::NestedNameSpecifierLoc, clang::QualType, clang::NamedDecl*) (/usr/local/bin/clang-3.7+0x1ffbb6f) #45 0x1ff24ec clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff24ec) #46 0x1ff089f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) (/usr/local/bin/clang-3.7+0x1ff089f) #47 0x2007b12 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&) (/usr/local/bin/clang-3.7+0x2007b12) #48 0x20104b3 bool clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArguments(clang::TemplateArgumentLoc const*, clang::TemplateArgumentLoc const*, clang::TemplateArgumentListInfo&) (/usr/local/bin/clang-3.7+0x20104b3) #49 0x1ffc9b7 clang::Sema::Subst(clang::TemplateArgumentLoc const*, unsigned int, clang::TemplateArgumentListInfo&, clang::MultiLevelTemplateArgumentList const&) (/usr/local/bin/clang-3.7+0x1ffc9b7) #50 0x1fc8b52 FinishTemplateArgumentDeduction(clang::Sema&, clang::ClassTemplatePartialSpecializationDecl*, clang::TemplateArgumentList const&, llvm::SmallVectorImpl&, clang::sema::TemplateDeductionInfo&) (/usr/local/bin/clang-3.7+0x1fc8b52) #51 0x1fc8696 clang::Sema::DeduceTemplateArguments(clang::ClassTemplatePartialSpecializationDecl*, clang::TemplateArgumentList const&, clang::sema::TemplateDeductionInfo&) (/usr/local/bin/clang-3.7+0x1fc8696) #52 0x1ff8f1b clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) (/usr/local/bin/clang-3.7+0x1ff8f1b) #53 0x204951e clang::Sema::RequireCompleteTypeImpl(clang::SourceLocation, clang::QualType, clang::Sema::TypeDiagnoser&) (/usr/local/bin/clang-3.7+0x204951e) #54 0x2049210 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::Sema::TypeDiagnoser&) (/usr/local/bin/clang-3.7+0x2049210) #55 0x1d78926 clang::Sema::CheckBaseSpecifier(clang::CXXRecordDecl*, clang::SourceRange, bool, clang::AccessSpecifier, clang::TypeSourceInfo*, clang::SourceLocation) (/usr/local/bin/clang-3.7+0x1d78926) #56 0x1ff70d6 clang::Sema::SubstBaseSpecifiers(clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&) (/usr/local/bin/clang-3.7+0x1ff70d6) #57 0x1ff74a7 clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) (/usr/local/bin/clang-3.7+0x1ff74a7) #58 0x1ff9328 clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) (/usr/local/bin/clang-3.7+0x1ff9328) #59 0x204951e clang::Sema::RequireCompleteTypeImpl(clang::SourceLocation, clang::QualType, clang::Sema::TypeDiagnoser&) (/usr/local/bin/clang-3.7+0x204951e) #60 0x2049210 clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType, clang::Sema::TypeDiagnoser&) (/usr/local/bin/clang-3.7+0x2049210) #61 0x1c92aa0 clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&, clang::DeclContext*) (/usr/local/bin/clang-3.7+0x1c92aa0) #62 0x1df8761 clang::Sema::BuildQualifiedDeclarationNameExpr(clang::CXXScopeSpec&, clang::DeclarationNameInfo const&, bool, clang::TypeSourceInfo**) (/usr/local/bin/clang-3.7+0x1df8761) #63 0x2008ad1 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDependentScopeDeclRefExpr(clang::DependentScopeDeclRefExpr*, bool, clang::TypeSourceInfo**) (/usr/local/bin/clang-3.7+0x2008ad1) #64 0x2007aab clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&) (/usr/local/bin/clang-3.7+0x2007aab) #65 0x200649e clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) (/usr/local/bin/clang-3.7+0x200649e) #66 0x1ff242a clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff242a) #67 0x1ff1f2e clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff1f2e) #68 0x1ff089f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) (/usr/local/bin/clang-3.7+0x1ff089f) #69 0x1fffe7c clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCXXUnresolvedConstructExpr(clang::CXXUnresolvedConstructExpr*) (/usr/local/bin/clang-3.7+0x1fffe7c) #70 0x1ffb4e4 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExprs(clang::Expr**, unsigned int, bool, llvm::SmallVectorImpl&, bool*) (/usr/local/bin/clang-3.7+0x1ffb4e4) #71 0x200883f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) (/usr/local/bin/clang-3.7+0x200883f) #72 0x1ffa3d0 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) (/usr/local/bin/clang-3.7+0x1ffa3d0) #73 0x2007aab clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&) (/usr/local/bin/clang-3.7+0x2007aab) #74 0x2006278 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) (/usr/local/bin/clang-3.7+0x2006278) #75 0x2005caf clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTSIInObjectScope(clang::TypeLoc, clang::QualType, clang::NamedDecl*, clang::CXXScopeSpec&) (/usr/local/bin/clang-3.7+0x2005caf) #76 0x1ffbb6f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformNestedNameSpecifierLoc(clang::NestedNameSpecifierLoc, clang::QualType, clang::NamedDecl*) (/usr/local/bin/clang-3.7+0x1ffbb6f) #77 0x1ff24ec clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff24ec) #78 0x1ff089f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) (/usr/local/bin/clang-3.7+0x1ff089f) #79 0x1ff3fbb clang::Sema::SubstType(clang::QualType, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) (/usr/local/bin/clang-3.7+0x1ff3fbb) #80 0x1f8b1e9 clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation, clang::TemplateArgumentListInfo&) (/usr/local/bin/clang-3.7+0x1f8b1e9) #81 0x2006a68 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) (/usr/local/bin/clang-3.7+0x2006a68) #82 0x1ff242a clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff242a) #83 0x1ff089f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) (/usr/local/bin/clang-3.7+0x1ff089f) #84 0x1ff3fbb clang::Sema::SubstType(clang::QualType, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) (/usr/local/bin/clang-3.7+0x1ff3fbb) #85 0x1f92eb2 clang::Sema::CheckTemplateArgument(clang::NamedDecl*, clang::TemplateArgumentLoc&, clang::NamedDecl*, clang::SourceLocation, clang::SourceLocation, unsigned int, llvm::SmallVectorImpl&, clang::Sema::CheckTemplateArgumentKind) (/usr/local/bin/clang-3.7+0x1f92eb2) #86 0x1fcadcb clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*, bool) (/usr/local/bin/clang-3.7+0x1fcadcb) #87 0x1fcca3e clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool) (/usr/local/bin/clang-3.7+0x1fcca3e) #88 0x1f2b473 clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::OverloadCandidateSet&, bool, bool) (/usr/local/bin/clang-3.7+0x1f2b473) #89 0x1f3a458 clang::Sema::AddOverloadedCallCandidates(clang::UnresolvedLookupExpr*, llvm::ArrayRef, clang::OverloadCandidateSet&, bool) (/usr/local/bin/clang-3.7+0x1f3a458) #90 0x1f3a55c clang::Sema::buildOverloadedCallSet(clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, llvm::MutableArrayRef, clang::SourceLocation, clang::OverloadCandidateSet*, clang::ActionResult*) (/usr/local/bin/clang-3.7+0x1f3a55c) #91 0x1f3a87d clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) (/usr/local/bin/clang-3.7+0x1f3a87d) #92 0x1df123d clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) (/usr/local/bin/clang-3.7+0x1df123d) #93 0x20088b7 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) (/usr/local/bin/clang-3.7+0x20088b7) #94 0x1ffa3d0 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) (/usr/local/bin/clang-3.7+0x1ffa3d0) #95 0x1ff1dfd clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (/usr/local/bin/clang-3.7+0x1ff1dfd) #96 0x1ff089f clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) (/usr/local/bin/clang-3.7+0x1ff089f) #97 0x1ff07bb clang::Sema::SubstType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) (/usr/local/bin/clang-3.7+0x1ff07bb) #98 0x2014095 clang::TemplateDeclInstantiator::InstantiateTypedefNameDecl(clang::TypedefNameDecl*, bool) (/usr/local/bin/clang-3.7+0x2014095) #99 0x2015101 clang::TemplateDeclInstantiator::VisitTypeAliasDecl(clang::TypeAliasDecl*) (/usr/local/bin/clang-3.7+0x2015101) #100 0x201cec8 clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) (/usr/local/bin/clang-3.7+0x201cec8) #101 0x200d066 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDeclStmt(clang::DeclStmt*) (/usr/local/bin/clang-3.7+0x200d066) #102 0x200a6a1 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*, bool) (/usr/local/bin/clang-3.7+0x200a6a1) #103 0x1ff9d31 clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) (/usr/local/bin/clang-3.7+0x1ff9d31) #104 0x2020ee1 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) (/usr/local/bin/clang-3.7+0x2020ee1) #105 0x1e25c89 clang::Sema::MarkFunctionReferenced(clang::SourceLocation, clang::FunctionDecl*, bool) (/usr/local/bin/clang-3.7+0x1e25c89) #106 0x1e293b2 MarkExprReferenced(clang::Sema&, clang::SourceLocation, clang::Decl*, clang::Expr*, bool) (/usr/local/bin/clang-3.7+0x1e293b2) #107 0x1f3a063 clang::Sema::FixOverloadedFunctionReference(clang::Expr*, clang::DeclAccessPair, clang::FunctionDecl*) (/usr/local/bin/clang-3.7+0x1f3a063) #108 0x1f3aa05 FinishOverloadedCallExpr(clang::Sema&, clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, clang::OverloadCandidateSet*, clang::OverloadCandidate**, clang::OverloadingResult, bool) (/usr/local/bin/clang-3.7+0x1f3aa05) #109 0x1f3a904 clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) (/usr/local/bin/clang-3.7+0x1f3a904) #110 0x1df123d clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) (/usr/local/bin/clang-3.7+0x1df123d) #111 0x20088b7 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) (/usr/local/bin/clang-3.7+0x20088b7) #112 0x1ffa3d0 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) (/usr/local/bin/clang-3.7+0x1ffa3d0) #113 0x1ff9fe1 clang::Sema::SubstExpr(clang::Expr*, clang::MultiLevelTemplateArgumentList const&) (/usr/local/bin/clang-3.7+0x1ff9fe1) #114 0x2017040 clang::TemplateDeclInstantiator::VisitStaticAssertDecl(clang::StaticAssertDecl*) (/usr/local/bin/clang-3.7+0x2017040) #115 0x201cec8 clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) (/usr/local/bin/clang-3.7+0x201cec8) #116 0x200d066 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDeclStmt(clang::DeclStmt*) (/usr/local/bin/clang-3.7+0x200d066) #117 0x200a6a1 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*, bool) (/usr/local/bin/clang-3.7+0x200a6a1) #118 0x1ff9d31 clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) (/usr/local/bin/clang-3.7+0x1ff9d31) #119 0x2020ee1 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) (/usr/local/bin/clang-3.7+0x2020ee1) #120 0x1fd1145 clang::Sema::DeduceReturnType(clang::FunctionDecl*, clang::SourceLocation, bool) (/usr/local/bin/clang-3.7+0x1fd1145) #121 0x1deb24b clang::Sema::DiagnoseUseOfDecl(clang::NamedDecl*, clang::SourceLocation, clang::ObjCInterfaceDecl const*, bool) (/usr/local/bin/clang-3.7+0x1deb24b) #122 0x1f3c079 CreateFunctionRefExpr(clang::Sema&, clang::FunctionDecl*, clang::NamedDecl*, bool, clang::SourceLocation, clang::DeclarationNameLoc const&) (/usr/local/bin/clang-3.7+0x1f3c079) #123 0x1f415bc clang::Sema::BuildCallToObjectOfClassType(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation) (/usr/local/bin/clang-3.7+0x1f415bc) #124 0x1df15ee clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool) (/usr/local/bin/clang-3.7+0x1df15ee) #125 0x1b239c8 clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) (/usr/local/bin/clang-3.7+0x1b239c8) #126 0x1b286c7 clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) (/usr/local/bin/clang-3.7+0x1b286c7) #127 0x1b21972 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/usr/local/bin/clang-3.7+0x1b21972) #128 0x1b218d9 clang::Parser::ParseExpression(clang::Parser::TypeCastState) (/usr/local/bin/clang-3.7+0x1b218d9) #129 0x1b57d7c clang::Parser::ParseExprStatement() (/usr/local/bin/clang-3.7+0x1b57d7c) #130 0x1b5797e clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) (/usr/local/bin/clang-3.7+0x1b5797e) #131 0x1b56b9f clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) (/usr/local/bin/clang-3.7+0x1b56b9f) #132 0x1b5cf64 clang::Parser::ParseCompoundStatementBody(bool) (/usr/local/bin/clang-3.7+0x1b5cf64) #133 0x1b5d816 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/usr/local/bin/clang-3.7+0x1b5d816) #134 0x1af08cc clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/usr/local/bin/clang-3.7+0x1af08cc) #135 0x1affb7d clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/usr/local/bin/clang-3.7+0x1affb7d) #136 0x1aefb3d clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/usr/local/bin/clang-3.7+0x1aefb3d) #137 0x1aef640 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (/usr/local/bin/clang-3.7+0x1aef640) #138 0x1aeea54 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/usr/local/bin/clang-3.7+0x1aeea54) #139 0x1aee028 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) (/usr/local/bin/clang-3.7+0x1aee028) #140 0x1aeae36 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/bin/clang-3.7+0x1aeae36) #141 0x1441f39 clang::FrontendAction::Execute() (/usr/local/bin/clang-3.7+0x1441f39) #142 0x14188e3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/bin/clang-3.7+0x14188e3) #143 0x14adb0c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/bin/clang-3.7+0x14adb0c) #144 0x70b17f cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/bin/clang-3.7+0x70b17f) #145 0x70a6a1 main (/usr/local/bin/clang-3.7+0x70a6a1) #146 0x7fedf6297b95 __libc_start_main (/lib64/libc.so.6+0x24b95) #147 0x707b0d _start (/usr/local/bin/clang-3.7+0x707b0d) Stack dump: 0. Program arguments: /usr/local/bin/clang-3.7 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name matrix_test.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu haswell -target-feature -sse4a -target-feature -avx512bw -target-feature +cx16 -target-feature -tbm -target-feature -adx -target-feature -fma4 -target-feature -avx512vl -target-feature -prfchw -target-feature +bmi2 -target-feature -avx512pf -target-feature +fsgsbase -target-feature +avx -target-feature -avx512cd -target-feature +rtm -target-feature +popcnt -target-feature +fma -target-feature +bmi -target-feature +aes -target-feature +rdrnd -target-feature +sse4.1 -target-feature +sse4.2 -target-feature +avx2 -target-feature -avx512er -target-feature +sse -target-feature +lzcnt -target-feature +pclmul -target-feature -avx512f -target-feature +f16c -target-feature +ssse3 -target-feature +mmx -target-feature +cmov -target-feature -xop -target-feature -rdseed -target-feature +movbe -target-feature +hle -target-feature -sha -target-feature +sse2 -target-feature +sse3 -target-feature -avx512dq -dwarf-column-info -coverage-file /home/rnburn/work/echo/matrix/CMakeFiles/matrix-test.dir/unittest/matrix_test.cpp.o -resource-dir /usr/local/bin/../lib/clang/3.7.0 -D MKL_ILP64 -I /home/rnburn/proj/echo/matrix/include -I /opt/intel/mkl/include -internal-isystem /usr/local/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /usr/local/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++14 -fdeprecated-macro -fdebug-compilation-dir /home/rnburn/work/echo/matrix -ferror-limit 19 -fmessage-length 125 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o CMakeFiles/matrix-test.dir/unittest/matrix_test.cpp.o -x c++ /home/rnburn/proj/echo/matrix/unittest/matrix_test.cpp 1. /home/rnburn/proj/echo/matrix/unittest/matrix_test.cpp:132:3: current parser token ')' 2. /home/rnburn/proj/echo/matrix/unittest/matrix_test.cpp:122:31: parsing function body '____C_A_T_C_H____T_E_S_T____122' 3. /home/rnburn/proj/echo/matrix/unittest/matrix_test.cpp:122:31: in compound statement ('{}') clang-3.7: error: unable to execute command: Segmentation fault clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 234142) Target: x86_64-unknown-linux-gnu Thread model: posix clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.7: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 05:19:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 12:19:06 +0000 Subject: [LLVMbugs] [Bug 23134] New: Use of uninitialized Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23134 Bug ID: 23134 Summary: Use of uninitialized Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, ruiu at google.com Classification: Unclassified From http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/6819/steps/annotate/logs/stdio FAIL: lld :: Driver/undef-basic.objtxt (26 of 756) ******************** TEST 'lld :: Driver/undef-basic.objtxt' FAILED ******************** Script: -- lld -flavor gnu -u undefinedsymbol -e entrysymbol /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/test/Driver/undef-basic.objtxt --output-filetype=yaml --noinhibit-exec | FileCheck /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/test/Driver/undef-basic.objtxt -- Exit Code: 2 Command Output (stderr): -- ==27811==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7f3d5a4610a3 in allowLinkWithDynamicLibraries /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/include/lld/ReaderWriter/ELFLinkingContext.h:139:45 #1 0x7f3d5a4610a3 in lld::GnuLdDriver::parse(int, char const**, std::__1::unique_ptr >&, llvm::raw_ostream&) /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/lib/Driver/GnuLdDriver.cpp:632 #2 0x7f3d5a455e04 in lld::GnuLdDriver::linkELF(int, char const**, llvm::raw_ostream&) /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/lib/Driver/GnuLdDriver.cpp:170:8 #3 0x7f3d5a3fea61 in lld::UniversalDriver::link(int, char const**, llvm::raw_ostream&) /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/lib/Driver/UniversalDriver.cpp:203:12 #4 0x7f3d5a3fd9ca in main /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/tools/lld/lld.cpp:35:10 #5 0x7f3d58c35eac in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x1eeac) #6 0x7f3d5a398b40 in _start (/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build_msan/bin/lld+0x9fb40) SUMMARY: MemorySanitizer: use-of-uninitialized-value /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/include/lld/ReaderWriter/ELFLinkingContext.h:139:45 in allowLinkWithDynamicLibraries Exiting -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 08:28:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 15:28:21 +0000 Subject: [LLVMbugs] [Bug 22815] Inconsistent logic for deciding if a relocation is necessary In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22815 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Fixed in r234165. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 09:04:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 16:04:18 +0000 Subject: [LLVMbugs] [Bug 23131] std::function constructor unable to take std::allocator In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23131 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Marshall Clow (home) --- This is not a libc++ bug. The allocator argument for the constructor to std::function must satisfy the allocator requirements (see func.wrap.func.con/1). std::allocator, despite its name, does not satisfy those requirements. [ Aside: It cannot satisfy those requirements; because it would have to be able to construct and destroy objects of type `void` ] -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 09:42:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 16:42:31 +0000 Subject: [LLVMbugs] [Bug 22717] Decouple memory management and external symbol resolution. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22717 Lang Hames changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Lang Hames --- This was fixed by r233509. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 10:33:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 17:33:57 +0000 Subject: [LLVMbugs] [Bug 23135] New: [C++11/14] Body of constexpr function templates instantiated too eagerly in unevaluated operands Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23135 Bug ID: 23135 Summary: [C++11/14] Body of constexpr function templates instantiated too eagerly in unevaluated operands Product: clang Version: trunk Hardware: All OS: All Status: NEW Keywords: compile-fail Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: gonzalobg88 at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu, richard-llvm at metafoo.co.uk Classification: Unclassified GCC has the same bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52269 ~Quoting that bug report: Ai Azuma wrote: The following well-formed code cannot be compiled with clang-trunk and the -std=c++11 (and -std=c++14) flags. template int f(T x) { return x.get(); } template constexpr int g(T x) { return x.get(); } int main() { // O.K. The body of `f' is not required. decltype(f(0)) a; // Seems to instantiate the body of `g' // and results in an error. decltype(g(0)) b; return 0; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 11:19:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 18:19:18 +0000 Subject: [LLVMbugs] [Bug 23136] New: clang seems to silently ignore the weak attribute (mingw) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23136 Bug ID: 23136 Summary: clang seems to silently ignore the weak attribute (mingw) Product: clang Version: trunk Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: t.poechtrager at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat test.cpp #include #include #include #ifdef WEAK #undef WEAK #define WEAK __attribute__((weak)) #else #define WEAK #endif WEAK void *operator new(size_t size) throw() { void *p = malloc(size); if(!p) abort(); return p; } WEAK void *operator new[](size_t size) throw() { void *p = malloc(size); if(!p) abort(); return p; } WEAK void operator delete(void *p) throw() { if(p) free(p); } WEAK void operator delete(void *p, size_t) throw() { if(p) free(p); } WEAK void operator delete[](void *p) throw() { if(p) free(p); } WEAK void operator delete[](void *p, size_t) throw() { if(p) free(p); } WEAK int main() { new char[100]; } $ i686-w64-mingw32-clang++ test.cpp -Weverything -Wno-missing-prototypes -c -o 1.o $ i686-w64-mingw32-clang++ test.cpp -Weverything -Wno-missing-prototypes -c -o 2.o -DWEAK $ LC_ALL=C i686-w64-mingw32-clang++ 1.o 2.o 2.o:(.text+0x0): multiple definition of `operator new(unsigned int)' 1.o:(.text+0x0): first defined here 2.o:(.text+0x40): multiple definition of `operator new[](unsigned int)' 1.o:(.text+0x40): first defined here 2.o:(.text+0x80): multiple definition of `operator delete(void*)' 1.o:(.text+0x80): first defined here 2.o:(.text+0xb0): multiple definition of `operator delete(void*, unsigned int)' 1.o:(.text+0xb0): first defined here 2.o:(.text+0xe0): multiple definition of `operator delete[](void*)' 1.o:(.text+0xe0): first defined here 2.o:(.text+0x110): multiple definition of `operator delete[](void*, unsigned int)' 1.o:(.text+0x110): first defined here 2.o:(.text+0x140): multiple definition of `main' 1.o:(.text+0x140): first defined here collect2: error: ld returned 1 exit status clang-3.7: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation) mingw-g++ handles this correctly: $ i686-w64-mingw32-g++ test.cpp -c -o 1.o $ i686-w64-mingw32-g++ test.cpp -c -o 2.o -DWEAK $ LC_ALL=C i686-w64-mingw32-g++ 1.o 2.o && echo $? 0 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 14:07:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 21:07:22 +0000 Subject: [LLVMbugs] [Bug 23122] frameescape intrinsic leads to the backend crashing In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23122 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- Really closing... -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 15:36:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 22:36:03 +0000 Subject: [LLVMbugs] [Bug 23137] New: Assertion: SymbolMap.find(&A_SD.getSymbol()) != SymbolMap.end() && "Symbol must already have been defined in ExecutePostLayoutBinding!", file lib\MC\WinCOFFObjectWriter.cpp, line 690 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23137 Bug ID: 23137 Summary: Assertion: SymbolMap.find(&A_SD.getSymbol()) != SymbolMap.end() && "Symbol must already have been defined in ExecutePostLayoutBinding!", file lib\MC\WinCOFFObjectWriter.cpp, line 690 Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: douglas_yung at playstation.sony.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code when compiled targeting Windows causes an assertion failure in the compiler: //================= // // Compile command: clang -cc1 -triple x86_64-pc-windows-msvc -emit-obj -fcxx-exceptions -fexceptions // namespace std { inline void A( int* C) {} inline void B(int* C ) { A( C); } class D { public: int *E; void F(int G) { try { B(this->E ); } catch (...) {} } }; } void foo() { std::D v01; v01.F(1024); } //================= When using clang (r234143) built using Visual Studio 2013 Update 4 on my Windows 7 x64 machine, it produces the following assertion failure: Assertion failed: SymbolMap.find(&A_SD.getSymbol()) != SymbolMap.end() && "Symbol must already have been defined in ExecutePostLayoutBinding!", file C:\src\llvm\llvm\lib\MC\WinCOFFObjectWriter.cpp, line 690 0x000000013FC8FF55 (0x0000000000000016 0x000007FE23B46E8B 0x0000000000000000 0x0000000077929CAA) 0x000007FEE5A3EE1D (0x000007FE00000001 0x0000000000000000 0x0000000142529C30 0x0000000000000194), raise() + 0x1E9 bytes(s) 0x000007FEE5A44A14 (0x000007FEE5AAC4D0 0x0000000142529C30 0x000000014252A1D0 0x0000000142529C30), abort() + 0x18 bytes(s) 0x000007FEE5A45D5F (0x0000000000E96808 0x0000000000A7D0D0 0x0000000000ED3C10 0x0000000000E96808), _wassert() + 0x94F bytes(s) 0x000000013FAE249A (0x0000000000CC3250 0x0000000000E95C00 0x0000000000EFBE00 0x0000000000EAF9F0) 0x000000013FAC19D3 (0x0000000000000000 0x0000000000CC3250 0x0000000000E95C00 0x0000000000EAFA50) 0x000000013FABC1ED (0x0000000000CC24C0 0x0000000000E94960 0x0000000000A7D450 0x0000000000000016) 0x000000013FFC0D20 (0x0000000000000000 0x0000000000CC24B0 0x0000000000E68AA0 0x0000000000CC2588) 0x000000013F7DB91A (0x0000000000E68AA0 0x0000000000000002 0x0000000000A7D679 0x0000000000000002) 0x000000013F7E4079 (0x0000000000E51D60 0x0000000000E9B6A0 0x0000000000000000 0x0000000000000000) 0x000000013F7E29B9 (0x0000000000CC2478 0x0000000000A7D7B9 0x0000000000A7D880 0x00000001425C91B8) 0x0000000140218AE6 (0x0000000000C890B0 0x0000000000C890B0 0x0000000000A7D910 0x0000000077801A4A) 0x0000000140218CB2 (0x0000000000CC5E40 0x0000000000CC5E40 0x0000000000C8DFD0 0x0000000000CEB300) 0x0000000140200503 (0x0000000000CEB300 0x0000000000E294B0 0x0000000000000000 0x0000000000000000) 0x0000000140A227D5 (0x0000000000000000 0x0000000000A7DB00 0x0000000000C84670 0xFFFFFFFF00000002) 0x000000013FEF152D (0x0000000000C84670 0x0000000000000000 0x000000000000006A 0x0000000000000005) 0x00000001401FFE93 (0x0000000142BDF568 0x0000000000000000 0x0000000000000001 0x0000000000000000) 0x000000013FEF13D9 (0x0000000000000000 0x0000000000C82300 0x0000000000C85A90 0x0000000000000000) 0x000000013FEBA19D (0x000000013FC98B60 0x0000000000C84670 0x0000000000A7DE69 0x000000013FC98C50) 0x000000013FFB832D (0x0000000000A7DF18 0x0000000000C82180 0x0000000000C82220 0x0000000000C8DB48) 0x000000013F22337E (0x0000000000000040 0x0000000000000000 0x0000000142BC5020 0x0000000000A7E5E0) 0x000000013F2197FA (0x0000000000000008 0x0000000000C8CB22 0x0000000000A7E640 0x0000000000000000) 0x000000013F21F9DE (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x000000014174A927 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x00000000777F59ED (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0xD bytes(s) 0x000000007792C541 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 16:07:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 06 Apr 2015 23:07:24 +0000 Subject: [LLVMbugs] [Bug 23138] New: Assertion: isa(OutlinedBB->getTerminator()), file WinEHPrepare.cpp, line 659 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23138 Bug ID: 23138 Summary: Assertion: isa(OutlinedBB->getTerminator()), file WinEHPrepare.cpp, line 659 Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: douglas_yung at playstation.sony.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code when compiled targeting Windows causes an assertion failure in the compiler: //=========== // // Compile command: clang -cc1 -triple x86_64-pc-windows-msvc -emit-obj -fcxx-exceptions -fexceptions // namespace std { inline void alpha( ) {} class bravo { public: void charlie(int delta) { echo(delta); try { alpha( ); } catch (...) { foxtrot(); } } void gulf() { try { hotel(); } catch (...) {} } void echo(int india) { gulf( ); } void foxtrot() {} void hotel() {} }; } void foo() { std::bravo v01; v01.charlie(1024); } //=========== When using a clang (r234143) built on Windows targeting Windows, compiling the above code produces the following assertion failure: Assertion failed: isa(OutlinedBB->getTerminator()), file C:\src\llvm\llvm\lib\CodeGen\WinEHPrepare.cpp, line 659 0x000000014091FF55 (0x0000000000000016 0x000007FEDEA7A68F 0x0000000000000000 0x0000000077929CAA) 0x000007FEE430EE1D (0x000007FE00000001 0x0000000100000000 0x000000014312FD80 0x0000000000000190), raise() + 0x1E9 bytes(s) 0x000007FEE4314A14 (0x000007FEE437C4D0 0x000000014312FD80 0x000000014312FED0 0x000000014312FD80), abort() + 0x18 bytes(s) 0x000007FEE4315D5F (0x0000000002AAA640 0x0000000000CAD550 0x0000000000000002 0x0000000002A3CFD0), _wassert() + 0x94F bytes(s) 0x00000001402E1450 (0x0000000000000000 0x0000000000ACD510 0x0000000000000000 0x0000000002AAA640) 0x00000001402EB014 (0x0000000000CAD550 0x0000000100000001 0x0000000000000004 0x0000000000CAD550) 0x00000001402ECCB4 (0x0000000000000001 0x0000000002A3E6F0 0x0000000002A3E6F0 0x0000000000000000) 0x000000014047346C (0x0000000000000000 0x000000000000000A 0x0000000002A27390 0x0000000000C72548) 0x000000014047370F (0x0000000000000000 0x0000000000ACDA79 0x0000000002A481C0 0x0000000000C72548) 0x0000000140473C60 (0x0000000002A22740 0x0000000002A72E78 0x0000000000000000 0x0000000000000000) 0x00000001404729B9 (0x0000000000C72438 0x0000000000ACDBB9 0x0000000000ACDC80 0x00000001432591B8) 0x0000000140EA8AE6 (0x0000000000C391B0 0x0000000000C391B0 0x0000000000ACDD10 0x0000000077801A4A) 0x0000000140EA8CB2 (0x0000000000C75E00 0x0000000000C75E00 0x0000000000C3DF90 0x0000000000C9B2C0) 0x0000000140E90503 (0x0000000000C9B2C0 0x00000000029F94B0 0x0000000000000000 0x0000000000000000) 0x00000001416B27D5 (0x0000000000000000 0x0000000000ACDF00 0x0000000000C3DBF0 0xFFFFFFFF00000002) 0x0000000140B8152D (0x0000000000C3DBF0 0x0000000000000000 0x000000000000006E 0x0000000000000005) 0x0000000140E8FE93 (0x000000014386F568 0x0000000000000000 0x0000000000000001 0x0000000000000000) 0x0000000140B813D9 (0x0000000000000000 0x0000000000C32400 0x0000000000C35B90 0x0000000000000000) 0x0000000140B4A19D (0x0000000140928B60 0x0000000000C3DBF0 0x0000000000ACE269 0x0000000140928C50) 0x0000000140C4832D (0x0000000000ACE318 0x0000000000C32280 0x0000000000C32320 0x0000000000C347C8) 0x000000013FEB337E (0x0000000000000040 0x0000000000000000 0x0000000143855020 0x0000000000ACE9E0) 0x000000013FEA97FA (0x0000000000000008 0x0000000000C3CC22 0x0000000000ACEA40 0x0000000000000000) 0x000000013FEAF9DE (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x00000001423DA927 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x00000000777F59ED (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0xD bytes(s) 0x000000007792C541 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s) This bug was found at the same time as bug 23137 and may be related. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 18:30:29 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 01:30:29 +0000 Subject: [LLVMbugs] [Bug 23036] ignoring unknown argument: --enable-new-dtags / RUNPATH support needed In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23036 emaste at freebsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from emaste at freebsd.org --- http://reviews.llvm.org/D8836 Support added in r234240 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 19:40:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 02:40:47 +0000 Subject: [LLVMbugs] [Bug 22042] Dependent alignof crashes In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22042 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com |org | --- Comment #1 from David Majnemer --- Fixed in r234280. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 20:48:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 03:48:20 +0000 Subject: [LLVMbugs] [Bug 23140] New: Typo correction of pointer-to-member operand raises "placeholders should have been weeded out by now" assertion Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23140 Bug ID: 23140 Summary: Typo correction of pointer-to-member operand raises "placeholders should have been weeded out by now" assertion Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: david.majnemer at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified consider: auto lneed = gned.*[] {}; compile with: ~/llvm/Debug+Asserts/bin/clang -cc1 t.cpp -std=c++11 'gned' has been typo corrected to 'lneed': UnresolvedLookupExpr 0x7483c00 '' lvalue (no ADL) = 'lneed' empty however, semantic analysis continues resulting in this assertion. instead, I would expect the source to be treated like: auto lneed = lneed.*[] {}; and raise a diagnostic like: variable 'lneed' declared with 'auto' type cannot appear in its own initializer -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 22:07:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 05:07:11 +0000 Subject: [LLVMbugs] [Bug 23141] New: std::bind const-qualifying bound arguments captured by value when compiled as C++14 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23141 Bug ID: 23141 Summary: std::bind const-qualifying bound arguments captured by value when compiled as C++14 Product: libc++ Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: eniebler at boost.org CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified The following code fails to compile when compiled as C++14: #include #include struct Fun { template void operator()(T && t, U && u) const { static_assert(std::is_same::value, ""); } }; int main() { std::bind(Fun{}, std::placeholders::_1, 42)("hello"); } The error is: static_assert(std::is_same::value, ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/local/clang-trunk/bin/../include/c++/v1/__functional_base:415:12: note: in instantiation of function template specialization 'Fun::operator()' requested here return _VSTD::forward<_Fp>(__f)(_VSTD::forward<_Args>(__args)...); ^ /usr/local/clang-trunk/bin/../include/c++/v1/__config:381:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ 1 error generated. When compiled as C++11, the code compiles successfully. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 6 23:02:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 06:02:11 +0000 Subject: [LLVMbugs] [Bug 23117] Assertion failure parsing block expressions with nonnull attributes In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23117 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Majnemer --- Fixed in r234297. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 01:37:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 08:37:18 +0000 Subject: [LLVMbugs] [Bug 23135] [C++11/14] Body of constexpr function templates instantiated too eagerly in unevaluated operands In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23135 Gonzalo BG changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Gonzalo BG --- Thanks Richard, that settles it. I'm closing this as invalid. Today I learned that constexpr functions are (potentially) instantiated in unevaluated contexts. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 03:51:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 10:51:25 +0000 Subject: [LLVMbugs] [Bug 23143] New: MachineLICM register pressure calculation incorrect Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23143 Bug ID: 23143 Summary: MachineLICM register pressure calculation incorrect Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: djasper at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The new test test/CodeGen/X86/licm-regpressure.ll shows this behavior (currently marked as XFAIL). MachineLICM assumes that it is hoisting all of the GEPs out of the loop under in a low pressure situation, when indeed there is register pressure. The cause here is that the RegLimit (for the RegClass GR64) is 12, but each instruction is assumed to have a cost of only 1. The problem seems to be that MachineLICM isn't considering the regmasks, i.e. the registers clobbered by the call. IR leading to the bad behavior: %struct.A = type { i32, i32, i32, i32, i32, i32, i32 } define void @test(i1 %b, %struct.A* %a) nounwind { entry: br label %loop-header loop-header: br label %loop-body loop-body: %0 = getelementptr inbounds %struct.A, %struct.A* %a, i64 0, i32 0 %1 = getelementptr inbounds %struct.A, %struct.A* %a, i64 0, i32 1 %2 = getelementptr inbounds %struct.A, %struct.A* %a, i64 0, i32 2 %3 = getelementptr inbounds %struct.A, %struct.A* %a, i64 0, i32 3 %4 = getelementptr inbounds %struct.A, %struct.A* %a, i64 0, i32 4 %5 = getelementptr inbounds %struct.A, %struct.A* %a, i64 0, i32 5 %6 = getelementptr inbounds %struct.A, %struct.A* %a, i64 0, i32 6 call void @assign(i32* %0) call void @assign(i32* %1) call void @assign(i32* %2) call void @assign(i32* %3) call void @assign(i32* %4) call void @assign(i32* %5) call void @assign(i32* %6) br i1 %b, label %loop-body, label %loop-exit loop-exit: ret void } declare void @assign(i32*) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 06:39:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 13:39:20 +0000 Subject: [LLVMbugs] [Bug 23144] New: Problem during "llvm-c-test" build Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23144 Bug ID: 23144 Summary: Problem during "llvm-c-test" build Product: Build scripts Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: petr_aleksandrov at mail.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14163 --> https://llvm.org/bugs/attachment.cgi?id=14163&action=edit CMake cache used during build During build the following errors occurs: [5/785] Linking C executable bin/llvm-c-test FAILED: : && /opt/develop/bin/cc -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-comment -ffunction-sections -fdata-sections -std=gnu99 -Wstrict-prototypes -O3 -DNDEBUG -Wl,-allow-shlib-undefined -Wl,-O3 -Wl,--gc-sections tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/disassemble.c.o tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/helpers.c.o tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/include-all.c.o tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/main.c.o tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/module.c.o tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/metadata.c.o tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/object.c.o tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/targets.c.o -o bin/llvm-c-test -rdynamic lib/libLLVM.so -Wl,-rpath,"\$ORIGIN/../lib" && : tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o:calc.c:function build_from_tokens: error: undefined reference to 'LLVMInt64Type' tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o:calc.c:function build_from_tokens: error: undefined reference to 'LLVMConstInt' tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o:calc.c:function build_from_tokens: error: undefined reference to 'LLVMBuildGEP' tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o:calc.c:function build_from_tokens: error: undefined reference to 'LLVMBuildLoad' tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o:calc.c:function build_from_tokens: error: undefined reference to 'LLVMBuildRet' tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o:calc.c:function build_from_tokens: error: undefined reference to 'LLVMBuildBinOp' tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o:calc.c:function handle_line: error: undefined reference to 'LLVMModuleCreateWithName' tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o:calc.c:function handle_line: error: undefined reference to 'LLVMInt64Type' tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/calc.c.o:calc.c:function handle_line: error: undefined reference to 'LLVMPointerType' ... I have switched "BUILD_SHARED_LIBS" on. Ubuntu 14.10. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 06:40:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 13:40:40 +0000 Subject: [LLVMbugs] [Bug 23145] New: llvm-symbolizer doesn't work on Windows Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23145 Bug ID: 23145 Summary: llvm-symbolizer doesn't work on Windows Product: compiler-rt Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: timurrrr at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Example: ------------ $ cat test.c void foo() { } int main() { foo(); } ------------ $ cl -nologo -Zi test.c -Fetest.exe [or clang-cl -Zi test.c -Fetest.exe] $ dumpbin /HEADERS test.exe | grep "image base" 400000 image base (00400000 to 0042DFFF) $ dumpbin /DISASM test.exe | grep "_foo:\|_main:" --after-context=1 _foo: 00401020: 55 push ebp -- _main: 00401030: 55 push ebp Now, ------------- $ cat symbols 0x1020 0x1030 ------------- And finally: ---------------------------------------------- $ cat symbols | llvm-symbolizer --obj test.exe ?? ??:0:0 ?? ??:0:0 ---------------------------------------------- The final command should instead tell me these are functions 'foo' and 'main' in file test.cpp on lines 1 and 4 respectively. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 07:01:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 14:01:36 +0000 Subject: [LLVMbugs] [Bug 23146] New: Missing 'null passed to a callee that requires a non-null argument' warning for block expression invocations Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23146 Bug ID: 23146 Summary: Missing 'null passed to a callee that requires a non-null argument' warning for block expression invocations Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: thonermann at coverity.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Bug 23117 fixed (in r234297) an assertion failure that occurred when nonnull attributes appertain to block declarations. Warnings are issued when invoking a block with a null argument for a block with a corresponding nonnull parameter when the attribute is explicitly specified for a block pointer type, but not for block invocations on block expressions that specify the attribute. In the following example, a warning is emitted for the invocation of bp(0), but not for the block expression invocation. $ cat t.c void(^bp)(int *) __attribute__((nonnull(1))); void f() { bp(0); // expected-warning{{null passed to a callee that requires a non-null argument}} ^(int *p1) __attribute__((nonnull(1))) {}(0); // expected-warning{{null passed to a callee that requires a non-null argument}} } $ clang -fblocks -c t.c t.c:3:9: warning: null passed to a callee that requires a non-null argument [-Wnonnull] bp(0); ~^ 1 warning generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 07:53:23 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 14:53:23 +0000 Subject: [LLVMbugs] [Bug 23147] New: #include_netxt is not included in VS? Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23147 Bug ID: 23147 Summary: #include_netxt is not included in VS? Product: clang Version: 3.5 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Headers Assignee: unassignedclangbugs at nondot.org Reporter: fatwreck at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hello, I was trying to compile a simple program which called __rdtsc() on MacOs, and was failing with the following error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include/intrin.h:26:15: fatal error: 'Intrin.h' file not found #include_next ^ 1 error generated. I checked the header file and noticed that comment above #include_next does not match the code: https://github.com/llvm-mirror/clang/blob/3e1cca7ad0cc730b54c1a2057f9ce36a85eab75a/lib/Headers/Intrin.h#L24-L27 I think it should be #ifdef _MSC_VER, or I am missing something? Thank you! Best, Alex -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 09:10:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 16:10:02 +0000 Subject: [LLVMbugs] [Bug 23149] New: VLA extension - explicit typing fails. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23149 Bug ID: 23149 Summary: VLA extension - explicit typing fails. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: sasho648 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The problem is that I can't assign VLA pointer or reference to a variable with explicit type. Examples: void func(std::size_t sz) { int arr[sz]; int (*pArr)[sz] = &arr; int (&refArr)[sz] = arr; } It fails to compile with those strange error message: error: cannot initialize a variable of type 'int (*)[sz]' with an rvalue of type 'int (*)[sz]' int (*pArr)[sz] = &arr; error: non-const lvalue reference to type 'int [sz]' cannot bind to a value of unrelated type 'int [sz]' int (&refArr)[sz] = arr; On the other hand this works fine: void func(std::size_t sz) { int arr[sz]; auto *pArr = &arr; auto &refArr = arr; } While reference to VLA arrays are not part of C99, pointers to them are well-defined and should be supported if compatibility with this standard is supported. However I hope reference will be kept too (as they are a cool add-on). Those constructs are well supported by GCC compiler too. Life examples on online-compiler with Clang(3.7.0): Non-working example: http://melpon.org/wandbox/permlink/ZIUJrZqmvBmDzfkC Working example, second one: http://melpon.org/wandbox/permlink/gSXxvRXQRaCBzdwN -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 09:11:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 16:11:19 +0000 Subject: [LLVMbugs] [Bug 23150] New: error in backend: Cannot select: intrinsic %llvm.eh.actions Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23150 Bug ID: 23150 Summary: error in backend: Cannot select: intrinsic %llvm.eh.actions Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dwendt at knights.ucf.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Compiling a large project(CryptoPP) with trunk clang in an MSVS2013 produced this: ...warnings above... 1>CL : fatal error : error in backend: Cannot select: intrinsic %llvm.eh.actions 1>clang-cl.exe : error : clang frontend command failed with exit code 70 (use -v to see invocation) 1> clang version 3.7.0 (trunk) 1> Target: x86_64-pc-windows-msvc 1> Thread model: posix The same project compiles fine under visual c++. The run script is below as there is only one attachment. The attachment is the preprocessed source. # Crash reproducer for clang version 3.7.0 (trunk) # Original command: "C:\\Program Files (x86)\\LLVM\\msbuild-bin\\CL.exe" "-cc1" "-triple" "x86_64-pc-windows-msvc" "-emit-obj" "-disable-free" "-main-file-name" "pch.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-relaxed-aliasing" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-D_MT" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-fcxx-exceptions" "-fexceptions" "-fms-volatile" "-fdiagnostics-format" "msvc" "-momit-leaf-frame-pointer" "-dwarf-column-info" "-ffunction-sections" "-coverage-file" "D:\\code\\hdistrib\\libs\\pch.cpp" "-resource-dir" "C:\\Program Files (x86)\\LLVM\\msbuild-bin\\..\\lib\\clang\\3.7.0" "-D" "NDEBUG" "-D" "WIN32" "-D" "_WINDOWS" "-D" "_MBCS" "-D" "_USRDLL" "-D" "CRYPTOPP_EXPORTS" "-D" "CRYPTOPP_ENABLE_COMPLIANCE_WITH_FIPS_140_2=1" "-D" "USE_PRECOMPILED_HEADERS" "-internal-isystem" "C:\\Program Files (x86)\\LLVM\\msbuild-bin\\..\\lib\\clang\\3.7.0\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\atlmfc\\include" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\um" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\shared" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\winrt" "-Os" "-Wall" "-Wno-error" "-std=c++11" "-fdeprecated-macro" "-fdebug-compilation-dir" "D:\\code\\hdistrib\\libs" "-ferror-limit" "19" "-fmessage-length" "0" "-mstackrealign" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=18.0" "-fno-threadsafe-statics" "-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-vectorize-loops" "-vectorize-slp" "-o" "x64\\cryptopp\\Release\\pch.obj" "-x" "c++" "pch.cpp" "C:\\Program Files (x86)\\LLVM\\msbuild-bin\\CL.exe" "-cc1" "-triple" "x86_64-pc-windows-msvc" "-emit-obj" "-disable-free" "-main-file-name" "pch.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-relaxed-aliasing" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-D_MT" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-fcxx-exceptions" "-fexceptions" "-fms-volatile" "-fdiagnostics-format" "msvc" "-momit-leaf-frame-pointer" "-dwarf-column-info" "-ffunction-sections" "-D" "NDEBUG" "-D" "WIN32" "-D" "_WINDOWS" "-D" "_MBCS" "-D" "_USRDLL" "-D" "CRYPTOPP_EXPORTS" "-D" "CRYPTOPP_ENABLE_COMPLIANCE_WITH_FIPS_140_2=1" "-D" "USE_PRECOMPILED_HEADERS" "-Os" "-Wall" "-Wno-error" "-std=c++11" "-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length" "0" "-mstackrealign" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=18.0" "-fno-threadsafe-statics" "-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-vectorize-loops" "-vectorize-slp" "-x" "c++" "pch-cd5962.cpp" -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 09:22:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 16:22:20 +0000 Subject: [LLVMbugs] [Bug 23150] error in backend: Cannot select: intrinsic %llvm.eh.actions In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23150 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |LATER --- Comment #2 from Reid Kleckner --- C++ exceptions are currently under development and not yet supported. You can disable them in the VS project properties panel. Also consider adding -D_HAS_EXCEPTIONS=0 so that the STL doesn't use them. If your project doesn't use exceptions and you can't get things to work, feel free to open more bugs for those issues. I ran your test case and I get a different crash here: While deleting: i8* %call.i62 Use still stuck around after Def is destroyed: %.in = phi i8* [ %call.i62, %invoke.cont26 ], [ %call.i63, %if.end18 ] Assertion failed: use_empty() && "Uses remain when a value is destroyed!", file ..\lib\IR\Value.cpp, line 82 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 10:02:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 17:02:48 +0000 Subject: [LLVMbugs] [Bug 23151] New: Clang VLA internal failure. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23151 Bug ID: 23151 Summary: Clang VLA internal failure. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: sasho648 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This code gives internal failure error no both C & C++ Clang compiler: #include #include void func(size_t sz, int (*arr)[*]) { printf("%lu", sizeof(*arr) / sizeof(int)); } int main() { size_t sz = 3; int arr[sz]; func(sz, &arr); } Life example: http://melpon.org/wandbox/permlink/ygeV7ELkk49jRZFS -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 10:32:29 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 17:32:29 +0000 Subject: [LLVMbugs] [Bug 23152] New: Many TsanRtlTest failures Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23152 Bug ID: 23152 Summary: Many TsanRtlTest failures Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: hjl.tools at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified On Linux/x86-64, llvm r234316 + clang r234320 + compiler-rt r234187 gave me: Unresolved Tests (17): ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.FuncCall ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop1 ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop1Read ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop1Write ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop2 ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop2Read ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop2Write ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop4 ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop4Read ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop4Write ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop8 ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop8Read ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.Mop8Write ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH.MutexLocal ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH_ThreadSanitizer.Singleton ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_BENCH_ThreadSanitizer.StopFlag ThreadSanitizer-Unit :: rtl/TsanRtlTest/DISABLED_SLOW_ThreadSanitizer.ThreadALot Expected Passes : 23270 Expected Failures : 151 Unsupported Tests : 444 Unresolved Tests : 17 Unexpected Failures: 2 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 11:15:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 18:15:10 +0000 Subject: [LLVMbugs] [Bug 23152] Many TsanRtlTest failures In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23152 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |FIXED --- Comment #1 from Reid Kleckner --- Should be fixed in r234336. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 12:25:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 19:25:51 +0000 Subject: [LLVMbugs] [Bug 23153] New: clang-check warn on suspect strncpy (etc.) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23153 Bug ID: 23153 Summary: clang-check warn on suspect strncpy (etc.) Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: bill.torpey at ullink.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I haven't been able to find an answer to this question, so thought I would ask it here. Can clang's static analysis find bugs of this sort: void func(char* arg) { char buf1[10]; char buf2[20]; strncpy(buf1, arg, sizeof(buf2)); } It doesn't appear to, but I want to make sure I'm not missing something. TIA! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 12:47:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 19:47:51 +0000 Subject: [LLVMbugs] [Bug 23137] Assertion: SymbolMap.find(&A_SD.getSymbol()) != SymbolMap.end() && "Symbol must already have been defined in ExecutePostLayoutBinding!", file lib\MC\WinCOFFObjectWriter.cpp, line 690 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23137 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- Fixed in r234346. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 15:01:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 22:01:50 +0000 Subject: [LLVMbugs] [Bug 23154] New: pthread with ucontext on mac Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23154 Bug ID: 23154 Summary: pthread with ucontext on mac Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: albertnetymk at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I am using ucontext along with pthread. The below program works OK on Linux, but has failed assertion on Mac. The problem seems that thread local variables are not correctly accessed after resuming the context from another thread. The program creates two threads, A and B. A sets the context ready before B could resume the context, for it's synced properly. It's very appreciated if someone could shed some light on this behavior on mac. ENV: ``` clang version 3.7.0 (http://llvm.org/git/llvm.git 8d70064a4ac2ae09b8003173e751cfad9dc15400) Target: x86_64-apple-darwin13.4.0 Thread model: posix ``` Program: ``` #define _XOPEN_SOURCE 800 #include #include #include #include #include #include #include static int flag = 0; void swap(ucontext_t *old, ucontext_t *new) { int ret = swapcontext(old, new); assert(ret == 0); } #define SSIZE MINSIGSTKSZ static char stack[SSIZE]; static ucontext_t a_ctx[2]; static ucontext_t b_ctx[2]; volatile static __thread int bug = 0; static void func(int b) { } static void f1 (void) { assert(bug == 0); func(bug); swap(&a_ctx[1], &a_ctx[0]); assert(bug == 1); } void *thread_a(void *arg) { printf("A is %lu\n", pthread_self()); bug = 0; ucontext_t ctx = a_ctx[1]; getcontext(&ctx); ctx.uc_stack.ss_sp = stack; ctx.uc_stack.ss_size = sizeof stack; makecontext(&ctx, f1, 0); swap(&a_ctx[0], &ctx); __atomic_store_n(&flag, 1, __ATOMIC_RELAXED); sleep(1); return NULL; } void *thread_b(void *arg) { printf("B is %lu\n", pthread_self()); bug = 1; while(__atomic_load_n(&flag, __ATOMIC_RELAXED) == 0) ; swap(&b_ctx[0], &a_ctx[1]); return NULL; } int main(int argc, char **argv) { pthread_t a, b; pthread_create(&b, NULL, &thread_b, NULL); pthread_create(&a, NULL, &thread_a, NULL); pthread_exit(NULL); } ``` I posted it on [SO](http://stackoverflow.com/questions/29430932/clang-bug-on-pthread-with-ucontext-on-mac) as well, but no real answers so far. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 15:09:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 22:09:34 +0000 Subject: [LLVMbugs] [Bug 23151] Clang VLA internal failure. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23151 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|-New Bugs |Frontend Resolution|--- |FIXED --- Comment #3 from David Majnemer --- Fixed in r234363. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 16:48:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 07 Apr 2015 23:48:21 +0000 Subject: [LLVMbugs] [Bug 23155] New: llvm 16 bit integer code causes lots of partial register stalls Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23155 Bug ID: 23155 Summary: llvm 16 bit integer code causes lots of partial register stalls Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: kevin.b.smith at intel.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When generating code for one of the eembc/telecom kernels llvm generates a lot of 16 bit operations, specifically loads that cause partial register usage. Due to the false dependency on the upper portion of the register, these operations are much slower than if they were expanded to be 32 bit operations. This specifically impacts the code generated for EEMBC/telecom/viterb00.c routine ACS. Eliminating the partial register stalls increases performance by about 27% for the data_2 input set. For other input sets the performance improvement is less, but it is significant for all of those inputs. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 17:54:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 00:54:50 +0000 Subject: [LLVMbugs] [Bug 18218] incorrect implementation of isnan and similar functions In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18218 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Marshall Clow (home) --- (In reply to comment #0) > The template should be enabled for every type that is convertible to an > arithmetic type, to make the implementation indistinguishable from what is > specified in the standard. After some research, and talking to a bunch of people, I have come to the conclusion that this is incorrect. This is LWG issue #2086 - http://cplusplus.github.io/LWG/lwg-defects.html#2086, and the discussion there is quite clear: The only valid types that can be passed to isnan (and others in ) are arithmetic types; i.e, the built-in integral and floating point types. No user-defined types. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 18:01:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 01:01:31 +0000 Subject: [LLVMbugs] [Bug 23035] lld reports "Undefined symbol" for shared lib's dependencies In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23035 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Davide Italiano --- r234378. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 19:09:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 02:09:55 +0000 Subject: [LLVMbugs] [Bug 23156] New: std::is_integral<__int128>::value is false with libstdc++ from GCC 5. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23156 Bug ID: 23156 Summary: std::is_integral<__int128>::value is false with libstdc++ from GCC 5. Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: toojays at toojays.net CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified g++-5 (Ubuntu 5-20150329-1ubuntu11~14.04) 5.0.0 20150329 (experimental) [trunk revision 221764] Ubuntu clang version 3.6.1-svn232753-1~exp1 (branches/release_36) (based on LLVM 3.6.1) jscott at citra:/tmp$ cat int128.cpp #include int main () { static_assert(std::is_integral<__int128>::value, "__int128 should be integral"); return 0; } jscott at citra:/tmp$ g++-5 -std=gnu++11 -c int128.cpp jscott at citra:/tmp$ clang++ -std=gnu++11 -c int128.cpp int128.cpp:5:3: error: static_assert failed "__int128 should be integral" static_assert(std::is_integral<__int128>::value, "__int128 should be integral"); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. With GCC 4.9, this program builds fine. This breakage appears to be due to the following GCC change: http://permalink.gmane.org/gmane.comp.gcc.cvs/165545 In GCC 4.9 there was a symbol _GLIBCXX_USE_INT128 defined somewhere (maybe in some config header? I'm not sure) which let this work. With GCC 5, __GLIBCXX_TYPE_INT_N_0 and __GLIBCXX_BITSIZE_INT_N_0 are built into the preprocessor, and must be defined to let type_traits acknowledge __int128 as an integer. I discovered this issue due to some code which uses GCC's SIMD Mersenne Twister extension. A minimal example is: #include typedef __gnu_cxx::simd_fast_mersenne_twister_engine< unsigned __int128, /* The following parameters all relate to Mersenne Twister internal * state. These are thoughtlessly copied from the definition of sfmt19937. */ 19937, 122, 18, 1, 11, 1, 0xdfffffefU, 0xddfecb7fU, 0xbffaffffU, 0xbffffff6U, 0x00000001U, 0x00000000U, 0x00000000U, 0x13c9e684U> sfmt19937_128; int main () { sfmt19937_128 engine; auto value = engine(); } Which fails to build with Clang 3.6 + libstdc++ 5.0 like: jscott at citra:/tmp$ clang++ -std=gnu++11 random.cpp In file included from random.cpp:1: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/c++/5.0.0/ext/random:67:7: error: static_assert failed "template argument substituting _UIntType not an unsigned integral type" static_assert(std::is_unsigned<_UIntType>::value, "template argument " ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ random.cpp:18:17: note: in instantiation of template class '__gnu_cxx::simd_fast_mersenne_twister_engine' requested here sfmt19937_128 engine; ^ 1 error generated. With the following definitions added to the top of the file it builds. Haven't tried a real example to see if it works though. """ #define __GLIBCXX_BITSIZE_INT_N_0 128 #define __GLIBCXX_TYPE_INT_N_0 __int128 """ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 19:00:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 02:00:02 +0000 Subject: [LLVMbugs] [Bug 18218] incorrect implementation of isnan and similar functions In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18218 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |richard-llvm at metafoo.co.uk Resolution|INVALID |--- --- Comment #8 from Richard Smith --- (In reply to comment #7) > The only valid types that can be passed to isnan (and others in > ) are arithmetic types; i.e, the built-in integral and floating point > types. No user-defined types. That may have been the intent, but I don't see any way to read the standard's wording that way. From the example in comment#0: std::isnan(A()); There are no arguments of arithmetic type, so none of the bullets in 26.8/11 apply. The overload set contains 'isnan(float)', 'isnan(double)', and 'isnan(long double)', and 'isnan(float)' should be selected. To my reading, what paragraph 11 requires is overload sets like this: template typename conditional::value, T, U>::type cast_if_arithmetic(U u) { return u; } template struct is_double_or_integral : integral_constant::value && !is_same::value && !is_same::value> {}; bool isgreater(float, float); bool isgreater(double, double); bool isgreater(long double, long double); // bullet 1 template typename enable_if::value || is_same::value, bool>::type isgreater(T t, U u) { return isgreater(cast_if_arithmetic(t), cast_if_arithmetic(u)); } // bullet 2 template typename enable_if::value || is_double_or_integral::value, bool>::type isgreater(T t, U u) { return isgreater(cast_if_arithmetic(t), cast_if_arithmetic(u)); } // bullet 3 requires no overloads: bullets 1 and 2 would have applied // if there were an arithmetic argument of a type other than float -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 20:50:37 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 03:50:37 +0000 Subject: [LLVMbugs] [Bug 23157] New: Assertion `!Legal->isUniform(SI->getPointerOperand()) && "We do not allow storing to uniform addresses"' failed. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23157 Bug ID: 23157 Summary: Assertion `!Legal->isUniform(SI->getPointerOperand()) && "We do not allow storing to uniform addresses"' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedbugs at nondot.org Reporter: peter at pcc.me.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified (reduced from chromium third_party/mesa/src/src/mesa/main/texcompress_fxt1.c) $ cat texcompress.c int a, d; const unsigned char *b[1]; char c[8]; void fn1() { const unsigned char **e = b; int i; for (; a; a++) for (; d;) for (; i; i++) c[i] = *e[a]++; } $ ~/src/llvm-build-dbg/bin/clang -O2 texcompress.c clang-3.7: /.../lib/Transforms/Vectorize/LoopVectorize.cpp:1834: virtual void ::InnerLoopVectorizer::vectorizeMemoryInstruction(llvm::Instruction *): Assertion `!Legal->isUniform(SI->getPointerOperand()) && "We do not allow storing to uniform addresses"' failed. Reverting r234361 fixes the assertion failure. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 7 22:44:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 05:44:33 +0000 Subject: [LLVMbugs] [Bug 23158] New: sNAN is not handled correct on legacy X87. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23158 Bug ID: 23158 Summary: sNAN is not handled correct on legacy X87. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: chunyang.cdai2 at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified When handling the float or double signaling NaN (sNAN) value with legacy X87 on x86. If it loads signal NaN to the x87 FP, the sNAN will be changed into into quiet NANs (qNAN). And Sometimes the value will be handled with normal regiter because of optimzation. This will leads to difference result. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 01:47:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 08:47:33 +0000 Subject: [LLVMbugs] [Bug 23159] New: Warning for ODR violation Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23159 Bug ID: 23159 Summary: Warning for ODR violation Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: hfinkel at anl.gov CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Richard provided to me this example showing ODR violation: #include // implicitly internal linkage due to 'const' const int n = 5; // odr violation, captures n by reference inline auto f() { return std::make_pair(n, 3); } // much more obvious odr violation, takes address of n inline auto g() { static const int *p = &n; return p; } Clang compiles this, however, without issuing any warnings. Taking the address of a variable with internal linkage in an inline function is probably not a good idea. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 06:41:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 13:41:21 +0000 Subject: [LLVMbugs] [Bug 21517] crash on ill formed code In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21517 Axel Naumann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Axel Naumann --- This has been fixed somewhere between then and now (r233280). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 07:42:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 14:42:50 +0000 Subject: [LLVMbugs] [Bug 22716] Need a mechanism to represent global profile counts in CFG and MachineCFG In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22716 Diego Novillo changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 07:43:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 14:43:19 +0000 Subject: [LLVMbugs] [Bug 22716] Need a mechanism to represent global profile counts in CFG and MachineCFG In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22716 Diego Novillo changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #3 from Diego Novillo --- Bah. I can't click today. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 09:57:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 16:57:20 +0000 Subject: [LLVMbugs] [Bug 23147] #include_next is not included in VS? In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23147 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Reid Kleckner --- This seems like an issue in XCode, then, and not upstream Clang. You should follow up with Apple. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 11:10:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 18:10:53 +0000 Subject: [LLVMbugs] [Bug 23162] New: CMake build should support a host with CLT Command Line Tools installed but not Xcode Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23162 Bug ID: 23162 Summary: CMake build should support a host with CLT Command Line Tools installed but not Xcode Product: compiler-rt Version: unspecified Hardware: All OS: MacOS X Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: jonathan+llvm at pinacea.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14169 --> https://llvm.org/bugs/attachment.cgi?id=14169&action=edit Patch CMakeLists.txt test exit code of xcodebuild When you run Cmake to configure 'compiler-rt' it issues a few commands with xcodebuild to detect the SDK Path. But when Xcode is not installed xcodebuild / xcrun / ... doesn't return an empty string but instead a message "Error: ....." which obviously isn't a valid answer and path The patch attached solve this issue by checking the return/exit code of xcodebuild and in that case change the path content to an empty string. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 13:05:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 20:05:39 +0000 Subject: [LLVMbugs] [Bug 23035] lld reports "Undefined symbol" for shared lib's dependencies In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23035 emaste at freebsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #2 from emaste at freebsd.org --- Reverted in r234414 New review with testcase update in http://reviews.llvm.org/D8901 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 13:40:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 20:40:16 +0000 Subject: [LLVMbugs] [Bug 23163] New: gep(gep...) merging in instcombine optimization hurts performance sometimes Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23163 Bug ID: 23163 Summary: gep(gep...) merging in instcombine optimization hurts performance sometimes Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: wmi at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14170 --> https://llvm.org/bugs/attachment.cgi?id=14170&action=edit 1.cc For the testcase 1.cc attached, ~/workarea/llvm-r234388/build/bin/clang -O2 -fno-omit-frame-pointer -std=c++11 1.cc -S -o 1.s In 1.s, the kernel loop contains 29 insns: .LBB1_6: # %for.body7 # Parent Loop BB1_3 Depth=1 # => This Inner Loop Header: Depth=2 leaq (%r12,%rdi), %rsi movslq %esi, %rbx leaq (%rbx,%r10), %rsi movzbl (%r9,%rsi), %esi leal (%rsi,%rsi,2), %esi leal (%r13,%rdi), %r8d movslq %r8d, %rcx addq %r10, %rcx movzbl (%r9,%rcx), %ecx leal 1(%rbx), %eax cltq addq %r10, %rax movzbl (%r9,%rax), %eax addl %ecx, %eax leal (%r14,%rdi), %ecx movslq %ecx, %rcx addq %r10, %rcx movzbl (%r9,%rcx), %ecx addl $2, %ebx movslq %ebx, %rbx addq %r10, %rbx movzbl (%r9,%rbx), %ebx leal (%rcx,%rsi,2), %ecx leal (%rcx,%rax,4), %eax addl %ebx, %eax movl %eax, (%r11,%rdi,2) addq $2, %rdi decl %edx jne .LBB1_6 If we disable gep merge in InstCombine pass, the kernel loop contains less insns (25 insns): .LBB1_6: # %for.body7 # Parent Loop BB1_3 Depth=1 # => This Inner Loop Header: Depth=2 leaq (%r12,%rcx), %rsi movslq %esi, %rsi movzbl (%r9,%rsi), %edx leal (%rdx,%rdx,2), %edx leal (%r13,%rcx), %ebx movslq %ebx, %rbx movzbl (%r9,%rbx), %ebx leal 1(%rsi), %r8d movslq %r8d, %rax movzbl (%r9,%rax), %eax addl %ebx, %eax leal (%r14,%rcx), %ebx movslq %ebx, %rbx movzbl (%r9,%rbx), %ebx addl $2, %esi movslq %esi, %rsi movzbl (%r9,%rsi), %esi leal (%rbx,%rdx,2), %edx leal (%rdx,%rax,4), %eax addl %esi, %eax movl %eax, (%r11,%rcx,2) addq $2, %rcx incl %edi cmpl %edi, %r15d jne .LBB1_6 gep(gep ...) merging optimization is similar with forward propagation optimization. We need to be careful especially when the source gep has more than one use. Usually we do the optimization only when gep merging will not increase the cost of the destination. We can see why gep merging is bad here from the IR of 1.cc below: * The IR before InstCombine: ... %2 = load i8*, i8** %data, align 8, !tbaa !7 %idx.ext2 = sext i32 %call1 to i64 %add.ptr3 = getelementptr inbounds i8, i8* %2, i64 %idx.ext2 ... for.body7: ... %arrayidx = getelementptr inbounds i8, i8* %add.ptr3, i64 %idxprom %3 = load i8, i8* %arrayidx, align 1, !tbaa !9 ... %arrayidx11 = getelementptr inbounds i8, i8* %add.ptr3, i64 %idxprom10 %4 = load i8, i8* %arrayidx11, align 1, !tbaa !9 ... %arrayidx15 = getelementptr inbounds i8, i8* %add.ptr3, i64 %idxprom14 %5 = load i8, i8* %arrayidx15, align 1, !tbaa !9 ... %arrayidx23 = getelementptr inbounds i8, i8* %add.ptr3, i64 %idxprom22 %6 = load i8, i8* %arrayidx23, align 1, !tbaa !9 ... br label %for.cond5 * The IR after InstCombine with gep merge: ... %2 = load i8*, i8** %data, align 8, !tbaa !7 %idx.ext2 = sext i32 %call1 to i64 ... for.body7: ... %add.ptr3.sum = add nsw i64 %idx.ext2, %idxprom %arrayidx = getelementptr inbounds i8, i8* %2, i64 %add.ptr3.sum %3 = load i8, i8* %arrayidx, align 1, !tbaa !9 ... %add.ptr3.sum61 = add nsw i64 %idx.ext2, %idxprom10 %arrayidx11 = getelementptr inbounds i8, i8* %2, i64 %add.ptr3.sum61 %4 = load i8, i8* %arrayidx11, align 1, !tbaa !9 ... %add.ptr3.sum63 = add nsw i64 %idx.ext2, %idxprom14 %arrayidx15 = getelementptr inbounds i8, i8* %2, i64 %add.ptr3.sum63 %5 = load i8, i8* %arrayidx15, align 1, !tbaa !9 ... %add.ptr3.sum64 = add nsw i64 %idx.ext2, %idxprom22 %arrayidx23 = getelementptr inbounds i8, i8* %2, i64 %add.ptr3.sum64 %6 = load i8, i8* %arrayidx23, align 1, !tbaa !9 ... br label %for.cond5 We can see that after gep merging, there is one less gep outside the loop, but there are four more add insns inside the loop. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 13:50:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 20:50:27 +0000 Subject: [LLVMbugs] [Bug 23157] Assertion `!Legal->isUniform(SI->getPointerOperand()) && "We do not allow storing to uniform addresses"' failed. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23157 Adam Nemet changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Adam Nemet --- r234424 is the fix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 14:26:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 21:26:10 +0000 Subject: [LLVMbugs] [Bug 23138] Assertion: isa(OutlinedBB->getTerminator()), file WinEHPrepare.cpp, line 659 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23138 Andy Kaylor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |andrew.kaylor at intel.com |org | --- Comment #2 from Andy Kaylor --- This was caused by not clearing the nested landing pad list between functions. It should be fixed by r234433. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 15:25:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 22:25:07 +0000 Subject: [LLVMbugs] [Bug 23164] New: Nested static vars in same DWARF scope Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23164 Bug ID: 23164 Summary: Nested static vars in same DWARF scope Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: paul_robinson at playstation.sony.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified If you have two static variables with the same name in nested lexical blocks: int main() { static float a = 50; int b = a; { static int a = 200; b += a; } return b; } You'll find that both DIEs for the two "a" variables are siblings. <2><43>: Abbrev Number: 3 (DW_TAG_variable) <44> DW_AT_name : (indirect string, offset: 0x54): a <48> DW_AT_type : <0x7c> <4c> DW_AT_decl_file : 1 <4d> DW_AT_decl_line : 2 <4e> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) <2><58>: Abbrev Number: 3 (DW_TAG_variable) <59> DW_AT_name : (indirect string, offset: 0x54): a <5d> DW_AT_type : <0x83> <61> DW_AT_decl_file : 1 <62> DW_AT_decl_line : 5 <63> DW_AT_location : 9 byte block: 3 4 0 0 0 0 0 0 0 (DW_OP_addr: 4) There's a lexical_block missing. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 15:36:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 22:36:30 +0000 Subject: [LLVMbugs] [Bug 11700] clang++ puts DW_AT_containing type in the wrong place in DWARF output In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=11700 Paul Robinson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |paul_robinson at playstation.s | |ony.com Resolution|--- |DUPLICATE --- Comment #1 from Paul Robinson --- Normally I'd mark the newer bug as the dup, but in this case the newer bug has some helpful discussion in it so I think we're better off keeping that one open. *** This bug has been marked as a duplicate of bug 21902 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 15:48:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 22:48:24 +0000 Subject: [LLVMbugs] [Bug 18462] DWARF for static local attached to wrong DIE In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18462 Paul Robinson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Paul Robinson --- This got fixed sometime in the 3.5 timeframe. The entry for the func inside the namespace is a definition now, so gdb finds the static variable. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 15:55:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 08 Apr 2015 22:55:28 +0000 Subject: [LLVMbugs] [Bug 23112] clang-cl: /fp is not supported In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23112 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- r234449 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 18:46:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 01:46:58 +0000 Subject: [LLVMbugs] [Bug 23165] New: abort with "pure virtual method called", when a virtual function is called on a POD temporary passed as an argument (in program compiled w/ clang trunk -std=c++11) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23165 Bug ID: 23165 Summary: abort with "pure virtual method called", when a virtual function is called on a POD temporary passed as an argument (in program compiled w/ clang trunk -std=c++11) Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: dholbert at mozilla.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14171 --> https://llvm.org/bugs/attachment.cgi?id=14171&action=edit C++ testcase STR: 1. Compile attached program using clang 3.7 with -std=c++11: clang++-3.7 -std=c++11 test.cpp (Or use -std=gnu++0x) 2. Run the resulting a.out ACTUAL RESULTS: The program aborts with: > pure virtual method called > terminate called without an active exception > Aborted (core dumped) EXPECTED RESULTS: No abort; virtual function should run successfully. I get EXPECTED RESULTS if I drop the "-std=c++11" command-line argument. I also get EXPECTED RESULTS from clang++-3.6 (with the c++11 command-line argument included). So this is a regression, or at least a behavior-change. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 8 19:48:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 02:48:57 +0000 Subject: [LLVMbugs] [Bug 23166] New: Segmentation fault in llvm-symbolizer on missing compile units Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23166 Bug ID: 23166 Summary: Segmentation fault in llvm-symbolizer on missing compile units Product: new-bugs Version: 3.6 Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: me at cirw.in CC: llvmbugs at cs.uiuc.edu Classification: Unclassified 0 llvm-symbolizer 0x00000001064f6839 llvm::sys::PrintStackTrace(__sFILE*) + 57 1 llvm-symbolizer 0x00000001064f6f9b SignalHandler(int) + 635 2 libsystem_platform.dylib 0x00007fff93515f1a _sigtramp + 26 3 libsystem_platform.dylib 0x000000000005d12a _sigtramp + 1823765034 4 llvm-symbolizer 0x00000001063c2530 llvm::DWARFUnit::collectAddressRanges(std::__1::vector, std::__1::allocator > >&) + 64 5 llvm-symbolizer 0x00000001063b21f1 llvm::DWARFDebugAranges::generate(llvm::DWARFContext*) + 257 6 llvm-symbolizer 0x00000001063aaf43 llvm::DWARFContext::getCompileUnitForAddress(unsigned long long) + 195 7 llvm-symbolizer 0x00000001063ab6fc llvm::DWARFContext::getInliningInfoForAddress(unsigned long long, llvm::DILineInfoSpecifier) + 92 8 llvm-symbolizer 0x000000010639ddd4 llvm::symbolize::ModuleInfo::symbolizeInlinedCode(unsigned long long, llvm::symbolize::LLVMSymbolizer::Options const&) const + 132 9 llvm-symbolizer 0x000000010639e224 llvm::symbolize::LLVMSymbolizer::symbolizeCode(std::__1::basic_string, std::__1::allocator > const&, unsigned long long) + 116 10 llvm-symbolizer 0x00000001063a4865 main + 1525 11 libdyld.dylib 0x00007fff96ae45c9 start + 1 Stack dump: 0. Program arguments: ./llvm/Release+Asserts/bin/llvm-symbolizer -obj=segfaulty [1] 32676 done echo 0xb6f74 | 32677 segmentation fault ./llvm/Release+Asserts/bin/llvm-symbolizer -obj=segfaulty If you run llvm-dwarfdump on this file you get an assertion failure, which seems reasonable: Assertion failed: (CU && "Null Compile Unit?"), function dump, file DWARFCompileUnit.cpp, line 26. 0 llvm-dwarfdump 0x00000001033978a9 llvm::sys::PrintStackTrace(__sFILE*) + 57 1 llvm-dwarfdump 0x000000010339800b SignalHandler(int) + 635 2 libsystem_platform.dylib 0x00007fff93515f1a _sigtramp + 26 3 llvm-dwarfdump 0x00000001033ba69d nuls + 3413 4 llvm-dwarfdump 0x0000000103397d76 abort + 22 5 llvm-dwarfdump 0x0000000103397d51 __assert_rtn + 81 6 llvm-dwarfdump 0x000000010334bc05 llvm::DWARFCompileUnit::dump(llvm::raw_ostream&) + 885 7 llvm-dwarfdump 0x000000010334be2b llvm::DWARFContext::dump(llvm::raw_ostream&, llvm::DIDumpType) + 475 8 llvm-dwarfdump 0x00000001033488bb main + 1195 9 libdyld.dylib 0x00007fff96ae45c9 start + 1 10 libdyld.dylib 0x0000000000000002 start + 1766963770 Stack dump: 0. Program arguments: ./llvm/Release+Asserts/bin/llvm-dwarfdump segfaulty [1] 32568 illegal hardware instruction ./llvm/Release+Asserts/bin/llvm-dwarfdump segfaulty > /dev/null -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 01:53:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 08:53:14 +0000 Subject: [LLVMbugs] [Bug 23168] New: uniform_real_distribution isn't uniform. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23168 Bug ID: 23168 Summary: uniform_real_distribution isn't uniform. Product: libc++ Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: art at blahonga.org CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified Looking at the implementation of uniform_real_distribution it's quite obvious that it isn't respecting the pigeonhole principle. And since lots of other distributions are built on top of uniform_real_distribution, all those other distributions are broken too. Here's a very simple test: $ cat urd.cxx #include #include #include #include int main() { std::default_random_engine gen; double from = 0x1p52, to = from + 2; std::uniform_real_distribution dis(from, to); long long bucket[3] = { 0 }; int i; for (i = 0; i < 1000000; i++) { double r = dis(gen); unsigned int b = (int)(r - from); if (b >= 3) { printf("foo: %d %f\n", b, r); } assert(b < 3); bucket[b]++; } for (i = 0; i < 3; i++) { printf("%lld\n", bucket[i]); } return 0; } $ c++ -v Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix $ c++ -std=c++11 -o foo urd.cxx && ./foo 249701 500046 250253 I looked through the code available on the svn trunk on the web and it hasn't changed enough to fix this. The reason 0x1p52 is the start of the range is because at [2^52,2^53) doubles have exactly integer precision which allows the generator only three possible output values. Any other range could be chosen and display the same problem as long as we constrict the generator to few (non 2^n) outputs. Three possible outputs will display the greatest bias in the output. GCC libstdc++ is broken too in the exact same way. FYI. A while ago I started an attempt to make a decent solution to a small part of this problem because it's harder than it looks: https://github.com/art4711/random-double/blob/master/rd.c -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 07:07:44 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 14:07:44 +0000 Subject: [LLVMbugs] [Bug 23057] fuzz clang In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23057 Bug 23057 depends on bug 21838, which changed state. Bug 21838 Summary: [fuzz] SEGV in/below ParseGNUAttributes https://llvm.org/bugs/show_bug.cgi?id=21838 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 07:07:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 14:07:42 +0000 Subject: [LLVMbugs] [Bug 21838] [fuzz] SEGV in/below ParseGNUAttributes In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21838 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution|--- |WORKSFORME --- Comment #2 from Aaron Ballman --- This no longer crashes for me on ToT. E:\llvm\2013>clang -fno-crash-diagnostics -std=c++11 -xc++ -c -emit-llvm "E:\Aaron Ballman\Desktop\test.cpp" E:\Aaron Ballman\Desktop\test.cpp:1:33: error: expected ')' struct { __attribute__((typename > ^ ) E:\Aaron Ballman\Desktop\test.cpp:1:35: error: expected ')' struct { __attribute__((typename > ^ ) E:\Aaron Ballman\Desktop\test.cpp:1:35: error: expected member name or ';' after declaration specifiers struct { __attribute__((typename > ^ E:\Aaron Ballman\Desktop\test.cpp:1:35: error: expected '}' E:\Aaron Ballman\Desktop\test.cpp:1:8: note: to match this '{' struct { __attribute__((typename > ^ E:\Aaron Ballman\Desktop\test.cpp:1:35: error: expected ';' after struct struct { __attribute__((typename > ^ ; E:\Aaron Ballman\Desktop\test.cpp:1:1: error: anonymous structs and classes must be class members struct { __attribute__((typename > ^ 6 errors generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 07:28:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 14:28:40 +0000 Subject: [LLVMbugs] [Bug 21818] [fuzz] Assertion `Tok.is(tok::tilde) && "ParseOptionalCXXScopeSpecifier fail"' failed. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21818 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution|--- |WORKSFORME --- Comment #1 from Aaron Ballman --- This test no longer reproduces for me on ToT: E:\llvm\2013>clang -fno-crash-diagnostics -std=c++11 -xc++ -c -emit-llvm "E:\Aaron Ballman\Desktop\test.cpp" E:\Aaron Ballman\Desktop\test.cpp:1:1: error: C++ requires a type specifier for all declarations a { ^ E:\Aaron Ballman\Desktop\test.cpp:1:4: error: expected expression a { ^ E:\Aaron Ballman\Desktop\test.cpp:1:4: error: expected '}' E:\Aaron Ballman\Desktop\test.cpp:1:3: note: to match this '{' a { ^ E:\Aaron Ballman\Desktop\test.cpp:1:4: error: expected ';' after top level declarator a { ^ ; 4 errors generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 07:28:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 14:28:40 +0000 Subject: [LLVMbugs] [Bug 23057] fuzz clang In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23057 Bug 23057 depends on bug 21818, which changed state. Bug 21818 Summary: [fuzz] Assertion `Tok.is(tok::tilde) && "ParseOptionalCXXScopeSpecifier fail"' failed. https://llvm.org/bugs/show_bug.cgi?id=21818 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 08:38:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 15:38:58 +0000 Subject: [LLVMbugs] [Bug 20912] -freciprocal-math flag doesn't generate 'arcp' in LLVM IR In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20912 Sanjay Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sanjay Patel --- Fixed here: http://reviews.llvm.org/rL234493 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 09:09:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 16:09:53 +0000 Subject: [LLVMbugs] [Bug 23165] abort with "pure virtual method called", when a virtual function is called on a POD temporary passed as an argument (in program compiled w/ clang trunk -std=c++11) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23165 Benjamin Kramer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |benny.kra at gmail.com Resolution|--- |FIXED --- Comment #3 from Benjamin Kramer --- Fixed in r234499, sorry for the breakage. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 09:17:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 16:17:04 +0000 Subject: [LLVMbugs] [Bug 23171] New: Improper function to pointer conversion in call expression in C++ Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23171 Bug ID: 23171 Summary: Improper function to pointer conversion in call expression in C++ Product: clang Version: 3.5 Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: alexandermbock at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Given this code: void f() { f(); } clang generates this AST: TranslationUnitDecl 0x1028254d0 <> |-TypedefDecl 0x102825a10 <> __int128_t '__int128' |-TypedefDecl 0x102825a70 <> __uint128_t 'unsigned __int128' |-TypedefDecl 0x102825e30 <> __builtin_va_list '__va_list_tag [1]' `-FunctionDecl 0x102825ed0 f 'void (void)' `-CompoundStmt 0x102826058 `-CallExpr 0x102826030 'void' `-ImplicitCastExpr 0x102826018 'void (*)(void)' `-DeclRefExpr 0x102825fc8 'void (void)' lvalue Function 0x102825ed0 'f' 'void (void)' Note the ImplicitCastExpr . [expr.call]/1 says: For a call to a non-member function or to a static member function, the postfix expression shall be either an lvalue that refers to a function (in which case the function-to-pointer standard conversion is suppressed on the postfix expression), or it shall have pointer to function type. I would not expect the AST to contain a function to pointer conversion when the standard explicitly states that one does not occur. I am not aware of any circumstance in which this could change the observable behavior of a program, but it complicates tool development when the AST does not match what is expected from the standard. Note that this does not apply to C; C11 6.5.2.2 says: The expression that denotes the called function shall have type pointer to function returning void or returning a complete object type other than an array type. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 09:50:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 16:50:36 +0000 Subject: [LLVMbugs] [Bug 23172] New: function-level attribute leakage Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23172 Bug ID: 23172 Summary: function-level attribute leakage Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: spatel+llvm at rotateright.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat fast-attribute.ll define double @add_0_fast(double %a) #0 { %add = fadd double %a, 0.0 ret double %add } define double @add_0_not_fast(double %a) { %add = fadd double %a, 0.0 ret double %add } attributes #0 = { "unsafe-fp-math"="true" } ---------------------------------------------------------------------- The 2nd function should have an add instruction, but: $ ./llc -o - fast-attribute.ll _add_0_fast: ## @add_0_fast retq _add_0_not_fast: ## @add_0_not_fast retq -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 09:51:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 16:51:03 +0000 Subject: [LLVMbugs] [Bug 20942] TableGen and AttrDump.inc In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20942 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution|--- |FIXED --- Comment #1 from Aaron Ballman --- This was fixed with r220930 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 11:04:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 18:04:33 +0000 Subject: [LLVMbugs] [Bug 23173] New: PPC Back end crashes in 32-bit mode on conversions of i64 to/from f32 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23173 Bug ID: 23173 Summary: PPC Back end crashes in 32-bit mode on conversions of i64 to/from f32 Product: libraries Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedbugs at nondot.org Reporter: nemanja.i.ibm at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Reduced test case: $ cat bug_conv_f32_to_i64.c // Compile with clang -target=powerpc-unknown-unknown -c -mcpu=pwr7 unsigned long long testullf(float arg) { return arg; } $ clang -target=powerpc-unknown-unknown -c -mcpu=pwr7 bug_conv_f32_to_i64.c Do not know how to custom type legalize this operation! UNREACHABLE executed at $LLVM_SRC/lib/Target/PowerPC/PPCISelLowering.cpp:7729! Same thing happens when llc is run on the resulting ll/bc file. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 11:22:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 18:22:10 +0000 Subject: [LLVMbugs] [Bug 23174] New: Class StreamingMemoryObject doesn't respect call to setKnownObjectSize. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23174 Bug ID: 23174 Summary: Class StreamingMemoryObject doesn't respect call to setKnownObjectSize. Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: kschimpf at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified CL http://reviews.llvm.org/D8931 shows that StreamingMemoryObject doesn't respect the call to setKnownObjectSize. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 11:50:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 18:50:51 +0000 Subject: [LLVMbugs] [Bug 23175] New: Infinite loop iterating Objective-C method declarations in categories when the AST was deserialized from an .ast file Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23175 Bug ID: 23175 Summary: Infinite loop iterating Objective-C method declarations in categories when the AST was deserialized from an .ast file Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: thonermann at coverity.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I encountered an infinite loop in Clang 3.4 - trunk (r234313) when iterating over ObjCMethodDecl declarations using the Decl::redecl_begin() and Decl::redecl_end() interfaces for methods declared in both category and category implementation declarations when the AST has been deserialized from a .ast file. Iteration terminates correctly when the AST has not been serialized and then deserialized. I haven't been able to reproduce this issue using the clang command line. I have a unit test that I will attach. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 12:24:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 19:24:08 +0000 Subject: [LLVMbugs] [Bug 23176] New: atomic compare-and-swap under thread sanitizer after multithreaded fork is incorrect Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23176 Bug ID: 23176 Summary: atomic compare-and-swap under thread sanitizer after multithreaded fork is incorrect Product: compiler-rt Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: bsilver16384+llvm at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Many of the atomic compare-and-swap primitives work incorrectly under thread sanitizer after a multithreaded fork. Some of the ones which do not work: __sync_bool_compare_and_swap, __sync_val_compare_and_swap, __tsan_atomic32_compare_exchange_val. They all return a value indicating that the variable did not contain the correct value at the start, even when it does. However, they do change the value of the variable correctly. The variants which return the previous value always return 1. __tsan_atomic32_compare_exchange_strong does work correctly under the same circumstances. Here's a simple test program which shows the problem: #include #include #include #include void succeed() { int test = 4; int result = 4; __tsan_atomic32_compare_exchange_strong(&test, &result, 5, __tsan_memory_order_seq_cst, __tsan_memory_order_seq_cst); printf("got %d value is %d\n", result, test); } void fail2() { int test = 4; int result = __tsan_atomic32_compare_exchange_val( &test, 4, 5, __tsan_memory_order_seq_cst, __tsan_memory_order_seq_cst); printf("got %d value is %d\n", result, test); } void fail1() { int test = 4; int result = __sync_val_compare_and_swap(&test, 4, 5); printf("got %d value is %d\n", result, test); } void nop() {} int main() { ::std::thread thread1(nop); if (fork() == 0) { fail1(); fail2(); succeed(); exit(0); } else { thread1.join(); } } Here's what it prints for me: got 1 value is 5 got 1 value is 5 got 4 value is 5 Those 1s should be 4s. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 12:38:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 19:38:01 +0000 Subject: [LLVMbugs] [Bug 23177] New: static char strange linker error Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23177 Bug ID: 23177 Summary: static char strange linker error Product: lld Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: daniel.liverance at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I'm using Xcode on Apple LLVM version 6.1.0 (clang-602.0.49) based on LLVM 3.6.0svn There is a strange linker error with the following code: #include #include class Foo { public: static const char Something = 0; }; std::map test_fail; int main(int argc, const char * argv[]) { if (Foo::Something == 0) { char bar = Foo::Something; printf("Foo::Something = %d\n", bar); printf("Foo::Something = %d\n", Foo::Something); test_fail[Foo::Something] = 0; } return 0; } This program fails to link on the symbol Foo::Something in _main, and it's odd because it only fails to link when using it with the std::map. If you comment out "test_fail[Foo::Something] = 0;" it successfully links. It will also link if you change: static const char Something = 0; to: static const unsigned char Something = 0; It will also link if you change: std::map test_fail; to: std::map test_fail; It will also compile if you cast the Foo::Something in the map usage like: test_fail[(char)Foo::Something] = 0; test_fail[(unsigned char)Foo::Something] = 0; both will fix the linker error. I believe this is a bug in the linker. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 12:50:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 19:50:55 +0000 Subject: [LLVMbugs] [Bug 23178] New: -g leaks memory Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23178 Bug ID: 23178 Summary: -g leaks memory Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: dblaikie at gmail.com, dexonsmith at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14177 --> https://llvm.org/bugs/attachment.cgi?id=14177&action=edit log -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 13:20:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 20:20:32 +0000 Subject: [LLVMbugs] [Bug 23177] static char strange linker error In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23177 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |INVALID --- Comment #1 from David Majnemer --- Hi Daniel, Your program is invalid because you don't specify a definition of Foo::Something. You need something like the following in at least one translation unit: const char Something::Foo; The reason why you are observing different behavior between 'char' and 'unsigned char' is due to the fact that your static data member is ODR-used in the operator[] of the map because the map takes a char& parameter. When you change the static data member's type to 'unsigned char', you instead get a temporary created of the appropriate type and have it's address passed to the map. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 13:52:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 20:52:03 +0000 Subject: [LLVMbugs] [Bug 23179] New: Warn on missing exports in microsoft mode? Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23179 Bug ID: 23179 Summary: Warn on missing exports in microsoft mode? Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider something like this: struct CpuProfileDeoptFrame { int script_id; }; // XXX //template class V8_EXPORT std::vector; struct V8_EXPORT CpuProfileDeoptInfo { std::vector stack; }; Unless the line marked XXX is present, cl will warn on this with 2>D:\src\v8\include/v8-profiler.h(31): warning C4251: 'v8::CpuProfileDeoptInfo::stack' : class 'std::vector>' needs to have dll-interface to be used by clients of struct 'v8::CpuProfileDeoptInfo' 2> with 2> [ 2> _Ty=v8::CpuProfileDeoptFrame 2> ] (..\..\src\compiler\change-lowering.cc) There's probably a good reason for that -- should we warn on this too? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 14:13:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 21:13:20 +0000 Subject: [LLVMbugs] [Bug 16804] Assertion failure for local extern declarations of variables with names matching function parameters In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=16804 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution|--- |WORKSFORME --- Comment #3 from Aaron Ballman --- This issue no longer reproduces for me on ToT (r234484). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 14:22:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 21:22:57 +0000 Subject: [LLVMbugs] [Bug 22671] assertion failure taking address of MS property In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22671 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution|--- |FIXED --- Comment #2 from Aaron Ballman --- This should be fixed by r230362. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 14:36:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 21:36:53 +0000 Subject: [LLVMbugs] [Bug 20763] Asserts on valid with anonymous union member name being hidden by namespace member declaration In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20763 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution|--- |WORKSFORME --- Comment #1 from Aaron Ballman --- This no longer reproduces for me on ToT (r234484). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 14:42:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 21:42:22 +0000 Subject: [LLVMbugs] [Bug 23180] New: Conditional jump or move depends on uninitialised value Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23180 Bug ID: 23180 Summary: Conditional jump or move depends on uninitialised value Product: new-bugs Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: eric at youngblut.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Valgrind found a bug and we confirmed it by reading the generated assembly code. ======== file1.c ======== #include #include bool pop_if_contains(int *value); static int pop_or_default(int default_value) { int value; return pop_if_contains(&value) ? value : default_value; } int main(void) { int value = pop_or_default(1001); if (value != 1001) puts("error"); } ======== file2.c ======== #include bool pop_if_contains(int *value) { return false; } ======== clang -Os -fno-omit-frame-pointer file1.c file2.c valgrind ./a.out ==24488== Memcheck, a memory error detector ==24488== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==24488== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==24488== Command: ./a.out ==24488== ==24488== Conditional jump or move depends on uninitialised value(s) ==24488== at 0x400548: main (in /home/ericy/a.out) ==24488== ==24488== ==24488== HEAP SUMMARY: ==24488== in use at exit: 0 bytes in 0 blocks ==24488== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==24488== ==24488== All heap blocks were freed -- no leaks are possible ==24488== ==24488== For counts of detected and suppressed errors, rerun with: -v ==24488== Use --track-origins=yes to see where uninitialised values come from ==24488== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1) (gdb) disassemble main Dump of assembler code for function main: 0x0000000000400530 <+0>: push %rbp 0x0000000000400531 <+1>: mov %rsp,%rbp 0x0000000000400534 <+4>: sub $0x10,%rsp 0x0000000000400538 <+8>: lea -0x4(%rbp),%rdi 0x000000000040053c <+12>: callq 0x400560 0x0000000000400541 <+17>: cmpl $0x3e9,-0x4(%rbp) 0x0000000000400548 <+24>: je 0x400558 0x000000000040054a <+26>: xor $0x1,%al 0x000000000040054c <+28>: jne 0x400558 0x000000000040054e <+30>: mov $0x4005f4,%edi 0x0000000000400553 <+35>: callq 0x400410 0x0000000000400558 <+40>: xor %eax,%eax 0x000000000040055a <+42>: add $0x10,%rsp 0x000000000040055e <+46>: pop %rbp 0x000000000040055f <+47>: retq It seems that the compiler has erroneously reordered the comparisons. The cmpl/je is the "if (value != 1001)" and the xor/jne is the ? operator, but they're in the wrong order. Found at Qumulo, Inc. (qumulo.com). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 16:44:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 09 Apr 2015 23:44:51 +0000 Subject: [LLVMbugs] [Bug 23182] New: There doesn't seem to be a way to specify a dwarf version with -gmlt/-gline-tables-only Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23182 Bug ID: 23182 Summary: There doesn't seem to be a way to specify a dwarf version with -gmlt/-gline-tables-only Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: dexonsmith at apple.com CC: aprantl at apple.com, dblaikie at gmail.com, echristo at gmail.com, friss at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified All the -g* options are in a single option group, and kill whatever comes before them (either that, or I'm very bad at the command-line today?). On Mach-O (where the default is currently dwarf 2), `-gdwarf-4 -gmlt` gives you "line tables only dwarf 2", whereas `-gmlt -gdwarf-4` gives you "full debug info dwarf 4". It's not clear to me what the right answer is here. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 17:05:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 00:05:12 +0000 Subject: [LLVMbugs] [Bug 23180] Conditional jump or move depends on uninitialised value In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23180 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |INVALID --- Comment #3 from David Majnemer --- There is no bug to fix, LLVM is free to compute whatever values based off of uninitialized memory it likes so long as those speculative computations never effect the program's behavior. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 17:16:59 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 00:16:59 +0000 Subject: [LLVMbugs] [Bug 23183] New: clang 3.5.2 and later miscompiles llvm-gcc Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23183 Bug ID: 23183 Summary: clang 3.5.2 and later miscompiles llvm-gcc Product: clang Version: 3.6 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: howarth.mailing.lists at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The clang compilers from 3.5.2 and later miscompile the legacy llvm-gcc code from Apple's open source repo. The llvm-gcc bootstrap (tested with the llvm-gcc42 fink packaging) can be restore with... sed -i '1s/^/#pragma clang optimize off\n/' ./llvmCore/lib/CodeGen/MachineSSAUpdater.cpp sed -i '1s/^/#pragma clang optimize off\n/' ./llvmCore/lib/Transforms/Utils/SSAUpdater.cpp Compiling the files with -O1 is insufficient to remove the miscompilation and -O0 is required. Disabling vectorization via the pragma statement likewise is insufficient to eliminate the miscompilation of the code. Do we have any pragma statements that would disable specific optimizations enabled in going from -O0 to -O1? Note that Apple clang 6.0 (based on 3.5svn) works but Apple clang 6.1 (based on 3.6svn) is broken. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 18:34:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 01:34:13 +0000 Subject: [LLVMbugs] [Bug 23184] New: error building clang with mingw-64 on windows Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23184 Bug ID: 23184 Summary: error building clang with mingw-64 on windows Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: timothy.wright.software at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified I pulled the latest svn repositories and did manage to build the same code with Visual Studio. But I'm trying to use the YouCompleteMe plugin for vim, which needs clang built with mingw64. The Visual Studio build did not work. Here is the error. Not really sure how to continue. command-line output llvm[4]: Compiling Action.cpp for Release+Asserts build llvm[4]: Compiling Compilation.cpp for Release+Asserts build llvm[4]: Compiling CrossWindowsToolChain.cpp for Release+Asserts build llvm[4]: Compiling Driver.cpp for Release+Asserts build llvm[4]: Compiling DriverOptions.cpp for Release+Asserts build llvm[4]: Compiling Job.cpp for Release+Asserts build llvm[4]: Compiling MSVCToolChain.cpp for Release+Asserts build In file included from c:\mingw64\x86_64-w64-mingw32\include\winnt.h:7681:0, from c:\mingw64\x86_64-w64-mingw32\include\minwindef.h:146, from c:\mingw64\x86_64-w64-mingw32\include\windef.h:8, from c:\mingw64\x86_64-w64-mingw32\include\windows.h:69, from c:/llvm-3.6/tools/clang/lib/Driver/MSVCToolChain.cpp:38: c:\mingw64\x86_64-w64-mingw32\include\ktmtypes.h:88:9: error: declaration of 'UO W _TRANSACTION_NOTIFICATION_RECOVERY_ARGUMENT::UOW' [-fpermissive] UOW UOW; ^ c:\mingw64\x86_64-w64-mingw32\include\ktmtypes.h:13:16: error: changes meaning o f 'UOW' from 'typedef GUID UOW' [-fpermissive] typedef GUID UOW,*PUOW; ^ In file included from c:\mingw64\x86_64-w64-mingw32\include\winnt.h:7681:0, from c:\mingw64\x86_64-w64-mingw32\include\minwindef.h:146, from c:\mingw64\x86_64-w64-mingw32\include\windef.h:8, from c:\mingw64\x86_64-w64-mingw32\include\windows.h:69, from c:/llvm-3.6/tools/clang/lib/Driver/MSVCToolChain.cpp:38: c:\mingw64\x86_64-w64-mingw32\include\ktmtypes.h:132:9: error: declaration of 'U OW _KCRM_TRANSACTION_BLOB::UOW' [-fpermissive] UOW UOW; ^ In file included from c:\mingw64\x86_64-w64-mingw32\include\winnt.h:7681:0, from c:\mingw64\x86_64-w64-mingw32\include\minwindef.h:146, from c:\mingw64\x86_64-w64-mingw32\include\windef.h:8, from c:\mingw64\x86_64-w64-mingw32\include\windows.h:69, from c:/llvm-3.6/tools/clang/lib/Driver/MSVCToolChain.cpp:38: c:\mingw64\x86_64-w64-mingw32\include\ktmtypes.h:13:16: error: changes meaning o f 'UOW' from 'typedef GUID UOW' [-fpermissive] typedef GUID UOW,*PUOW; ^ /usr/bin/rm: cannot lstat `/c/llvm/tools/clang/lib/Driver/Release+Asserts/MSVCTo olChain.d.tmp': No such file or directory make[4]: *** [/c/llvm/tools/clang/lib/Driver/Release+Asserts/MSVCToolChain.o] Er ror 1 make[4]: Leaving directory `/c/llvm/tools/clang/lib/Driver' make[3]: *** [Driver/.makeall] Error 2 make[3]: Leaving directory `/c/llvm/tools/clang/lib' make[2]: *** [all] Error 1 make[2]: Leaving directory `/c/llvm/tools/clang' make[1]: *** [clang/.makeall] Error 2 make[1]: Leaving directory `/c/llvm/tools' make: *** [all] Error 1 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 20:07:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 03:07:24 +0000 Subject: [LLVMbugs] [Bug 16804] Assertion failure for local extern declarations of variables with names matching function parameters In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=16804 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |RESOLVED Resolution|WORKSFORME |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 20:40:29 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 03:40:29 +0000 Subject: [LLVMbugs] [Bug 23173] PPC Back end crashes in 32-bit mode on conversions of i64 to/from f32 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23173 Hal Finkel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hal Finkel --- r234561 should fix this (at least in the sense that we don't crash, and seem to generate the right instructions -- we also seem to generate some extra stores, but that's perhaps a separate matter). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 22:23:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 05:23:36 +0000 Subject: [LLVMbugs] [Bug 23186] New: Type correction leads to null dereference Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23186 Bug ID: 23186 Summary: Type correction leads to null dereference Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: david.majnemer at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified consider: decltype(ned); template struct S { enum { V }; void f() { switch (0) case V: ; } }; compile with: clang -cc1 -std=c++11 t.cpp this leads us to getting the size of a dependent type: BuiltinType 0x74851a0 '' dependent -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 9 22:31:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 05:31:36 +0000 Subject: [LLVMbugs] [Bug 23187] New: Clang cannot consume -Og Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23187 Bug ID: 23187 Summary: Clang cannot consume -Og Product: clang Version: 3.6 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: noloader at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Clang is having trouble consuming -Og. -Og was added to GCC a couple of years ago (2012 or so). It enables optimizations that don't effect debugging sessions. That is, you still get analysis but you don't see a lot of "optimized out" under the debugger. Read more at https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html#Optimize-Options. ********** $ /usr/local/bin/clang --version clang version 3.6.0 (tags/RELEASE_360/final) Target: x86_64-apple-darwin12.6.0 Thread model: posix ********** /usr/local/bin/clang -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -g3 -Og -Wall -fsanitize=undefined -fsanitize=address -DDSO_DLFCN -DHAVE_DLFCN_H -arch i386 -DL_ENDIAN -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o cryptlib.o cryptlib.c error: invalid integral value 'g' in '-Og' error: invalid integral value 'g' in '-Og' make[1]: *** [cryptlib.o] Error 1 make: *** [build_crypto] Error 1 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 02:30:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 09:30:11 +0000 Subject: [LLVMbugs] [Bug 23188] New: compile error "invalid native target: 'x86'" Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23188 Bug ID: 23188 Summary: compile error "invalid native target: 'x86'" Product: new-bugs Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: ThePsyjo at googlemail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14182 --> https://llvm.org/bugs/attachment.cgi?id=14182&action=edit fix for parser.read() in llvmbuild.componentinfo Hi, while building llvm i got the message llvm-build: error: invalid native target: 'x86' all the time. In the end, LibraryDependencies.inc was missing and the build failed. My environment: Gentoo default/linux/amd64/13.0 python-2.7 (default) all packages are more or less not older than 2 months I tracked it down to the RawConfigParser which is not used properly: parser.read(path) <- expects a list of file_names not a string https://docs.python.org/2/library/configparser.html#ConfigParser.RawConfigParser.read A patch is attached. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 05:44:23 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 12:44:23 +0000 Subject: [LLVMbugs] [Bug 15853] __has_attribute does not parse C++11 namespaced attributes In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15853 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Aaron Ballman --- This issue was fixed with r223467 and r223468; __has_cpp_attribute parses namespaces, __has_attribute only parses GNU-style attributes (which do not have namespaces), and __has_declspec_attribute was added. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 07:16:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 14:16:16 +0000 Subject: [LLVMbugs] [Bug 22499] Crash while compiling lambdas within a template function In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22499 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution|--- |WORKSFORME --- Comment #5 from Aaron Ballman --- This appears to be fixed on ToT -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 08:05:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 15:05:13 +0000 Subject: [LLVMbugs] [Bug 23189] New: Crash when compiling C++ (qt + gtest) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23189 Bug ID: 23189 Summary: Crash when compiling C++ (qt + gtest) Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: winfried_mb2 at xmsnet.nl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14183 --> https://llvm.org/bugs/attachment.cgi?id=14183&action=edit preprocessed source file and run script that crashed clang++ frontend When compiling a project that uses Qt and Googles GTest from QtCreator (using cmake), I suddenly got a Clang crash. The output included a request to file a bug report, so here it is. I also attach the preprocessed source file and associated run script as requested. O.S. is openSuse 13.2. I upgraded the default llvm/clang of OpenSuse 13.2 with the clang 3.6 packages at http://download.opensuse.org/repositories/devel:/tools:/compiler/openSUSE_13.2/x86_64/llvm-clang-3.6.0-417.7.x86_64.rpm version information: winfried at linux-dobbe:~> /usr/bin/clang++ -v clang version 3.6.0 (tags/RELEASE_360/final 230777) Target: x86_64-suse-linux Thread model: posix Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/4.8 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/4.9 Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8 Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.9 Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/4.9 Candidate multilib: .;@m64 Selected multilib: .;@m64 command line and backtrace: [ 90%] Building CXX object test/unit/qtftpserver/CMakeFiles/qtftpserver_ut.dir/qtftpserver_ut.cpp.o cd /home/winfried/svn_checkout/qtftp-build-clang-debug/test/unit/qtftpserver && /usr/bin/clang++ -DQT_CORE_LIB -DQT_NETWORK_LIB -std=c++14 -g -fPIE -I/home/winfried/svn_checkout/qtftp-build-clang-debug/test/unit/qtftpserver -I/home/winfried/svn_checkout/qtftp/test/unit/qtftpserver -I/home/winfried/install/gmock_170_clang_debug/include -I/home/winfried/svn_checkout/qtftp/lib/include -I/home/winfried/svn_checkout/qtftp/lib/src -I/home/winfried/svn_checkout/qtftp/test/unit/stubs/include -isystem /home/winfried/install/Qt540/5.4/gcc_64/include -isystem /home/winfried/install/Qt540/5.4/gcc_64/include/QtNetwork -I/home/winfried/install/Qt540/5.4/gcc_64/include/QtCore -I/home/winfried/install/Qt540/5.4/gcc_64/mkspecs/linux-g++ -o CMakeFiles/qtftpserver_ut.dir/qtftpserver_ut.cpp.o -c /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver/qtftpserver_ut.cpp #0 0x7f6e53874f18 llvm::sys::PrintStackTrace(_IO_FILE*) (/usr/bin/../lib64/libLLVMSupport.so+0xa2f18) #1 0x7f6e538763ab (/usr/bin/../lib64/libLLVMSupport.so+0xa43ab) #2 0x7f6e520be200 __restore_rt (/lib64/libc.so.6+0x35200) #3 0x7f6e4f110bee clang::Sema::DeduceFunctionTypeFromReturnExpr(clang::FunctionDecl*, clang::SourceLocation, clang::Expr*&, clang::AutoType*) (/usr/bin/../lib64/../lib64/libclangSema.so+0x35abee) #4 0x7f6e4f1101c6 clang::Sema::ActOnCapScopeReturnStmt(clang::SourceLocation, clang::Expr*) (/usr/bin/../lib64/../lib64/libclangSema.so+0x35a1c6) #5 0x7f6e4f1117a9 clang::Sema::ActOnReturnStmt(clang::SourceLocation, clang::Expr*, clang::Scope*) (/usr/bin/../lib64/../lib64/libclangSema.so+0x35b7a9) #6 0x7f6e4f4caed0 clang::Parser::ParseReturnStatement() (/usr/bin/../lib64/../lib64/libclangParse.so+0x91ed0) #7 0x7f6e4f4c6e9f clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x8de9f) #8 0x7f6e4f4c61cf clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) (/usr/bin/../lib64/../lib64/libclangParse.so+0x8d1cf) #9 0x7f6e4f4cc38f clang::Parser::ParseCompoundStatementBody(bool) (/usr/bin/../lib64/../lib64/libclangParse.so+0x9338f) #10 0x7f6e4f4a524b clang::Parser::ParseLambdaExpressionAfterIntroducer(clang::LambdaIntroducer&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x6c24b) #11 0x7f6e4f4a36d0 clang::Parser::ParseLambdaExpression() (/usr/bin/../lib64/../lib64/libclangParse.so+0x6a6d0) #12 0x7f6e4f497b62 clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) (/usr/bin/../lib64/../lib64/libclangParse.so+0x5eb62) #13 0x7f6e4f493652 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/usr/bin/../lib64/../lib64/libclangParse.so+0x5a652) #14 0x7f6e4f474a1c clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/usr/bin/../lib64/../lib64/libclangParse.so+0x3ba1c) #15 0x7f6e4f472749 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/usr/bin/../lib64/../lib64/libclangParse.so+0x39749) #16 0x7f6e4f46ec97 clang::Parser::ParseSimpleDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*) (/usr/bin/../lib64/../lib64/libclangParse.so+0x35c97) #17 0x7f6e4f46e91d clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x3591d) #18 0x7f6e4f4c6cff clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x8dcff) #19 0x7f6e4f4c61cf clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) (/usr/bin/../lib64/../lib64/libclangParse.so+0x8d1cf) #20 0x7f6e4f4cc38f clang::Parser::ParseCompoundStatementBody(bool) (/usr/bin/../lib64/../lib64/libclangParse.so+0x9338f) #21 0x7f6e4f4ccb26 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x93b26) #22 0x7f6e4f465e9c clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x2ce9c) #23 0x7f6e4f46525a clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x2c25a) #24 0x7f6e4f48b54e clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int, clang::Decl*) (/usr/bin/../lib64/../lib64/libclangParse.so+0x5254e) #25 0x7f6e4f4890a5 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, clang::Parser::ParsedAttributesWithRange&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x500a5) #26 0x7f6e4f46f254 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) (/usr/bin/../lib64/../lib64/libclangParse.so+0x36254) #27 0x7f6e4f4dd9a0 clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/usr/bin/../lib64/../lib64/libclangParse.so+0xa49a0) #28 0x7f6e4f4dd740 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (/usr/bin/../lib64/../lib64/libclangParse.so+0xa4740) #29 0x7f6e4f4dcceb clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/usr/bin/../lib64/../lib64/libclangParse.so+0xa3ceb) #30 0x7f6e4f48374a clang::Parser::ParseInnerNamespace(std::vector >&, std::vector >&, std::vector >&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x4a74a) #31 0x7f6e4f482dbd clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) (/usr/bin/../lib64/../lib64/libclangParse.so+0x49dbd) #32 0x7f6e4f46e749 clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) (/usr/bin/../lib64/../lib64/libclangParse.so+0x35749) #33 0x7f6e4f4dc7ff clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/usr/bin/../lib64/../lib64/libclangParse.so+0xa37ff) #34 0x7f6e4f4dc1a8 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) (/usr/bin/../lib64/../lib64/libclangParse.so+0xa31a8) #35 0x7f6e4f462886 clang::ParseAST(clang::Sema&, bool, bool) (/usr/bin/../lib64/../lib64/libclangParse.so+0x29886) #36 0x7f6e529d7169 clang::FrontendAction::Execute() (/usr/bin/../lib64/libclangFrontend.so+0x93169) #37 0x7f6e529ab563 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/bin/../lib64/libclangFrontend.so+0x67563) #38 0x7f6e52741e82 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/bin/../lib64/libclangFrontendTool.so+0x2e82) #39 0x40c806 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/bin/clang-3.6+0x40c806) #40 0x40bc21 main (/usr/bin/clang-3.6+0x40bc21) #41 0x7f6e520aab05 __libc_start_main (/lib64/libc.so.6+0x21b05) #42 0x40910c _start (/usr/bin/clang-3.6+0x40910c) Stack dump: 0. Program arguments: /usr/bin/clang-3.6 -cc1 -triple x86_64-suse-linux -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name qtftpserver_ut.cpp -mrelocation-model pic -pic-level 2 -pie-level 2 -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -g -dwarf-column-info -coverage-file /home/winfried/svn_checkout/qtftp-build-clang-debug/test/unit/qtftpserver/CMakeFiles/qtftpserver_ut.dir/qtftpserver_ut.cpp.o -resource-dir /usr/bin/../lib64/clang/3.6.0 -isystem /home/winfried/install/Qt540/5.4/gcc_64/include -isystem /home/winfried/install/Qt540/5.4/gcc_64/include/QtNetwork -D QT_CORE_LIB -D QT_NETWORK_LIB -I /home/winfried/svn_checkout/qtftp-build-clang-debug/test/unit/qtftpserver -I /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver -I /home/winfried/install/gmock_170_clang_debug/include -I /home/winfried/svn_checkout/qtftp/lib/include -I /home/winfried/svn_checkout/qtftp/lib/src -I /home/winfried/svn_checkout/qtftp/test/unit/stubs/include -I /home/winfried/install/Qt540/5.4/gcc_64/include/QtCore -I /home/winfried/install/Qt540/5.4/gcc_64/mkspecs/linux-g++ -internal-isystem /usr/bin/../lib64/gcc/x86_64-suse-linux/4.9/../../../../include/c++/4.9 -internal-isystem /usr/bin/../lib64/gcc/x86_64-suse-linux/4.9/../../../../include/c++/4.9/x86_64-suse-linux -internal-isystem /usr/bin/../lib64/gcc/x86_64-suse-linux/4.9/../../../../include/c++/4.9/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib64/clang/3.6.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++14 -fdeprecated-macro -fdebug-compilation-dir /home/winfried/svn_checkout/qtftp-build-clang-debug/test/unit/qtftpserver -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o CMakeFiles/qtftpserver_ut.dir/qtftpserver_ut.cpp.o -x c++ /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver/qtftpserver_ut.cpp 1. /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver/qtftpserver_ut.cpp:40:107: current parser token ';' 2. /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver/qtftpserver_ut.cpp:8:1: parsing namespace 'QTFTP' 3. /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver/qtftpserver_ut.cpp:12:1: parsing struct/union/class body 'TestTftpServer' 4. /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver/qtftpserver_ut.cpp:32:9: parsing function body 'getNetworkStreamBySource' 5. /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver/qtftpserver_ut.cpp:32:9: in compound statement ('{}') 6. /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver/qtftpserver_ut.cpp:33:37: lambda expression parsing 7. /home/winfried/svn_checkout/qtftp/test/unit/qtftpserver/qtftpserver_ut.cpp:34:13: in compound statement ('{}') clang-3.6: error: unable to execute command: Segmentation fault clang-3.6: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.6.0 (tags/RELEASE_360/final 230777) Target: x86_64-suse-linux Thread model: posix clang-3.6: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.6: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.6: note: diagnostic msg: /tmp/qtftpserver_ut-a3b984.cpp clang-3.6: note: diagnostic msg: /tmp/qtftpserver_ut-a3b984.sh clang-3.6: note: diagnostic msg: ******************** make[2]: *** [test/unit/qtftpserver/CMakeFiles/qtftpserver_ut.dir/qtftpserver_ut.cpp.o] Error 254 make[1]: *** [test/unit/qtftpserver/CMakeFiles/qtftpserver_ut.dir/all] Error 2 test/unit/qtftpserver/CMakeFiles/qtftpserver_ut.dir/build.make:54: recipe for target 'test/unit/qtftpserver/CMakeFiles/qtftpserver_ut.dir/qtftpserver_ut.cpp.o' failed make[2]: Leaving directory '/home/winfried/svn_checkout/qtftp-build-clang-debug' CMakeFiles/Makefile2:307: recipe for target 'test/unit/qtftpserver/CMakeFiles/qtftpserver_ut.dir/all' failed make[1]: Leaving directory '/home/winfried/svn_checkout/qtftp-build-clang-debug' Makefile:76: recipe for target 'all' failed make: *** [all] Error 2 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 08:49:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 15:49:03 +0000 Subject: [LLVMbugs] [Bug 23190] New: MSPropertyDeclRefExpr crashes with noexcept Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23190 Bug ID: 23190 Summary: MSPropertyDeclRefExpr crashes with noexcept Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: aaron at aaronballman.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Use of an MSPropertyDeclRefExpr and a noexcept expression causes a failed assertion. e.g.) struct S { __declspec(property(get=getter)) int x; int getter() noexcept(false) { throw "hahaha"; } }; S s; int v = noexcept(s.x); Yields: E:\llvm\2013>clang -cc1 -fsyntax-only -std=c++11 "E:\Aaron Ballman\Desktop\test. cpp" E:\Aaron Ballman\Desktop\test.cpp:11:18: warning: expression with side effects h as no effect in an unevaluated context int v = noexcept(s.x); ^ Invalid class for expression UNREACHABLE executed at E:\llvm\llvm\tools\clang\lib\Sema\SemaExceptionSpec.cpp: 1149! 0x01F280B9 (0x00000016 0x470775EB 0x06AEC77C 0x06AEC708), HandleAbort() + 0x9 by tes(s), e:\llvm\llvm\lib\support\windows\signals.inc, line 290 0x0F5FF7F9 (0x00000016 0x01F280B0 0x06AEC70C 0x01F35BB9), raise() + 0x2B9 bytes( s) 0x0F60B284 (0x06AEE608 0x06AEC77C 0x035B11EC 0x058D9234), abort() + 0x34 bytes(s ) 0x01F35BB9 (0x058D9234 0x058D91FC 0x0000047D 0x06AEC7B8), llvm::llvm_unreachable _internal() + 0x89 bytes(s), e:\llvm\llvm\lib\support\errorhandling.cpp, line 11 7 + 0x8 byte(s) 0x035B11EC (0x006D7EB0 0x06AED768 0xCCCCCCCC 0xCCCCCCCC), clang::Sema::canThrow( ) + 0x55C bytes(s), e:\llvm\llvm\tools\clang\lib\sema\semaexceptionspec.cpp, lin e 1158 0x032E845C (0x06AEC824 0x000000B1 0x006D7EB0 0x000000BD), clang::Sema::BuildCXXN oexceptExpr() + 0x7C bytes(s), e:\llvm\llvm\tools\clang\lib\sema\semaexprcxx.cpp , line 5800 + 0xC byte(s) 0x032E83C6 (0x06AEC824 0x000000B1 0x000000B9 0x006D7EB0), clang::Sema::ActOnNoex ceptExpr() + 0x26 bytes(s), e:\llvm\llvm\tools\clang\lib\sema\semaexprcxx.cpp, l ine 5807 + 0x18 byte(s) 0x02F7E67D (0x06AED798 0x00000000 0x00000000 0x06AED7A7), clang::Parser::ParseCa stExpression() + 0x241D bytes(s), e:\llvm\llvm\tools\clang\lib\parse\parseexpr.c pp, line 1240 + 0x4F byte(s) 0x02F7ED89 (0x06AED7CC 0x00000000 0x00000000 0x00000000), clang::Parser::ParseCa stExpression() + 0x39 bytes(s), e:\llvm\llvm\tools\clang\lib\parse\parseexpr.cpp , line 441 0x02F7B539 (0x06AEDA08 0x00000000 0x00716A58 0x06AEDAE8), clang::Parser::ParseAs signmentExpression() + 0x99 bytes(s), e:\llvm\llvm\tools\clang\lib\parse\parseex pr.cpp, line 170 0x02F6A720 (0x06AEDA08 0x06AEE228 0x06AEE608 0x00000000), clang::Parser::ParseIn itializer() + 0x30 bytes(s), e:\llvm\llvm\tools\clang\include\clang\parse\parser .h, line 1521 + 0xE byte(s) 0x02F554A1 (0x06AEDD98 0x06AEDB4C 0x00000000 0x06AEE2A8), clang::Parser::ParseDe clarationAfterDeclaratorAndAttributes() + 0x501 bytes(s), e:\llvm\llvm\tools\cla ng\lib\parse\parsedecl.cpp, line 1958 0x02F54A59 (0x06AEE5AC 0x06AEE2E0 0x00000000 0x00000000), clang::Parser::ParseDe clGroup() + 0x6B9 bytes(s), e:\llvm\llvm\tools\clang\lib\parse\parsedecl.cpp, li ne 1743 + 0x1F byte(s) 0x02F36455 (0x06AEE5AC 0x06AEE5D4 0x06AEE2E0 0x00000003), clang::Parser::ParseDe clOrFunctionDefInternal() + 0x2D5 bytes(s), e:\llvm\llvm\tools\clang\lib\parse\p arser.cpp, line 893 + 0x16 byte(s) 0x02F36109 (0x06AEE5AC 0x06AEE5D4 0x00000000 0x00000003), clang::Parser::ParseDe clarationOrFunctionDefinition() + 0x89 bytes(s), e:\llvm\llvm\tools\clang\lib\pa rse\parser.cpp, line 909 + 0x1B byte(s) 0x02F35B4C (0x06AEE5AC 0x06AEE5D4 0x00000000 0x06AEE68C), clang::Parser::ParseEx ternalDeclaration() + 0x90C bytes(s), e:\llvm\llvm\tools\clang\lib\parse\parser. cpp, line 767 + 0x16 byte(s) 0x02F32695 (0x06AEE644 0x06AEE734 0x06AEE69C 0x00716A58), clang::Parser::ParseTo pLevelDecl() + 0x205 bytes(s), e:\llvm\llvm\tools\clang\lib\parse\parser.cpp, li ne 569 + 0x12 byte(s) 0x02F30968 (0x00700608 0x00000000 0x00000000 0x06AEE6B8), clang::ParseAST() + 0x 1B8 bytes(s), e:\llvm\llvm\tools\clang\lib\parse\parseast.cpp, line 144 + 0xC by te(s) 0x021D3D21 (0x06AEE6E0 0xCCCCCCCC 0xCCCCCCCC 0xCCCCCCCC), clang::ASTFrontendActi on::ExecuteAction() + 0x101 bytes(s), e:\llvm\llvm\tools\clang\lib\frontend\fron tendaction.cpp, line 538 + 0x30 byte(s) 0x021D390E (0x06AEE7D8 0x00000000 0xCCCCCCCC 0xCCCCCCCC), clang::FrontendAction: :Execute() + 0x7E bytes(s), e:\llvm\llvm\tools\clang\lib\frontend\frontendaction .cpp, line 439 + 0xF byte(s) 0x0218ECA1 (0x006A6890 0x06AEECE0 0x00000000 0xCCCCCCCC), clang::CompilerInstanc e::ExecuteAction() + 0x2A1 bytes(s), e:\llvm\llvm\tools\clang\lib\frontend\compi lerinstance.cpp, line 808 0x022E506E (0x0069A948 0x06AEFA90 0xCCCCCCCC 0xCCCCCCCC), clang::ExecuteCompiler Invocation() + 0x30E bytes(s), e:\llvm\llvm\tools\clang\lib\frontendtool\execute compilerinvocation.cpp, line 222 + 0x11 byte(s) 0x00B6BC22 (0x06AEF678 0x00000003 0x006AB488 0x00AA137F), cc1_main() + 0x302 byt es(s), e:\llvm\llvm\tools\clang\tools\driver\cc1_main.cpp, line 110 + 0xE byte(s ) 0x00B59138 (0x06AEF670 0x00000005 0x006AB492 0x00000000), ExecuteCC1Tool() + 0x7 8 bytes(s), e:\llvm\llvm\tools\clang\tools\driver\driver.cpp, line 369 + 0x2B by te(s) 0x00B594DA (0x00000005 0x00697CE8 0x00694928 0x7F3A4262), main() + 0x2FA bytes(s ), e:\llvm\llvm\tools\clang\tools\driver\driver.cpp, line 415 + 0x33 byte(s) 0x03E98E49 (0x06AEFAF4 0x766A338A 0x7EFDE000 0x06AEFB34), __tmainCRTStartup() + 0x199 bytes(s), f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c, line 626 + 0x19 byte (s) 0x03E98F8D (0x7EFDE000 0x06AEFB34 0x77199F72 0x7EFDE000), mainCRTStartup() + 0xD bytes(s), f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c, line 466 0x766A338A (0x7EFDE000 0x4F1BE5C2 0x00000000 0x00000000), BaseThreadInitThunk() + 0x12 bytes(s) 0x77199F72 (0x03E98F80 0x7EFDE000 0x00000000 0x00000000), RtlInitializeException Chain() + 0x63 bytes(s) 0x77199F45 (0x03E98F80 0x7EFDE000 0x00000000 0x00000000), RtlInitializeException Chain() + 0x36 bytes(s) It seems that the canThrow() function has an llvm_unreachable that is actually reachable. I believe the correct fix is to look through to the getter or setter function the property represents to see if it throws or not. However, it seems that we claim PseudoObjectExprClass never throws (with a FIXME), so a temporary solution may be to move the MSPropertyRefExprClass case to be with the pseudo object one. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 11:03:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 18:03:57 +0000 Subject: [LLVMbugs] [Bug 23178] -g leaks memory In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23178 Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Duncan --- Fixed in r234617. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 11:34:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 18:34:55 +0000 Subject: [LLVMbugs] [Bug 23192] New: gcc 4.9.2 suffers bootstrap comparison failures with clang 3.5.1 and later. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23192 Bug ID: 23192 Summary: gcc 4.9.2 suffers bootstrap comparison failures with clang 3.5.1 and later. Product: clang Version: 3.6 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: howarth.mailing.lists at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The Xcode 6.3 release (with Apple Clang 6.1 compilers based on 3.6.0svn) produces bootstrap comparison failures in the gcc 4.9.2 build on x86_64-apple-darwin14. The same bootstrap comparison failure is also seen on x86_64-apple-darwin13 with Xcode 6.2 but using the llvm.org clang 3.5.1, 3.5.2 or 3.6.0 compilers instead of the Apple Clang 6.0 compilers. Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/asan.o differs gcc/attribs.o differs gcc/bitmap.o differs gcc/c/c-decl.o differs gcc/cfg.o differs gcc/coverage.o differs gcc/cp/class.o differs gcc/cp/semantics.o differs gcc/cp/tree.o differs gcc/dse.o differs gcc/dwarf2out.o differs gcc/except.o differs gcc/fortran/trans-common.o differs gcc/ggc-common.o differs gcc/graphite-clast-to-gimple.o differs gcc/graphite.o differs gcc/ipa-profile.o differs gcc/ira-color.o differs gcc/ira-costs.o differs gcc/java/jcf-io.o differs gcc/loop-unroll.o differs gcc/lto-streamer-in.o differs gcc/lto-streamer-out.o differs gcc/objc/objc-act.o differs gcc/objcp/objcp-act.o differs gcc/passes.o differs gcc/plugin.o differs gcc/postreload-gcse.o differs gcc/statistics.o differs gcc/trans-mem.o differs gcc/tree-cfg.o differs gcc/tree-eh.o differs gcc/tree-ssa-ccp.o differs gcc/tree-ssa-coalesce.o differs gcc/tree-ssa-dom.o differs gcc/tree-ssa-live.o differs gcc/tree-ssa-loop-ivopts.o differs gcc/tree-ssa-phiopt.o differs gcc/tree-ssa-pre.o differs gcc/tree-ssa-reassoc.o differs gcc/tree-ssa-threadupdate.o differs gcc/tree-ssa-uncprop.o differs gcc/tree-vectorizer.o differs gcc/valtrack.o differs gcc/vtable-verify.o differs Makefile:20180: recipe for target 'compare' failed The observation, that the llvm.org clang 3.5.1 or later compilers along side Xcode 6.2 produces the same bootstrap comparison failure, eliminates the cctools changes in Xcode 6.3 as the culprit and points to miscompilation of the stage1 compiler instead. Reducing the optimization of the stage1 bootstrap with STAGE1_CFLAGS="-O0 -g" and STAGE1_CXXFLAGS="-O0 -g" doesn't eliminate the bootstrap comparison failure. Interestingly, current gcc trunk 5.0svn doesn't exhibit the bootstrap comparison failure (with the stock build or using --enable-checking=release). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 12:21:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 19:21:55 +0000 Subject: [LLVMbugs] [Bug 23186] Type correction leads to null dereference In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23186 Kaelyn Takata changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |rikka at google.com |org | --- Comment #1 from Kaelyn Takata --- This has been fixed in r234623. BTW, I'm guessing the null dereference is from a build with assertions disabled; for me the test case caused the following crash while parsing the body of f(): Unknown builtin type! UNREACHABLE executed at ../tools/clang/lib/AST/ASTContext.cpp:1519! [56-frame backtrace & stack dump] -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 12:44:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 19:44:56 +0000 Subject: [LLVMbugs] [Bug 23193] New: std::uncaught_exception() true when it should not be anymore Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23193 Bug ID: 23193 Summary: std::uncaught_exception() true when it should not be anymore Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: alexis at m2osw.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified I wrote a test suite for Zipios++ (https://sourceforge.net/projects/zipios/) using Catch.hpp (https://github.com/philsquared/Catch). There seems to be a problem with std::uncaught_exception() when I run the code under FreeBSD 10.1 with version 3.4.1 of clang. (20140512) The software will throw exceptions that are gobbled in some way (caught), but std::uncaught_exception() continues to return true on normal return. // here std::uncaught_exception() is false run_a_test(); // here std::uncaught_exception() is true One example where I get the problem, a streambuf throws an exception which is caught in the read() function of the iostream implementation (as expected) but then std::uncaught_exception() remains true even though the try/catch should have cleared it. The easiest way to reproduce is to get FreeBSD, compile Zipios++ and run the test suite. With a copy of catch.hpp (single header file) under contrib/... you can just type: dev/build and that will happen. Note that I commented out a certain number of tests at this time. You probably want to edit the tests/catch_zipfile.cpp and remove the `#ifndef __clang__` to make sure you get the errors. Without those guards it is reproducible by just these two or three tests where such appears. Let me know if you need any help with getting things to replicate the problem. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 13:50:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 20:50:27 +0000 Subject: [LLVMbugs] [Bug 23187] Clang cannot consume -Og In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23187 Paul Robinson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |paul_robinson at playstation.s | |ony.com Resolution|--- |DUPLICATE --- Comment #1 from Paul Robinson --- *** This bug has been marked as a duplicate of bug 20765 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 14:04:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 21:04:26 +0000 Subject: [LLVMbugs] [Bug 23194] New: Assertion failed: (isa(D) && "declaration not instantiated in this scope") Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23194 Bug ID: 23194 Summary: Assertion failed: (isa(D) && "declaration not instantiated in this scope") Product: clang Version: trunk Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: howard.hinnant at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Assertion failed: (isa(D) && "declaration not instantiated in this scope"), function findInstantiationOf, file /Users/howardhinnant/Development/llvm/tools/clang/lib/Sema/SemaTemplateInstantiate.cpp, line 2802. Here is a reduced case that comes from real-world code which causes this assert in clang tip-of-trunk: struct X { int operator()() const {return 0;} }; struct Y { Y(int) {} }; template int make_seed_pair() noexcept { struct state_t { X x; Y y{x()}; }; return 0; } int main() { auto s = make_seed_pair(); } Using this command line: clang++ -std=c++11 test.cpp This is a regression. This compiler compiles this example ok: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 14:35:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 21:35:19 +0000 Subject: [LLVMbugs] [Bug 23195] New: Failure to exploit final modifier for pointer to member devirtualization Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23195 Bug ID: 23195 Summary: Failure to exploit final modifier for pointer to member devirtualization Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: listmail at philipreames.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified We appear to be failing to devirtualize a pointer-to-member call when we know that the type of the receiver is a final class. (NOTE: This bug report is based on data collected on a ToT build in early March. I have not confirmed that this still applies to ToT today.) I originally noted this when writing a toy interpreter. Here's a simplified bit of code pulled from that project: struct Interpreter final { typedef void (Interpreter::*BytecodeFuncType)(void *); BytecodeFuncType BytecodeFuncs[NumBytecodes] = { ... }; void dispatch_next(void* stack){ BytecodeFuncType NextFunc = BytecodeFuncs[bytecode[current_index]]; current_index++; (this->*NextFunc)(stack); } }; The important part is this line: (this->*NextFunc)(stack); This is calling a pointer-to-member function where the receiver type is statically known. In particular, we know that "this" is a static type of Interpreter and that, because of the final annotation, there are no other possible dynamic types. We emit LLVM IR that looks like this (after -O3): %13 = load { i64, i64 }* %arrayidx3.i, align 8, !tbaa !10 %.fca.0.extract.i = extractvalue { i64, i64 } %13, 0 %.fca.1.extract.i = extractvalue { i64, i64 } %13, 1 %14 = bitcast %struct.Interpreter* %this to i8* %15 = getelementptr inbounds i8* %14, i64 %.fca.1.extract.i %this.adjusted.i = bitcast i8* %15 to %struct.Interpreter* %16 = and i64 %.fca.0.extract.i, 1 %memptr.isvirtual.i = icmp eq i64 %16, 0 br i1 %memptr.isvirtual.i, label %memptr.nonvirtual.i, label %memptr.virtual.i memptr.virtual.i: ; preds = %_ZNSt6vectorIlSaIlEE9push_backEOl.exit %17 = bitcast i8* %15 to i8** %vtable.i = load i8** %17, align 8, !tbaa !11 %18 = add i64 %.fca.0.extract.i, -1 %19 = getelementptr i8* %vtable.i, i64 %18 %20 = bitcast i8* %19 to void (%struct.Interpreter*, %"class.std::vector"*)** %memptr.virtualfn.i = load void (%struct.Interpreter*, %"class.std::vector"*)** %20, align 8 br label %_ZN11Interpreter13dispatch_nextERSt6vectorIlSaIlEE.exit memptr.nonvirtual.i: ; preds = %_ZNSt6vectorIlSaIlEE9push_backEOl.exit %memptr.nonvirtualfn.i = inttoptr i64 %.fca.0.extract.i to void (%struct.Interpreter*, %"class.std::vector"*)* br label %_ZN11Interpreter13dispatch_nextERSt6vectorIlSaIlEE.exit _ZN11Interpreter13dispatch_nextERSt6vectorIlSaIlEE.exit: ; preds = %memptr.virtual.i, %memptr.nonvirtual.i %21 = phi void (%struct.Interpreter*, %"class.std::vector"*)* [ %memptr.virtualfn.i, %memptr.virtual.i ], [ %memptr.nonvirtualfn.i, %memptr.nonvirtual.i ] tail call void %21(%struct.Interpreter* %this.adjusted.i, %"class.std::vector"* dereferenceable(24) %stack) ret void The virtual dispatch path of this control flow is impossible. Similarly, all of the this adjustment code is unnecessary. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 15:10:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 22:10:58 +0000 Subject: [LLVMbugs] [Bug 23196] New: relocation refers to discarded section Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23196 Bug ID: 23196 Summary: relocation refers to discarded section Product: libraries Version: trunk Hardware: PC OS: Linux Status: ASSIGNED Severity: normal Priority: P Component: MC Assignee: rafael.espindola at gmail.com Reporter: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat test.ll $zed = comdat any @bar = internal global i8 42, comdat($zed) @bah = alias i8* @bar define i8* @foo() { ret i8* @bah } $ cat test2.ll $zed = comdat any @bar = internal global i8 42, comdat($zed) @bah = alias i8* @bar define i8* @foo2() { ret i8* @bah } define i32 @main() { ret i32 0 } $ ./build/bin/llc test2.ll -o test2.o -filetype=obj $ ./build/bin/llc test.ll -o test.o -filetype=obj $ clang test.o test2.o -o foo test2.o:test2.ll:function foo2: warning: relocation refers to discarded section -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 15:11:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 22:11:14 +0000 Subject: [LLVMbugs] [Bug 23197] New: Usage of "-fsyntax-only" in lib Tooling not compatible with cl driver mode Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23197 Bug ID: 23197 Summary: Usage of "-fsyntax-only" in lib Tooling not compatible with cl driver mode Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: bugs.brainlab.eiband at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The string literal "-fsyntax-only" is used in several places of the clang code. However this option is not a valid option in cl mode. Code which uses this literal must be sure that the cl mode is not set. In cl mode the corresponding option is "/Zs". I am using clang tooling on windows in cl mode. The method getClangSyntaxOnlyAdjuster() adds the option "-fsyntax-only" to clang tools without checking for cl mode. Result: A warning is shown that the option "-fsyntax-only" is not supported. Expected result: No warning issued for options which were not specified on the command line. Two alternative changes fixed this issue for me: A) Use "/Zs" instead of "-fsyntax-only" in function getClangSyntaxOnlyAdjuster() when in cl mode. B) Make -fsyntax-only a CoreOption in Options.td. Reading the sources, only options with flags CLOption or CoreOption are valid in cl mode. I am quite new to the LLVM/Clang code so I cannot say how an appropriate fix would look like. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 16:52:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 10 Apr 2015 23:52:01 +0000 Subject: [LLVMbugs] [Bug 23199] New: Discriminators are added to the line table more often than necessary Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23199 Bug ID: 23199 Summary: Discriminators are added to the line table more often than necessary Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedbugs at nondot.org Reporter: dexonsmith at apple.com CC: aprantl at apple.com, dblaikie at gmail.com, dnovillo at google.com, echristo at gmail.com, friss at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified As discussed on the list [1], we add discriminators to line table entries more often than necessary. There may be some downstream users (e.g., Linux perf) depending on the weak checks -- they should be fixed, and then we should fix our code to only add discriminators when the entries can't already be discriminated. Currently, we check: - filename - line We should also check: - column - discriminator - directory I'll add FIXMEs to the code and mention this PR when I transition the current functionality from DILocation over to MDLocation. [1]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150406/270650.html -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 17:34:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Apr 2015 00:34:34 +0000 Subject: [LLVMbugs] [Bug 23200] New: AddDiscriminators and DILocation::computeNewDiscriminator() modifies the LLVMContext inappropriately Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23200 Bug ID: 23200 Summary: AddDiscriminators and DILocation::computeNewDiscriminator() modifies the LLVMContext inappropriately Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedbugs at nondot.org Reporter: dexonsmith at apple.com CC: aprantl at apple.com, dblaikie at gmail.com, dnovillo at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified `DILocation::computeNewDiscriminator()` modifies a table in the LLVMContext indexed by filename/line. This will changes results in other modules created in the same context, and the table doesn't get serialized to bitcode/assembly (so roundtripping will change the results of `computeNewDiscriminator()`). Although it doesn't cause problems for `clang` in practice, this is fairly broken. Fortunately, the fix is simple: move the table (and logic) into `AddDiscriminators::runOnFunction()` and stop modifying the LLVMContext. This table is discriminating between adjacent basic blocks, so it doesn't need global state. I'll add FIXMEs and tag this PR when I move the function over to MDLocation, and hopefully circle back to fix it soon after (if no one beats me to it). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 18:59:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Apr 2015 01:59:48 +0000 Subject: [LLVMbugs] [Bug 19139] explain why a variable is const In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=19139 rtrieu at google.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from rtrieu at google.com --- Fixed in r234677 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 10 19:19:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Apr 2015 02:19:18 +0000 Subject: [LLVMbugs] [Bug 23201] New: getHostCPUName() detects qemu i386 as pentium2 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23201 Bug ID: 23201 Summary: getHostCPUName() detects qemu i386 as pentium2 Product: libraries Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Core LLVM classes Assignee: unassignedbugs at nondot.org Reporter: mgilbert at debian.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This causes problems for mesa and gnome-shell: https://freedesktop.org/patch/34445 This is a regression between llvm 3.4 and 3.5. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 11 03:14:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Apr 2015 10:14:50 +0000 Subject: [LLVMbugs] [Bug 23202] New: Registers are moved around in do{}while(); loop Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23202 Bug ID: 23202 Summary: Registers are moved around in do{}while(); loop Product: libraries Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: www.kostantinaras at yahoo.gr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14189 --> https://llvm.org/bugs/attachment.cgi?id=14189&action=edit The whole function The loop: do{ previous = next; in_pos++; *out_pos++ = previous; if(in_pos == in_limit) goto end; next = *in_pos; }while(previous != next); is translateted with -O2 to: .LBB0_3: # Parent Loop BB0_2 Depth=1 # => This Inner Loop Header: Depth=2 #DEBUG_VALUE: xrle_compress:out <- R14 #DEBUG_VALUE: xrle_compress:repeat <- 1 mov rax, rdi mov rcx, rsi mov r13, rdx add r13, 16 mov qword ptr [rbx], rax cmp r12, rcx je .LBB0_4 # BB#7: # in Loop: Header=BB0_3 Depth=2 #DEBUG_VALUE: xrle_compress:out <- R14 #DEBUG_VALUE: xrle_compress:repeat <- 1 mov rdi, qword ptr [rcx] #DEBUG_VALUE: xrle_compress:next <- RDI lea rsi, qword ptr [rcx + 8] cmp rax, rdi mov rdx, rbx mov rbx, r13 jne .LBB0_3 Notice how many mov instructions are used: -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 11 05:28:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Apr 2015 12:28:27 +0000 Subject: [LLVMbugs] [Bug 23109] clang-cl does not recognize -fno-color-diagnostics In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23109 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |hans at chromium.org Resolution|--- |FIXED --- Comment #3 from Hans Wennborg --- Committed in r234685. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 11 08:45:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Apr 2015 15:45:47 +0000 Subject: [LLVMbugs] [Bug 23203] New: error in backend: SSE register return with SSE disabled Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23203 Bug ID: 23203 Summary: error in backend: SSE register return with SSE disabled Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: blastrock at free.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14190 --> https://llvm.org/bugs/attachment.cgi?id=14190&action=edit The preprocessed file I'm trying to compile some code (in this case its a modified version of string.cpp from libcxx) with SSE disabled (-mno-sse), but this gives me the following error: fatal error: error in backend: SSE register return with SSE disabled clang-3.6: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 3.6.1 Target: x86_64-unknown-linux-gnu Thread model: posix clang-3.6: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.6: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.6: note: diagnostic msg: /tmp/string-117432.cpp clang-3.6: note: diagnostic msg: /tmp/string-117432.sh clang-3.6: note: diagnostic msg: ******************** I'm attaching the preprocessed cpp file (which is different from the one mentioned above since it didn't compile, complaining about using ::int8_t). I reduced the command line to: clang-3.6 "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-target-cpu" "x86-64" "-target-feature" "-sse" "-nobuiltininc" "-O0" "-std=c++0x" "-x" "c++" "string.cpp" -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 11 10:16:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Apr 2015 17:16:35 +0000 Subject: [LLVMbugs] [Bug 23204] New: -Wabsolute-value gives false positives Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23204 Bug ID: 23204 Summary: -Wabsolute-value gives false positives Product: clang Version: 3.6 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: mayer.julian at googlemail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified version is Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn) the new absolute value warning in xcode 4.3 seems bugged it gives a warning on this code: printf("\n\n\n%li\n\n", labs([@"12345" length] - [@"1234567" length])); which outputs "2". it says the labs() is not necessary. however, when removing it the output is -2. so the warning clearly directs users into making wrong code changes... -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 11 11:46:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Apr 2015 18:46:57 +0000 Subject: [LLVMbugs] [Bug 23205] New: Typo in Kaleidoscope 4.3 main text Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23205 Bug ID: 23205 Summary: Typo in Kaleidoscope 4.3 main text Product: Website Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Documentation Assignee: unassignedbugs at nondot.org Reporter: iusellvm at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Section 4.3 contains the code OurFPM.add(new DataLayout(*TheExecutionEngine->getDataLayout())); I think it should be OpenModule->setDataLayout(*NewEngine->getDataLayout()); which is the same as the full code listing at the bottom of the page. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 11 13:25:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 11 Apr 2015 20:25:58 +0000 Subject: [LLVMbugs] [Bug 23192] gcc 4.9.2 suffers bootstrap comparison failures with clang 3.5.1 and later caused by r211272 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23192 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #13 from Dimitry Andric --- (In reply to comment #11) > (In reply to comment #10) > > Do you mind if I close this as a duplicate? > > Sure but why isn't the author of the offending commit added to your bug > report? He is. > Is he aware that the bug was filed? I mailed him earlier, and he asked me to file a PR, which I did. Afterwards, I haven't really seen any activity on the PR. (In reply to comment #12) > Hopefully this issue will get more attention now the Apple's default system > compiler breaks the FSF gcc bootstrap. In FreeBSD ports, we are configuring with --with-build-config=bootstrap-debug as a (hopefully temporary) workaround, see: https://svnweb.freebsd.org/ports?view=revision&revision=375846 But indeed, it would be better if this was solved in LLVM. *** This bug has been marked as a duplicate of bug 22046 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 12 03:23:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Apr 2015 10:23:57 +0000 Subject: [LLVMbugs] [Bug 23206] New: Failling to build compiler-r on fedora Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23206 Bug ID: 23206 Summary: Failling to build compiler-r on fedora Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: bioinfornatics at fedoraproject.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14191 --> https://llvm.org/bugs/attachment.cgi?id=14191&action=edit patch Dear, To be able to build compiler-rt the cmake way need to be enhanced. The current build process will not works if: - you do not have llvm buildir (that is what happen when using llvm pakèckaged by distro) - COMPILER_RT_TEST_TARGET_TRIPLE var is empty I fixed this issue in the submitted patch llvm cmake file are search in the llvm prefix dir instead of the build dir -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 12 04:01:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Apr 2015 11:01:02 +0000 Subject: [LLVMbugs] [Bug 23207] New: bogus error: no matching function for call to ... (candidate template ignored: substitution failure) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23207 Bug ID: 23207 Summary: bogus error: no matching function for call to ... (candidate template ignored: substitution failure) Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: janus at gcc.gnu.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14193 --> https://llvm.org/bugs/attachment.cgi?id=14193&action=edit test case Compiling the attached test code with clang++ logging.cc -std=c++11 results in the following error: logging.cc:58:3: error: no matching function for call to 'create_all_loggers_impl' create_all_loggers_impl::value>(); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ logging.cc:47:32: note: candidate template ignored: disabled by 'enable_if' [with index = 18] inline typename std::enable_if<(index == 0)>::type create_all_loggers_impl() {} ^ logging.cc:51:52: note: candidate template ignored: substitution failure [with index = 18]: non-type template argument is not a constant expression inline typename std::enable_if<(index != 0)>::type create_all_loggers_impl() { ^ 1 error generated. I see the same behaviour with clang 3.4.2 and 3.5.0 (haven't tried other versions), while g++ 4.7 and upward compiles the file just fine. Curiously, if I remove the last logarea ('R') in lines 25 and 28, the error goes away. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 12 07:13:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 12 Apr 2015 14:13:13 +0000 Subject: [LLVMbugs] [Bug 23208] New: c_str() in llvm::sys::RemoveFileOnSignal and llvm::sys::DontRemoveFileOnSignal Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23208 Bug ID: 23208 Summary: c_str() in llvm::sys::RemoveFileOnSignal and llvm::sys::DontRemoveFileOnSignal Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: yaron.keren at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified 1) In the Unix version of these functions, c_str() is being called on all FilesToRemoveRef members but it is not called in the Windows version of these functions. 2) With the exception of locking, shouldn't the Unix and Windows versions be identical? 3) DontRemoveFileOnSignal also calls c_str() so that: // We need to call c_str() on every element which would have been moved by // the erase. These elements, in a C++98 implementation where c_str() // requires a reallocation on the first call may have had the call to c_str() // made on insertion become invalid by being copied down an element. since we don't support C++98 is calling c_str() still required? 4) Related, see patch on llvm-commits, the Windows version of sys::DontRemoveFileOnSignal calls FilesToRemove->push_back(Filename); which seems like a bug. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 00:23:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 07:23:21 +0000 Subject: [LLVMbugs] [Bug 23209] New: expandMOVImm for AArch64 can in rare cases assign an immediate to SP instead the desired WZR pseudo register Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23209 Bug ID: 23209 Summary: expandMOVImm for AArch64 can in rare cases assign an immediate to SP instead the desired WZR pseudo register Product: libraries Version: 3.6 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedbugs at nondot.org Reporter: por at cryptomathic.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hi, I have seen a few cases of expandMOVImm on AArch64 generating an ORRWri instruction writing to SP where WZR was intended, causing crashes at run-time. The problem has been observed with LLVM 3.5.1 and LLVM 3.6.0. The following patch seems to fix it for us: ------------------------- Index: AArch64ExpandPseudoInsts.cpp =================================================================== --- AArch64ExpandPseudoInsts.cpp (revision 125567) +++ AArch64ExpandPseudoInsts.cpp (revision 125568) @@ -398,6 +398,31 @@ // Try a MOVI instruction (aka ORR-immediate with the zero register). uint64_t UImm = Imm << (64 - BitSize) >> (64 - BitSize); uint64_t Encoding; + const unsigned DstReg0 = MI.getOperand(0).getReg(); + + // explicit tests for MOV ZR,imm which *can* be generated by morpher and must be removed, + // it's logically a no-op, but since ZR (x31) is an alias for SP (x31) in many instructions like ORR + // it will clobber the SP... + if (BitSize == 32) { + // moving an immediate to WZR is a logical no-op, remove it + if (DstReg0 == AArch64::WZR) { + MI.eraseFromParent(); + return true; + } + assert(DstReg0 != AArch64::WSP && "Mov imm to WSP forbidden"); + assert(DstReg0 != AArch64::WZR && "Mov imm to WZR forbidden"); + assert(AArch64::GPR32spRegClass.contains(DstReg0) && "Mov dest not 32 bit SP reg class"); + } else { + // moving an immediate to XZR is a logical no-op, remove it + if (DstReg0 == AArch64::XZR) { + MI.eraseFromParent(); + return true; + } + assert(DstReg0 != AArch64::SP && "Mov imm to SP forbidden"); + assert(DstReg0 != AArch64::XZR && "Mov imm to XZR forbidden"); + assert(AArch64::GPR64spRegClass.contains(DstReg0) && "Mov dest not 64 bit SP reg class"); + } + if (AArch64_AM::processLogicalImmediate(UImm, BitSize, Encoding)) { unsigned Opc = (BitSize == 32 ? AArch64::ORRWri : AArch64::ORRXri); MachineInstrBuilder MIB = ---------------------------- -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 01:09:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 08:09:55 +0000 Subject: [LLVMbugs] [Bug 23210] New: ICE on -O2 when using clang {3.7|3.5|3.4} from debian Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23210 Bug ID: 23210 Summary: ICE on -O2 when using clang {3.7|3.5|3.4} from debian Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: juchem at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified -O0 compiles fine clang c.4 and 3.5 also crash when optimizations are on repro: $ clang++-3.7 -O2 -std=c++11 /tmp/ephemeral_rope_test-2c2816.cpp output: Debian clang version 3.7.0-svn230892-1 (trunk) (based on LLVM 3.7.0) Target: x86_64-pc-linux-gnu Thread model: posix Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.9.2 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.4 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 "/usr/lib/llvm-3.7/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name ephemeral_rope_test.cpp -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25 -momit-leaf-frame-pointer -v -g -dwarf-column-info -resource-dir /usr/lib/llvm-3.7/bin/../lib/clang/3.7.0 -D FATAL_USE_CXXABI -I . -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/x86_64-linux-gnu/c++/4.9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/x86_64-linux-gnu/c++/4.9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/backward -internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm-3.7/bin/../lib/clang/3.7.0/include -internal-externc-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -Wall -Werror -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/marcelo/src/fatal -ferror-limit 19 -fmessage-length 0 -pthread -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /tmp/ephemeral_rope_test-8a4927.o -x c++ fatal/string/test/ephemeral_rope_test.cpp clang -cc1 version 3.7.0 based upon LLVM 3.7.0 default target x86_64-pc-linux-gnu ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/x86_64-linux-gnu/c++/4.9" #include "..." search starts here: #include <...> search starts here: . /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/x86_64-linux-gnu/c++/4.9 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/backward /usr/local/include /usr/lib/llvm-3.7/bin/../lib/clang/3.7.0/include /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/include /usr/include/x86_64-linux-gnu /usr/include End of search list. clang: error: unable to execute command: Killed clang: error: clang frontend command failed due to signal (use -v to see invocation) Debian clang version 3.7.0-svn230892-1 (trunk) (based on LLVM 3.7.0) Target: x86_64-pc-linux-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 02:57:37 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 09:57:37 +0000 Subject: [LLVMbugs] [Bug 23211] New: clang doesn't warn when integer is tried against literal that is too big Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23211 Bug ID: 23211 Summary: clang doesn't warn when integer is tried against literal that is too big Product: clang Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: nchambers at dtscode.io CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14195 --> https://llvm.org/bugs/attachment.cgi?id=14195&action=edit Testcase Using the attached testcase, clang doesn't output any warnings when comparing an unsigned int against a literal that is too big in size. Compile Flags: dtscode at dtscode-laptop:~/Desktop$ clang unsigned-test.c -o unsigned-test -Wall -Wextra -pedantic -Wtype-limits dtscode at dtscode-laptop:~/Desktop$ using similar flags in gcc (with the addition of -std=c99 since I'm a few releases behind): dtscode at dtscode-laptop:~/Desktop$ gcc -std=c99 unsigned-test.c -o unsigned-test -Wall -Wextra -pedantic unsigned-test.c: In function ‘main’: unsigned-test.c:5:3: warning: comparison is always true due to limited range of data type [-Wtype-limits] for (unsigned int i=0; i<=4294967295; i++) sum++; ^ dtscode at dtscode-laptop:~/Desktop$ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 04:26:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 11:26:17 +0000 Subject: [LLVMbugs] [Bug 23212] New: Regression: Miscompile with -O1 and -fsanitize=signed-integer-overflow Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23212 Bug ID: 23212 Summary: Regression: Miscompile with -O1 and -fsanitize=signed-integer-overflow Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: jonathan.sauer at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following program should print 1, and it does so when compiled with clang r234732 and either -O1 or -fsanitize=signed-integer-overflow. However, when compiled with both -O1 *and* -fsanitize=signed-integer-overflow, it prints 0. #include int flipSign(unsigned int t) { return -int(t); } int main() { std::printf("%d\n", -2 == flipSign(2)); } % ~/LLVM/build/Release+Asserts/bin/clang++ -O1 clang.cpp && ./a.out 1 % ~/LLVM/build/Release+Asserts/bin/clang++ -fsanitize=signed-integer-overflow clang.cpp && ./a.out 1 % ~/LLVM/build/Release+Asserts/bin/clang++ -O1 -fsanitize=signed-integer-overflow clang.cpp && ./a.out 0 When compiled with clang r234147, it always prints 1. So does removing the explicit cast to "int" in "flipSign". The miscompile also happens with higher optimization levels, e.g. -O2, -O3 and -Os. Detailed clang version: clang version 3.7.0 (trunk 234732) Target: x86_64-apple-darwin13.4.0 Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 04:43:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 11:43:52 +0000 Subject: [LLVMbugs] [Bug 23213] New: Failure to hoist loop invariant Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23213 Bug ID: 23213 Summary: Failure to hoist loop invariant Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: bigcheesegs at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14196 --> https://llvm.org/bugs/attachment.cgi?id=14196&action=edit Original C++ Code LLVM fails to properly optimize the attached code from Mike Acton's talk "How to Write Code the Compiler Can Actually Optimize". The issue is that Foo::Bar is inlined into Foo::Baz before Foo::Bar has been optimized, and LICM/SCEV can't handle the resulting double loop. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 08:48:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 15:48:45 +0000 Subject: [LLVMbugs] [Bug 23214] New: [META] Using LLD as FreeBSD's system linker Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23214 Bug ID: 23214 Summary: [META] Using LLD as FreeBSD's system linker Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: emaste at freebsd.org CC: llvmbugs at cs.uiuc.edu Depends on: 22906, 23024, 23035 Classification: Unclassified This is a meta-bug to track dependencies needed for LLD to be functional as FreeBSD's system linker. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 09:47:44 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 16:47:44 +0000 Subject: [LLVMbugs] [Bug 23215] New: Pure virtual warning for qualified calls Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23215 Bug ID: 23215 Summary: Pure virtual warning for qualified calls Product: clang Version: 3.6 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: alexandermbock at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified struct A { virtual void f() = 0; A() { A::f(); } }; clang emits: warning: call to pure virtual member function 'f'; overrides of 'f' in subclasses are not available in the constructor of 'A' A::f(); ^ This warning does not make sense for a qualified (non-virtual) call. Overrides will not be considered and the linker will enforce the existence of a definition. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 10:50:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 17:50:24 +0000 Subject: [LLVMbugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 23035, which changed state. Bug 23035 Summary: lld reports "Undefined symbol" for shared lib's dependencies https://llvm.org/bugs/show_bug.cgi?id=23035 What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 10:50:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 17:50:24 +0000 Subject: [LLVMbugs] [Bug 23035] lld reports "Undefined symbol" for shared lib's dependencies In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23035 emaste at freebsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #3 from emaste at freebsd.org --- Reapplied in r234553 with test case update -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 12:17:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 19:17:45 +0000 Subject: [LLVMbugs] [Bug 23212] Regression: Miscompile with -O1 and -fsanitize=signed-integer-overflow In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23212 Nick Lewycky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nlewycky at google.com Resolution|--- |FIXED --- Comment #1 from Nick Lewycky --- Fixed in r234780. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 12:26:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 19:26:11 +0000 Subject: [LLVMbugs] [Bug 23216] New: Regression: "llvm.frameescape used outside of entry block" with -Os for some __try blocks Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23216 Bug ID: 23216 Summary: Regression: "llvm.frameescape used outside of entry block" with -Os for some __try blocks Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14198 --> https://llvm.org/bugs/attachment.cgi?id=14198&action=edit repro clang "-cc1" "-triple" "x86_64-pc-windows-msvc" "-emit-obj" "-Os" "-w" "-std=c++11" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=18.0" "-fdelayed-template-parsing" "-x" "c++" "repro.ii.ok" Half-reduced test case attached. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 13:53:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 20:53:43 +0000 Subject: [LLVMbugs] [Bug 23217] New: Inefficient unrolling in vectorization pass when VF==1 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23217 Bug ID: 23217 Summary: Inefficient unrolling in vectorization pass when VF==1 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedbugs at nondot.org Reporter: wmi at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14199 --> https://llvm.org/bugs/attachment.cgi?id=14199&action=edit bad.s We found the unrolling in loop vectorization pass when VF==1 was inefficient when analyzing an internal benchmark. The simple testcase 1.c here is used to show the problem: 1.c: int a[1000], N; void foo() { long i; for (i = 0; i < N; i++) { a[i*7] = 3; } } ~/workarea/llvm-r234389/build/bin/clang -O2 -S 1.c In loop vectorization pass, VF=1 and UF=2 are computed for the above loop. Because VF==1, no vectorization will be done, but the loop will still be unrolled by a factor of two. A remainder loop will be generated. In loop unroll pass, the unrolled loop body will be unrolled another time by a factor of two. The remainder loop will be unrolled by a factor of four. Two extra loop prologues and a bunch of other checks will be generated. See the bad.s attached. If we disabled the unrolling in loop vectorization pass when VF==1, loop unroll pass will do unrolling for the above loop by a factor of four all at once and generate much less extra code like prologue and overflow checks. See the good.s attached. We experimentally disabled the unrolling in loop vectorization pass and saw the internal benchmark improved 5% on sandybridge and 9% on westmere. Google ref b/19469562 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 15:26:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 22:26:00 +0000 Subject: [LLVMbugs] [Bug 23218] New: Enable thread sanitizer for PPC64 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23218 Bug ID: 23218 Summary: Enable thread sanitizer for PPC64 Product: libraries Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedbugs at nondot.org Reporter: wschmidt at linux.vnet.ibm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The thread sanitizer is not currently enabled for the PowerPC target. There are some memory configuration issues that need to be dealt with before this can be done. It would be good to have this working. IBM is considering opening a bounty on this item. If this occurs, the acceptance criteria would be for the thread sanitizer to be enabled with all tests passing for PPC64 BE and LE buildbots (targets powerpc64[le]-linux-gnu). I will post here if and when a bounty is posted. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 15:28:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 22:28:48 +0000 Subject: [LLVMbugs] [Bug 23219] New: Enable memory sanitizer for PPC64 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23219 Bug ID: 23219 Summary: Enable memory sanitizer for PPC64 Product: libraries Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedbugs at nondot.org Reporter: wschmidt at linux.vnet.ibm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The memory sanitizer is not currently enabled for the PowerPC target. It would be good to have this working. IBM is considering opening a bounty on this item. If this occurs, the acceptance criteria would be for the memory sanitizer to be enabled with all tests passing for PPC64 BE and LE buildbots (targets powerpc64[le]-linux-gnu). I will post here if and when a bounty is posted. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 13 16:23:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 13 Apr 2015 23:23:41 +0000 Subject: [LLVMbugs] [Bug 23220] New: r234581 broke a test in Chromium Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23220 Bug ID: 23220 Summary: r234581 broke a test in Chromium Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified With r234581, `out\Release\sbox_integration_tests.exe --gtest_filter=ProcessMitigationsTest.CheckDep` fails. I tried building all .obj files with both r234581 applied and reverted, and the only .obj file that makes a difference is the one for sandbox/win/src/broker_services.cc. ( https://code.google.com/p/chromium/codesearch#chromium/src/sandbox/win/src/broker_services.cc&q=broker_services.cc&sq=package:chromium&type=cs ) I'm attaching the assembly output from each clang to this bug. Labels are different everywhere, but code is really only different for 4 functions: * BrokerServicesBase::SpawnTarget * BrokerServicesBase::AddTargetPeer (looks harmless?) * BrokerServicesBase::InstallAppContainer * BrokerServicesBase::UninstallAppContainer The first function has the most differences. I'll debug some more later. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 01:53:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 08:53:04 +0000 Subject: [LLVMbugs] [Bug 15581] ARM: GMP 5.1.1 'make check' fails with optimization levels >= -O0 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15581 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Anton Korobeynikov --- (In reply to comment #11) > Right. Would be good if Dmitry committed his regression test for this. > Otherwise, it is fixed. Fixed then. Please reopen if there is still an issue. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 01:58:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 08:58:48 +0000 Subject: [LLVMbugs] [Bug 23222] New: override error Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23222 Bug ID: 23222 Summary: override error Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: jim at cernproductions.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 02:15:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 09:15:05 +0000 Subject: [LLVMbugs] [Bug 23223] New: clang 3.6 segmentation fault Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23223 Bug ID: 23223 Summary: clang 3.6 segmentation fault Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: blastrock at free.fr CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Clang crashes with the attached preprocessed source. The code is not correct and fixing the errors avoids the crash, but still :) Compile with: "clang-3.6" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "test2impl.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" "-g" "-dwarf-column-info" "-D" "test2_EXPORTS" "-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length" "0" "-mstackrealign" "-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-x" "c++" "test2impl-c04fd2.cpp" -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 03:02:38 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 10:02:38 +0000 Subject: [LLVMbugs] [Bug 23222] override error In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23222 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 07:41:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 14:41:48 +0000 Subject: [LLVMbugs] [Bug 23226] New: Missed optimisation - memcpy is not removed Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23226 Bug ID: 23226 Summary: Missed optimisation - memcpy is not removed Product: new-bugs Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: nick at indigorenderer.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The memcpy on line 24 is not optimised away. It is not completely dead - there is a read from the destination memory region on line 26 and 27. It could be optimised to remove the memcpy, and just read from the source memory instead. Note that the only reason I'm using memcpy in the first place is because load and stores for array types produce terrible code and/or kill llvm compilation. Code paste with line numbers here: http://pastie.org/10089845 Please let me know if anyone wants more information - I can provide some context of what I am trying to do etc.. if needed. The IR is from LLVM 3.4 but the problem still exists with 3.6. ; ModuleID = 'WinterModule' target datalayout = "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" ; Function Attrs: nounwind declare void @llvm.memcpy.p0i8.p0i8.i32(i8* nocapture, i8* nocapture readonly, i32, i32, i1) #0 ; Function Attrs: nounwind define void @main_array_int__256___array_int__256__([256 x i32]* noalias nocapture sret %ret, [256 x i32]* noalias nocapture readonly %vals, [256 x i32]* noalias nocapture readonly %b) #0 { entry: %"New running state.i" = alloca [256 x i32], align 4 %"Running state.i" = alloca [256 x i32], align 4 %0 = bitcast [256 x i32]* %"New running state.i" to i8* call void @llvm.lifetime.start(i64 1024, i8* %0) #0 %1 = bitcast [256 x i32]* %"Running state.i" to i8* call void @llvm.lifetime.start(i64 1024, i8* %1) #0 %2 = bitcast [256 x i32]* %b to i8* call void @llvm.memcpy.p0i8.p0i8.i32(i8* %0, i8* %2, i32 1024, i32 4, i1 false) #0 br label %loop.i loop.i: ; preds = %loop.i, %entry %indvars.iv.i = phi i64 [ %indvars.iv.next.i, %loop.i ], [ 0, %entry ] %"array elem ptr.i" = getelementptr inbounds [256 x i32]* %vals, i64 0, i64 %indvars.iv.i %"array elem.i" = load i32* %"array elem ptr.i", align 4 call void @llvm.memcpy.p0i8.p0i8.i32(i8* %1, i8* %0, i32 1024, i32 4, i1 false) #0 %3 = sext i32 %"array elem.i" to i64 %4 = getelementptr inbounds [256 x i32]* %"Running state.i", i64 0, i64 %3 %5 = load i32* %4, align 4 %6 = add i32 %5, 1 %"new elem ptr.i.i.i" = getelementptr inbounds [256 x i32]* %"New running state.i", i64 0, i64 %3 store i32 %6, i32* %"new elem ptr.i.i.i", align 4 %indvars.iv.next.i = add nuw nsw i64 %indvars.iv.i, 1 %exitcond.i = icmp eq i64 %indvars.iv.next.i, 256 br i1 %exitcond.i, label %fold_function_array_int__256___int__array_int__256____array_int__256___array_int__256__.exit, label %loop.i fold_function_array_int__256___int__array_int__256____array_int__256___array_int__256__.exit: ; preds = %loop.i %7 = bitcast [256 x i32]* %ret to i8* call void @llvm.memcpy.p0i8.p0i8.i32(i8* %7, i8* %0, i32 1024, i32 4, i1 false) #0 call void @llvm.lifetime.end(i64 1024, i8* %0) #0 call void @llvm.lifetime.end(i64 1024, i8* %1) #0 ret void } ; Function Attrs: nounwind declare void @llvm.lifetime.start(i64, i8* nocapture) #0 ; Function Attrs: nounwind declare void @llvm.lifetime.end(i64, i8* nocapture) #0 attributes #0 = { nounwind } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 10:34:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 17:34:19 +0000 Subject: [LLVMbugs] [Bug 23227] New: MCExpr evaluation shouldn't always be signed Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23227 Bug ID: 23227 Summary: MCExpr evaluation shouldn't always be signed Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedbugs at nondot.org Reporter: ahmed.bougacha at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Consider: echo 'movz x1, ((0xfffffffffffffffc & 0xffff000000000000) >> 48), LSL #48' | llvm-mc -arch aarch64 :1:10: error: immediate must be an integer in range [0, 65535]. movz x1, ((0xfffffffffffffffc & 0xffff000000000000) >> 48), LSL #48 That's not true with a logical shift, but MCExpr evaluation works on int64_t, and propagates the "sign" bit. There's a FIXME for this, but, to my knowledge, no PR: // FIXME: We need target hooks for the evaluation. It may be limited in // width, and gas defines the result of comparisons and right shifts // differently from Apple as. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 12:00:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 19:00:42 +0000 Subject: [LLVMbugs] [Bug 23228] New: RuntimeDyldCOFF should handle relocations for external symbols Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23228 Bug ID: 23228 Summary: RuntimeDyldCOFF should handle relocations for external symbols Product: libraries Version: trunk Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: Generic Execution Engine Support Assignee: unassignedbugs at nondot.org Reporter: lhames at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified RuntimeDyldCOFF does not currently handle relocations for external symbols (see addRelocationForSymbol). In MCJIT and Orc this causes failures when bitcode containing references to external symbols is JIT'd on Windows. Manoel Teixeira brought this to my attention, as he has run in to it while bringing up a new JIT. In the short term this can be worked around by pre-resolving symbols and baking their addresses into the bitcode. Unfortunately that prevents use of object caches, and in the future may be a barrier to JIT debugging support. In the longer term it would be great to get support for external symbols. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 12:20:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 19:20:55 +0000 Subject: [LLVMbugs] [Bug 5680] bitcode files do not preserve order of use lists In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=5680 Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Duncan --- I turned this on by default in r234510, then reversed course [1] with r234919, r234920 (clang), and r234921. Also cleaned up the output of `verify-uselistorder` in r234929. Now it's on by default for `clang -save-temps`, `clang -emit-llvm`, and for all the LLVM tools I found that output bitcode. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084468.html -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 12:55:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 19:55:26 +0000 Subject: [LLVMbugs] [Bug 23229] New: Assertion failed: ((PartVT.isInteger() || PartVT == MVT::x86mmx) && ValueVT.isInteger() && "Unknown mismatch!"), function getCopyToParts Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23229 Bug ID: 23229 Summary: Assertion failed: ((PartVT.isInteger() || PartVT == MVT::x86mmx) && ValueVT.isInteger() && "Unknown mismatch!"), function getCopyToParts Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified As reported in https://bugs.freebsd.org/199450, clang crashes with the following assertion failure in SpiderMonkey's FoldConstants.cpp file, when compiled for the armv6--freebsd11.0-gnueabihf target: Assertion failed: ((PartVT.isInteger() || PartVT == MVT::x86mmx) && ValueVT.isInteger() && "Unknown mismatch!"), function getCopyToParts, file /share/dim/src/llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp, line 399. This also reproduces with clang trunk r234702. Reduced test case is: ====================================================================== a, b, c, d; double e; fn1() { asm("" : "=r"(a), "=&r"(b), "=&r"(c), "=&r"(d), "=&r"(e) : "4"(e)); } ====================================================================== Compile with: clang -cc1 -triple armv6 -emit-obj -target-cpu arm1176jzf-s testcase.c Note: the target-cpu setting is essential to trigger this assert. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 13:19:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 20:19:12 +0000 Subject: [LLVMbugs] [Bug 18653] Abort after class declaration as template argument In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18653 Simbad changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |slipperysimbad at gmail.com Resolution|--- |FIXED --- Comment #3 from Simbad --- $ clang++ -c -std=c++11 declbug.cpp $ clang++ --version clang version 3.7.0 (trunk 232330) (llvm/trunk 232335) Target: x86_64-unknown-linux-gnu Thread model: posix I can no longer reproduce this bug. Closing resolved. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 13:51:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 20:51:55 +0000 Subject: [LLVMbugs] [Bug 23230] New: asan/TestCases/strtol_strict.c is sensitive to heap content Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23230 Bug ID: 23230 Summary: asan/TestCases/strtol_strict.c is sensitive to heap content Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: hjl.tools at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified asan/TestCases/strtol_strict.c has void test3(char *array, char *endptr) { // Buffer overflow if base is invalid. long r = strtol(array - 1, NULL, -1); assert(r == 0); } ... int main(int argc, char **argv) { char *array = (char*)malloc(3); char *endptr = NULL; array[0] = '1'; array[1] = '2'; array[2] = '3'; ... if (!strcmp(argv[1], "test3")) test3(array, endptr); // CHECK3: {{.*ERROR: AddressSanitizer: heap-buffer-overflow on address}} // CHECK3: READ of size 5 When array[-1] happens to be '\0', we will get READ of size 1 at 0x60200000efef thread T0 instead of READ of size 5 at 0x60200000efef thread T0 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 13:59:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 20:59:57 +0000 Subject: [LLVMbugs] [Bug 23216] Regression: "llvm.frameescape used outside of entry block" with -Os for some __try blocks In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23216 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |FIXED --- Comment #1 from Reid Kleckner --- Thanks, I fixed the inliner in r234937 and relanded in r234942. Let's see if bots like it. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 14:03:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 21:03:53 +0000 Subject: [LLVMbugs] [Bug 23231] New: support symbol version script / --version-script option Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23231 Bug ID: 23231 Summary: support symbol version script / --version-script option Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: emaste at freebsd.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified A useful blog post at http://www.airs.com/blog/archives/300 GNU ld description: --version-script=version-scriptfile Specify the name of a version script to the linker. This is typically used when creating shared libraries to specify additional information about the version hierarchy for the library being created. This option is only meaningful on ELF platforms which support shared libraries. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 14:06:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 21:06:19 +0000 Subject: [LLVMbugs] [Bug 23232] New: implement -x and -X options, delete all local / temporary local symbols Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23232 Bug ID: 23232 Summary: implement -x and -X options, delete all local / temporary local symbols Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: emaste at freebsd.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified GNU ld description: -x --discard-all Delete all local symbols. -X --discard-locals Delete all temporary local symbols. (These symbols start with system-specific local label prefixes, typically .L for ELF systems or L for traditional a.out systems.) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 14:09:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 21:09:03 +0000 Subject: [LLVMbugs] [Bug 23233] New: implement --dynamic-linker override option Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23233 Bug ID: 23233 Summary: implement --dynamic-linker override option Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: emaste at freebsd.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Required for the FreeBSD base system build. GNU ld description: --dynamic-linker file Set the name of the dynamic linker. This is only meaningful when generating dynamically linked ELF executables. The default dynamic linker is normally correct; don't use this unless you know what you are doing. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 16:50:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 14 Apr 2015 23:50:50 +0000 Subject: [LLVMbugs] [Bug 23234] New: Link error with variable template Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23234 Bug ID: 23234 Summary: Link error with variable template Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangbugs at nondot.org Reporter: ldionne.2 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code does not link with Clang r234717: ------------------------------------------------------------------------------ struct f { void operator()() const { } }; template auto vtemplate = f{}; int main() { vtemplate(); } ------------------------------------------------------------------------------ Something curious is that replacing auto vtemplate = f{}; by f vtemplate{}; resolves the problem. Also note that I think the problem was introduced recently, because I could almost swear that this compiled fine about a week ago. The exact output is: › ~/code/llvm/release/bin/clang++ -std=c++1y ~/code/hana/test/worksheet.cpp Undefined symbols for architecture x86_64: "vtemplate", referenced from: _main in worksheet-0a36a3.o ld: symbol(s) not found for architecture x86_64 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 17:10:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 00:10:17 +0000 Subject: [LLVMbugs] [Bug 23235] New: Multiple races reported in std::async (TSan) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23235 Bug ID: 23235 Summary: Multiple races reported in std::async (TSan) Product: libc++ Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: oleg at smolsky.net CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified Created attachment 14204 --> https://llvm.org/bugs/attachment.cgi?id=14204&action=edit TSan output I've just noticed TSan warnings when using std::async on Linux. A small example is below. Compiled with Clang 3.6 and linked against an instrumented version of libc++: /opt/clang36/bin/clang++ -std=c++14 -g -fno-omit-frame-pointer -fsanitize=thread -stdlib=libc++ -fcolor-diagnostics future.cpp -Wl,-rpath /opt/clang36/lib-tsan -lc++abi -o future #include #include #include #include std::atomic _counter; int main() { _counter = 1; auto f = std::async(std::launch::async, []{ _counter += 2; return true; }); std::cout << "Result: " << std::boolalpha << f.get() << "\n"; return 0; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 18:08:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 01:08:52 +0000 Subject: [LLVMbugs] [Bug 23234] Link error with variable template In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23234 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- Should be fixed in r234961. Want to post-commit review that, David, since I managed to break it once already? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 14 22:02:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 05:02:02 +0000 Subject: [LLVMbugs] [Bug 21743] machine copy propagation kills ABI-related copies on win64 (atom?) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21743 vtjnash at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME |--- --- Comment #7 from vtjnash at gmail.com --- Alright, someone found a new test case for this one. (reproducible on llvm3.5 through svn commit r234975+) The full (runnable) example is captured at https://gist.github.com/vtjnash/80a2aa73f04e33ec13b2 In particular, we are interested in the following lines: callq *%rax vmovapd %xmm0, %xmm6 vxorps %xmm0, %xmm0, %xmm0 vcvtsi2sdq %rsi, %xmm0, %xmm7 movl $339772768, %eax # imm = 0x14408560 # kill: XMM0 XMM6 vmovaps %xmm7, %xmm1 callq *%rax Per the win64 calling convention, the argument value got returned in xmm0, and should be passed to the next function, still in xmm0. However, we see that this value is getting listed in the 'kill' comment (after getting zero'd by the vxorps instruction, but before being used by the second function call) Adding -disable-copyprop replaces the 'kill' comment with the missing `vmovapd %xmm6, %xmm0` instruction (and makes no other changes to the output) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 02:03:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 09:03:40 +0000 Subject: [LLVMbugs] [Bug 23237] New: fatal error: error in backend: Cannot select: intrinsic %llvm.x86.sse2.mfence Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23237 Bug ID: 23237 Summary: fatal error: error in backend: Cannot select: intrinsic %llvm.x86.sse2.mfence Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: paulepanter at users.sourceforge.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14205 --> https://llvm.org/bugs/attachment.cgi?id=14205&action=edit Preprocessed source Using Building a coreboot [1] firmware image for an AGESA board like the ASRock E350M1, it fails with the following error. Please note, that I needed to apply the patch with the work-around from bug 21538 [2] to get it past another error. ------ 8< ---- >8 ------ $ make […] CC vendorcode/amd/agesa/f14/Lib/amdlib.libagesa.o fatal error: error in backend: Cannot select: intrinsic %llvm.x86.sse2.mfence clang: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 3.7.0 (http://llvm.org/git/clang.git 111e330648f7da9910029bf4e1bc4547dbd8f43f) (http://llvm.org/git/llvm.git 058309ba87896d28a995118f5415011caa97cfbe) Target: i386--linux-elf Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/amdlib-8ab3eb.c clang: note: diagnostic msg: /tmp/amdlib-8ab3eb.sh clang: note: diagnostic msg: ******************** Makefile:250: recipe for target 'build/vendorcode/amd/agesa/f14/Lib/amdlib.libagesa.o' failed make: *** [build/vendorcode/amd/agesa/f14/Lib/amdlib.libagesa.o] Error 70 ------ 8< ---- >8 ------ Please find amdlib-8ab3eb.c attached. [1] http://www.coreboot.org [2] https://llvm.org/bugs/show_bug.cgi?id=21538 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 03:05:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 10:05:32 +0000 Subject: [LLVMbugs] [Bug 23197] Usage of "-fsyntax-only" in lib Tooling not compatible with cl driver mode In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23197 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 05:11:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 12:11:00 +0000 Subject: [LLVMbugs] [Bug 23238] New: __cxa_new_handler missing in libc++abi from 3.6 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23238 Bug ID: 23238 Summary: __cxa_new_handler missing in libc++abi from 3.6 Product: libc++abi Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: jeremyhu at apple.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified libc++abi from the 3.6.0 tarball is not binary compatible with older versions and will break the system if installed on OSX. I noticed this when updating libcxxabi in MacPorts. libc++abi from 3.5.1 contains the symbol ___cxa_new_handler whereas 3.6.0 contains the C++ mangled symbol __ZSt17__cxa_new_handler instead -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 07:32:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 14:32:47 +0000 Subject: [LLVMbugs] [Bug 23240] New: Less efficient stack adjustment code with -g Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23240 Bug ID: 23240 Summary: Less efficient stack adjustment code with -g Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: russell_gallop at sn.scee.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Enabling debug info results in larger code at address 0x13. Without -g a 1 byte pop instruction is used, with -g a 4 byte add is used to adjust the stack pointer. Guessing that this is in the X86 backend. Reduced from Burg in the llvm-test-suite. With revision r234984. $ cat lex.c int a; int fn2(); int fn1() { int b; if ((b = fn2()) == '\n') a++; return b; } $ clang -c -O1 lex.c -o lex.o && objdump -d lex.o lex.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: 50 push %rax 1: 31 c0 xor %eax,%eax 3: e8 00 00 00 00 callq 8 8: 83 f8 0a cmp $0xa,%eax b: 75 06 jne 13 d: ff 05 00 00 00 00 incl 0x0(%rip) # 13 13: 5a pop %rdx 14: c3 retq $ clang -c -O1 lex.c -o lex_g.o -g && objdump -d lex_g.o lex_g.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: 50 push %rax 1: 31 c0 xor %eax,%eax 3: e8 00 00 00 00 callq 8 8: 83 f8 0a cmp $0xa,%eax b: 75 06 jne 13 d: ff 05 00 00 00 00 incl 0x0(%rip) # 13 13: 48 83 c4 08 add $0x8,%rsp 17: c3 retq -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 09:51:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 16:51:36 +0000 Subject: [LLVMbugs] [Bug 23238] __cxa_new_handler missing in libc++abi from 3.6 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23238 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Reid Kleckner --- Sounds good, so fixed in r235013. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 10:18:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 17:18:54 +0000 Subject: [LLVMbugs] [Bug 22357] missed opportunities in reassociation or instcombine In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22357 Jingyue Wu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jingyue Wu --- r234855 takes an initial step of tackling the general problem behind this bug. Mark this bug as resolved. Feel free to reopen or contribute to NaryReassociate when the current implementation is not enough. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 13:36:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 20:36:58 +0000 Subject: [LLVMbugs] [Bug 23242] New: [ms] __declspec(selectany) not handled correctly for extern "C" symbols Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23242 Bug ID: 23242 Summary: [ms] __declspec(selectany) not handled correctly for extern "C" symbols Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This compiles and links with both cl and clang-cl: __declspec(selectany) int ChromeEnableBits[1]; int main() { return ChromeEnableBits[0]; } This compiles and links fine with cl: extern "C" __declspec(selectany) int ChromeEnableBits[1]; int main() { return ChromeEnableBits[0]; } With clang-cl: D:\src\llvm-ninja-rel64>bin\clang-cl foo.cc foo-ac216e.obj : error LNK2019: unresolved external symbol ChromeEnableBits referenced in function main foo.exe : fatal error LNK1120: 1 unresolved externals clang-cl.exe: error: linker command failed with exit code 1120 (use -v to see invocation) Code like this is created by mc.exe, msvs's message compiler. So it's important to match cl.exe here. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 14:33:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 21:33:18 +0000 Subject: [LLVMbugs] [Bug 22653] Add a weak/strong flag to RuntimeDyld's symbol table. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22653 Lang Hames changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Lang Hames --- This was fixed by r231724. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 14:35:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 21:35:45 +0000 Subject: [LLVMbugs] [Bug 15729] RuntimeDyld doesn't handle calls to external functions from MachO objects In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15729 Lang Hames changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Lang Hames --- I'm going to close this - As far as I'm aware there's no longer any issues with external symbol resolution in MachO, and we use it fairly regularly these days. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 14:50:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 21:50:17 +0000 Subject: [LLVMbugs] [Bug 23242] [ms] __declspec(selectany) not handled correctly for extern "C" symbols In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23242 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nico Weber --- r235046 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 15:01:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 22:01:20 +0000 Subject: [LLVMbugs] [Bug 23243] New: [ms] crash on __declspec(selectany) in .c file Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23243 Bug ID: 23243 Summary: [ms] crash on __declspec(selectany) in .c file Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This crashes if it's in a .c file (but works in a .cc file): __declspec(selectany) int x3; 'common' global may not be in a Comdat! i32* @x3 fatal error: error in backend: Broken module found, compilation aborted! Found while investigating r235046, but not caused by it. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 15:20:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 22:20:39 +0000 Subject: [LLVMbugs] [Bug 23244] New: [QoI] Improve failure when trying to bind float types to integer registers for IAS in hardfp mode Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23244 Bug ID: 23244 Summary: [QoI] Improve failure when trying to bind float types to integer registers for IAS in hardfp mode Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedbugs at nondot.org Reporter: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Test case from Firefox: int a, b, c, d, g, h, i; double e; struct A { static int m_fn1(int) { asm("" : "=r"(a), "=&r"(b), "=&r"(c), "=&r"(d), "=&r"(e) : "4"(e)); } }; struct Shuffle { static int m_fn2(int) { A::m_fn1(0); } } *f; template void FuncShuffle(int *, unsigned, int *) { f[Shuffle::m_fn2(0)]; } void simd_int32x4_shuffleMix() { FuncShuffle(&g, h, &i); } This currently fails with an assertion (SelectionDAGBuilder.cpp:398, void getCopyToParts(llvm::SelectionDAG&, llvm::SDLoc, llvm::SDValue, llvm::SDValue*, unsigned int, llvm::MVT, const llvm::Value*, llvm::ISD::NodeType): Assertion `(PartVT.isInteger() || PartVT == MVT::x86mmx) && ValueVT.isInteger() && "Unknown mismatch!"' failed). It should be properly detected. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 15:31:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 22:31:05 +0000 Subject: [LLVMbugs] [Bug 22778] Remove the inlinedAt: field from DI/MDLocalVariable In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22778 Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Duncan --- Fixed as of r235050, via the following: r234019 = 2d2520986ead1d49503cbef0394c843a7adcc2b2 r234021 = b0d0a65e1d5635ae53a09bc6cd9691c817fefe61 r234026 = 9dcb78c67661d175bf60dd01ce9e1dbc349f632f r234038 = f4f021c0a40fd1db3bbcf6cf14c4a4476fee268c r235040 = 666ef776b3ca5cf45e37e0c01e6af9f15a1f9c9c r235041 = cb334476f1dfdfc662bbfe85576b800367fa0f68 r235042 = cd72ec433f4d039940a2b039a95378b6d02cfc76 (clang) r235048 = 94255c8eb0bd037ad3f186f15b664ab680771358 r235050 = 88e419d66e38fe6606cfe15362c40765ea430deb -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 15:31:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 22:31:05 +0000 Subject: [LLVMbugs] [Bug 21432] First-class (metadata-based) IR for debug info In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21432 Bug 21432 depends on bug 22778, which changed state. Bug 22778 Summary: Remove the inlinedAt: field from DI/MDLocalVariable https://llvm.org/bugs/show_bug.cgi?id=22778 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 15:36:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 22:36:31 +0000 Subject: [LLVMbugs] [Bug 20402] -Wconsumed leads to: Assertion failed: (StateMapsArray[Block->getBlockID()] && "Block has no block info"), function borrowInfo, file tools/clang/lib/Analysis/Consumed.cpp, line 1080. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20402 DeLesley Hutchins changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from DeLesley Hutchins --- Bugfix submitted by Chris Wailes, and released as r235051. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 15:59:38 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 22:59:38 +0000 Subject: [LLVMbugs] [Bug 23245] New: [ms] clang-cl doesn't reject a selectany program that cl rejects Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23245 Bug ID: 23245 Summary: [ms] clang-cl doesn't reject a selectany program that cl rejects Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This is rejected by cl but not by clang-cl: template struct C { __declspec(selectany) static int a; }; int f() { C c; return c.a; } D:\src\llvm-ninja-rel64>cl foo.cc Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64 Copyright (C) Microsoft Corporation. All rights reserved. foo.cc foo.cc(7) : error C2496: 'C::a' : 'selectany' can only be applied to data items with external linkage foo.cc(8) : see reference to class template instantiation 'C' being compiled foo.cc(7) : error C2496: 'C::a' : 'selectany' can only be applied to data items with external linkage foo.cc(10) : see reference to class template instantiation 'C' being compiled We should reject it too. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 16:07:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 23:07:24 +0000 Subject: [LLVMbugs] [Bug 23243] [ms] crash on __declspec(selectany) in .c file In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23243 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Nico Weber --- r235053 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 16:55:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 15 Apr 2015 23:55:33 +0000 Subject: [LLVMbugs] [Bug 23246] New: cannot select scalar_to_vector llvm.x86.mmx.punpckhbw Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23246 Bug ID: 23246 Summary: cannot select scalar_to_vector llvm.x86.mmx.punpckhbw Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I think this broke between r234774 (known good) and r234879 (known bad). Apologies for the odd testcase, this came out of delta and I couldn't make it more sensible. Testcase: typedef long __m64 __attribute__((__vector_size__(8))); typedef long __m128i __attribute__((__vector_size__(16))); typedef char __v8qi __attribute__((__vector_size__(8))); void consume(__m128i); void test(__m64 __m1, __m64 __m2) { __m64 C = __builtin_ia32_punpckhbw((__v8qi)__m1, (__v8qi)__m2); __m64 q0; __m128i trans_tmp_3 = {(long)q0, (long)C}; consume(trans_tmp_3); } $ clang -mavx b.cc -O2 -std=c++11 fatal error: error in backend: Cannot select: 0x2e8c290: v2i64 = scalar_to_vector 0x2e8c7e0 [ORD=9] [ID=14] 0x2e8c7e0: x86mmx = llvm.x86.mmx.punpckhbw 0x2e8c6d0, 0x2e8c3a0, 0x2e8c5c0 [ORD=6] [ID=13] 0x2e8c6d0: i64 = TargetConstant<3941> [ID=3] 0x2e8c3a0: x86mmx = bitcast 0x2e8bf60 [ORD=3] [ID=11] 0x2e8bf60: i64,ch = CopyFromReg 0x2e1a2c0, 0x2e8be50 [ORD=1] [ID=9] 0x2e8be50: i64 = Register %vreg0 [ID=1] 0x2e8c5c0: x86mmx = bitcast 0x2e8c180 [ORD=5] [ID=12] 0x2e8c180: i64,ch = CopyFromReg 0x2e1a2c0, 0x2e8c070 [ORD=1] [ID=10] 0x2e8c070: i64 = Register %vreg1 [ID=2] In function: _Z4testDv1_lS_ clang: error: clang frontend command failed with exit code 70 (use -v to see invocation) Target: x86_64-grtev4-linux-gnu -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 18:38:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 01:38:52 +0000 Subject: [LLVMbugs] [Bug 22899] false negative of -Winteger-overflow In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22899 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |davide at freebsd.org Resolution|--- |FIXED --- Comment #1 from Davide Italiano --- Can't repro on recent clang, seems fixed. % ./clang conv.c -Wconversion conv.c:3:30: warning: overflow in expression; result is -445703536 with type 'int' [-Winteger-overflow] int a = ((uint16_t)0xE570L * (uint16_t)(-1L)); ^ conv.c:5:26: warning: overflow in expression; result is -445703536 with type 'int' [-Winteger-overflow] b = ((uint16_t)0xE570L * (uint16_t)(-1L)); ^ 2 warnings generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 19:04:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 02:04:02 +0000 Subject: [LLVMbugs] [Bug 23247] New: L-values produced by casts to volatile references aren't tracked as volatile Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23247 Bug ID: 23247 Summary: L-values produced by casts to volatile references aren't tracked as volatile Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: rjmccall at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified static int global = 4; int main() { const_cast(global) = 4; } IRGen marks this store volatile if the cast is a reinterpret_cast, but not if it's a static_cast, const_cast, or C-style cast. Storing to the dereferenced result of casting to a volatile pointer type seems to work in all cases. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 19:26:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 02:26:09 +0000 Subject: [LLVMbugs] [Bug 23081] Port DITypeRef/DIScopeRef/DIRef to the new debug info hierarchy In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23081 Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Duncan --- This is finished as r235071. (Not sure what all went into it -- and it was mostly fixed a while ago -- as I didn't end up tracking this separately from bug 23080.) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 19:26:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 02:26:10 +0000 Subject: [LLVMbugs] [Bug 23080] Remove DIDescriptor and its subclasses In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23080 Bug 23080 depends on bug 23081, which changed state. Bug 23081 Summary: Port DITypeRef/DIScopeRef/DIRef to the new debug info hierarchy https://llvm.org/bugs/show_bug.cgi?id=23081 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 15 19:40:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 02:40:43 +0000 Subject: [LLVMbugs] [Bug 23246] cannot select scalar_to_vector llvm.x86.mmx.punpckhbw In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23246 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ahmed Bougacha --- r235072 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 03:50:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 10:50:36 +0000 Subject: [LLVMbugs] [Bug 23249] New: LCSSA::verifyAnalysis() and verifyAnalysis() does nothing? Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23249 Bug ID: 23249 Summary: LCSSA::verifyAnalysis() and verifyAnalysis() does nothing? Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: yaron.keren at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hi Chandler, Warnings level 4 were recently enabled for Visual C++ and it complains that: lib\transforms\utils\lcssa.cpp(345): warning C4718: 'verifyLoop' : recursive call has no side effects, deleting essentially, it says that verifyLoop does nothing other than call itself, which appear to be true both in debug and release modes: static void verifyLoop(Loop &L, DominatorTree &DT) { // Recurse depth-first through inner loops. for (Loop::iterator LI = L.begin(), LE = L.end(); LI != LE; ++LI) verifyLoop(**LI, DT); // Check the special guarantees that LCSSA makes. //assert(L.isLCSSAForm(DT) && "LCSSA form not preserved!"); } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 08:33:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 15:33:08 +0000 Subject: [LLVMbugs] [Bug 23252] New: New assert: "Symbol must already have been defined in ExecutePostLayoutBinding!" Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23252 Bug ID: 23252 Summary: New assert: "Symbol must already have been defined in ExecutePostLayoutBinding!" Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: hans at chromium.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified After r235101, DebugInfo/unconditional-branch.ll started failing on Windows. It's reproducible like this: $ bin/llc -fast-isel=false -O0 -filetype=obj -mtriple=i686-cygwin ../test/DebugInfo/unconditional-branch.ll I expect the switch change is unrelated. I'll pacify the test by adding a Linux triple to it for now. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 11:12:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 18:12:58 +0000 Subject: [LLVMbugs] [Bug 23253] New: Clang should not allow call constructor directly. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23253 Bug ID: 23253 Summary: Clang should not allow call constructor directly. Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: kunling at lingcc.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified For the following code, clang++ could compile with -std=c++11, and give the following output which is incorrect. #include struct B { }; struct C { C (){ std::cout << "C" << '\n'; } C (B *) { std::cout << "C (B *)" << '\n';} }; B *y = nullptr; int main() { C::C (y); } output: $ clang++ sfo.cpp -std=c++11 $ ./a.out C While g++ give an meaningful error message. $ g++ sfo.cpp -std=c++11 sfo.cpp: In function ‘int main()’: sfo.cpp:34:10: error: cannot call constructor ‘C::C’ directly [-fpermissive] C::C (y); ^ sfo.cpp:34:10: note: for a function-style cast, remove the redundant ‘::C’ This bug was from Stackoverflow.com question ( http://stackoverflow.com/q/29681449/566459 ). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 12:38:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 19:38:32 +0000 Subject: [LLVMbugs] [Bug 23254] New: Nested name specifier refers to injected class name, not the constructor Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23254 Bug ID: 23254 Summary: Nested name specifier refers to injected class name, not the constructor Product: clang Version: 3.6 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: mjbshaw at hotmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified >From the StackOverflow question: http://stackoverflow.com/q/29681449/1287251 The code: #include struct B { }; struct C { C (){ std::cout << "C" << '\n'; } C (B *) { std::cout << "C (B *)" << '\n';} }; B *y = nullptr; int main() { C::C (y); } compiles with clang 3.5 and 3.6 and prints "C". This should not be valid code, though, as C::C should refer to the constructor (and not the inject class name C). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 13:05:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 20:05:30 +0000 Subject: [LLVMbugs] [Bug 23255] New: Minor error in documentation for shl Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23255 Bug ID: 23255 Summary: Minor error in documentation for shl Product: Documentation Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: General docs Assignee: unassignedbugs at nondot.org Reporter: keith at doctorigor.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 15:01:23 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 22:01:23 +0000 Subject: [LLVMbugs] [Bug 23256] New: tuple is_constructible attempts tuple to A conversion Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23256 Bug ID: 23256 Summary: tuple is_constructible attempts tuple to A conversion Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: eugeni.stepanov at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified I'm not sure this is a bug, but... std::is_trivially_copy_constructible>::value instantiates A's type conversion constructor with tuple as an argument. Is it allowed to do that? #include class A { public: A() : value_(0) {} template explicit constexpr A(T value) : value_(static_cast(value)) {} private: int value_; }; A a; A b(a); static_assert(std::is_trivially_copy_constructible>::value, "zz"); $ ./bin/clang++ ../1.cc -c -std=c++11 -stdlib=libc++ ../1.cc:9:16: error: cannot convert 'std::__1::tuple' to 'int' without a conversion operator : value_(static_cast(value)) {} ^~~~~~~~~~~~~~~~~~~~~~~ /code/llvm/build/bin/../include/c++/v1/type_traits:2356:38: note: in instantiation of function template specialization 'A::A >' requested here : public integral_constant ^ /code/llvm/build/bin/../include/c++/v1/__tuple:303:32: note: in instantiation of template class 'std::__1::is_constructible &>' requested here is_constructible<_Up0, _Tp0>::value && ^ /code/llvm/build/bin/../include/c++/v1/__tuple:315:12: note: in instantiation of template class 'std::__1::__tuple_constructible_imp &>, std::__1::__tuple_types >' requested here : public __tuple_constructible_imp< ^ /code/llvm/build/bin/../include/c++/v1/__tuple:328:14: note: in instantiation of template class 'std::__1::__tuple_constructible_apply &>, std::__1::__tuple_types >' requested here : public __tuple_constructible_apply::type>::value == ^ /code/llvm/build/bin/../include/c++/v1/tuple:583:26: note: in instantiation of template class 'std::__1::__tuple_constructible &>, std::__1::__tuple_types, true, true>' requested here __tuple_constructible ^ /code/llvm/build/bin/../include/c++/v1/tuple:610:9: note: while substituting prior template arguments into non-type template parameter [with _Up = &>] tuple(_Up&&... __u) ^~~~~ /code/llvm/build/bin/../include/c++/v1/type_traits:2689:31: note: while substituting deduced template arguments into function template 'tuple' [with _Up = &>, $1 = (no value)] : integral_constant ^ /code/llvm/build/bin/../include/c++/v1/type_traits:2817:14: note: in instantiation of template class 'std::__1::is_trivially_constructible, const std::__1::tuple &>' requested here : public is_trivially_constructible<_Tp, typename add_lvalue_reference::type> ^ ../1.cc:18:20: note: in instantiation of template class 'std::__1::is_trivially_copy_constructible >' requested here static_assert(std::is_trivially_copy_constructible>::value, "zz"); -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 15:03:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 22:03:27 +0000 Subject: [LLVMbugs] [Bug 23257] New: [LegacyPassManager] Add -print-func-after-all command-line options Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23257 Bug ID: 23257 Summary: [LegacyPassManager] Add -print-func-after-all command-line options Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Transformation Utilities Assignee: unassignedbugs at nondot.org Reporter: mcrosier at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Similar to the -mllvm -print-after-all command-line option, it would be nice to have an option that does the same, but on a per function basis (e.g., -print-func-after-all="funcname"). In the past I've used llvm-extract to extract the function in question and then run opt/llc, but it's difficult to match the behavior of the -O options (e.g., -O3) accepted by clang and those accepted by opt and llc. This should also work for the related command-line options (e.g., -print-before-all, -print-before=). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 15:14:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 22:14:07 +0000 Subject: [LLVMbugs] [Bug 23258] New: Add -mskip-rax-setup option for x86-64 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23258 Bug ID: 23258 Summary: Add -mskip-rax-setup option for x86-64 Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: hjl.tools at gmail.com CC: llvmbugs at cs.uiuc.edu, michael.m.kuperstein at intel.com Classification: Unclassified GCC 5 added a compiler option, -mskip-rax-setup, for x86-64. It skips setting up the RAX register when SSE is disabled and there are no variable arguments passed in vector registers. Since kernel doesn't pass vector registers to functions with variable arguments, this option can be used to optimize the x86-64 kernel. For kernel 3.17: text data bss dec hex filename 11455921 2204048 5853184 19513153 129bf41 vmlinux #with -mskip-rax-setup 11480079 2204048 5853184 19537311 12a1d9f vmlinux It will be nice to implement it in clang. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 16:15:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 23:15:13 +0000 Subject: [LLVMbugs] [Bug 15243] clang makes nested-namespace incorrectly In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15243 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Richard Smith --- *** This bug has been marked as a duplicate of bug 13403 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 16:15:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 23:15:16 +0000 Subject: [LLVMbugs] [Bug 23254] Nested name specifier refers to injected class name, not the constructor In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23254 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |DUPLICATE --- Comment #1 from Richard Smith --- *** This bug has been marked as a duplicate of bug 13403 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 16:16:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 16 Apr 2015 23:16:08 +0000 Subject: [LLVMbugs] [Bug 23253] Clang should not allow call constructor directly. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23253 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |DUPLICATE --- Comment #2 from Richard Smith --- *** This bug has been marked as a duplicate of bug 23254 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 18:04:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 01:04:26 +0000 Subject: [LLVMbugs] [Bug 23259] New: Error during code selection with broadcast instruction (AVX2) with optsize Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23259 Bug ID: 23259 Summary: Error during code selection with broadcast instruction (AVX2) with optsize Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: Wolfgang_Pieb at playstation.sony.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14212 --> https://llvm.org/bugs/attachment.cgi?id=14212&action=edit IR generated from a C++ test case using __builtin_shufflevector The attached IR gets (with llc r235151): LLVM ERROR: Cannot select: 0x502f8b0: v2i64 = X86ISD::VBROADCAST 0x502dec0 [ORD=7] [ID=18] 0x502dec0: i64,ch = load 0x4fd3100, 0x502f690, 0x502dfd0 [ORD=7] [ID=16] 0x502f690: i64 = X86ISD::Wrapper 0x5030830 [ID=14] 0x5030830: i64 = TargetConstantPool 0 [ID=11] 0x502dfd0: i64 = undef [ID=4] In function: _Z7test768Dv3_l This was introduced with r218263. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 18:05:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 01:05:18 +0000 Subject: [LLVMbugs] [Bug 23260] New: DebugInfo: Wrong value for inlined formal_parameters of a function inlined twice Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23260 Bug ID: 23260 Summary: DebugInfo: Wrong value for inlined formal_parameters of a function inlined twice Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedbugs at nondot.org Reporter: dexonsmith at apple.com CC: dblaikie at gmail.com, llvmbugs at cs.uiuc.edu Classification: Unclassified $ cat t.c void sink(void); static __attribute__((always_inline)) void bar(int a) { sink(); } void foo(void) { bar(0); bar(1); } $ clang -g -O2 t.c -S -emit-llvm -o - | grep llvm.dbg.value tail call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !12, metadata !17) #3, !dbg !18 tail call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !12, metadata !17) #3, !dbg !21 declare void @llvm.dbg.value(metadata, i64, metadata, metadata) #2 Notice that both intrinsics get `i32 0`. This happens during dead argument elimination. *** IR Dump After Dead Argument Elimination ***; ModuleID = 't.c' ; Function Attrs: alwaysinline nounwind ssp uwtable define internal fastcc void @bar() #1 { entry: call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !12, metadata !20), !dbg !21 call void @sink(), !dbg !22 ret void, !dbg !23 } I suspect the right solution is to lose the variable entirely. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 18:35:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 01:35:55 +0000 Subject: [LLVMbugs] [Bug 7802] False positive for -Wunreachable-code In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=7802 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 19:23:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 02:23:20 +0000 Subject: [LLVMbugs] [Bug 23261] New: assertion failure emitting lvalue CK_AddressSpaceCast Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23261 Bug ID: 23261 Summary: assertion failure emitting lvalue CK_AddressSpaceCast Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified This: int __attribute__((address_space(1))) a = 0; void f() { int &b = reinterpret_cast(a); } results in: clang-3.6: IR/Constants.cpp:1571: static llvm::Constant *llvm::ConstantExpr::getCast(unsigned int, llvm::Constant *, llvm::Type *, bool): Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"' failed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 21:20:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 04:20:21 +0000 Subject: [LLVMbugs] [Bug 23262] New: undefined reference to `__atomic_load_8', when it comes to 64-bit atomic load. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23262 Bug ID: 23262 Summary: undefined reference to `__atomic_load_8', when it comes to 64-bit atomic load. Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: rwindz0 at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified clang fails to deal with 64-bit atomic load and compare_exchange_weak when it comes with -stdlib=libstdc++, while gcc can deal with it correctly. The test program is from http://preshing.com/20150402/you-can-do-any-kind-of-atomic-read-modify-write-operation/ : cat >test-atomic.cc< struct Terms { uint32_t x; uint32_t y; }; std::atomic terms; void atomicFibonacciStep() { Terms oldTerms = terms.load(); Terms newTerms; do { newTerms.x = oldTerms.y; newTerms.y = oldTerms.x + oldTerms.y; } while (!terms.compare_exchange_weak(oldTerms, newTerms)); } int main() { atomicFibonacciStep(); } EOF test with: $clang++-3.7 -std=c++11 -stdlib=libstdc++ -O3 test-atomic.cc /tmp/test-atomic-190571.o: In function `std::atomic::load(std::memory_order) const': test-atomic.cc:(.text[_ZNKSt6atomicI5TermsE4loadESt12memory_order]+0x14): undefined reference to `__atomic_load_8' /tmp/test-atomic-190571.o: In function `std::atomic::compare_exchange_weak(Terms&, Terms, std::memory_order, std::memory_order)': test-atomic.cc:(.text[_ZNSt6atomicI5TermsE21compare_exchange_weakERS0_S0_St12memory_orderS3_]+0x2b): undefined reference to `__atomic_compare_exchange_8' clang: error: linker command failed with exit code 1 (use -v to see invocation) $g++-4.9 -std=c++11 -O3 test-atomic.cc (exited status 0) $clang++-3.7 -std=c++11 -stdlib=libstdc++ -O3 -S test-atomic.cc -o - ... callq __atomic_load_8 movq %rax, 8(%rsp) movq %rax, %rcx shrq $32, %rcx movl %ecx, %edx addl %eax, %edx shlq $32, %rdx orq %rcx, %rdx leaq 8(%rsp), %rsi movl $terms, %edi movl $5, %ecx movl $5, %r8d callq __atomic_compare_exchange_8 testb %al, %al jne .LBB0_3 ... $g++-4.9 -std=c++11 -O3 -S test-atomic.cc -o - ... .LFB329: .cfi_startproc movq terms(%rip), %rax movq %rax, %rdx movl %eax, -24(%rsp) shrq $32, %rdx movl %edx, -20(%rsp) .p2align 4,,10 .p2align 3 .L4: addl %edx, %eax movl %edx, %edx salq $32, %rax orq %rax, %rdx movq -24(%rsp), %rax lock cmpxchgq %rdx, terms(%rip) jne .L6 rep ret .p2align 4,,10 .p2align 3 ... BTW: clang++ works just fine with libc++. (the generated assembly code looks almost the same to gcc's) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 22:34:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 05:34:51 +0000 Subject: [LLVMbugs] [Bug 23262] undefined reference to `__atomic_load_8', when it comes to 64-bit atomic load. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23262 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |INVALID --- Comment #2 from Richard Smith --- GCC miscompiled your code. Note that this instruction: movq terms(%rip), %rax is *not* atomic, if terms happens to straddle a cache line, which it might because it has only 4 byte alignment and has size 8. You should add alignas(8) to your "struct Terms" to work around libstdc++ failing to align std::atomic properly. Oddly, while x86 does not have a misaligned 8 byte load instruction, it does have a misaligned 8-byte compare-exchange instruction (lock cmpxchgq), but LLVM is unable to represent a misaligned cmpxchg, so we won't emit that. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 16 23:21:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 06:21:24 +0000 Subject: [LLVMbugs] [Bug 23263] New: clang miscompiles atomics by using optimized libcalls for underaligned storage Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23263 Bug ID: 23263 Summary: clang miscompiles atomics by using optimized libcalls for underaligned storage Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Per https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary, "All the optimized routines expect that the object will be properly aligned for a data type of the specified size". However, Clang and GCC get this wrong: struct X { int a, b; }; X f(X *p) { X r; __atomic_load(p, &r, 5); return r; } ... calls __atomic_load_8. And GCC's libatomic implements __atomic_load_8 on x86_64 with a single 8-byte mov, which is only atomic for a correctly-aligned operand. We should instead emit a call to __atomic_load(8, p, &r, 5) because we have no reason to think that p is 8 byte aligned. The same happens for __atomic_store and probably all the other atomic libcalls. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 01:12:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 08:12:51 +0000 Subject: [LLVMbugs] [Bug 23265] New: clang compile aarch64 neon intrinsics error Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23265 Bug ID: 23265 Summary: clang compile aarch64 neon intrinsics error Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: zhongwei.yao at chromium.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Clang fails on compile arm neon intrinsic file for aarch64 target. Here is the log: /home/zhongwei/projects/read_learn/llvm-toolchain/build/bin/clang -v -target aarch64-none-linux-androideabi -O2 -D__ARM_NEON -c ../../webrtc/modules/audio_coding/codecs/isac/fix/source/filterbanks_neon.c clang version 3.7.0 (trunk 235161) Target: aarch64-none-linux-androideabi Thread model: posix Found candidate GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/4.8.2 Selected GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/4.8 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/home/zhongwei/projects/read_learn/llvm-toolchain/build/bin/clang-3.7" -cc1 -triple aarch64-none-linux-androideabi -emit-obj -disable-free -main-file-name filterbanks_neon.c -mrelocation-model pic -pic-level 1 -mthread-model posix -mdi\ sable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu generic -target-feature +neon -target-abi aapcs -backend-option -aarch64-fix-cortex-a53-835769=1 -v -dwarf-column-info -fno-unique-section-names \ -coverage-file /home/zhongwei/project/webrtc_git/src/out/iOS_Release/filterbanks_neon.c -resource-dir /home/zhongwei/projects/read_learn/llvm-toolchain/build/bin/../lib/clang/3.7.0 -D __ARM_NEON -internal-isystem /usr/local/include -inte\ rnal-isystem /home/zhongwei/projects/read_learn/llvm-toolchain/build/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -fdebug-compilation-dir /home/zhongwei/project/webrtc_git/s\ rc/out/iOS_Release -ferror-limit 19 -fmessage-length 118 -mstackrealign -fallow-half-arguments-and-returns -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o filterbanks_neon.o -x c ../../web\ rtc/modules/audio_coding/codecs/isac/fix/source/filterbanks_neon.c clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /home/zhongwei/projects/read_learn/llvm-toolchain/build/bin/../lib/clang/3.7.0/include /usr/include End of search list. clang-3.7: /home/zhongwei/projects/read_learn/llvm-toolchain/llvm/include/llvm/CodeGen/ValueTypes.h:226: unsigned int llvm::EVT::getVectorNumElements() const: Assertion `isVector() && "Invalid vector type!"' failed. 0 clang-3.7 0x00000000025e7e3a llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 44 1 clang-3.7 0x00000000025e814f 2 clang-3.7 0x00000000025e6c4f 3 libpthread.so.0 0x00002b5d50e4d340 4 libc.so.6 0x00002b5d51acacc9 gsignal + 57 5 libc.so.6 0x00002b5d51ace0d8 abort + 328 6 libc.so.6 0x00002b5d51ac3b86 7 libc.so.6 0x00002b5d51ac3c32 8 clang-3.7 0x0000000001342170 9 clang-3.7 0x000000000134da6e 10 clang-3.7 0x000000000134e4ea 11 clang-3.7 0x000000000135d477 12 clang-3.7 0x0000000002aa7058 llvm::SelectionDAGISel::DoInstructionSelection() + 528 13 clang-3.7 0x0000000002aa69ec llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 3544 14 clang-3.7 0x0000000002aa5845 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 235 15 clang-3.7 0x0000000002aa8b61 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2841 16 clang-3.7 0x0000000002aa49d9 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1013 17 clang-3.7 0x00000000013442a2 18 clang-3.7 0x0000000001e91dcb llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95 19 clang-3.7 0x00000000021d8cec llvm::FPPassManager::runOnFunction(llvm::Function&) + 290 19 clang-3.7 0x00000000021d8cec llvm::FPPassManager::runOnFunction(llvm::Function&) + 290 20 clang-3.7 0x00000000021d8e5c llvm::FPPassManager::runOnModule(llvm::Module&) + 84 21 clang-3.7 0x00000000021d917a 22 clang-3.7 0x00000000021d9820 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 244 23 clang-3.7 0x00000000021d9a3f llvm::legacy::PassManager::run(llvm::Module&) + 39 24 clang-3.7 0x0000000002b7083d 25 clang-3.7 0x0000000002b708ed clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::r\ aw_pwrite_stream*) + 127 26 clang-3.7 0x0000000002b52282 27 clang-3.7 0x00000000035d13c0 clang::ParseAST(clang::Sema&, bool, bool) + 784 28 clang-3.7 0x00000000027e97c6 clang::ASTFrontendAction::ExecuteAction() + 322 29 clang-3.7 0x0000000002b54798 clang::CodeGenAction::ExecuteAction() + 1486 30 clang-3.7 0x00000000027e92a1 clang::FrontendAction::Execute() + 139 31 clang-3.7 0x00000000027b0ed4 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 772 32 clang-3.7 0x00000000028fe389 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 993 33 clang-3.7 0x00000000012d4a22 cc1_main(llvm::ArrayRef, char const*, void*) + 770 34 clang-3.7 0x00000000012cd28e 35 clang-3.7 0x00000000012cd875 main + 1074 36 libc.so.6 0x00002b5d51ab5ec5 __libc_start_main + 245 37 clang-3.7 0x00000000012ca239 Stack dump: 0. Program arguments: /home/zhongwei/projects/read_learn/llvm-toolchain/build/bin/clang-3.7 -cc1 -triple aarch64-none-linux-androideabi -emit-obj -disable-free -main-file-name filterbanks_neon.c -mrelocation-model pic -pic-level 1 -\ mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu generic -target-feature +neon -target-abi aapcs -backend-option -aarch64-fix-cortex-a53-835769=1 -v -dwarf-column-info -f\ no-unique-section-names -coverage-file /home/zhongwei/project/webrtc_git/src/out/iOS_Release/filterbanks_neon.c -resource-dir /home/zhongwei/projects/read_learn/llvm-toolchain/build/bin/../lib/clang/3.7.0 -D __ARM_NEON -internal-isystem \ /usr/local/include -internal-isystem /home/zhongwei/projects/read_learn/llvm-toolchain/build/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -fdebug-compilation-dir /home/zhong\ wei/project/webrtc_git/src/out/iOS_Release -ferror-limit 19 -fmessage-length 118 -mstackrealign -fallow-half-arguments-and-returns -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o filterban\ ks_neon.o -x c ../../webrtc/modules/audio_coding/codecs/isac/fix/source/filterbanks_neon.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '../../webrtc/modules/audio_coding/codecs/isac/fix/source/filterbanks_neon.c'. 4. Running pass 'AArch64 Instruction Selection' on function '@WebRtcIsacfix_AllpassFilter2FixDec16Neon' clang-3.7: error: unable to execute command: Aborted (core dumped) clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 235161) Target: aarch64-none-linux-androideabi Thread model: posix clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.7: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.7: note: diagnostic msg: /tmp/filterbanks_neon-c2acf1.c clang-3.7: note: diagnostic msg: /tmp/filterbanks_neon-c2acf1.sh clang-3.7: note: diagnostic msg: ******************** make: *** [trunk-clang] Error 254 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 01:46:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 08:46:45 +0000 Subject: [LLVMbugs] [Bug 23196] relocation refers to discarded section In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23196 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Fixed in r235167. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 04:27:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 11:27:49 +0000 Subject: [LLVMbugs] [Bug 23025] Regression(r233187): Windows ABI codegen is busted In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23025 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #29 from Rafael Ávila de Espíndola --- Fixed in r235181. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 05:40:29 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 12:40:29 +0000 Subject: [LLVMbugs] [Bug 23266] New: raw_svector_ostream::pwrite problems Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23266 Bug ID: 23266 Summary: raw_svector_ostream::pwrite problems Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: yaron.keren at gmail.com CC: llvmbugs at cs.uiuc.edu, rafael.espindola at gmail.com Classification: Unclassified Hi Rafael, Try adding this to the raw_pwrite_stream_test.cpp unit test, which will fail. SmallString<16> Buffer4; raw_svector_ostream OS4(Buffer4); OS4.pwrite(Test.data(), Test.size(), 0); OS4 << '4'; StringRef S4 = OS4.str(); EXPECT_EQ(S4, "4est"); While raw_fd_ostream::pwrite is careful to keep the current position so you can do random r/w without disturbing the current stream position, raw_svector_ostream::pwrite does not keep it, assuming the currrent position is the vector size. Thus any write after pwrite will always occur at the end of the vector and following the previous write(), inconsistent with raw_svector_ostream::pwrite and programmer expectation. Furthermore, the code if (End > OS.size()) OS.resize(End); must call resync() as it may modify the OS vector without updating the pointers OutBufStart, OutBufEnd and OutBufCur. These problems cause sometime corrupt ELF object file when written into a raw_svector_ostream instead of raw_fd_ostream. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 05:51:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 12:51:49 +0000 Subject: [LLVMbugs] [Bug 23071] MS-compatibility: XAudio2.h fails to compile due to spaces in GUID In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23071 Will Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |lantictac at gmail.com Resolution|--- |FIXED --- Comment #7 from Will Wilson --- Fixed by r235186: [MSVC] Mimic MSVC whitespace collapse for incompatible token pasting The workaround is simple but a little ugly. Let me know if there's any fallout. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 06:39:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 13:39:22 +0000 Subject: [LLVMbugs] [Bug 23267] New: missing initializer on template instantiated from variadic template class Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23267 Bug ID: 23267 Summary: missing initializer on template instantiated from variadic template class Product: clang Version: 3.5 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: camorton2 at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified #include template struct A {}; template < template < class ..., class ... _T , _T ... > class ... T > struct B { template struct C { template struct D { A[I]...> f() { printf("Yes called f\n"); return A[I]...>(); } }; }; }; template struct E {}; A<> a1 = B<>::C<>::D<>().f(); int main(void){} Function f() is not called. Clang AST does not have the initializer for a1 VarDecl 0x13197c50 col:5 a1 'A<>':'struct A<>' -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 07:29:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 14:29:09 +0000 Subject: [LLVMbugs] [Bug 23268] New: Regression in r235154-r235156 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23268 Bug ID: 23268 Summary: Regression in r235154-r235156 Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu, nicolasweber at gmx.de, rnk at google.com Classification: Unclassified Created attachment 14219 --> https://llvm.org/bugs/attachment.cgi?id=14219&action=edit testcase This crashes clang -cc1 -triple x86_64-pc-windows-msvc -emit-llvm-bc -std=c++11 -fms-compatibility test.ii -o test.bc #OK llc test.bc #crash -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 08:43:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 15:43:54 +0000 Subject: [LLVMbugs] [Bug 23269] New: clang generates 1.5 slower loop code than gcc Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23269 Bug ID: 23269 Summary: clang generates 1.5 slower loop code than gcc Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: dvyukov at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ clang++ -v clang version 3.7.0 (trunk 234143) Target: x86_64-unknown-linux-gnu $ g++ -v Target: x86_64-linux-gnu gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) Below is the test program. Processor is Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz. Build the program with: $ g++/clang++ test.cc -Wall -O3 -msse3 -g g++ compiled binary runs 2.813s. g++ compiled binary runs 4.353s. =========== #include typedef unsigned char byte; byte* volatile arr1; byte* volatile arr2; __attribute__((noinline)) void compare(byte* p1, byte* p2, bool* f1, bool *f2) { bool cnt = false; for (int i = 0; i < 1<<16; i++) { byte v1 = p1[i]; byte v2 = p2[i]; if (__builtin_expect(v1 == 0 && v2 != 0, 0)) { *f1 = true; *f2 = true; return; } if (__builtin_expect(v1 < v2, 0)) { cnt = true; } } *f1 = false; *f2 = cnt; } int main() { arr1 = (byte*)calloc(1<<16, 1); arr2 = (byte*)calloc(1<<16, 1); for (int i = 0; i < 1000; i++) { int idx = rand() % (1<<16); arr1[idx] = 100; arr2[idx] = 100; } int x = 0; for (int i = 0; i < 50000; i++) { bool f1, f2; compare(arr1, arr2, &f1, &f2); x += f1; x += f2; } return x; } ===== g++-compiled binary profile: │ 0000000000400630 : │ xor %eax,%eax │ xor %r9d,%r9d │ mov $0x1,%r11d │ nop 0.02 │10: movzbl (%rsi,%rax,1),%r8d 8.05 │ movzbl (%rdi,%rax,1),%r10d 29.73 │ test %r8b,%r8b │ jne 39 6.48 │1f: cmp %r8b,%r10b 9.31 │ cmovb %r11d,%r9d 43.24 │ add $0x1,%rax 0.03 │ cmp $0x10000,%rax │ jne 10 │ movb $0x0,(%rdx) │ mov %r9b,(%rcx) │ retq 3.14 │39: test %r10b,%r10b │ jne 1f │ movb $0x1,(%rdx) │ movb $0x1,(%rcx) │ retq clang++-compiled profile: │ 0000000000400640 : ▒ │ xor %r11d,%r11d ▒ │ xor %r8d,%r8d ▒ │ nop ▒ 4.14 │10: mov (%rdi,%r11,1),%r9b ▒ 12.93 │ mov (%rsi,%r11,1),%r10b ▒ 6.93 │ test %r9b,%r9b ▒ │ jne 22 ▒ 4.11 │ test %r10b,%r10b ▒ │ jne 76 ▒ 5.82 │22: movzbl %r10b,%r10d ▒ 1.43 │ movzbl %r9b,%eax ▒ 4.40 │ cmp %r10d,%eax ▒ 8.51 │ mov $0x1,%r9b ▒ 1.44 │ ┌──jb 35 ◆ 7.17 │ │ mov %r8b,%r9b ▒ 1.63 │35:└─ mov 0x1(%rdi,%r11,1),%r8b ▒ 2.84 │ mov 0x1(%rsi,%r11,1),%r10b ▒ 8.69 │ test %r8b,%r8b ▒ │ jne 49 ▒ 1.80 │ test %r10b,%r10b ▒ │ jne 76 ▒ 3.94 │49: inc %r11 ▒ 5.29 │ movzbl %r10b,%r10d ▒ 2.14 │ movzbl %r8b,%eax ▒ 1.18 │ cmp %r10d,%eax ▒ 4.64 │ mov $0x1,%r8b ▒ 3.93 │ jb 5f ▒ 3.83 │ mov %r9b,%r8b ▒ 1.58 │5f: inc %r11 ▒ 1.62 │ cmp $0x10000,%r11 ▒ │ jl 10 ▒ │ movb $0x0,(%rdx) ▒ │ and $0x1,%r8b ▒ │ mov %r8b,(%rcx) ▒ │ retq ▒ │76: movb $0x1,(%rdx) ▒ │ mov $0x1,%r8b ▒ │ mov %r8b,(%rcx) ▒ │ retq -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 11:54:21 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 18:54:21 +0000 Subject: [LLVMbugs] [Bug 23271] New: llvm-mc incorrectly disassembles RIP relative instructions with REX.B Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23271 Bug ID: 23271 Summary: llvm-mc incorrectly disassembles RIP relative instructions with REX.B Product: tools Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llvmc Assignee: unassignedbugs at nondot.org Reporter: matt_barney at yahoo.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Bug Synopsis ============ From: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf "The ModR/M encoding for RIP-relative addressing does not depend on using prefix. Specifically, the r/m bit field encoding of 101B (used to select RIP-relative addressing) is not affected by the REX prefix. For example, selecting R13 (REX.B = 1, r/m = 101B) with mod = 00B still results in RIP-relative addressing." -- 2-6 Vol. 2A, Intel 64 and ia32 Architectures Software Developer's Manual As such, we should expect when REX = 0x49 (REX.W = 1, and REX.B = 1), for example, to not affect the disassembly of RIP relative addressing in an ADD instruction. So: echo "0x49 0x03 0x1d 0xff 0x0 0x0 0x0" | llvm-mc --disassemble should disassemble to: .text addq 255(%rip), %rbp instead, we receive: .text addq (%r13), %rbp incl (%rax) addb %al, (%rax) I.e., REX.B selected %r13 in the ModR/M byte after disassembly, which is explicitly proscribed in the specification above. Compare this to a REX without the B bit set (REX.W = 1, REX.R = 1), i.e., 0x4c: echo "0x4c 0x03 0x1d 0xff 0x0 0x0 0x0" | llvm-mc --disassemble which correctly disassembles to: .text addq 255(%rip), %r13 Steps to Reproduce ================= uname: Linux derp 3.19.3-3-ARCH #1 SMP PREEMPT Wed Apr 8 14:10:00 CEST 2015 x86_64 GNU/Linux llvm: 3.5 tool: llvm-mc 1. run the following command: echo "0x49 0x03 0x1d 0xff 0x0 0x0 0x0" | llvm-mc --disassemble 2. Note the output: .text addq (%r13), %rbp incl (%rax) addb %al, (%rax) 3. Which should be: .text addq 255(%rip), %rbp -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 12:11:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 19:11:25 +0000 Subject: [LLVMbugs] [Bug 23272] New: LLVM ERROR: Cannot represent a difference across sections Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23272 Bug ID: 23272 Summary: LLVM ERROR: Cannot represent a difference across sections Product: new-bugs Version: unspecified Hardware: PC OS: All Status: ASSIGNED Severity: normal Priority: P Component: new bugs Assignee: rafael.espindola at gmail.com Reporter: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14220 --> https://llvm.org/bugs/attachment.cgi?id=14220&action=edit test Running llc test.ll -o test.o -filetype=obj -generate-arange-section fails on the attached testcase. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 14:11:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 21:11:26 +0000 Subject: [LLVMbugs] [Bug 23273] New: Assertion failed: (Subtarget->hasAVX() && "Expected a subtarget with AVX!"), function X86SelectSIToFP Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23273 Bug ID: 23273 Summary: Assertion failed: (Subtarget->hasAVX() && "Expected a subtarget with AVX!"), function X86SelectSIToFP Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This assertion is reproducible with trunk r235079, when targeting the i386 architecture. Testcase: ====================================================================== a; fn1(double); main() { fn1(a); } ====================================================================== Compile with: $ clang -cc1 -triple i386 -emit-obj testcase.c Assertion failed: (Subtarget->hasAVX() && "Expected a subtarget with AVX!"), function X86SelectSIToFP, file lib/Target/X86/X86FastISel.cpp, line 2093. Abort trap This seems to be recently introduced; trunk r230746 does not assert yet. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 14:16:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 21:16:25 +0000 Subject: [LLVMbugs] [Bug 23272] LLVM ERROR: Cannot represent a difference across sections In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23272 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Rafael Ávila de Espíndola --- Fixed in r235227 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 14:59:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 21:59:07 +0000 Subject: [LLVMbugs] [Bug 23255] Minor error in documentation for shl In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23255 Sean Silva changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |chisophugis at gmail.com Resolution|--- |FIXED --- Comment #2 from Sean Silva --- r235230 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 15:52:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 22:52:05 +0000 Subject: [LLVMbugs] [Bug 23274] New: clang 3.5 or can't compile strigi 0.7.8 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23274 Bug ID: 23274 Summary: clang 3.5 or can't compile strigi 0.7.8 Product: clang Version: 2.6 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: howarth.mailing.lists at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The existing strigi 0.7.8 source code fails to compile against clang 3.5 or later with the error... In file included from /sw/src/fink.build/strigi-0.7.8-2/strigi-0.7.8/strigidaemon/bin/daemon/xesam/xesamsession.cpp:20: In file included from /sw/src/fink.build/strigi-0.7.8-2/strigi-0.7.8/strigidaemon/bin/daemon/xesam/xesamsession.h:24: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/list:2060:18: error: invalid operands to binary expression ('const value_type' (aka 'const XesamSearch') and 'const value_type' (aka 'const XesamSearch')) if (*__i == __x) ~~~~ ^ ~~~ /sw/src/fink.build/strigi-0.7.8-2/strigi-0.7.8/strigidaemon/bin/daemon/xesam/xesamsession.cpp:200:17: note: in instantiation of member function 'std::__1::list >::remove' requested here p->searches.remove(search); ^ /sw/src/fink.build/strigi-0.7.8-2/strigi-0.7.8/strigidaemon/bin/daemon/xesam/xesamsearch.h:46:10: note: candidate function not viable: 'this' argument has type 'const value_type' (aka 'const XesamSearch'), but method is not marked const bool operator==(const XesamSearch& xs) { return p == xs.p; } ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/utility:403:1: note: candidate template ignored: could not match 'pair' against 'const XesamSearch' operator==(const pair<_T1,_T2>& __x, const pair<_T1,_T2>& __y) ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iterator:573:1: note: candidate template ignored: could not match 'reverse_iterator' against 'const XesamSearch' operator==(const reverse_iterator<_Iter1>& __x, const reverse_iterator<_Iter2>& __y) ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iterator:874:6: note: candidate template ignored: could not match 'istreambuf_iterator' against 'const XesamSearch' bool operator==(const istreambuf_iterator<_CharT,_Traits>& __a, ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iterator:977:1: note: candidate template ignored: could not match 'move_iterator' against 'const XesamSearch' operator==(const move_iterator<_Iter1>& __x, const move_iterator<_Iter2>& __y) ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iterator:1293:1: note: candidate template ignored: could not match '__wrap_iter' against 'const XesamSearch' operator==(const __wrap_iter<_Iter1>& __x, const __wrap_iter<_Iter2>& __y) throw() ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:1795:6: note: candidate template ignored: could not match 'allocator' against 'const XesamSearch' bool operator==(const allocator<_Tp>&, const allocator<_Up>&) throw() {return true;} ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2879:1: note: candidate template ignored: could not match 'unique_ptr' against 'const XesamSearch' operator==(const unique_ptr<_T1, _D1>& __x, const unique_ptr<_T2, _D2>& __y) {return __x.get() == __y.get();} ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2915:1: note: candidate template ignored: could not match 'unique_ptr' against 'const XesamSearch' operator==(const unique_ptr<_T1, _D1>& __x, nullptr_t) throw() ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2923:1: note: candidate template ignored: could not match 'unique_ptr' against 'const XesamSearch' operator==(nullptr_t, const unique_ptr<_T1, _D1>& __x) throw() ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4716:1: note: candidate template ignored: could not match 'shared_ptr' against 'const XesamSearch' operator==(const shared_ptr<_Tp>& __x, const shared_ptr<_Up>& __y) throw() ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4765:1: note: candidate template ignored: could not match 'shared_ptr' against 'const XesamSearch' operator==(const shared_ptr<_Tp>& __x, nullptr_t) throw() ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4773:1: note: candidate template ignored: could not match 'shared_ptr' against 'const XesamSearch' operator==(nullptr_t, const shared_ptr<_Tp>& __x) throw() ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:493:6: note: candidate template ignored: could not match 'fpos' against 'const XesamSearch' bool operator==(const fpos<_StateT>& __x, const fpos<_StateT>& __y) ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:3796:1: note: candidate template ignored: could not match 'basic_string' against 'const XesamSearch' operator==(const basic_string<_CharT, _Traits, _Allocator>& __lhs, ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:3808:1: note: candidate template ignored: could not match 'basic_string, type-parameter-0-0>' against 'const XesamSearch' operator==(const basic_string, _Allocator>& __lhs, ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:3827:1: note: candidate template ignored: could not match 'const _CharT *' against 'value_type' (aka 'XesamSearch') operator==(const _CharT* __lhs, ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:3836:1: note: candidate template ignored: could not match 'basic_string' against 'const XesamSearch' operator==(const basic_string<_CharT,_Traits,_Allocator>& __lhs, ^ 1 error generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 16:35:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 23:35:06 +0000 Subject: [LLVMbugs] [Bug 23274] clang 3.5 or can't compile strigi 0.7.8 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23274 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dimitry at andric.com Resolution|--- |INVALID --- Comment #4 from Dimitry Andric --- (In reply to comment #2) > I am actually rather surprised that the FreeBSD developers haven't already > run into this issue. Yes, we have fixed this some time ago. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196603 and the comments in there. The fix is to make XesamSearch::operator==() const. See also the upstream fix: http://quickgit.kde.org/?p=strigidaemon.git&a=blobdiff&h=acb30a5a395659796e5dd550ee470aeaaec25198&hp=bd93d200049b9d6aeee6030832f974978fa31c9c&hb=2667f0bf37bc52c3375d0bc3727d2474568508a7&f=bin%2Fdaemon%2Fxesam%2Fxesamsearch.h In any case, this is not a clang or libc++ problem. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 16:45:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 17 Apr 2015 23:45:34 +0000 Subject: [LLVMbugs] [Bug 23265] clang compile aarch64 neon intrinsics error In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23265 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Ahmed Bougacha --- Should be fixed with r235243. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 17 18:51:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Apr 2015 01:51:25 +0000 Subject: [LLVMbugs] [Bug 18457] add with symbolic immediate hits llvm_unreachable when writing object file In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18457 Jörg Sonnenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jörg Sonnenberger --- This has been fixed in the mean time. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 18 01:14:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Apr 2015 08:14:52 +0000 Subject: [LLVMbugs] [Bug 20873] lld: build warnings from gcc 4.8.2 on Ubuntu In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20873 Yaron Keren changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Yaron Keren --- This is too old. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 18 03:36:16 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Apr 2015 10:36:16 +0000 Subject: [LLVMbugs] [Bug 23275] New: Support VS 2015 CTP6 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23275 Bug ID: 23275 Summary: Support VS 2015 CTP6 Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: ismail at donmez.ws CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Looks like there are multiple problems with CTP6 support: [~]> clang-cl Code/c++/unsorted/shared_ptr.cpp(+cyg) In file included from C:/Users/ismail/Dropbox/Code/c++/unsorted/shared_ptr.cpp:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\memory:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xmemory:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xmemory0:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cstdint:5: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\yvals.h:8: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\crtdefs.h(10,10) : fatal error: 'corecrt.h' file not found #include ^ 1 error generated. If I manually adjust the include path: [~]> clang-cl -I"C:\Program Files (x86)\Windows Kits\10\Include\ucrt" -c Code/c++/unsorted/lambda.cpp In file included from C:/Users/ismail/Dropbox/Code/c++/unsorted/lambda.cpp:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\iostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\istream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ios:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum:7: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cmath:656: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xtgmath.h:8: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xtr1common(226,22) : error: use of undeclared identifier 'char16_t' struct _Is_integral ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xtr1common(232,22) : error: use of undeclared identifier 'char32_t' struct _Is_integral ^ In file included from C:/Users/ismail/Dropbox/Code/c++/unsorted/lambda.cpp:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\iostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\istream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ios:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum:10: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\streambuf:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xiosbase:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocale:8: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\stdexcept:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\exception:7: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstddef(405,14) : error: use of undeclared identifier 'char16_t' struct hash ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstddef(411,14) : error: use of undeclared identifier 'char32_t' struct hash ^ In file included from C:/Users/ismail/Dropbox/Code/c++/unsorted/lambda.cpp:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\iostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\istream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ios:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum:10: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\streambuf:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xiosbase:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocale:8: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\stdexcept:7: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstring:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xmemory0:8: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\limits(589,33) : error: use of undeclared identifier 'char16_t' template<> class numeric_limits ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\limits(879,33) : error: use of undeclared identifier 'char32_t' template<> class numeric_limits ^ In file included from C:/Users/ismail/Dropbox/Code/c++/unsorted/lambda.cpp:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\iostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\istream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ios:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum:10: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\streambuf:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xiosbase:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocale:8: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\stdexcept:7: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstring:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xmemory0:10: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xutility:8: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\utility:7: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\iosfwd(267,21) : error: use of undeclared identifier 'char16_t' struct char_traits ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\iosfwd(276,21) : error: use of undeclared identifier 'char32_t' struct char_traits ^ In file included from C:/Users/ismail/Dropbox/Code/c++/unsorted/lambda.cpp:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\iostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\istream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ios:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum:10: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\streambuf:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xiosbase:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocale:8: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\stdexcept:7: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstring(2597,22) : error: use of undeclared identifier 'char16_t' typedef basic_string, allocator > ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstring(2597,53) : error: expected unqualified-id typedef basic_string, allocator > ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstring(2599,22) : error: use of undeclared identifier 'char32_t' typedef basic_string, allocator > ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstring(2599,53) : error: expected unqualified-id typedef basic_string, allocator > ^ In file included from C:/Users/ismail/Dropbox/Code/c++/unsorted/lambda.cpp:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\iostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\istream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ostream:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ios:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum:10: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\streambuf:6: In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xiosbase:6: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocale(1004,30) : error: use of undeclared identifier 'char16_t' class _CRTIMP2_PURE codecvt ^ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocale(1328,30) : error: use of undeclared identifier 'char32_t' class _CRTIMP2_PURE codecvt ^ 14 errors generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 18 05:50:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Apr 2015 12:50:34 +0000 Subject: [LLVMbugs] [Bug 23276] New: Template version of std::pow fails to compile Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23276 Bug ID: 23276 Summary: Template version of std::pow fails to compile Product: libc++ Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: programmdude at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified I came up with a compile error when using emscripten 1.30 on windows, which uses libcxx as it's c++ library. When I peeked into the headers to find out what exactly caused it, I determined that this static assert was causing it to fail, the relevant lines are below. typedef typename __promote<_A1, _A2>::type __result_type; static_assert((!(is_same<_A1, __result_type>::value && is_same<_A2, __result_type>::value)), ""); Essentially, the two is_same queries are being inverted, so if both are true then false is being passed to static_assert. According to MSDN, static_assert fails if it's false. Unless I am mistaken, it should work correctly without the invert operator. For reference, compiling with std::pow(1.0f, 2.0f) was able to get this error. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 18 09:37:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Apr 2015 16:37:31 +0000 Subject: [LLVMbugs] [Bug 23277] New: __builtin_object_size(null_pointer) returns the wrong result Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23277 Bug ID: 23277 Summary: __builtin_object_size(null_pointer) returns the wrong result Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: danielmicay at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This outputs (size_t)-1 in both cases with `gcc -O2` but clang gives 0 for the second case: #include int main(int argc, char **argv) { printf("%zu\n", __builtin_object_size(NULL, 0)); void *p = NULL; printf("%zu\n", __builtin_object_size(p, 0)); return 0; } This is broken with glibc's _FORTIFY_SOURCE implementation for nullable parameters. It assumes that it can do comparisons like `object_size(buffer) < copy_size` after handling the unknown case, but this can result in a false positive with Clang. It's not a glibc bug because they're using GNU C as it is defined by GCC, which is where this feature comes from. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 18 09:51:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Apr 2015 16:51:12 +0000 Subject: [LLVMbugs] [Bug 23278] New: Regression(r235232): `Assertion `C1->getType() == C2->getType() && "Operand types in binary constant expression should match"' failed.` Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23278 Bug ID: 23278 Summary: Regression(r235232): `Assertion `C1->getType() == C2->getType() && "Operand types in binary constant expression should match"' failed.` Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Some chromium bots (upstream bug: http://crbug.com/478420) started failing to compile with clang-3.7: /b/build/slave/ClangToTAndroidASan/build/src/third_party/llvm/lib/IR/Constants.cpp:1850: static llvm::Constant* llvm::ConstantExpr::get(unsigned int, llvm::Constant*, llvm::Constant*, unsigned int, llvm::Type*): Assertion `C1->getType() == C2->getType() && "Operand types in binary constant expression should match"' failed. The regression range is 235229:235232 (last good:first bad), and it happens on non-arm bots too, so it's r235232 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 18 10:44:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Apr 2015 17:44:57 +0000 Subject: [LLVMbugs] [Bug 23280] New: objectsize should not be lowered to unknown before inlining Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23280 Bug ID: 23280 Summary: objectsize should not be lowered to unknown before inlining Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: danielmicay at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This will output 2 with `gcc -O2` but (size_t)-1 with Clang: #include #include static inline __attribute__((always_inline)) size_t object_size(char *p) { return __builtin_object_size(p, 0); } int main(int argc, char **argv) { char buf[2]; printf("%zu\n", object_size(buf)); return 0; } This means that _FORTIFY_SOURCE buffer size checks do not currently work with Clang because it lowers the __builtin_object_size calls to (size_t)-1 before the wrappers are inlined into the call sites. This will also break other compelling use cases for this feature. It makes a lot of sense to lower it to a *known* value pre-inlining to get more work done in the early function passes, but replacing it with -1 before then isn't good. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 18 13:14:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Apr 2015 20:14:55 +0000 Subject: [LLVMbugs] [Bug 23281] New: clang allows invalid code with lambda expression move-assignment Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23281 Bug ID: 23281 Summary: clang allows invalid code with lambda expression move-assignment Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: ryan.burn at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The following code compiles in clang++ 3.7 but is rejected by gcc and intel compiler. #include int main() { auto f = [](int x) { return 7*x; }; using T = decltype(f); T h(f); h = std::move(f); return 0; } Also, the standard seems to disallow it: http://eel.is/c++draft/expr.prim.lambda#20 – lambdas have deleted copy assignment. Also, http://eel.is/c++draft/class.copy#20 says that means that deleted copy assignment means there will be no move assignment. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 18 16:00:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 18 Apr 2015 23:00:14 +0000 Subject: [LLVMbugs] [Bug 23252] New assert: "Symbol must already have been defined in ExecutePostLayoutBinding!" In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23252 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |WORKSFORME --- Comment #1 from David Majnemer --- Hans, this doesn't produce for me on r235260. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 00:53:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 07:53:46 +0000 Subject: [LLVMbugs] [Bug 18024] [-cxx-abi microsoft] clang ignores alignment specifier before class definition In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18024 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|LLVM Codegen |Frontend Resolution|--- |FIXED --- Comment #3 from David Majnemer --- Fixed in r235272. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 00:53:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 07:53:47 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 18024, which changed state. Bug 18024 Summary: [-cxx-abi microsoft] clang ignores alignment specifier before class definition https://llvm.org/bugs/show_bug.cgi?id=18024 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 05:09:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 12:09:41 +0000 Subject: [LLVMbugs] [Bug 23285] New: Assertion failed: (DelayedTypos.empty() && "Uncorrected typos!"), function ~Sema, file tools/clang/lib/Sema/Sema.cpp, line 273. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23285 Bug ID: 23285 Summary: Assertion failed: (DelayedTypos.empty() && "Uncorrected typos!"), function ~Sema, file tools/clang/lib/Sema/Sema.cpp, line 273. Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Reproduces with trunk r235079, with assertions enabled. Reduced test case: ====================================================================== a = 0(uintmax_t ====================================================================== Compile with: clang -cc1 -triple x86_64 -emit-obj testcase.c -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 06:27:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 13:27:39 +0000 Subject: [LLVMbugs] [Bug 23286] New: can't implicitly cast lvalue to rvalue with this cast kind Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23286 Bug ID: 23286 Summary: can't implicitly cast lvalue to rvalue with this cast kind Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dimitry at andric.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Reproduces with trunk r235079, with assertions enabled. Reduced test case: ====================================================================== struct ifmediareq { if_media_t ifm_ulist } fn1() { ifmediareq *ifmr int *ep; ep = ifm->ifm_list ====================================================================== Compile with: $ clang -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj testcase.c testcase.c:2:3: error: unknown type name 'if_media_t' if_media_t ifm_ulist ^ testcase.c:2:23: warning: expected ';' at end of declaration list if_media_t ifm_ulist ^ ; testcase.c:4:3: error: must use 'struct' tag to refer to type 'ifmediareq' ifmediareq *ifmr int *ep; ^ struct testcase.c:4:19: error: expected ';' at end of declaration ifmediareq *ifmr int *ep; ^ ; testcase.c:5:8: error: use of undeclared identifier 'ifm'; did you mean 'ifmr'? ep = ifm->ifm_list ^~~ ifmr testcase.c:4:15: note: 'ifmr' declared here ifmediareq *ifmr int *ep; ^ can't implicitly cast lvalue to rvalue with this cast kind UNREACHABLE executed at /share/dim/src/llvm/trunk/tools/clang/lib/Sema/Sema.cpp:347! Abort trap -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 08:22:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 15:22:47 +0000 Subject: [LLVMbugs] [Bug 23287] New: lldb crashes when displaying information for an array of structs and inside of struct there is a long double member field Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23287 Bug ID: 23287 Summary: lldb crashes when displaying information for an array of structs and inside of struct there is a long double member field Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: mihail.nistor at freescale.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14227 --> https://llvm.org/bugs/attachment.cgi?id=14227&action=edit test case to reproduce the problem This problem was reproduced by using Ubuntu 64bits; find more details below: $uname -a Linux 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux The relevant source code from test1.c is below: struct _lstruct{ long double a_long_double; }; int main(void) { struct _lstruct ls[10]; return EXIT_SUCCESS; } The source code was compiled by using the gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 version. The test1.elf was compiled by using the following command: $gcc -o test1.elf -g -O0 test1.c ## COMMAND TO REPRODUCE: $ lldb ./test1.elf (lldb) target create "./test1.elf" Current executable set to './test1.elf' (x86_64). (lldb) b main Breakpoint 1: where = test1.elf`main + 8 at test1.c:11, address = 0x00000000004004f5 (lldb) r Process 12180 launched: './test1.elf' (x86_64) Process 12180 stopped * thread #1: tid = 12180, 0x00000000004004f5 test1.elf`main + 8 at test1.c:11, name = 'test1.elf', stop reason = breakpoint 1.1 frame #0: 0x00000000004004f5 test1.elf`main + 8 at test1.c:11 8 int main(void) { 9 struct _lstruct ls[10]; 10 -> 11 return EXIT_SUCCESS; 12 } (lldb) p ls lldb: /home/work/llvm/lib/Support/APFloat.cpp:3657: void llvm::APFloat::toString(llvm::SmallVectorImpl&, unsigned int, unsigned int) const: Assertion `!buffer.empty() && "no characters in buffer!"' failed. Aborted (core dumped) or (lldb) p ls[0].a_long_double lldb: /home/work/llvm/lib/Support/APFloat.cpp:3657: void llvm::APFloat::toString(llvm::SmallVectorImpl&, unsigned int, unsigned int) const: Assertion `!buffer.empty() && "no characters in buffer!"' failed. Aborted (core dumped) ##EXPECTED The LLDB doesn’t crash. ## TOOLS VERSION INFO: $ lldb --version lldb version 3.7.0 (http://llvm.org/git/lldb.git revision ffc85fd7b1d05e955111a5e8805209039663017b clang revision e8d60ed0efed466103489cf893bd8bcc32d5dfa7) $ gcc --version gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 08:44:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 15:44:19 +0000 Subject: [LLVMbugs] [Bug 23276] Template version of std::pow fails to compile In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23276 Eric Fiselier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED See Also| |https://llvm.org/bugs/show_ | |bug.cgi?id=22486 Resolution|--- |INVALID --- Comment #4 from Eric Fiselier --- This is not a bug in libc++, that is a bug in your sample code. Nothing in the standard says std::pow is a template so writing std::pow(...) is not a valid way to use std::pow. See this bug for a better discussion about what is going on. https://llvm.org/bugs/show_bug.cgi?id=22486 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 10:26:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 17:26:39 +0000 Subject: [LLVMbugs] [Bug 23289] New: Trivial values not rematerialized Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23289 Bug ID: 23289 Summary: Trivial values not rematerialized Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedbugs at nondot.org Reporter: james.molloy at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code produces really suboptimal code seemingly on all targets. #define N 16 extern void g(int); int f(int *p, int n) { for (int i = 0; i < n; ++i) { for (int k = 0; k < n; ++k) { #pragma clang loop unroll(full) for (int j = 0; j < N; ++j) g((j+i)*k); } } } It produces a bunch of spills: (main loop block): .LBB0_2: @ %.preheader.lr.ph.us [31/1853] @ =>This Loop Header: Depth=1 @ Child Loop BB0_3 Depth 2 mov r5, r4 mov r9, #0 add r0, r5, #11 add r6, r5, #4 add r7, r5, #3 add r8, r5, #2 add r4, r5, #1 str r0, [sp, #24] @ 4-byte Spill add r0, r5, #10 str r0, [sp, #20] @ 4-byte Spill add r0, r5, #9 str r0, [sp, #16] @ 4-byte Spill add r0, r5, #8 str r0, [sp, #12] @ 4-byte Spill add r0, r5, #7 str r0, [sp, #8] @ 4-byte Spill add r0, r5, #6 str r0, [sp, #4] @ 4-byte Spill add r0, r5, #5 str r0, [sp] @ 4-byte Spill .LBB0_3: @ %.preheader.us @ Parent Loop BB0_2 Depth=1 @ => This Inner Loop Header: Depth=2 mul r0, r5, r9 bl g mul r0, r4, r9 bl g mul r0, r8, r9 bl g mul r0, r7, r9 bl g mul r0, r6, r9 bl g ldr r0, [sp] @ 4-byte Reload mul r0, r0, r9 bl g ldr r0, [sp, #4] @ 4-byte Reload mul r0, r0, r9 bl g ldr r0, [sp, #8] @ 4-byte Reload ... snip, more like this ... X86 also shows massive spilling. The instructions outside the loop are trivially rematerializable, but for some reason seem not to be considered. Because this affects all targets, I suspect this is a bug in the core RA/Spill placement algorithm. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 11:54:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 18:54:41 +0000 Subject: [LLVMbugs] [Bug 23290] New: CompilerInstance::createPreprocessor() leaks the Preprocessor sometimes Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23290 Bug ID: 23290 Summary: CompilerInstance::createPreprocessor() leaks the Preprocessor sometimes Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: yaron.keren at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified CompilerInstance::createPreprocessor should not be called more than once as this will lead to a memory leak of the Preprocessor PP and probably to multiple initializations of various other stuff such as what done in InitializePreprocessor() = all sorts of trouble. Yet, if an assert is added: void CompilerInstance::createPreprocessor(TranslationUnitKind TUKind) { assert(!PP); three regression tests start failing, meaning they do call CompilerInstance::createPreprocessor more than once and it's possible scenario. Clang :: FixIt/fixit-recompile.c Clang :: Misc/serialized-diags-single-issue.c Clang :: PCH/local_static.cpp The first two tests use fixit but the third do not. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 16:46:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 23:46:10 +0000 Subject: [LLVMbugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 23233, which changed state. Bug 23233 Summary: implement --dynamic-linker override option https://llvm.org/bugs/show_bug.cgi?id=23233 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 16:46:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 19 Apr 2015 23:46:10 +0000 Subject: [LLVMbugs] [Bug 23233] implement --dynamic-linker override option In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23233 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Davide Italiano --- r235282. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 21:34:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 04:34:58 +0000 Subject: [LLVMbugs] [Bug 23290] CompilerInstance::createPreprocessor() leaks the Preprocessor sometimes In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23290 Yaron Keren changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Yaron Keren --- Oops, just noted PP is IntrusiveRefCntPtr so no leak. It's still interesting to know if it si correct to call CompilerInstance::createPreprocessor() more than once as it's quite rare. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 19 23:58:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 06:58:54 +0000 Subject: [LLVMbugs] [Bug 23278] Regression(r235232): `Assertion `C1->getType() == C2->getType() && "Operand types in binary constant expression should match"' failed.` In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23278 Nico Weber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nico Weber --- We don't see this problem on our bots anymore. Thanks for the quick fix! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 00:57:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 07:57:06 +0000 Subject: [LLVMbugs] [Bug 23291] New: sizeof(vla) leads to segmentation fault Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23291 Bug ID: 23291 Summary: sizeof(vla) leads to segmentation fault Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: ahmad at a3f.at CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14228 --> https://llvm.org/bugs/attachment.cgi?id=14228&action=edit Clang's outut before segfaulting Following crashes my Clang: void sz(int (*a)[*]) { (void)sizeof *a; } My setup: $ clang -v Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix On GCC, this error is printed instead: "error: '[*]' not allowed in other than function prototype scope" which looks like the correct action. Output and source files attached -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 02:11:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 09:11:18 +0000 Subject: [LLVMbugs] [Bug 23292] New: llvm-symbolize can't demangle some function in libc++ Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23292 Bug ID: 23292 Summary: llvm-symbolize can't demangle some function in libc++ Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: dvyukov at google.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified clang version 3.7.0 (trunk 235290) Target: x86_64-unknown-linux-gnu Testing reproducer from https://llvm.org/bugs/show_bug.cgi?id=23235 with tsan-ified libc++ I got the following output: #0 _ZNSt3__18__invokeIMNS_19__async_assoc_stateIbNS_12__async_funcIZ4mainE3$_0JEEEEEFvvEPS5_JEvEEDTcldsdeclsr3std3__1E7forwardIT0_Efp0_Efp_spclsr3std3__1E7forwardIT1_Efp1_EEEOT_OS9_DpOSA_ include/c++/v1/__functional_base:382:43 (a.out+0x000000499458) The function is not demangled while all other function are demangled. This looks like a bug in demangler. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 03:43:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 10:43:53 +0000 Subject: [LLVMbugs] [Bug 23293] New: libcxx: racy use-after-free on condition_variable Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23293 Bug ID: 23293 Summary: libcxx: racy use-after-free on condition_variable Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: dvyukov at google.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified clang version 3.7.0 (trunk 235293) Target: x86_64-unknown-linux-gnu The program is: #include #include #include #include std::atomic _counter; int main() { _counter = 1; auto f = std::async(std::launch::async, []{ _counter += 2; return true; }); std::cout << "Result: " << std::boolalpha << f.get() << "\n"; return 0; } ThreadSanitizer says: ================== WARNING: ThreadSanitizer: data race (pid=19479) Write of size 8 at 0x7d200000bfc0 by main thread: #0 pthread_cond_destroy /ssd/src/llvm/build/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1153 (a.out+0x00000044aa8c) #1 std::__1::condition_variable::~condition_variable() build/../projects/libcxx/src/condition_variable.cpp:23:5 (libc++.so.1+0x00000008cb69) #2 std::__1::__assoc_sub_state::~__assoc_sub_state() build/bin/../include/c++/v1/future:515:24 (a.out+0x00000049999a) #3 std::__1::__async_assoc_state >::~__async_assoc_state() build/bin/../include/c++/v1/future:940:7 (a.out+0x0000004992d5) #4 std::__1::__assoc_state::__on_zero_shared() build/bin/../include/c++/v1/future:635:5 (a.out+0x000000499a63) #5 std::__1::__async_assoc_state >::__on_zero_shared() build/bin/../include/c++/v1/future:990:5 (a.out+0x00000049930d) #6 std::__1::__shared_count::__release_shared() build/../projects/libcxx/src/memory.cpp:63:9 (libc++.so.1+0x00000008eb20) #7 std::__1::__release_shared_count::operator()(std::__1::__shared_count*) build/bin/../include/c++/v1/future:1155:41 (a.out+0x00000049a155) #8 std::__1::unique_ptr::reset(std::__1::__shared_count*) build/bin/../include/c++/v1/memory:2669:13 (a.out+0x0000004996bd) #9 std::__1::unique_ptr::~unique_ptr() build/bin/../include/c++/v1/memory:2637 (a.out+0x0000004996bd) #10 std::__1::future::get() build/bin/../include/c++/v1/future:1173 (a.out+0x0000004996bd) #11 main /tmp/shared_ptr.cc:17:50 (a.out+0x000000498f62) Previous read of size 8 at 0x7d200000bfc0 by thread T1: #0 pthread_cond_broadcast /ssd/src/llvm/build/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1146 (a.out+0x000000447e40) #1 std::__1::condition_variable::notify_all() build/../projects/libcxx/src/condition_variable.cpp:35:5 (libc++.so.1+0x00000008cbc9) #2 void std::__1::__assoc_state::set_value(bool&&) build/bin/../include/c++/v1/future:655:5 (a.out+0x000000499c01) #3 std::__1::__async_assoc_state >::__execute() build/bin/../include/c++/v1/future:975:9 (a.out+0x00000049934e) #4 _ZNSt3__18__invokeIMNS_19__async_assoc_stateIbNS_12__async_funcIZ4mainE3$_0JEEEEEFvvEPS5_JEvEEDTcldsdeclsr3std3__1E7forwardIT0_Efp0_Efp_spclsr3std3__1E7forwardIT1_Efp1_EEEOT_OS9_DpOSA_ build/bin/../include/c++/v1/__functional_base:382:12 (a.out+0x0000004994a1) #5 void std::__1::__thread_execute >::*)(), std::__1::__async_assoc_state >*, 1ul>(std::__1::tuple >::*)(), std::__1::__async_assoc_state >*>&, std::__1::__tuple_indices<1ul>) build/bin/../include/c++/v1/thread:337 (a.out+0x0000004994a1) #6 void* std::__1::__thread_proxy >::*)(), std::__1::__async_assoc_state >*> >(void*) build/bin/../include/c++/v1/thread:347 (a.out+0x0000004994a1) Location is heap block of size 120 at 0x7d200000bf80 allocated by main thread: #0 operator new(unsigned long) /ssd/src/llvm/build/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:615 (a.out+0x00000043e08f) #1 std::__1::future std::__1::__make_async_assoc_state >(std::__1::__async_func&&) build/bin/../include/c++/v1/future:2312:13 (a.out+0x000000499035) #2 std::__1::future::type>::type> std::__1::async(std::__1::launch, main::$_0&&) build/bin/../include/c++/v1/future:2361:16 (a.out+0x000000498fce) #3 main /tmp/shared_ptr.cc:12:14 (a.out+0x000000498f0d) Thread T1 (tid=19481, finished) created by main thread at: #0 pthread_create /ssd/src/llvm/build/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:951 (a.out+0x000000447123) #1 std::__1::thread::thread >::*)(), std::__1::__async_assoc_state >*, void>(void (std::__1::__async_assoc_state >::*&&)(), std::__1::__async_assoc_state >*&&) build/bin/../include/c++/v1/thread:359:16 (a.out+0x000000499282) #2 std::__1::future std::__1::__make_async_assoc_state >(std::__1::__async_func&&) build/bin/../include/c++/v1/future:2313:5 (a.out+0x0000004990a4) #3 std::__1::future::type>::type> std::__1::async(std::__1::launch, main::$_0&&) build/bin/../include/c++/v1/future:2361:16 (a.out+0x000000498fce) #4 main /tmp/shared_ptr.cc:12:14 (a.out+0x000000498f0d) SUMMARY: ThreadSanitizer: data race build/../projects/libcxx/src/condition_variable.cpp:23:5 in std::__1::condition_variable::~condition_variable() ================== The program was built as: clang++ test.cc -fsanitize=thread -std=c++14 -stdlib=libc++ -lc++abi -Wall -g -O1 with tsan-instrumented libcxx (see instructions here https://code.google.com/p/memory-sanitizer/wiki/LibcxxHowTo). The problem is here: __assoc_state<_Rp>::set_value(_Arg&& __arg) { unique_lock __lk(this->__mut_); #ifndef _LIBCPP_NO_EXCEPTIONS if (this->__has_value()) throw future_error(make_error_code(future_errc::promise_already_satisfied)); #endif ::new(&__value_) _Rp(_VSTD::forward<_Arg>(__arg)); this->__state_ |= base::__constructed | base::ready; __lk.unlock(); __cv_.notify_all(); } The function first unlocks the mutex and after than signals the cond var. But once the mutex is unlocked the object can be destroyed as it is in ready state. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 03:45:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 10:45:55 +0000 Subject: [LLVMbugs] [Bug 23235] Multiple races reported in std::async (TSan) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23235 Dmitry Vyukov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Dmitry Vyukov --- Filed https://llvm.org/bugs/show_bug.cgi?id=23293 for the racy use-after-free on cond var. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 05:31:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 12:31:46 +0000 Subject: [LLVMbugs] [Bug 23294] New: Performance degradation of eembc.1.1/idctrn01 test on x86 Avoton-1.7 due to adding of LICM pass after loop unrolling Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23294 Bug ID: 23294 Summary: Performance degradation of eembc.1.1/idctrn01 test on x86 Avoton-1.7 due to adding of LICM pass after loop unrolling Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedbugs at nondot.org Reporter: sergey.k.okunev at gmail.com CC: david.l.kreitzer at intel.com, denis.briltz at intel.com, elena.demikhovsky at intel.com, llvmbugs at cs.uiuc.edu, michael.m.kuperstein at intel.com, sergos.gnu at gmail.com, zia.ansari at intel.com Classification: Unclassified Created attachment 14231 --> https://llvm.org/bugs/attachment.cgi?id=14231&action=edit Initial ll-file of considered 't_run_test' function Bisect analysis showed LLVM revision 232011 is responsible for the degradation. The comments to commit are the following. commit a56999c5decca0023e5ce481fc08571e227e3aa3 Author: Kevin Qin Date: Thu Mar 12 05:36:01 2015 +0000 Reapply 'Run LICM pass after loop unrolling pass.' It's firstly committed at r231630, and reverted at r231635. Function pass InstructionSimplifier is inserted as barrier to make sure loop unroll pass won't affect on LICM pass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 232011 91177308-0d34-0410-b5e6-96231b3b80d8 LLVM-clang options: O2 -ffast-math -m32 -mfpmath=sse -march=slm -fPIE –pie The eembc_1_1/idctrn01 test has several hot loops with 3 levels of nesting (8 x 8 x 8 iterations). Each of these loops was fully unrolled. In adding the loop invariant code motion pass (LICM) after the loop unroll pass (in r. 232011), there are 16 loads hoisted up and the same 16 stores with constant addresses sunk from the body of hot loop. When machine specific code was generated for x86_32, AVT1.7 architecture these 16 loaded and stored values are transferred by stack spill, fill instructions due to lack of xmm registers. As result additional loads and stores (fills and spills) were generated inside, before and after loop in r232011 case. So, the number of loads and stores inside loop are very close for both revisions and ‘additional’ loads and stores before and after loop cause the regression. Changes enabled by considered revision in terms of simplified IR looks as follows. +16 <4 x i32> loads -> virt_regs1 !! hoisted up loads with const. addr br label %l_loop %l_loop: +16 <4 x i32> phi assignments calculations (virt_regs1 / virt_regs2) !! loads and stores were replaced by virtual regs br %exitcond, label %l_exit, label %l_loop %l_exit: +16 <4 x i32> phi assignments +16 virt_regs2 -> <4 x i32> stores !! sunk stores with const. addr Corresponding asm loop code fragments with one load-store chain for two revisions are the following. r232010: ------- xor %ecx,%ecx ; start of loop1 l_f772f5a0: add $0x20,%ecx movsbl -0x38(%eax),%edx movdqu 0x2d0(%ebx),%xmm6 !! load with const addr. is inside loop movd %edx,%xmm0 pshufd $0x0,%xmm0,%xmm2 pmulld %xmm2,%xmm3 paddd %xmm3,%xmm6 movdqu %xmm6,0x2d0(%ebx) !! store with const. addr. is inside loop ; ... and 15 more block like that ... add $0x1,%eax cmp $0x100,%ecx jne l_f772f5a0 ; end of loop1 vs. r232011: xor %ecx,%ecx movdqu 0x2d0(%ebx),%xmm0 !! hoisted up load with const. addr movdqa %xmm0,0xd0(%esp) !! spill-instr. before loop ; and 15 more movs like that ; start of loop1 l_f77c7680: add $0x20,%ecx movsbl -0x38(%eax),%edx movdqa 0xd0(%esp),%xmm7 !! fill-instr. inside loop movd %edx,%xmm2 pshufd $0x0,%xmm2,%xmm2 pmulld %xmm2,%xmm0 paddd %xmm0,%xmm7 movdqa %xmm7,0xd0(%esp) !! spill-instr. inside loop ; … and 15 more block like that … add $0x1,%eax cmp $0x100,%ecx jne l_f77c7680 ; end of loop1 movdqa 0xd0(%esp),%xmm0 !! fill-instr. after loop movdqu %xmm0,0x2d0(%ebx) !! sunk stores with const. addr ; and 15 more movs like that Okunev Sergey, Software Engineer Intel Compiler Team -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 05:42:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 12:42:15 +0000 Subject: [LLVMbugs] [Bug 23295] New: clang requires -std=c++11 or -std=c++14 to compile lamda assignments in boost 1.57/1.58 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23295 Bug ID: 23295 Summary: clang requires -std=c++11 or -std=c++14 to compile lamda assignments in boost 1.57/1.58 Product: clang Version: 2.6 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: howarth.mailing.lists at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I realize this is actually a boost bug but with the 1.58 release, it has existed for two boost releases now. The issue is reported at https://svn.boost.org/trac/boost/ticket/10785 and the bug details are that for boost 1.57 and 1.58, the test case... #include #include #include #include int add(int a, int b) { return a+b; } int main() { boost::function fuse = boost::lambda::bind(&add, boost::lambda::_1, -boost::lambda::_2); int a = fuse(3,6); std::cout << a << std::endl; } requires -std=c++11 or -std=c++14 to avoid the compiler error seen with the default -std=c++03. The problem impacts the builds of a number of packages that use boost and is annoying because forcing -std=c++11 sometimes results in new compilation issues. In a related question, does clang have any form of pragma which would allow -std=c++11 to be selectively invoked at the source file level? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 11:16:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 18:16:58 +0000 Subject: [LLVMbugs] [Bug 23291] sizeof(vla) leads to segmentation fault In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23291 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |WORKSFORME --- Comment #3 from David Majnemer --- I believe I fixed this bug fairly recently, it doesn't reproduce on clang version 3.7.0 (trunk 235253) (llvm/trunk 235260). Furthermore, please file bugs reported against 'Apple LLVM' with Apple. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 11:23:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 18:23:17 +0000 Subject: [LLVMbugs] [Bug 23296] New: code selection does not match horizontal add Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23296 Bug ID: 23296 Summary: code selection does not match horizontal add Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: matze at braunis.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14232 --> https://llvm.org/bugs/attachment.cgi?id=14232&action=edit Horizontal add code selection missed For the attached .ll file llvm fails to select the apropriate horizontal add code. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 11:44:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 18:44:34 +0000 Subject: [LLVMbugs] [Bug 23273] Assertion failed: (Subtarget->hasAVX() && "Expected a subtarget with AVX!"), function X86SelectSIToFP In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23273 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 11:49:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 18:49:26 +0000 Subject: [LLVMbugs] [Bug 23297] New: Extended asm %Qx/%Rx are backwards on big-endian ARMv7 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23297 Bug ID: 23297 Summary: Extended asm %Qx/%Rx are backwards on big-endian ARMv7 Product: clang Version: 3.5 Hardware: Other OS: other Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: solra at bizna.name CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This bug revolves around an obscure case in a compatible reimplementation of an essentially undocumented aspect of a GCC extension. Here goes. Example code: (compile with "-O3 -target armv7a-eabi" and either "-mlittle-endian" or "-mbig-endian") #include void test() { long long var; asm("MRRC p3, 0, %Q0, %R0, cr0":"=r"(var):); var = var + 1; printf("%016llX\n", var); } In GCC's extended asm for ARM targets, Q and R indicate, respectively, the least significant and most significant register of a register pair. The given example is a transfer from a 64-bit coprocessor register (cr0 of coprocessor #3) to two core registers (the low-order half and the high-order half of "var"). Regardless of whether I compile with -mlittle-endian or -mbig-endian, r0 is given as the low register and r1 as the high register: 8: ec510300 mrrc 3, 0, r0, r1, cr0 But the following two instructions demonstrate that this order is incorrect on big-endian: Little-endian: (r0 is low, r1 is high) c: e2902001 adds r2, r0, #1 10: e2a13000 adc r3, r1, #0 Big-endian: (r0 is high, r1 is low) c: e2913001 adds r3, r1, #1 10: e2a02000 adc r2, r0, #0 GCC 4.6, on the other hand, handles this correctly: Little-endian: 8: ec532300 mrrc 3, 0, r2, r3, cr0 Big-endian: 8: ec523300 mrrc 3, 0, r3, r2, cr0 Unrelatedly, it is interesting to compare GCC's optimization of this function to Clang's... GCC saves, uses, and restores some wholly unnecessary scratch registers, but also performs a tail call optimization, which Clang doesn't (and can't, since it saves the frame pointer while GCC doesn't). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 13:03:29 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 20:03:29 +0000 Subject: [LLVMbugs] [Bug 22849] Assertion fail at lib/AST/Decl.cpp:1856 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22849 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Reid Kleckner --- The reduced and original test cases work with r235335. I also want to point out that GCC itself rejects statement expressions in records in C++ mode, so anyone using this feature is skating on thin ice. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 13:43:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 20:43:00 +0000 Subject: [LLVMbugs] [Bug 23275] Support VS 2015 CTP6 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23275 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |WORKSFORME --- Comment #1 from Reid Kleckner --- The first issue can be solved by running in the appropriate environment. If I run "Developer Command Prompt for VS2015", and run clang-cl inside there, the issue is resolved. The second issue is the use of char16_t and char32_t, which became builtin types in 2015. The trouble is that defining those types in pre-2015 compilations causes errors when the headers define the types. David gave up and relies on the user to set -fms-compatibility-version to something. We default to 2013 compatibility, so if you want 2015 compat, pass something like -fms-compatibility-version=19.00.22609. Ultimately, you need to set this in order to link real executables, so this isn't a new imposition. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 15:44:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 22:44:12 +0000 Subject: [LLVMbugs] [Bug 23300] New: Regression(r235232): Log-related tests in Chromium started failing Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23300 Bug ID: 23300 Summary: Regression(r235232): Log-related tests in Chromium started failing Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Now that issue 23278 is fixed, head clang compiles Chromium again. However, some tests now fail. Running `out\Release\components_unittests.exe --gtest_filter=PersistedLogsTest.LongButSmallLogList` with a component_unittests.exe binary build by trunk clang fails, but if I revert r235232 (and r235258, r235261), rebuild clang, and do a full rebuild of the test binary, the crash goes away. I don't have anything close to a reduced repro at this point. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 15:53:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 22:53:27 +0000 Subject: [LLVMbugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 23232, which changed state. Bug 23232 Summary: implement -x and -X options, delete all local / temporary local symbols https://llvm.org/bugs/show_bug.cgi?id=23232 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 15:53:27 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 20 Apr 2015 22:53:27 +0000 Subject: [LLVMbugs] [Bug 23232] implement -x and -X options, delete all local / temporary local symbols In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23232 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Davide Italiano --- r235247 and r235357 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 17:32:25 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 00:32:25 +0000 Subject: [LLVMbugs] [Bug 23301] New: InstCombine: objectsize of alloca optimized to undef returns unknown Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23301 Bug ID: 23301 Summary: InstCombine: objectsize of alloca optimized to undef returns unknown Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: ahmed.bougacha at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Reported by Daniel Micay in PR23280: #include #include static inline __attribute__((always_inline)) size_t object_size(char *p) { return __builtin_object_size(p, 0); } int main(int argc, char **argv) { char buf[2]; printf("%zu\n", object_size(buf)); return 0; } This returns -1 because buf is optimized to undef by InstCombine. When InstCombine tries to erase an alloca, the isAllocSiteRemovable logic is smarter than the RAUW-undef logic: when there's a (objectsize (GEP/bitcast (alloca))), we should look through the alloca users to properly lower the objectsize calls. We currently just do something like alloca->RAUW(undef). Perhaps the RAUW-undef logic and isAllocSiteRemovable should match? This would let the above example print 2 instead of the current -1. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 20 23:36:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 06:36:20 +0000 Subject: [LLVMbugs] [Bug 16439] shl by 0 produces the wrong result for i128 on 32bit systems In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=16439 Paweł Bylica changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paweł Bylica --- Patch committed -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 07:43:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 14:43:50 +0000 Subject: [LLVMbugs] [Bug 21184] x86 code generation miscompilation (wider-than-legal types) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21184 Paweł Bylica changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paweł Bylica --- The problem is with the shl instruction and was fixed in revision r235370. *** This bug has been marked as a duplicate of bug 16439 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 08:24:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 15:24:39 +0000 Subject: [LLVMbugs] [Bug 23302] New: The Kaleidoscope tutorial is broken Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23302 Bug ID: 23302 Summary: The Kaleidoscope tutorial is broken Product: Documentation Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: General docs Assignee: unassignedbugs at nondot.org Reporter: Per.Mildner at sics.se CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Chapter 5 and Chapter 6 of the Kaleidoscope tutorial does not work at all. the code in Chapter 4 has had some changes to make it work with MCJIT, but the accompanying tutorial text no longer explains the actual code. This was discussed in the mailing list thread http://thread.gmane.org/gmane.comp.compilers.llvm.devel/80164 (Apologies if I got things wrong. I am new here.) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 08:45:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 15:45:52 +0000 Subject: [LLVMbugs] [Bug 23303] New: this Template code might not output error message Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23303 Bug ID: 23303 Summary: this Template code might not output error message Product: clang Version: 3.5 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: kunling at lingcc.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The code comes from stackoverflow http://stackoverflow.com/q/29776850/566459 // Forward declaration: template struct Base; template struct BaseFriend { friend struct Base; }; // Actual declaration: template struct Base { void foo() {} }; struct DerivedFriend : BaseFriend {}; struct Derived : Base { void foo(int) { Base::foo(); } }; G++ could successfully compile it, while using clang++ 3.6, it gives the following error message: error: too few template arguments for class template 'Base' Base::foo(); ^ test.cpp:3:8: note: template is declared here struct Base; ^ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 10:25:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 17:25:47 +0000 Subject: [LLVMbugs] [Bug 23296] code selection does not match horizontal add In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23296 Matthias Braun changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |matze at braunis.de --- Comment #4 from Matthias Braun --- This bug was fixed in r235394 as suggested by Andrea. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 11:43:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 18:43:52 +0000 Subject: [LLVMbugs] [Bug 23304] New: map fails copy-assignment Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23304 Bug ID: 23304 Summary: map fails copy-assignment Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: eugeni.stepanov at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified #include #include int main() { std::map m1, m2; m1 = m2; } As I read the standard, the only requirement is that pair must be CopyInsertable, and it looks like it is. Error text: In file included from ../1.cc:1: In file included from /code/llvm/build/bin/../include/c++/v1/string:439: In file included from /code/llvm/build/bin/../include/c++/v1/algorithm:627: /code/llvm/build/bin/../include/c++/v1/utility:299:15: error: no viable overloaded '=' first = __p.first; ~~~~~ ^ ~~~~~~~~~ /code/llvm/build/bin/../include/c++/v1/map:610:15: note: in instantiation of member function 'std::__1::pair, const std::__1::basic_string >::operator=' requested here {__nc = __v.__cc; return *this;} ^ /code/llvm/build/bin/../include/c++/v1/__tree:1265:35: note: in instantiation of member function 'std::__1::__value_type, const std::__1::basic_string >::operator=' requested here __cache->__value_ = *__first; ^ /code/llvm/build/bin/../include/c++/v1/__tree:1206:9: note: in instantiation of function template specialization 'std::__1::__tree, const std::__1::basic_string >, std::__1::__map_value_compare, std::__1::__value_type, const std::__1::basic_string >, std::__1::less >, true>, std::__1::allocator, const std::__1::basic_string > > >::__assign_multi, const std::__1::basic_string >, std::__1::__tree_node, const std::__1::basic_string >, void *> *, long> >' requested here __assign_multi(__t.begin(), __t.end()); ^ /code/llvm/build/bin/../include/c++/v1/map:898:21: note: in instantiation of member function 'std::__1::__tree, const std::__1::basic_string >, std::__1::__map_value_compare, std::__1::__value_type, const std::__1::basic_string >, std::__1::less >, true>, std::__1::allocator, const std::__1::basic_string > > >::operator=' requested here __tree_ = __m.__tree_; ^ ../1.cc:6:6: note: in instantiation of member function 'std::__1::map, const std::__1::basic_string, std::__1::less >, std::__1::allocator, const std::__1::basic_string > > >::operator=' requested here m1 = m2; -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 12:23:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 19:23:47 +0000 Subject: [LLVMbugs] [Bug 23266] raw_svector_ostream::pwrite problems In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23266 Yaron Keren changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Yaron Keren --- Fixed by Rafael's patch. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 12:55:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 19:55:53 +0000 Subject: [LLVMbugs] [Bug 21112] Allow using ASan and UBSan together on OSX In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21112 Alexey Samsonov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Alexey Samsonov --- ASan+UBSan should now work fine on OS X: UBSan bits are now embedded into ASan runtime, so if you compile/link with -fsanitize=address,undefined the binary should only depend on libclang_rt.asan_osx_dynamic.dylib (which would also contain UBSan handlers). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 14:30:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 21:30:06 +0000 Subject: [LLVMbugs] [Bug 23300] Regression(r235232): Log-related tests in Chromium started failing In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23300 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ahmed Bougacha --- Should be fixed with r235419. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 14:51:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 21:51:56 +0000 Subject: [LLVMbugs] [Bug 17049] Cannot select: 0x7f8f1a887a10: f32 = fp16_to_fp32 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17049 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |ahmed.bougacha at gmail.com Resolution|--- |FIXED --- Comment #3 from Ahmed Bougacha --- This has been fixed in the meantime, and should emit __gnu_h2f/f2h_ieee compiler-rt calls on targets without the hardware support. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 15:01:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 22:01:32 +0000 Subject: [LLVMbugs] [Bug 16491] Half precision floating point types broken on X86 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=16491 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |ahmed.bougacha at gmail.com Resolution|--- |FIXED --- Comment #1 from Ahmed Bougacha --- It should mostly work fine (on all targets) thanks to r235215. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 15:04:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 22:04:39 +0000 Subject: [LLVMbugs] [Bug 17047] Assertion `LC != RTLIB::UNKNOWN_LIBCALL && "Unsupported FP_EXTEND!"' failed In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17047 Ahmed Bougacha changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |ahmed.bougacha at gmail.com Resolution|--- |FIXED --- Comment #3 from Ahmed Bougacha --- This has been fixed in the meantime, and should emit __gnu_h2f/f2h_ieee compiler-rt calls on targets without the hardware support. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 15:22:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 22:22:49 +0000 Subject: [LLVMbugs] [Bug 23305] New: Support __fp16 vectors Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23305 Bug ID: 23305 Summary: Support __fp16 vectors Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: ahmed.bougacha at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified __fp16 is a storage-only type, and there are two CodeGen variants: - soften to i16, promote using llvm.convert.to/from.fp16 (e.g., X86) - when LangOptions::NativeHalfType or HalfArgsAndReturns, use the LLVM "half" type, promote using fpext/fptrunc (e.g., AArch64) In both cases, we don't do the right thing for vectors. On X86, this: typedef __fp16 __attribute__((__ext_vector_type__(4))) v4f16; void foo(v4f16 *a, v4f16 *b, v4f16 *c) { *c = *a + *b; } generates the very broken: %3 = add <4 x i16> %1, %2 This is because the Sema::UsualUnaryConversions don't apply to VectorTypes (see Sema::CheckVectorOperands), so we never try to promote to v4f32 (as we would promote __fp16 to f32). Even if we decide to reject that code and never do the implicit promotion, the alternative is also broken: typedef __fp16 __attribute__((__ext_vector_type__(4))) v4f16; typedef float __attribute__((__ext_vector_type__(4))) v4f32; void foo(v4f16 *a, v4f16 *b, v4f16 *c) { *c = __builtin_convertvector(*a, v4f32); } Generates: %2 = uitofp <4 x i16> %1 to <4 x float> Even when "half" is used instead of i16 (AArch64, or after we migrate away from the convert intrinsics), we generate IR without the promotion: %3 = fadd <4 x half> %1, %2 Relying on the backend to do the promotion. However, this has slightly different semantics, because LLVM works at the instruction level, and clang at the expression level. Consider: void foo(v4f16 *a, v4f16 *b, v4f16 *c) { *c = (*a + *b) + *c; } Doing the promotion in clang means the intermediate result is a v4f32. Doing it in LLVM means the intermediate result is truncated back to v4f16, before being extended again to v4f32. This can give different result, and it's probably best to mirror the scalar clang behavior of promoting entire expressions. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 15:31:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 22:31:19 +0000 Subject: [LLVMbugs] [Bug 23306] New: patchpoint: ran out of registers during register allocation Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23306 Bug ID: 23306 Summary: patchpoint: ran out of registers during register allocation Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedbugs at nondot.org Reporter: undingen at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14235 --> https://llvm.org/bugs/attachment.cgi?id=14235&action=edit Example using a lot of GVs When I create a patchpoint with many live values I get a "ran out of registers during register allocation" error. I tested it with 3.6 and trunk. Changing the regalloc does not help. @c0 = external global i64 @c1 = external global i64 ... %ret = call i64 (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.i64(i64 0, i32 512, i8* inttoptr (i64 -1 to i8*), i32 0, i64* @c0, i64* @c1, i64* @c2, i64* @c3, i64* @c4, i64* @c5, i64* @c6, i64* @c7, i64* @c8, i64* @c9, i64* @c10, i64* @c11, i64* @c12, i64* @c13, i64* @c14, i64* @c15) ret i64 %ret llc output: LLVM ERROR: ran out of registers during register allocation -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 16:41:43 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 21 Apr 2015 23:41:43 +0000 Subject: [LLVMbugs] [Bug 23304] map fails copy-assignment In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23304 Evgeniy Stepanov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Evgeniy Stepanov --- Aw, I got confused by the notations in table 99 where t is a value of type X (and not T), a is a value of type T (and not A) and so on. Thanks for the explanation. I guess it makes this works-as-intended. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 17:25:44 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 00:25:44 +0000 Subject: [LLVMbugs] [Bug 23307] New: clang fails to compile rstudio-0.98.1103/src/cpp/session/modules/SessionHTMLPreview.cpp against libc++ Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23307 Bug ID: 23307 Summary: clang fails to compile rstudio-0.98.1103/src/cpp/session/modules/SessionHTMLP review.cpp against libc++ Product: clang Version: 3.6 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: howarth.mailing.lists at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14237 --> https://llvm.org/bugs/attachment.cgi?id=14237&action=edit preprocessed source file for rstudio-0.98.1103/src/cpp/session/modules/SessionHTMLPreview.cpp The rstudio-0.98.1103/src/cpp/session/modules/SessionHTMLPreview.cpp file fails to compile with clang++ 3.6.0 against libc++ but compiles against libstdc++. The cryptic error is... # clang++ -DBOOST_ASIO_DISABLE_KQUEUE -DBOOST_ENABLE_ASSERT_HANDLER -DBOOST_SIGNALS_NO_DEPRECATION_WARNING -std=c++11 -stdlib=libc++ -O3 -DNDEBUG -c SessionHTMLPreview.ii In file included from /sw/src/fink.build/rstudio-desktop-0.98.1103-5/rstudio-0.98.1103/src/cpp/session/modules/SessionHTMLPreview.cpp:17: In file included from /sw/src/fink.build/rstudio-desktop-0.98.1103-5/rstudio-0.98.1103/src/cpp/session/modules/SessionHTMLPreview.hpp:25: In file included from /sw/src/fink.build/rstudio-desktop-0.98.1103-5/rstudio-0.98.1103/src/cpp/core/include/core/json/Json.hpp:19: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:439: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1572:12: error: no matching function for call to '__search' return std::__1::__search::type> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1586:22: note: in instantiation of function template specialization 'std::__1::search >, std::__1::__wrap_iter, std::__1::__equal_to >' requested here return std::__1::search(__first1, __last1, __first2, __last2, __equal_to<__v1, __v2>()); ^ /sw/src/fink.build/rstudio-desktop-0.98.1103-5/rstudio-0.98.1103/src/cpp/session/modules/SessionHTMLPreview.cpp:555:23: note: in instantiation of function template specialization 'std::__1::search >, std::__1::__wrap_iter >' requested here if (eod == std::search(std::istreambuf_iterator(*pStr), ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1456:1: note: candidate function [with _BinaryPredicate = std::__1::__equal_to &, _RandomAccessIterator1 = std::__1::istreambuf_iterator >, _RandomAccessIterator2 = std::__1::__wrap_iter] not viable: no known conversion from 'typename std::iterator_traits > >::iterator_category' (aka 'std::__1::input_iterator_tag') to 'std::__1::random_access_iterator_tag' for 6th argument __search(_RandomAccessIterator1 __first1, _RandomAccessIterator1 __last1, ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1419:1: note: candidate function [with _BinaryPredicate = std::__1::__equal_to &, _ForwardIterator1 = std::__1::istreambuf_iterator >, _ForwardIterator2 = std::__1::__wrap_iter] not viable: no known conversion from 'typename std::iterator_traits > >::iterator_category' (aka 'std::__1::input_iterator_tag') to 'std::__1::forward_iterator_tag' for 6th argument __search(_ForwardIterator1 __first1, _ForwardIterator1 __last1, ^ 1 error generated. Is this a valid error message? The preprocessed source to reproduce the error is attached. FYI, this is one of only two remaining issues preventing rstudio from being entirely built against libc++ under clang... https://support.rstudio.com/hc/communities/public/questions/203373368-Rstudio-0-98-1103-has-only-two-libc-build-issues-left -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 17:44:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 00:44:01 +0000 Subject: [LLVMbugs] [Bug 23049] [X86] 64-bit integer stores are not always illegal on a 32-bit system In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23049 Sanjay Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sanjay Patel --- After: http://reviews.llvm.org/rL235014 http://reviews.llvm.org/rL235210 http://reviews.llvm.org/rL235460 We generate: movl 4(%esp), %eax movlps %xmm0, (%eax) retl Exedeps is choosing movlps rather than movq because we're not using the extracted element and float is the default domain (smallest encoding?). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 19:19:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 02:19:41 +0000 Subject: [LLVMbugs] [Bug 23308] New: clang-cl errors about internal linkage on method in dllexported class that takes parameter with internal linkage Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23308 Bug ID: 23308 Summary: clang-cl errors about internal linkage on method in dllexported class that takes parameter with internal linkage Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: hans at chromium.org CC: llvmbugs at cs.uiuc.edu, nicolasweber at gmx.de Classification: Unclassified For example: $ cat | bin/clang-cl /c /Tp - namespace { struct T { }; } struct __declspec(dllexport) S { void foo(T &t); }; void S::foo(T &t) { }; (7,9) : error: 'S::foo' must have external linkage when declared 'dllexport' void S::foo(T &t) { }; ^ 1 error generated. Since T is in an anonymous namespace, S::foo gets internal linkage, and Clang errors when trying to dllexport it. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 19:51:17 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 02:51:17 +0000 Subject: [LLVMbugs] [Bug 23308] clang-cl errors about internal linkage on method in dllexported class that takes parameter with internal linkage In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23308 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |WORKSFORME --- Comment #1 from David Majnemer --- Why should we accept this? Microsoft gives an arbitrary name for 'T' which is not stable. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 19:54:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 02:54:39 +0000 Subject: [LLVMbugs] [Bug 23308] clang-cl errors about internal linkage on method in dllexported class that takes parameter with internal linkage In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23308 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME |--- --- Comment #2 from Hans Wennborg --- Because it's fine as long as one doesn't try to call the function outside the TU. Patch idea: http://reviews.llvm.org/D9182 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 21 21:31:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 04:31:31 +0000 Subject: [LLVMbugs] [Bug 23309] New: wrong code at -O1 and above on x86_64-linux-gnu Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23309 Bug ID: 23309 Summary: wrong code at -O1 and above on x86_64-linux-gnu Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: su at cs.ucdavis.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code is miscompiled by the current clang trunk (and 3.6.0) on x86_64-linux-gnu at -O1 and above in both 32-bit and 64-bit modes. This is a regression from 3.5.0. $ clang-trunk -v clang version 3.7.0 (trunk 235404) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.0.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.0.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -O0 small.c; ./a.out $ clang-3.5.0 -O1 small.c; ./a.out $ $ clang-trunk -O1 small.c $ ./a.out Aborted (core dumped) $ $ clang-3.6.0 -O1 small.c $ ./a.out Aborted (core dumped) $ ------------------------ int a, b, c, e, f; int fn1 () { int g; char i; for (; b < 1; b++) { c = 0; e = f || a + 1; i = 1 - c; g = -3 - i - e; if (g & 1) return 0; } return 0; } int main () { fn1 (); if (b) __builtin_abort (); return 0; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 01:29:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 08:29:41 +0000 Subject: [LLVMbugs] [Bug 23310] New: llvm-dis crashes Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23310 Bug ID: 23310 Summary: llvm-dis crashes Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: chengniansun at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14238 --> https://llvm.org/bugs/attachment.cgi?id=14238&action=edit test case to crash llvm-dis I used llvm to parse bitcode files, but my program crashed when parsing the attached bitcode file. I then tried llvm-dis, and it also crashed. $: /usr/local/clang-trunk/bin/llvm-dis main/libwebp-0.4.0/src/dsp/dec_sse2.bc 0 llvm-dis 0x000000000051114a 1 llvm-dis 0x00000000005125cb 2 libpthread.so.0 0x00007fc9afbc8340 3 libpthread.so.0 0x0000000001653ba9 Stack dump: 0. Program arguments: /usr/local/clang-trunk/bin/llvm-dis main/libwebp-0.4.0/src/dsp/dec_sse2.bc Segmentation fault (core dumped) $: clang-trunk -v clang version 3.7.0 (trunk 235404) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.0.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.0.0 Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.3 Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.4 Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $: -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 05:05:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 12:05:51 +0000 Subject: [LLVMbugs] [Bug 23311] New: Can't compile Clang on windows using Visual Studio 2015 preview Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23311 Bug ID: 23311 Summary: Can't compile Clang on windows using Visual Studio 2015 preview Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: libclang Assignee: unassignedclangbugs at nondot.org Reporter: ernest.galbrun at gmail.com CC: klimek at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified When trying to compile clang with Visual Studio 2015 preview, I get the following error when compiling RecordLayoutBuilder.cpp (in clangAST) : RecordLayoutBuilder.cpp(2981) error C2678: binary '==': no operator found which takes a left-hand operand of type 'llvm::DenseMapIterator' (or there is no acceptable conversion) (...) while trying to match the argument list '(llvm::DenseMapIterator, llvm::DenseMapIterator)' The compiler seem to complain because the egality-comparison operator is only defined for RHS maps of type llvm::DenseMapIterator I have solved the problem by replacing the comparison operator in DenseMap.h, lines 1039-1054 so that they can take input of any DenseMapIterator, not only ConstIterator. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 05:38:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 12:38:47 +0000 Subject: [LLVMbugs] [Bug 23312] New: [Backend: R600] UNREACHABLE executed at lib/Target/R600/AMDGPUInstrInfo.cpp:97! Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23312 Bug ID: 23312 Summary: [Backend: R600] UNREACHABLE executed at lib/Target/R600/AMDGPUInstrInfo.cpp:97! Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: rwindz0 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14239 --> https://llvm.org/bugs/attachment.cgi?id=14239&action=edit getelementptr.ll The testcase in platform-independent fix rL231984 reveals possible issues with R600 backend. The below lines are identical to test/CodeGen/X86/getelementptr.ll ; RUN: llc < %s -O0 -march=r600 ; RUN: llc < %s -O2 -march=r600 define i8* @test_trunc65(i8* %ptr) nounwind { ; CHECK-LABEL: test_trunc65 ; CHECK: 3 %d = getelementptr i8, i8* %ptr, i65 18446744073709551619 ; 2^64 + 3 ret i8* %d } define i8* @test_trunc128(i8* %ptr) nounwind { ; CHECK-LABEL: test_trunc128 ; CHECK: 5 %d = getelementptr i8, i8* %ptr, i128 18446744073709551621 ; 2^64 + 5 ret i8* %d } define i8* @test_trunc160(i8* %ptr) nounwind { ; CHECK-LABEL: test_trunc160 ; CHECK: 8 %d = getelementptr i8, i8* %ptr, i160 18446744073709551624 ; 2^64 + 8 ret i8* %d } define i8* @test_trunc256(i8* %ptr) nounwind { ; CHECK-LABEL: test_trunc256 ; CHECK: 13 %d = getelementptr i8, i8* %ptr, i256 18446744073709551629 ; 2^64 + 13 ret i8* %d } define i8* @test_trunc2048(i8* %ptr) nounwind { ; CHECK-LABEL: test_trunc2048 ; CHECK: 21 %d = getelementptr i8, i8* %ptr, i2048 18446744073709551637 ; 2^64 + 21 ret i8* %d } ; Test small index sext to pointer size define i8* @test_sext3(i8* %ptr) nounwind { ; CHECK-LABEL: test_sext3 ; CHECK: -3 %d = getelementptr i8, i8* %ptr, i3 -3 ret i8* %d } define i8* @test_sext5(i8* %ptr) nounwind { ; CHECK-LABEL: test_sext5 ; CHECK: -5 %d = getelementptr i8, i8* %ptr, i5 -5 ret i8* %d } define i8* @test_sext8(i8* %ptr) nounwind { ; CHECK-LABEL: test_sext8 ; CHECK: -8 %d = getelementptr i8, i8* %ptr, i8 -8 ret i8* %d } define i8* @test_sext13(i8* %ptr) nounwind { ; CHECK-LABEL: test_sext13 ; CHECK: -13 %d = getelementptr i8, i8* %ptr, i8 -13 ret i8* %d } define i8* @test_sext16(i8* %ptr) nounwind { ; CHECK-LABEL: test_sext16 ; CHECK: -21 %d = getelementptr i8, i8* %ptr, i8 -21 ret i8* %d } backtrace: $llc -O0 -march=r600 Not Implemented UNREACHABLE executed at /home/ch/sources-llvm/llvm/lib/Target/R600/AMDGPUInstrInfo.cpp:97! #0 0x1e6902e llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/ch/sources-llvm/llvm/lib/Support/Unix/Signals.inc:424:15 #1 0x1e69fa9 PrintStackTraceSignalHandler(void*) /home/ch/sources-llvm/llvm/lib/Support/Unix/Signals.inc:483:1 #2 0x1e6a483 SignalHandler(int) /home/ch/sources-llvm/llvm/lib/Support/Unix/Signals.inc:199:60 #3 0x7f6b0c99a8d0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xf8d0) #4 0x7f6b0bbda107 gsignal /build/glibc-Ir_s5K/glibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f6b0bbdb4e8 abort /build/glibc-Ir_s5K/glibc-2.19/stdlib/abort.c:91:0 #6 0x1e1b356 (/home/ch/build-debug/bin/llc+0x1e1b356) #7 0xf081e8 /home/ch/sources-llvm/llvm/lib/Target/R600/AMDGPUInstrInfo.cpp:97:3 #8 0x168d423 (anonymous namespace)::RAFast::spillVirtReg(llvm::MachineBasicBlock::bundle_iterator >, (anonymous namespace)::RAFast::LiveReg*) /home/ch/sources-llvm/llvm/lib/CodeGen/RegAllocFast.cpp:290:5 #9 0x168b63b (anonymous namespace)::RAFast::spillAll(llvm::MachineBasicBlock::bundle_iterator >) /home/ch/sources-llvm/llvm/lib/CodeGen/RegAllocFast.cpp:334:16 #10 0x1689914 (anonymous namespace)::RAFast::AllocateBasicBlock() /home/ch/sources-llvm/llvm/lib/CodeGen/RegAllocFast.cpp:1067:3 #11 0x1687e50 (anonymous namespace)::RAFast::runOnMachineFunction(llvm::MachineFunction&) /home/ch/sources-llvm/llvm/lib/CodeGen/RegAllocFast.cpp:1103:5 #12 0x15e142e llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /home/ch/sources-llvm/llvm/lib/CodeGen/MachineFunctionPass.cpp:40:3 #13 0x19bd31d llvm::FPPassManager::runOnFunction(llvm::Function&) /home/ch/sources-llvm/llvm/lib/IR/LegacyPassManager.cpp:1538:23 #14 0x19bd628 llvm::FPPassManager::runOnModule(llvm::Module&) /home/ch/sources-llvm/llvm/lib/IR/LegacyPassManager.cpp:1558:16 #15 0x19bdce9 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /home/ch/sources-llvm/llvm/lib/IR/LegacyPassManager.cpp:1616:23 #16 0x19bd8de llvm::legacy::PassManagerImpl::run(llvm::Module&) /home/ch/sources-llvm/llvm/lib/IR/LegacyPassManager.cpp:1723:16 #17 0x19be191 llvm::legacy::PassManager::run(llvm::Module&) /home/ch/sources-llvm/llvm/lib/IR/LegacyPassManager.cpp:1756:3 #18 0x784481 compileModule(char**, llvm::LLVMContext&) /home/ch/sources-llvm/llvm/tools/llc/llc.cpp:378:3 #19 0x7832f6 main /home/ch/sources-llvm/llvm/tools/llc/llc.cpp:201:13 #20 0x7f6b0bbc6b45 __libc_start_main /build/glibc-Ir_s5K/glibc-2.19/csu/libc-start.c:321:0 #21 0x783014 _start (/home/ch/build-debug/bin/llc+0x783014) Stack dump: 0. Program arguments: /home/ch/build-debug/bin/llc -O0 -march=r600 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'Fast Register Allocator' on function '@test_trunc65' $llc -O2 -march=r600 seems fine I used a llvm trunk/235497 built on Linux. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 06:21:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 13:21:50 +0000 Subject: [LLVMbugs] [Bug 23313] New: Project LTO does not build on Windows if the build path has spaces in it. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23313 Bug ID: 23313 Summary: Project LTO does not build on Windows if the build path has spaces in it. Product: Build scripts Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: jujjyl at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14240 --> https://llvm.org/bugs/attachment.cgi?id=14240&action=edit patch to fix build when build path has spaces in it. STR: Clone LLVM+Clang to a path that has spaces in it, and do a cmake build with Visual Studio 2013 to a directory that has spaces in it. Observed: When building LLVM in VS2013, it will fail with the following error: 1>------ Build started: Project: LTO, Configuration: RelWithDebInfo x64 ------ 1> LTODisassembler.cpp 1> lto.cpp 1>LINK : fatal error LNK1104: cannot open file 'sdk/emsdk/clang/fastcomp/build_incoming_vs2013_64/tools/lto/LTO.def' ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== In this case, LLVM build path was located in C:/code/em sdk/emsdk/clang/fastcomp/build_incoming_vs2013_64/. Looking at the generated VS project closer, and the CMakeLists.txt, this can be fixed by adding quotes in cmake/modules/AddLLVM.cmake: - set(export_file_linker_flag "/DEF:${export_file_linker_flag}") + set(export_file_linker_flag "/DEF:\"${export_file_linker_flag}\"") after which the build passes ok. Attached is a patch to illustrate the fix. This bug was originally reported in Emscripten SDK bug tracker: https://github.com/kripken/emscripten/issues/3382 . -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 07:08:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 14:08:51 +0000 Subject: [LLVMbugs] [Bug 23308] clang-cl errors about internal linkage on method in dllexported class that takes parameter with internal linkage In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23308 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Hans Wennborg --- r235471 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 08:09:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 15:09:22 +0000 Subject: [LLVMbugs] [Bug 23314] New: duplicate brace crashes treeTransform Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23314 Bug ID: 23314 Summary: duplicate brace crashes treeTransform Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: mjjunk47 at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified I had a duplicate brace in construction of my object: const wordList masterNames((fieldObjects.sortedNames()); instead of const wordList masterNames(fieldObjects.sortedNames()); This crashes the 'TreeTransform' pass In file included from decomposePar.C:94: In file included from ./readFields.H:68: ./readFields.C:84:60: error: expected ')' const wordList masterNames((fieldObjects.sortedNames()); ^ ./readFields.C:84:31: note: to match this '(' const wordList masterNames((fieldObjects.sortedNames()); ^ clang: TreeTransform.h:2930: clang::ExprResult clang::TreeTransform::TransformInitializer(clang::Expr*, bool) [with Derived = {anonymous}::TemplateInstantiator; clang::ExprResult = clang::ActionResult]: Assertion `NewArgs.empty() && "no parens or braces but have direct init with arguments?"' failed. 0 clang 0x00000000027eede2 llvm::sys::PrintStackTrace(_IO_FILE*) + 34 1 clang 0x00000000027ee9c9 2 libpthread.so.0 0x00002b99a070e1f0 3 libc.so.6 0x00002b99a15a3065 gsignal + 53 4 libc.so.6 0x00002b99a15a44e8 abort + 328 5 libc.so.6 0x00002b99a159bf72 6 libc.so.6 0x00002b99a159c022 7 clang 0x0000000000ecbbae 8 clang 0x0000000000ecbc8b clang::Sema::SubstInitializer(clang::Expr*, clang::MultiLevelTemplateArgumentList const&, bool) + 75 9 clang 0x0000000000ee5383 clang::Sema::InstantiateVariableInitializer(clang::VarDecl*, clang::VarDecl*, clang::MultiLevelTemplateArgumentList const&) + 323 10 clang 0x0000000000eee1b0 clang::Sema::BuildVariableInstantiation(clang::VarDecl*, clang::VarDecl*, clang::MultiLevelTemplateArgumentList const&, llvm::SmallVector*, clang::DeclContext*, clang::LocalInstantiationScope*, bool) + 928 11 clang 0x0000000000ef0088 clang::TemplateDeclInstantiator::VisitVarDecl(clang::VarDecl*, bool) + 376 12 clang 0x0000000000eeae1c clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 140 1 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 09:23:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 16:23:22 +0000 Subject: [LLVMbugs] [Bug 23313] Project LTO does not build on Windows if the build path has spaces in it. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23313 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |FIXED --- Comment #1 from Reid Kleckner --- Thanks, applied in r235519. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 10:30:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 17:30:48 +0000 Subject: [LLVMbugs] [Bug 23259] Error during code selection with broadcast instruction (AVX2) with optsize In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23259 Sanjay Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sanjay Patel --- Thanks, Andrea! Updating status to 'resolved'. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 10:52:38 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 17:52:38 +0000 Subject: [LLVMbugs] [Bug 23320] New: Use power of 2 operations for bitfields Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23320 Bug ID: 23320 Summary: Use power of 2 operations for bitfields Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: pete.cooper at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified r235528 changed MachineOperand::OpKind from an unsigned char to a bitfield. This was to optimize the accesses of the bitfields after it. We had a struct something like struct MachineOperand { unsigned char OpKind; unsigned int bitfield1 : 1; unsigned int bitfield2 : 1; ... } Although the 24-bits of bitfields and the unsigned char shared 32-bits of storage space, the actual accesses to the bitfields were generated as i24 load/store which isn't legal. This ultimately leads to the backend having to split the i24 in to i8 and i16 operations. We should see if its possible for clang to emit the unsigned char and bitfields as an i32 given that this is how they are stored. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 10:58:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 17:58:15 +0000 Subject: [LLVMbugs] [Bug 23321] New: Optimize bitfield accesses to generate power of 2 load/store Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23321 Bug ID: 23321 Summary: Optimize bitfield accesses to generate power of 2 load/store Product: tools Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: opt Assignee: unassignedbugs at nondot.org Reporter: pete.cooper at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified r235528 changed MachineOperand::OpKind from an unsigned char to a bitfield. This was to optimize the accesses of the bitfields after it. We had a struct something like struct MachineOperand { unsigned char OpKind; unsigned int bitfield1 : 1; unsigned int bitfield2 : 1; ... } Although the 24-bits of bitfields and the unsigned char shared 32-bits of storage space, the actual accesses to the bitfields were generated as i24 load/store which isn't legal. This ultimately leads to the backend having to split the i24 in to i8 and i16 operations. We should be able to optimize this so that the load/store are done as i32 operations. Attaching before/after IR which is an unsigned char/bitfield. Note that there may be issues with volatility which prevent doing an optimization here. That will have to be investigated. If OpKind was volatile then folding it in to the bitfields with load/store has the possibility to change behavior. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 11:43:11 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 18:43:11 +0000 Subject: [LLVMbugs] [Bug 23323] New: Handling of -m is broken Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23323 Bug ID: 23323 Summary: Handling of -m is broken Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified ldd will only accept "-m elf_x86_64" if the triple is x86. This means that unlike gnu ld or gold to cross link one has to do something like -flavor gnu -target x86_64-linux-gnu -m elf_x86_64 Just -flavor gnu -m elf_x86_64 should be sufficient. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 13:33:00 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 20:33:00 +0000 Subject: [LLVMbugs] [Bug 23324] New: Second argument to signed Neon vtbl functions should be unsigned Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23324 Bug ID: 23324 Summary: Second argument to signed Neon vtbl functions should be unsigned Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Headers Assignee: unassignedclangbugs at nondot.org Reporter: lennox at cs.columbia.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The ARM C Language Extensions document (ACLE) specifies that the second (index) parameter to the vtbl and vtbx family of functions should be unsigned, even when the other parameters are signed: Aarch32: T vtblN_ST(TxN a, UT b); T vtbxN_ST(T a, TxN b, UT c); Aarch64: T vqtblNQ_ST (T2xN t, UT idx); T vqtbxNQ_ST (T a, T2xN t, UT idx); E.g., int8x8_t vqtbl1_s8 (int8x16_t a, uint8x8_t b) Clang declares them to be signed, instead. GCC has had these correct for Aarch64 since GCC 4.9, though for ARM (Aarch32) it still has the second value signed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 14:00:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 21:00:01 +0000 Subject: [LLVMbugs] [Bug 23309] wrong code at -O1 and above on x86_64-linux-gnu In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23309 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|-New Bugs |Scalar Optimizations Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |unassignedbugs at nondot.org |org | Product|clang |libraries --- Comment #3 from David Majnemer --- Fixed in r235544. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 14:39:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 22 Apr 2015 21:39:24 +0000 Subject: [LLVMbugs] [Bug 23220] r234581 broke a test in Chromium In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23220 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from David Majnemer --- Re-committed as r235553. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 19:26:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 02:26:06 +0000 Subject: [LLVMbugs] [Bug 23307] clang fails to compile rstudio-0.98.1103/src/cpp/session/modules/SessionHTMLPreview.cpp against libc++ In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23307 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |INVALID --- Comment #4 from Richard Smith --- Reduced self-contained testcase: #include #include #include void f(std::istream &s, std::string x) { std::istreambuf_iterator eod; std::search(std::istreambuf_iterator(s), eod, x.begin(), x.end()); } Fails with libc++, passes with libstdc++, fails with libstdc++ and -D_GLIBCXX_CONCEPT_CHECKS (which makes it actually check that std::search is not being abused in this way). FWIW, libstdc++ is silently generating wrong code when its std::search is given an input iterator (it assumes it can save the iterator position and backtrack). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 21:04:55 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 04:04:55 +0000 Subject: [LLVMbugs] [Bug 23325] New: [ms] manging mismatch with cl Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23325 Bug ID: 23325 Summary: [ms] manging mismatch with cl Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This is mangled differently by clang-cl and cl: struct SkPoint {}; class SkXfermode {}; class SkPaint {}; class SkCanvas { protected: void onDrawPatch(const SkPoint cubics[12], const SkPoint texCoords[4], SkXfermode* xmode, const SkPaint& paint); }; void SkCanvas::onDrawPatch(const SkPoint cubics[12], const SkPoint texCoords[4], SkXfermode* xmode, const SkPaint& paint) {} >..\..\llvm-rw-build-rel\bin\clang-cl /c test.cc >dumpbin /symbols test.obj ... 009 00000000 SECT1 notype () External | ?onDrawPatch at SkCanvas@@IAEXQBUSkPoint@@QBU2 at PAVSkXfermode@@@Z > cl /c test.cc Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x86 Copyright (C) Microsoft Corporation. All rights reserved. test.cc >dumpbin /symbols test.obj ... 008 00000000 SECT3 notype () External | ?onDrawPatch at SkCanvas@@IAEXQBUSkPoint@@0PAVSkXfermode@@@Z (The two manglings do demangle to the same thing though :-/) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 22:21:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 05:21:31 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 23325, which changed state. Bug 23325 Summary: [ms] manging mismatch with cl https://llvm.org/bugs/show_bug.cgi?id=23325 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 22 22:21:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 05:21:31 +0000 Subject: [LLVMbugs] [Bug 23325] [ms] manging mismatch with cl In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23325 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|Frontend |LLVM Codegen Blocks| |12477 Resolution|--- |FIXED --- Comment #2 from David Majnemer --- Fixed in r235572. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 01:38:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 08:38:07 +0000 Subject: [LLVMbugs] [Bug 23327] New: Clang win32 assert "The next DeclContext should be lexically contained in the current one." Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23327 Bug ID: 23327 Summary: Clang win32 assert "The next DeclContext should be lexically contained in the current one." Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: partow at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Attached code example builds error/warning free with clang (3.2+) built on linux. However when attempting to build the same code, using the win32 clang build the following error is observed: 1>------ Rebuild All started: Project: exprtk_test, Configuration: Release Win32 ------ 1>clang-cl.exe : warning : argument unused during compilation: '/GL' 1>clang-cl.exe : warning : argument unused during compilation: '/Gm-' 1>clang-cl.exe : warning : argument unused during compilation: '/GS' 1> Assertion failed: getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one.", file D:\src\llvm_snapshot_235383\llvm\tools\clang\lib\Sema\SemaDecl.cpp, line 1073 1> 0x00C1BCE7 (0x00000016 0x0199BC72 0x00138888 0x056EE364) 1> 0x0199CF21 (0x02268D40 0x02268B60 0x00000431 0x0568BE20) 1> 0x01419017 (0x04FC06E0 0x056EE364 0x00138888 0x0636F9E0) 1> 0x012A82DD (0x00000000 0x00000000 0x0010F0D4 0x00138C28) 1> 0x00BA0274 (0x0636F9E0 0x0165B0CF 0x0014EFA8 0x0636F9E0) 1> 0x012A796D (0x0014EFA8 0x0636F9E0 0x07693960 0x004F90BE) 1> 0x0165B0CF (0x00108B10 0x02F2DDFC 0x02F2DDFC 0x00138888) 1> 0x014F347D (0x00000001 0x00139938 0x073EC4A0 0x00000000) 1> 0x013B0875 (0x073EC4C4 0x04939328 0x013B20B3 0x073EC520) 1> 0x0180FC94 (0x073EC520 0x013FDF8C 0x02F2DE8C 0x073EC4A0) 1> 0x013B20B3 (0x02F2DE8C 0x073EC4A0 0x00000000 0x00138888) 1> 0x013FDF8C (0x00000000 0x073EC4A0 0x07694048 0x07695358) 1> 0x013FDFB4 (0x00000600 0x000EA978 0x0759C088 0x00000008) 1> 0x013FA961 (0x004F90BE 0x07693960 0x00000001 0x00F2C500) 1> 0x0165D053 (0x00138888 0x07693960 0x00000000 0x02290480) 1> 0x00F1FF89 (0x00000001 0x073EC4A0 0x004FA804 0x00138888) 1> 0x0165B46A (0x073EC4A0 0x004FA804 0x00138888 0x073EC4A0) 1>clang-cl.exe : error : clang frontend command failed due to signal (use -v to see invocation) 1> clang version 3.7.0 (trunk) 1> Target: i686-pc-windows-msvc 1> Thread model: posix 1> clang-cl.exe: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. 1> clang-cl.exe: note: diagnostic msg: 1> ******************** 1> 1> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: 1> Preprocessed source(s) and associated run script(s) are located at: 1> clang-cl.exe: note: diagnostic msg: C:\Users\user\AppData\Local\Temp\exprtk_test-53da00.cpp 1> clang-cl.exe: note: diagnostic msg: C:\Users\user\AppData\Local\Temp\exprtk_test-53da00.sh 1> clang-cl.exe: note: diagnostic msg: 1> 1> ******************** ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ========== -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 04:48:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 11:48:07 +0000 Subject: [LLVMbugs] [Bug 23328] New: LLVM_OPTIMIZED_TABLEGEN broken Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23328 Bug ID: 23328 Summary: LLVM_OPTIMIZED_TABLEGEN broken Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: t.scheller at samsung.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Tried to build with -DLLVM_OPTIMIZED_TABLEGEN=ON on x86-64 Linux (-DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS=ON): $ make [ 4%] Built target LLVMSupport [ 6%] Built target LLVMTableGen [ 8%] Built target llvm-tblgen make[2]: *** No rule to make target 'NATIVE/bin/llvm-tblgen', needed by 'include/llvm/IR/Intrinsics.gen.tmp'. Stop. CMakeFiles/Makefile2:480: recipe for target 'include/llvm/IR/CMakeFiles/intrinsics_gen.dir/all' failed make[1]: *** [include/llvm/IR/CMakeFiles/intrinsics_gen.dir/all] Error 2 Makefile:137: recipe for target 'all' failed make: *** [all] Error 2 This is with r235577 and CMake 3.0.2. Any idea what could be wrong? If you know of any "known good" revisions I'd be happy to give it try to see if this is a regression. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 07:51:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 14:51:51 +0000 Subject: [LLVMbugs] [Bug 23330] New: Trivial division by zero case causes SIGFPE Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23330 Bug ID: 23330 Summary: Trivial division by zero case causes SIGFPE Product: libraries Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedbugs at nondot.org Reporter: matszpk at interia.pl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Following trivial cases causes SIGFPE: .data .int 6/0 and .data b = 0 .int 6/b clang and llbvm-mc fails if try to compile these examples. This bug is reproducible for 3.4, 3.5 and 3.6 versions. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 08:42:18 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 15:42:18 +0000 Subject: [LLVMbugs] [Bug 23331] New: http://llvm.org/docs/NVPTXUsage.html#the-kernel uses outdated metadata syntax Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23331 Bug ID: 23331 Summary: http://llvm.org/docs/NVPTXUsage.html#the-kernel uses outdated metadata syntax Product: Documentation Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: General docs Assignee: unassignedbugs at nondot.org Reporter: christian.pehle at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The user guide for the NVPTX Back-end uses outdated metadata syntax in http://llvm.org/docs/NVPTXUsage.html#the-kernel, if the metadata keyword in the last two lines is ommitted the code works as is. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 08:54:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 15:54:28 +0000 Subject: [LLVMbugs] [Bug 22719] Improvements in raw branch profile data representation In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22719 Diego Novillo changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Diego Novillo --- Closing as fixed for now. Will re-open if new issues show up. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 09:14:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 16:14:40 +0000 Subject: [LLVMbugs] [Bug 21082] __attribute__((__format__(printf ignored for function pointer members of struct In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21082 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution|--- |FIXED --- Comment #1 from Aaron Ballman --- Implemented in r235606 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 09:15:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 16:15:50 +0000 Subject: [LLVMbugs] [Bug 17905] no diagnostic for variadic main In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=17905 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Aaron Ballman --- Fixed in r235605 (we now diagnose this as an extension). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 09:26:38 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 16:26:38 +0000 Subject: [LLVMbugs] [Bug 23228] RuntimeDyldCOFF should handle relocations for external symbols In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23228 Andy Ayers changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Andy Ayers --- Patch committed at r235554. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 10:30:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 17:30:33 +0000 Subject: [LLVMbugs] [Bug 21277] AArch64: "Cannot Select" error for FP conversions from/to vectors of half/f16 operands In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21277 Pirama Arumuga Nainar changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Pirama Arumuga Nainar --- Fixed in rL235609: [AArch64] Handle vec4, vec8, vec16 *itofp for half -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 12:57:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 19:57:31 +0000 Subject: [LLVMbugs] [Bug 23332] New: clang: error: unable to execute command: Segmentation fault: 11 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23332 Bug ID: 23332 Summary: clang: error: unable to execute command: Segmentation fault: 11 Product: new-bugs Version: 3.6 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: rlschie at sandia.gov CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Clang exits with a segmentation fault when compiling code that compiled in earlier versions of clang. Attached are the summary files that clang asks to submit with the bug report. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 14:11:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 21:11:08 +0000 Subject: [LLVMbugs] [Bug 23333] New: Inverted conditionals not being CSEd Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23333 Bug ID: 23333 Summary: Inverted conditionals not being CSEd Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: listmail at philipreames.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified We currently fail to recognize the CSE oppurtunity in the following example in EarlyCSE or JumpThreading. GVN does get this case: define i8 @earlycse(i8 addrspace(1)* %ptr) { %cnd = icmp eq i8 addrspace(1)* %ptr, null br i1 %cnd, label %null, label %not_null null: %cnd2 = icmp ne i8 addrspace(1)* %ptr, null %res = select i1 %cnd2, i8 2, i8 1 ret i8 %res not_null: ret i8 0 } For EarlyCSE: When we encounter %cnd2, we could lookup it's inverse in the SimpleValue structure and use the negation of that check. For JumpThreading: We should know that %ptr == null at the compare. We just don't appear to be using this fact at all. Alternatively, we could choose to canonicalize the NE to an EQ case and invert the select. If that approach was chosen, InstCombine might be a more reasonable place. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 14:18:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 23 Apr 2015 21:18:05 +0000 Subject: [LLVMbugs] [Bug 21743] machine copy propagation kills ABI-related copies on win64 (atom?) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21743 Quentin Colombet changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Quentin Colombet --- Should be fixed by Committed revision 235647. Thanks for reporting the issue! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 21:06:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 04:06:35 +0000 Subject: [LLVMbugs] [Bug 23334] New: crash in Sema::CleanupVarDeclMarking with [=] lambda Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23334 Bug ID: 23334 Summary: crash in Sema::CleanupVarDeclMarking with [=] lambda Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: nlewycky at google.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: void fn1() { constexpr int kIsolationClass = 0; const int kBytesPerConnection = 0; [=] { 0(kUserkIsolationClass); kBytesPerConnection, kBytesPerConnection; }; } in -std=c++11 mode. I believe I can get a crash on valid out of this too. ==31903==ERROR: AddressSanitizer: heap-use-after-free on address 0x61900000d7e0 at pc 0x00000060f4f9 bp 0x7fffc27a6c60 sp 0x7fffc27a6c58 READ of size 8 at 0x61900000d7e0 thread T0 #0 0x60f4f8 in llvm::SmallPtrSetIteratorImpl::AdvanceIfNotValid() third_party/llvm/llvm/include/llvm/ADT/SmallPtrSet.h:171:13 #1 0x1f336d4 in llvm::SmallPtrSetIterator::operator++() third_party/llvm/llvm/include/llvm/ADT/SmallPtrSet.h:201:5 #2 0x1eb26f2 in clang::Sema::CleanupVarDeclMarking() third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:13140:16 #3 0x1dd96c4 in clang::Sema::MaybeCreateExprWithCleanups(clang::Expr*) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExprCXX.cpp:5150:3 #4 0x1dd9606 in clang::Sema::MaybeCreateExprWithCleanups(clang::ActionResult) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExprCXX.cpp:5144:10 #5 0x1de086a in clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool, bool, bool) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExprCXX.cpp:6439:10 #6 0x1bc78b5 in clang::Sema::ActOnExprStmt(clang::ActionResult) third_party/llvm/llvm/tools/clang/lib/Sema/SemaStmt.cpp:46:8 #7 0x18bdc13 in clang::Parser::ParseExprStatement() third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:408:10 #8 0x18bcecc in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:220:12 #9 0x18bc238 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:106:20 #10 0x18c538a in clang::Parser::ParseCompoundStatementBody(bool) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:958:11 #11 0x18fc656 in clang::Parser::ParseLambdaExpressionAfterIntroducer(clang::LambdaIntroducer&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:1250:19 #12 0x18fa194 in clang::Parser::ParseLambdaExpression() third_party/llvm/llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:729:10 #13 0x191112d in clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:1283:13 #14 0x190a27b in clang::Parser::ParseCastExpression(bool, bool, clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:437:20 #15 0x190823d in clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:167:20 #16 0x190817d in clang::Parser::ParseExpression(clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:121:18 #17 0x18bda0e in clang::Parser::ParseExprStatement() third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:384:19 #18 0x18bcecc in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:220:12 #19 0x18bc238 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:106:20 #20 0x18c538a in clang::Parser::ParseCompoundStatementBody(bool) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:958:11 #21 0x18c61b6 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:1873:21 [...] 0x61900000d7e0 is located 96 bytes inside of 1024-byte region [0x61900000d780,0x61900000db80) freed by thread T0 here: #0 0x4ffd6b in __interceptor_free third_party/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:30:3 #1 0x1ea955d in clang::Sema::PopExpressionEvaluationContext() third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:12018:3 #2 0x1ec792c in addAsFieldToClosureType(clang::Sema&, clang::sema::LambdaScopeInfo*, clang::VarDecl*, clang::QualType, clang::QualType, clang::SourceLocation, bool) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:12655:1 #3 0x1eb7864 in captureInLambda(clang::sema::LambdaScopeInfo*, clang::VarDecl*, clang::SourceLocation, bool, clang::QualType&, clang::QualType&, bool, clang::Sema::TryCaptureKind, clang::SourceLocation, bool, clang::Sema&) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:12738:25 #4 0x1eb4e6e in clang::Sema::tryCaptureVariable(clang::VarDecl*, clang::SourceLocation, clang::Sema::TryCaptureKind, clang::SourceLocation, bool, clang::QualType&, clang::QualType&, unsigned int const*) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:13034:12 #5 0x1e58489 in clang::MarkVarDeclODRUsed(clang::VarDecl*, clang::SourceLocation, clang::Sema&, unsigned int const*) third_party/llvm/llvm/tools/clang/include/clang/Sema/SemaInternal.h:70:3 #6 0x1eb26ea in clang::Sema::CleanupVarDeclMarking() third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:13153:5 #7 0x1dd96c4 in clang::Sema::MaybeCreateExprWithCleanups(clang::Expr*) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExprCXX.cpp:5150:3 #8 0x1dd9606 in clang::Sema::MaybeCreateExprWithCleanups(clang::ActionResult) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExprCXX.cpp:5144:10 #9 0x1de086a in clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool, bool, bool) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExprCXX.cpp:6439:10 #10 0x1bc78b5 in clang::Sema::ActOnExprStmt(clang::ActionResult) third_party/llvm/llvm/tools/clang/lib/Sema/SemaStmt.cpp:46:8 #11 0x18bdc13 in clang::Parser::ParseExprStatement() third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:408:10 #12 0x18bcecc in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:220:12 #13 0x18bc238 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:106:20 #14 0x18c538a in clang::Parser::ParseCompoundStatementBody(bool) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:958:11 #15 0x18fc656 in clang::Parser::ParseLambdaExpressionAfterIntroducer(clang::LambdaIntroducer&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:1250:19 #16 0x18fa194 in clang::Parser::ParseLambdaExpression() third_party/llvm/llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:729:10 #17 0x191112d in clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:1283:13 #18 0x190a27b in clang::Parser::ParseCastExpression(bool, bool, clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:437:20 #19 0x190823d in clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:167:20 #20 0x190817d in clang::Parser::ParseExpression(clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:121:18 #21 0x18bda0e in clang::Parser::ParseExprStatement() third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:384:19 #22 0x18bcecc in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:220:12 #23 0x18bc238 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:106:20 #24 0x18c538a in clang::Parser::ParseCompoundStatementBody(bool) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:958:11 #25 0x18c61b6 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:1873:21 #26 0x1895ef8 in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) third_party/llvm/llvm/tools/clang/lib/Parse/Parser.cpp:1104:10 #27 0x1949a47 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) third_party/llvm/llvm/tools/clang/lib/Parse/ParseDecl.cpp:1689:11 #28 0x1894f20 in clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) third_party/llvm/llvm/tools/clang/lib/Parse/Parser.cpp:893:10 #29 0x1894619 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) third_party/llvm/llvm/tools/clang/lib/Parse/Parser.cpp:909:12 previously allocated by thread T0 here: #0 0x50004b in __interceptor_malloc third_party/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3 #1 0x4a7aca6 in llvm::SmallPtrSetImplBase::Grow(unsigned int) third_party/llvm/llvm/lib/Support/SmallPtrSet.cpp:141:28 #2 0x4a7aa04 in llvm::SmallPtrSetImplBase::insert_imp(void const*) third_party/llvm/llvm/lib/Support/SmallPtrSet.cpp:61:5 #3 0x1f3674e in llvm::SmallPtrSetImpl::insert(clang::Expr*) third_party/llvm/llvm/include/llvm/ADT/SmallPtrSet.h:265:14 #4 0x1eb876c in DoMarkVarDeclReferenced(clang::Sema&, clang::SourceLocation, clang::VarDecl*, clang::Expr*) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:13271:7 #5 0x1e69efa in clang::Sema::BuildDeclRefExpr(clang::ValueDecl*, clang::QualType, clang::ExprValueKind, clang::DeclarationNameInfo const&, clang::CXXScopeSpec const*, clang::NamedDecl*, clang::TemplateArgumentListInfo const*) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:1678:3 #6 0x1e700a3 in clang::Sema::BuildDeclarationNameExpr(clang::CXXScopeSpec const&, clang::DeclarationNameInfo const&, clang::NamedDecl*, clang::NamedDecl*, clang::TemplateArgumentListInfo const*, bool) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:2981:12 #7 0x1e6de0f in clang::Sema::BuildDeclarationNameExpr(clang::CXXScopeSpec const&, clang::LookupResult&, bool, bool) third_party/llvm/llvm/tools/clang/lib/Sema/SemaExpr.cpp:2749:12 #8 0x2063aef in clang::Sema::ClassifyName(clang::Scope*, clang::CXXScopeSpec&, clang::IdentifierInfo*&, clang::SourceLocation, clang::Token const&, bool, std::unique_ptr >) third_party/llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:1029:10 #9 0x189727c in clang::Parser::TryAnnotateName(bool, std::unique_ptr >) third_party/llvm/llvm/tools/clang/lib/Parse/Parser.cpp:1365:45 #10 0x18a4b63 in clang::Parser::isCXXDeclarationSpecifier(clang::Parser::TPResult, bool*) third_party/llvm/llvm/tools/clang/lib/Parse/ParseTentative.cpp:1160:15 #11 0x191b9a9 in clang::Parser::isKnownToBeDeclarationSpecifier() third_party/llvm/llvm/tools/clang/include/clang/Parse/Parser.h:1789:14 #12 0x190ccc1 in clang::Parser::isNotExpressionStart() third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:216:10 #13 0x1908727 in clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:251:35 #14 0x18bda0e in clang::Parser::ParseExprStatement() third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:384:19 #15 0x18bcecc in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:220:12 #16 0x18bc238 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:106:20 #17 0x18c538a in clang::Parser::ParseCompoundStatementBody(bool) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:958:11 #18 0x18fc656 in clang::Parser::ParseLambdaExpressionAfterIntroducer(clang::LambdaIntroducer&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:1250:19 #19 0x18fa194 in clang::Parser::ParseLambdaExpression() third_party/llvm/llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:729:10 #20 0x191112d in clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:1283:13 #21 0x190a27b in clang::Parser::ParseCastExpression(bool, bool, clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:437:20 #22 0x190823d in clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:167:20 #23 0x190817d in clang::Parser::ParseExpression(clang::Parser::TypeCastState) third_party/llvm/llvm/tools/clang/lib/Parse/ParseExpr.cpp:121:18 #24 0x18bda0e in clang::Parser::ParseExprStatement() third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:384:19 #25 0x18bcecc in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:220:12 #26 0x18bc238 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:106:20 #27 0x18c538a in clang::Parser::ParseCompoundStatementBody(bool) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:958:11 #28 0x18c61b6 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) third_party/llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:1873:21 #29 0x1895ef8 in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) third_party/llvm/llvm/tools/clang/lib/Parse/Parser.cpp:1104:10 SUMMARY: AddressSanitizer: heap-use-after-free third_party/llvm/llvm/include/llvm/ADT/SmallPtrSet.h:171:13 in llvm::SmallPtrSetIteratorImpl::AdvanceIfNotValid() Shadow bytes around the buggy address: 0x0c327fff9aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c327fff9ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c327fff9ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c327fff9ad0: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff9ae0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c327fff9af0: fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd 0x0c327fff9b00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c327fff9b10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c327fff9b20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c327fff9b30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c327fff9b40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==31903==ABORTING -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 21:44:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 04:44:26 +0000 Subject: [LLVMbugs] [Bug 23335] New: array-bounds warnigns building clang with gcc 4.9.1 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23335 Bug ID: 23335 Summary: array-bounds warnigns building clang with gcc 4.9.1 Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: yaron.keren at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Thread model: posix gcc version 4.9.1 (i686-posix-dwarf-rev1cee, Built by MinGW-W64 project) [ 76%] Building CXX object lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64AddressTypePromotion.cpp.obj In file included from C:/llvm/tools/clang/include/clang/Basic/PartialDiagnostic.h:19:0, from C:/llvm/tools/clang/include/clang/AST/DeclarationName.h:17, from C:/llvm/tools/clang/include/clang/AST/DeclBase.h:18, from C:/llvm/tools/clang/include/clang/AST/Decl.h:18, from C:/llvm/tools/clang/include/clang/AST/ASTTypeTraits.h:20, from C:/llvm/tools/clang/include/clang/AST/ASTContext.h:18, from C:/llvm/tools/clang/include/clang/Sema/SemaInternal.h:18, from C:/llvm/tools/clang/lib/Sema/SemaTemplateInstantiate.cpp:13: C:/llvm/tools/clang/include/clang/Basic/Diagnostic.h: In member function 'bool clang::Sema::InstantiatingTemplate::CheckInstantiationDepth(clang::SourceLocation, clang::SourceRange)': C:/llvm/tools/clang/include/clang/Basic/Diagnostic.h:983:39: warning: array subscript is above array bounds [-Warray-bounds] DiagObj->DiagArgumentsKind[NumArgs] = Kind; ^ C:/llvm/tools/clang/include/clang/Basic/Diagnostic.h:984:40: warning: array subscript is above array bounds [-Warray-bounds] DiagObj->DiagArgumentsVal[NumArgs++] = V; ^ C:/llvm/tools/clang/include/clang/Basic/Diagnostic.h:983:39: warning: array subscript is above array bounds [-Warray-bounds] DiagObj->DiagArgumentsKind[NumArgs] = Kind; ^ C:/llvm/tools/clang/include/clang/Basic/Diagnostic.h:984:40: warning: array subscript is above array bounds [-Warray-bounds] DiagObj->DiagArgumentsVal[NumArgs++] = V; ^ C:/llvm/tools/clang/include/clang/Basic/Diagnostic.h:983:39: warning: array subscript is above array bounds [-Warray-bounds] DiagObj->DiagArgumentsKind[NumArgs] = Kind; ^ C:/llvm/tools/clang/include/clang/Basic/Diagnostic.h:984:40: warning: array subscript is above array bounds [-Warray-bounds] DiagObj->DiagArgumentsVal[NumArgs++] = V; ^ C:/llvm/tools/clang/include/clang/Basic/Diagnostic.h:983:39: warning: array subscript is above array bounds [-Warray-bounds] DiagObj->DiagArgumentsKind[NumArgs] = Kind; ^ C:/llvm/tools/clang/include/clang/Basic/Diagnostic.h:984:40: warning: array subscript is above array bounds [-Warray-bounds] DiagObj->DiagArgumentsVal[NumArgs++] = V; ^ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 23 21:45:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 04:45:56 +0000 Subject: [LLVMbugs] [Bug 23336] New: unknown conversion type warnings building clang with gcc 4.9.1 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23336 Bug ID: 23336 Summary: unknown conversion type warnings building clang with gcc 4.9.1 Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: yaron.keren at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Thread model: posix gcc version 4.9.1 (i686-posix-dwarf-rev1cee, Built by MinGW-W64 project) [100%] [100%] Building C object tools/clang/tools/c-arcmt-test/CMakeFiles/c-arcmt-test.dir/c-arcmt-test.c.obj Building C object tools/clang/tools/c-index-test/CMakeFiles/c-index-test.dir/c-index-test.c.obj C:/llvm/tools/clang/tools/c-index-test/c-index-test.c: In function 'PrintCursor': C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:828:22: warning: unknown conversion type character 'l' in format [-Wformat=] I, TAK, clang_Cursor_getTemplateArgumentValue(Cursor, I)); ^ C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:828:22: warning: too many arguments for format [-Wformat-extra-args] C:/llvm/tools/clang/tools/c-index-test/c-index-test.c: In function 'PrintTypeSize': C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:1364:7: warning: unknown conversion type character 'l' in format [-Wformat=] printf(" [sizeof=%lld]", Size); ^ C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:1364:7: warning: too many arguments for format [-Wformat-extra-args] C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:1371:7: warning: unknown conversion type character 'l' in format [-Wformat=] printf(" [alignof=%lld]", Align); ^ C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:1371:7: warning: too many arguments for format [-Wformat-extra-args] C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:1396:13: warning: unknown conversion type character 'l' in format [-Wformat=] printf(" [offsetof=%lld]", Offset); ^ C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:1396:13: warning: too many arguments for format [-Wformat-extra-args] C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:1399:13: warning: unknown conversion type character 'l' in format [-Wformat=] printf(" [offsetof=%lld/%lld]", Offset, Offset2); ^ C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:1399:13: warning: unknown conversion type character 'l' in format [-Wformat=] C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:1399:13: warning: too many arguments for format [-Wformat-extra-args] C:/llvm/tools/clang/tools/c-index-test/c-index-test.c: In function 'perform_print_build_session_timestamp': C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:4002:3: warning: unknown conversion type character 'l' in format [-Wformat=] printf("%lld\n", clang_getBuildSessionTimestamp()); ^ C:/llvm/tools/clang/tools/c-index-test/c-index-test.c:4002:3: warning: too many arguments for format [-Wformat-extra-args] Linking CXX executable ../../../../bin/c-arcmt-test.exe -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 03:55:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 10:55:58 +0000 Subject: [LLVMbugs] [Bug 23337] New: "-x" flag to ld removes inline constructors Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23337 Bug ID: 23337 Summary: "-x" flag to ld removes inline constructors Product: lld Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: mx4492+nospam at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified For a complete description, see http://stackoverflow.com/questions/24921221/x-link-flag-causing-link-errors-on-mac-osx-10-9-bug -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 05:52:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 12:52:49 +0000 Subject: [LLVMbugs] [Bug 23249] LCSSA::verifyAnalysis() and verifyAnalysis() does nothing? In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23249 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Aaron Ballman --- I have removed the offending code in r235717. If Chandler (or anyone else) would like to verify the pass by resurrecting the assert, it's trivial enough to do with version control. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 10:43:51 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 17:43:51 +0000 Subject: [LLVMbugs] [Bug 23338] New: Should LFTS be restricted to C++14? Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23338 Bug ID: 23338 Summary: Should LFTS be restricted to C++14? Product: libc++ Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: eric at efcs.ca CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified We need to decide on a policy for restricting the use of LFTS features. Most of LFTS can be implemented using only C++11. I think these new features are useful enough that there is a strong motivation to provide them whenever possible. So should we allow users to use parts of the LFTS in C++11? I think the rational for keeping it C++14 only is: - N4335 references the C++14 standard as its base document - C++11 should be "stable". Additions added to the language after C++11 not break valid code. Some other considerations: - What restrictions do other standard libraries place on the use of the LFTS? Should we try and match these restrictions? - Should including the headers in C++98/C++11 explicitly cause compile errors? (Similar to how libstdc++ handles C++11 only headers). I'll write up documentation and rational for whatever we decide here. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 11:13:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 18:13:39 +0000 Subject: [LLVMbugs] [Bug 23328] LLVM_OPTIMIZED_TABLEGEN broken In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23328 Chris Bieneman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Chris Bieneman --- This should be resolved with r235732. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 11:26:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 18:26:45 +0000 Subject: [LLVMbugs] [Bug 23339] New: Continuous memory fences fail lower into one Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23339 Bug ID: 23339 Summary: Continuous memory fences fail lower into one Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedbugs at nondot.org Reporter: rwindz0 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified We have file test.ll which contains: define i32 @t1() { entry: fence seq_cst fence seq_cst fence seq_cst fence seq_cst ret i32 0 } When dealing with arm taret, the output looks like sane: $llc -O0 -mtriple arm-linux-gnueabi -mcpu cortex-a53 test.ll -o - .type t1,%function t1: @ @t1 .fnstart @ BB#0: @ %entry movw r0, #0 dmb ish bx lr .Lfunc_end0: .size t1, .Lfunc_end0-t1 .fnend But with arm64 target: $llc -O0 -mtriple arm64-linux-gnueabi -mcpu cortex-a53 test.ll -o - t1: // @t1 .cfi_startproc // BB#0: // %entry mov w8, wzr dmb ish dmb ish dmb ish dmb ish mov w0, w8 ret .Lfunc_end0: .size t1, .Lfunc_end0-t1 .cfi_endproc We have multiple "dmb ish" instructions here. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 13:10:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 20:10:28 +0000 Subject: [LLVMbugs] [Bug 23340] New: Support metadata attachments on functions Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23340 Bug ID: 23340 Summary: Support metadata attachments on functions Product: libraries Version: trunk Hardware: PC OS: All Status: ASSIGNED Severity: normal Priority: P Component: Core LLVM classes Assignee: unassignedbugs at nondot.org Reporter: dexonsmith at apple.com CC: dblaikie at gmail.com, dnovillo at google.com, llvmbugs at cs.uiuc.edu Classification: Unclassified `Function` definitions should support `MDNode` attachments, with a similar syntax to instructions: define void @foo() nounwind !attach !0 { unreachable } !0 = !{} Attachments wouldn't be allowed on declarations, just definitions. There are two open problems this can help with: 1. For PGO, we need somewhere to attach the function entry count. Attaching to the function definition is a simple solution. define void @foo() !prof !0 { unreachable } !0 = !{i32 987} 2. In debug info, we repeatedly build up a map from `Function` to the canonical `MDSubrogram` for it. Keeping this mapping accurate takes subtle logic in `lib/Linker` (see PR21910/PR22792) and it's expensive to compute and maintain. Attaching it directly to the `Function` designs away the problem. define void @foo() !dbg !0 { unreachable } !0 = !MDSubprogram(name: "foo", function: void ()* @foo) (For clarity, the scope of this PR is adding the IR infrastructure, not solving either of those two problems.) Discussion on the list was here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084483.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084485.html For now, I'm just going to put everything in the `LLVMContext`: same approach as `Instruction`, but without the optimization for `!dbg`. If a heap profile tells us we should special-case `!dbg` we can add that logic later. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 14:38:03 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 21:38:03 +0000 Subject: [LLVMbugs] [Bug 23341] New: bad diagnostic on "override" in out-of-line definition Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23341 Bug ID: 23341 Summary: bad diagnostic on "override" in out-of-line definition Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: nlewycky at google.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: class Y { virtual void foo(); }; class X : public Y { void foo() override; }; void X::foo() override { } $ clang b15592394.cc -std=c++11 b15592394.cc:8:15: error: expected function body after function declarator void X::foo() override { } ^ 1 error generated. I wanted something like what we do for static. Something like this: b15592394.cc:8:1: error: 'static' can only be specified inside the class definition static void X::foo() { } ^~~~~~~ If you're looking at this, please also note related bug 22075 which may be fixable at the same time. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 15:00:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 22:00:52 +0000 Subject: [LLVMbugs] [Bug 23342] New: Warn when a template class declares a dependent friend function [-Wnon-template-friend] Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23342 Bug ID: 23342 Summary: Warn when a template class declares a dependent friend function [-Wnon-template-friend] Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: rnk at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The out-of-line friend declaration is very likely broken because the declaration is not part of the template. GCC has a -Wnon-template-friend warning that finds this. template struct Arg { friend bool operator==(const Arg& lhs, T rhs) { return false; } friend bool operator!=(const Arg& lhs, T rhs); }; template bool operator!=(const Arg& lhs, T rhs) { return true; } bool foo() { Arg arg; return (arg == 42) || (arg != 42); } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 15:10:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 22:10:04 +0000 Subject: [LLVMbugs] [Bug 23340] Support metadata attachments on functions In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23340 Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Duncan --- Pretty straightforward in the end (although, clang doesn't use them for anything yet, so I'm sure there are latent bugs). Finished as of r235786. r235763 = 4eae7e061e33b9d984357856710babe5450dd93d r235764 = d8c574a5a4f9b9aa8220f34842903a7049de917d r235767 = 9cd7a4b72d2844550108d3da0b94b525428124fa r235769 = 223d9cfd301cb6f34b66ae9bb18c38250d78dca7 r235770 = af8df399e1e5b01691de5edf42f09d4d8b308251 r235772 = 61317d57df145c9392951c124876c7a58e66c1d1 r235774 = c8be244db70dfc071528c5b4e9387df91f2b0031 r235775 = 3be414736a67463ede1ff7f86e145897d79856fa r235778 = eb713786cd8d071d79e1dfdc8b1bb6b0067bfa74 r235782 = 233c2e72168c1e838d65c4a294b329771aed2184 r235783 = eb79bb6e61583c3ba05c8478809c02e3cc7bb6d3 r235784 = ef477f3580c1db48ccdc21915d4f5d99ff61a983 r235785 = ae3211466a644543315876809e5a516ab5dd1ffd r235786 = 8efc1906901401ecf6d72975aca4a8a40e1706d4 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 15:48:28 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 24 Apr 2015 22:48:28 +0000 Subject: [LLVMbugs] [Bug 23343] New: const const double Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23343 Bug ID: 23343 Summary: const const double Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Testcase: template struct X { typedef const T& const_reference; }; void helper(const X x) { decltype(x)::const_reference y = x; } $ clang b15959151.cc -std=c++11 b15959151.cc:5:32: error: no viable conversion from 'const X' to 'const const double' decltype(x)::const_reference y = x; ^ ~ 1 error generated. We should never print "const const double". -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 17:08:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 25 Apr 2015 00:08:56 +0000 Subject: [LLVMbugs] [Bug 22262] LLVM's pivot element selection is bad for sparse switch statements In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22262 Hans Wennborg changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Hans Wennborg --- This was committed in r235560, with follow-ups in r235608 and r235729. See the code review at http://reviews.llvm.org/D8649 for numbers and such. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 24 20:35:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 25 Apr 2015 03:35:40 +0000 Subject: [LLVMbugs] [Bug 23345] New: [globalsmodref-aa] Atomics not considered to access memory. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23345 Bug ID: 23345 Summary: [globalsmodref-aa] Atomics not considered to access memory. Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: Global Analyses Assignee: unassignedbugs at nondot.org Reporter: chisophugis at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The loop "// Scan the function bodies for explicit loads or stores." in http://llvm.org/klaus/llvm/blob/master/lib/Analysis/IPA/GlobalsModRef.cpp#L-438 appears to ignore atomic operations (e.g. cmpxchg, atomicrmw). Patch will be on llvm-commits shortly. This bug has probably been latent since those instructions were introduced. A quick blame shows the loop was last touched in 2012. I found this because the "compare and swap" was being hoisted out of a standard "compare and swap" loop with -fno-inline: test case: opt -S :1 ; preds = %1, %0 %2 = call i64 @_ZL16compareAndSwap64Pxxx(i64* %p) %3 = icmp eq i64 %2, 0 br i1 %3, label %1, label %4 ; ' is not defined [-Wundefined-inline] DECL_CONSTEXPR int typeId(); ^ undef.cpp:18:15: note: used here (void)typeId(); ^ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 25 20:49:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 03:49:46 +0000 Subject: [LLVMbugs] [Bug 11280] __sync_bool_compare_and_swap build error In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=11280 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 25 20:50:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 03:50:49 +0000 Subject: [LLVMbugs] [Bug 11280] __sync_bool_compare_and_swap build error In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=11280 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 25 20:51:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 03:51:14 +0000 Subject: [LLVMbugs] [Bug 20207] Assertion failed: (End.getPointer() <= EndPtr && "frontend claimed part of a token?") In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20207 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 25 20:52:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 03:52:42 +0000 Subject: [LLVMbugs] [Bug 16907] Crash in lambda expression In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=16907 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Davide Italiano --- Fixed in head. % ./clang++ lamda.cpp -o lambda lamda.cpp:5:5: warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions] auto f = []() { ^ lamda.cpp:5:14: error: expected expression auto f = []() { ^ 1 warning and 1 error generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 25 20:55:02 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 03:55:02 +0000 Subject: [LLVMbugs] [Bug 21055] "std::function foo = std::bind(std::exit, 0)" does not compile In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21055 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Davide Italiano --- Builds on clang HEAD. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 25 22:33:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 05:33:05 +0000 Subject: [LLVMbugs] [Bug 23350] New: Assertion `DelayedTypos.empty() && "Uncorrected typos!" fires in malformed ternary Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23350 Bug ID: 23350 Summary: Assertion `DelayedTypos.empty() && "Uncorrected typos!" fires in malformed ternary Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: david.majnemer at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified consider: int z = 1 ? N : ; running this in either c or c++ mode causes an assertion failure -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 26 09:26:47 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 16:26:47 +0000 Subject: [LLVMbugs] [Bug 23351] New: Initializing reference to array crashes clang: Assertion `CurInit.get()->isRValue() && "not a temporary"' failed. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23351 Bug ID: 23351 Summary: Initializing reference to array crashes clang: Assertion `CurInit.get()->isRValue() && "not a temporary"' failed. Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: david.majnemer at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified either: const char (&V)[]{"a"}; or: const char (&V)[1]{"a"}; results in: lib/Sema/SemaInit.cpp:6031: clang::ExprResult clang::InitializationSequence::Perform(clang::Sema&, const clang::InitializedEntity&, const clang::InitializationKind&, clang::MultiExprArg, clang::QualType*): Assertion `CurInit.get()->isRValue() && "not a temporary"' failed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 26 09:34:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 16:34:48 +0000 Subject: [LLVMbugs] [Bug 20884] find_package(LLVM REQUIRED CONFIG) fails with Error:set_property could not find TARGET LLVMSupport. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20884 Dan Liew changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Dan Liew --- I'm closing this because the original report was for a different bug. I've opened a separate bug for the packaging issue (PR23352). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 26 09:35:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 16:35:48 +0000 Subject: [LLVMbugs] [Bug 15629] clang::Expr::setType() Assertion failed: "Expressions can't have reference type" In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15629 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |david.majnemer at gmail.com Resolution|--- |FIXED Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com |org | --- Comment #2 from David Majnemer --- Fixed in r235818. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 26 10:06:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 17:06:36 +0000 Subject: [LLVMbugs] [Bug 23353] New: clang crashes on valid code at -O2 and -O3 on x86_64-linux-gnu Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23353 Bug ID: 23353 Summary: clang crashes on valid code at -O2 and -O3 on x86_64-linux-gnu Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: su at cs.ucdavis.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The current clang trunk crashes when compiling the following test case on x86_64-linux-gnu at -O2 and -O3 in both 32-bit and 64-bit modes. It also affects 3.5.0 and 3.6.0, but not 3.4.x. $ clang-trunk -v clang version 3.7.0 (trunk 235803) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.0.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.0.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -Os -c small.c $ clang-3.4.2 -O2 -c small.c $ $ clang-trunk -O2 -c small.c clang: /tmp/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:6324: unsigned int llvm::SelectionDAG::AssignTopologicalOrder(): Assertion `AllNodes.back().use_empty() && "Last node in topologic sort has users!"' failed. #0 0x2af9faa llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang+0x2af9faa) #1 0x2afb43b (/usr/local/clang-trunk/bin/clang+0x2afb43b) #2 0x7fd88429d340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #3 0x7fd88323bcc9 gsignal /build/buildd/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7fd88323f0d8 abort /build/buildd/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7fd883234b86 __assert_fail_base /build/buildd/eglibc-2.19/assert/assert.c:92:0 #6 0x7fd883234c32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #7 0x21909c1 llvm::SelectionDAG::AssignTopologicalOrder() (/usr/local/clang-trunk/bin/clang+0x21909c1) #8 0x21e51de llvm::SelectionDAGISel::DoInstructionSelection() (/usr/local/clang-trunk/bin/clang+0x21e51de) #9 0x21e4418 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr/local/clang-trunk/bin/clang+0x21e4418) #10 0x21e2d98 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/local/clang-trunk/bin/clang+0x21e2d98) #11 0x21df864 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/usr/local/clang-trunk/bin/clang+0x21df864) #12 0x1fef321 (/usr/local/clang-trunk/bin/clang+0x1fef321) #13 0x237e76c llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang+0x237e76c) #14 0x2a59e24 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang+0x2a59e24) #15 0x2a5a05b llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang+0x2a5a05b) #16 0x2a5a545 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang+0x2a5a545) #17 0x95a69d clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) (/usr/local/clang-trunk/bin/clang+0x95a69d) #18 0x94c5e5 (/usr/local/clang-trunk/bin/clang+0x94c5e5) #19 0xb67403 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang+0xb67403) #20 0x740ebe clang::FrontendAction::Execute() (/usr/local/clang-trunk/bin/clang+0x740ebe) #21 0x712b0c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/clang-trunk/bin/clang+0x712b0c) #22 0x6f4dc8 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/clang-trunk/bin/clang+0x6f4dc8) #23 0x6ebfa2 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/clang-trunk/bin/clang+0x6ebfa2) #24 0x6f3550 main (/usr/local/clang-trunk/bin/clang+0x6f3550) #25 0x7fd883226ec5 __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:321:0 #26 0x6ebc19 _start (/usr/local/clang-trunk/bin/clang+0x6ebc19) Stack dump: 0. Program arguments: /usr/local/clang-trunk/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.24 -momit-leaf-frame-pointer -dwarf-column-info -fno-unique-section-names -coverage-file /data2/c-hunter-results/C/instrument-bugs/CSMITH/20150424-clang-trunk-m64-g-O3-build-064506/small.c -resource-dir /usr/local/clang-trunk/bin/../lib/clang/3.7.0 -internal-isystem /usr/local/include -internal-isystem /usr/local/clang-trunk/bin/../lib/clang/3.7.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -fdebug-compilation-dir /data2/c-hunter-results/C/instrument-bugs/CSMITH/20150424-clang-trunk-m64-g-O3-build-064506 -ferror-limit 19 -fmessage-length 140 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o small.o -x c small.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'small.c'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@fn2' clang: error: unable to execute command: Aborted (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 235803) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/small-a82618.c clang: note: diagnostic msg: /tmp/small-a82618.sh clang: note: diagnostic msg: ******************** $ ----------------------------- int a; volatile int b; char c; char fn1 (char p1, char p2) { return p1 * p2; } void fn2 () { for (c = -2; c < 3; c++) b = fn1 (c, a) && 1; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 26 11:25:40 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 26 Apr 2015 18:25:40 +0000 Subject: [LLVMbugs] [Bug 23354] New: Missing LLVM-C interface for building atomic compare exchange instructions Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23354 Bug ID: 23354 Summary: Missing LLVM-C interface for building atomic compare exchange instructions Product: libraries Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Core LLVM classes Assignee: unassignedbugs at nondot.org Reporter: coder0xff at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The LLVMBuildAtomicRMW function doesn't seem to support an op code for compare exchange, and I couldn't find a function for building compare exchange in specific. It's either missing, or I just had no luck searching for it. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 26 23:45:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 06:45:34 +0000 Subject: [LLVMbugs] [Bug 23356] New: Wrong comment parsing with -std=c89 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23356 Bug ID: 23356 Summary: Wrong comment parsing with -std=c89 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: abramo.bagnara at bugseng.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14257 --> https://llvm.org/bugs/attachment.cgi?id=14257&action=edit Patch to fix C89 comment parsing In general clang cannot parse line comments when they are not enabled, otherwise valid code is seen as invalid. I've attached patch to fix that. $ cat p.c #define str_(x) #x #define str(x) str_(x) char *s = str(//); $ clang-3.5 -std=c89 -c p.c p.c:3:11: error: unterminated function-like macro invocation char *s = str(//); ^ p.c:2:9: note: macro 'str' defined here #define str(x) str_(x) ^ p.c:3:19: error: expected expression char *s = str(//); ^ p.c:3:10: error: expected ';' after top level declarator char *s = str(//); ^ ; 3 errors generated. $ gcc -std=c89 -c p.c $ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 06:34:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 13:34:50 +0000 Subject: [LLVMbugs] [Bug 23358] New: A Division by Zero does not generate a floating point exception when optimizations are enabled Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23358 Bug ID: 23358 Summary: A Division by Zero does not generate a floating point exception when optimizations are enabled Product: clang Version: 3.6 Hardware: PC OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: manus at eiffel.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following program #include #include int main () { int volatile l = 123; int volatile v = (1 / (l - l)); printf ("Value of v is %d\n", v); } will not generate a floating point exception when compiled in -O1/-O2/-O3 optimization. This starded when upgrading the latest Xcode (v6.3) from Apple: cc --version Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 07:50:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 14:50:10 +0000 Subject: [LLVMbugs] [Bug 23359] New: Apt repository's have invalid paths in cmake files (Debian 8) Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23359 Bug ID: 23359 Summary: Apt repository's have invalid paths in cmake files (Debian 8) Product: Build scripts Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: andreas at fink.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified freshly installed Debian 8 Did execute this: # # LLVM 3.6 # FILE=/etc/apt/sources.list.d/llvm.list echo "deb http://llvm.org/apt/jessie/ llvm-toolchain-jessie-3.6 main" > $FILE echo "deb-src http://llvm.org/apt/jessie/ llvm-toolchain-jessie-3.6 main" >> $FILE wget -O - http://llvm.org/apt/llvm-snapshot.gpg.key > /tmp/llvm-snapshot.gpg.key apt-key add /tmp/llvm-snapshot.gpg.key apt-get update apt-get install clang-3.6 clang-3.6-doc libclang-common-3.6-dev libclang-3.6-dev libclang1-3.6 libclang1-3.6-dbg libllvm-3.6-ocaml-dev libllvm3.6 libllvm3.6-dbg lldb-3.6 llvm-3.6 llvm-3.6-dev llvm-3.6-doc llvm-3.6-examples llvm-3.6-runtime clang-modernize-3.6 clang-format-3.6 python-clang-3.6 lldb-3.6-dev libc++-dev libc++-helpers libc++-test libc++1 then I downloaded gnustep which I need to build for ObjectiveC 2.0 support (ARC). wget http://download.gna.org/gnustep/libobjc2-1.7.tar.bz2 wget http://ftpmain.gnustep.org/pub/gnustep/core/gnustep-make-2.6.6.tar.gz wget http://ftpmain.gnustep.org/pub/gnustep/core/gnustep-base-1.24.7.tar.gz wget http://ftpmain.gnustep.org/pub/gnustep/core/gnustep-gui-0.24.0.tar.gz wget http://ftpmain.gnustep.org/pub/gnustep/core/gnustep-back-0.24.0.tar.gz tar -xvjf libobjc2-1.7.tar.bz2 tar -xvzf gnustep-make-2.6.6.tar.gz tar -xvzf gnustep-back-0.24.0.tar.gz tar -xvzf gnustep-base-1.24.7.tar.gz tar -xvzf gnustep-gui-0.24.0.tar.gz cd gnustep-make-2.6.6 ./configure CC=clang-3.6 CXX=clang++-3.6 --disable-importing-config-file --enable-debug-by-default --enable-objc-nonfragile-abi make install cd ../libobjc2-1.7 mkdir build cd build cmake .. this fails wit a cmake include file not found Fix for this part: in file /usr/share/llvm-3.6/cmake/LLVMConfig.cmake the line set(LLVM_CMAKE_DIR "/usr/lib/llvm-3.6/share/llvm/cmake") should be set(LLVM_CMAKE_DIR "/usr/share/llvm-3.6/cmake") (its being referenced by libobjc and line 53 fails) When this is fixed, the make process gets further but still fails at a later stage in the AddLLVM.cmake file (couldn't figure out yet how to fix that part yet). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 08:00:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 15:00:35 +0000 Subject: [LLVMbugs] [Bug 23358] A Division by Zero does not generate a floating point exception when optimizations are enabled In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23358 Michael Kuperstein changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |michael.m.kuperstein at intel. | |com Resolution|--- |INVALID --- Comment #1 from Michael Kuperstein --- Integer division by zero is undefined behavior. I'm not sure why it would generate a floating point exception, in particular. Or am I missing something special about this example? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 08:14:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 15:14:46 +0000 Subject: [LLVMbugs] [Bug 20699] [AVX512] Cannot select: 0x7fd69c057070: v16i1 = X86ISD::PCMPEQ In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20699 Elena Demikhovsky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |elena.demikhovsky at intel.com Resolution|--- |FIXED --- Comment #1 from Elena Demikhovsky --- I fixed this bug in revision 235875. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 08:17:06 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 15:17:06 +0000 Subject: [LLVMbugs] [Bug 20724] [AVX512] Cannot select: 0x7fd80b841b68: ch = store when returning <16 x i1> from function In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20724 Elena Demikhovsky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |elena.demikhovsky at intel.com Resolution|--- |FIXED --- Comment #1 from Elena Demikhovsky --- I fixed the bug in 235889. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 08:24:33 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 15:24:33 +0000 Subject: [LLVMbugs] [Bug 20665] [AVX512] argument #2 has unhandled type v16i1 error with <16 x i1> function argument In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20665 Elena Demikhovsky changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |elena.demikhovsky at intel.com Resolution|--- |FIXED --- Comment #1 from Elena Demikhovsky --- fixed in 235889 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 10:30:49 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 17:30:49 +0000 Subject: [LLVMbugs] [Bug 18496] [cmake] .S assembly files not compiled by cmake in libclang_rt.ARCH In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=18496 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Reid Kleckner --- Closing based on Andrew's investigation. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 10:30:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 17:30:50 +0000 Subject: [LLVMbugs] [Bug 15732] [META] CMake build equivalent to the autotools build In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15732 Bug 15732 depends on bug 18496, which changed state. Bug 18496 Summary: [cmake] .S assembly files not compiled by cmake in libclang_rt.ARCH https://llvm.org/bugs/show_bug.cgi?id=18496 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 10:32:42 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 17:32:42 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 21062, which changed state. Bug 21062 Summary: MS ABI: Assertion in VFTableBuilder when compiling hierarchy with virtual inheritance https://llvm.org/bugs/show_bug.cgi?id=21062 What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 10:32:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 17:32:41 +0000 Subject: [LLVMbugs] [Bug 21062] MS ABI: Assertion in VFTableBuilder when compiling hierarchy with virtual inheritance In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21062 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Reid Kleckner --- Fixed in r235899. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 10:32:52 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 17:32:52 +0000 Subject: [LLVMbugs] [Bug 21064] MS ABI: Assertion failed: CXXInfo->BaseOffsets.count(Base) && "Did not find base!" In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21064 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Reid Kleckner --- Fixed in r235899. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 10:32:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 17:32:53 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 21064, which changed state. Bug 21064 Summary: MS ABI: Assertion failed: CXXInfo->BaseOffsets.count(Base) && "Did not find base!" https://llvm.org/bugs/show_bug.cgi?id=21064 What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 13:33:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 20:33:15 +0000 Subject: [LLVMbugs] [Bug 23358] A Division by Zero does not generate a floating point exception when optimizations are enabled In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23358 Emmanuel STAPF changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #3 from Emmanuel STAPF --- My concern is not with the standard that says it is an undefined behavior. What I'm saying is that since I've been using clang, the clang definition of undefined behavior was to throw a floating point exception (behavior you only get now with the -O0 optimization). As a user, I expect the behavior of throwing the exception to remain the same across versions and across various compiler flags (there might be exception to this rule since certain command line options changes some behaviors). I was just highlighting that fact and am hoping you will fix this. Note that the behavior of throwing an exception is quite common to various C compilers on the various platforms I've been dealing with. PS: I kept the `volatile' modifier from the original piece of code I was debugging but it has actually no bearing in the behavior, so you can update the code sample to just: #include #include int main () { int w = 123; int v = (1 / (w - w)); printf ("Value of v is %d\n", v); } Here is the output I'm observing: : cc -O0 a.c ; ./a.out Floating exception : cc -O1 a.c ; ./a.out Value of v is 1455093720 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 13:42:20 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 20:42:20 +0000 Subject: [LLVMbugs] [Bug 23358] A Division by Zero does not generate a floating point exception when optimizations are enabled In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23358 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |INVALID --- Comment #4 from Richard Smith --- (In reply to comment #3) > What I'm saying is that since I've been using clang, the clang definition of > undefined behavior was to throw a floating point exception That is not correct. Clang does not define this particular undefined behavior, and never did. It is the nature of undefined behavior that sometimes you'll see it behaving in some predictable way, but that does not make it defined. [In the original testcase, we are in fact preserving the two volatile loads of l, and if they produce different answers, we will correctly compute the value of v.] See http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 13:46:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 20:46:31 +0000 Subject: [LLVMbugs] [Bug 14620] No "control reaches end of non-void function" warning when using function-try-blocks In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=14620 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Aaron Ballman --- Resolving as WORKSFORME; if you find that ToT's behavior is insufficient, please reopen with further details. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 13:53:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 20:53:24 +0000 Subject: [LLVMbugs] [Bug 21000] clang doesn't pass -I flags to the assembler (both with and without integrated as) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21000 Artem Belevich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Artem Belevich --- Committed in http://reviews.llvm.org/rL235915 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 14:28:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 21:28:24 +0000 Subject: [LLVMbugs] [Bug 23334] crash in Sema::CleanupVarDeclMarking with [=] lambda In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23334 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Smith --- Fixed in r235921. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 14:39:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 21:39:30 +0000 Subject: [LLVMbugs] [Bug 21000] clang doesn't pass -I flags to the assembler (both with and without integrated as) In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21000 Artem Belevich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #4 from Artem Belevich --- D7472 / r235915 is insufficient as other assembler variants also need to be covered. I've rolled back my changes until I have a better fix. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 15:00:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 22:00:50 +0000 Subject: [LLVMbugs] [Bug 22272] Deadlock on ctrl-c In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22272 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Very likely fixed by r235914. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 15:31:53 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 27 Apr 2015 22:31:53 +0000 Subject: [LLVMbugs] [Bug 15842] need to check for a placeholder in argument to noexcept In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15842 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Aaron Ballman --- Fixed in r235931 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 17:29:48 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 00:29:48 +0000 Subject: [LLVMbugs] [Bug 23361] New: [AVX512] Cannot select v16i1 = select Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23361 Bug ID: 23361 Summary: [AVX512] Cannot select v16i1 = select Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14259 --> https://llvm.org/bugs/attachment.cgi?id=14259&action=edit test case With the attached test case, if I run "llc -mcpu=knl bug.ll", I get the following output: LLVM ERROR: Cannot select: 0x7f84c0892ca0: v16i1 = select 0x7f84c08cfd70, 0x7f84c08975b0, 0x7f84c08995b0 [ORD=4] [ID=44] 0x7f84c08cfd70: i1 = truncate 0x7f84c0892420 [ORD=3] [ID=41] 0x7f84c0892420: i8 = X86ISD::SETCC 0x7f84c08d0600, 0x7f84c08d1a40 [ORD=3] [ID=39] 0x7f84c08d0600: i8 = Constant<4> [ID=22] 0x7f84c08d1a40: i32 = X86ISD::CMP 0x7f84c08d0f90, 0x7f84c08d1820 [ORD=3] [ID=37] 0x7f84c08d0f90: i16,ch = CopyFromReg 0x7f84c0439030, 0x7f84c08d0930 [ORD=3] [ID=26] 0x7f84c08d0930: i16 = Register %vreg31 [ID=2] 0x7f84c08d1820: i16 = Constant<0> [ID=3] 0x7f84c08975b0: v16i1 = BUILD_VECTOR 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820, 0x7f84c08d0820 [ORD=4] [ID=36] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08d0820: i1 = TargetConstant<0> [ID=25] 0x7f84c08995b0: v16i1,ch = CopyFromReg 0x7f84c0439030, 0x7f84c0899390 [ORD=4] [ID=27] 0x7f84c0899390: v16i1 = Register %vreg30 [ID=4] In function: volume_tile___uniuniuniuniun_3C_unf_3E_un_3C_uni_3E_un_3C_Cunf_5B_4_5D__3E_un_3C_Cunf_5B_4_5D__3E_uniuniun_3C_unf_3E_ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 18:04:35 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 01:04:35 +0000 Subject: [LLVMbugs] [Bug 23362] New: [AVX512] i1 parameter in function declaration -> UNREACHABLE executed at CallingConvLower.cpp:81! Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23362 Bug ID: 23362 Summary: [AVX512] i1 parameter in function declaration -> UNREACHABLE executed at CallingConvLower.cpp:81! Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14260 --> https://llvm.org/bugs/attachment.cgi?id=14260&action=edit test case With top of tree and the attached test case, if I run "llc -mcpu=knl bugpoint-reduced-simplified.ll", I get: Formal argument #13 has unhandled type i1 UNREACHABLE executed at CallingConvLower.cpp:81! 0 llc 0x0000000109b9fb09 void std::__1::seed_seq::generate(unsigned int*, unsigned int*) + 12297 1 llc 0x0000000109ba049b void std::__1::seed_seq::generate(unsigned int*, unsigned int*) + 14747 2 libsystem_platform.dylib 0x00007fff978b8f1a _sigtramp + 26 3 llc 0x000000010a3522ed vtable for llvm::cl::opt > + 133709 4 llc 0x0000000109ba0206 void std::__1::seed_seq::generate(unsigned int*, unsigned int*) + 14086 5 llc 0x0000000109b895a1 void* llvm::object_creator >() + 3601 6 llc 0x00000001095000d3 void std::__1::vector >::__push_back_slow_path(llvm::BranchFolder::SameTailElt&&) + 10419 7 llc 0x00000001091d1dad std::__1::__tree, std::__1::allocator >::destroy(std::__1::__tree_node*) + 96301 8 llc 0x0000000109443ae7 std::__1::__tree, std::__1::allocator > >, std::__1::__map_value_compare, std::__1::allocator > >, std::__1::less, true>, std::__1::allocator, std::__1::allocator > > > >::destroy(std::__1::__tree_node, std::__1::allocator > >, void*>*) + 211047 9 llc 0x000000010945bcc1 void std::__1::vector >::__push_back_slow_path(llvm::GCRoot&&) + 26481 10 llc 0x000000010945a698 void std::__1::vector >::__push_back_slow_path(llvm::GCRoot&&) + 20808 11 llc 0x00000001091ba664 std::__1::__tree, std::__1::allocator >::destroy(std::__1::__tree_node*) + 228 12 llc 0x00000001095b7b1c llvm::raw_ostream& llvm::WriteGraph(llvm::raw_ostream&, llvm::MachineFunction const* const&, bool, llvm::Twine const&) + 5484 13 llc 0x0000000109af5a8e llvm::hash_code llvm::hashing::detail::hash_combine_range_impl(llvm::MDOperand const*, llvm::MDOperand const*) + 34382 14 llc 0x0000000109af5ceb llvm::hash_code llvm::hashing::detail::hash_combine_range_impl(llvm::MDOperand const*, llvm::MDOperand const*) + 34987 15 llc 0x0000000109af62a3 llvm::hash_code llvm::hashing::detail::hash_combine_range_impl(llvm::MDOperand const*, llvm::MDOperand const*) + 36451 16 llc 0x0000000108a4db6d 17 libdyld.dylib 0x00007fff8a5225c9 start + 1 18 libdyld.dylib 0x0000000000000003 start + 1974327867 Stack dump: 0. Program arguments: llc -mcpu=knl bugpoint-reduced-simplified.ll 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@ShadeTile' [2] 40384 illegal hardware instruction llc -mcpu=knl bugpoint-reduced-simplified.ll -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 18:08:31 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 01:08:31 +0000 Subject: [LLVMbugs] [Bug 23363] New: [AVX512] bitcast assertion hits in SelectionDAG.cpp Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23363 Bug ID: 23363 Summary: [AVX512] bitcast assertion hits in SelectionDAG.cpp Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: matt at pharr.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14261 --> https://llvm.org/bugs/attachment.cgi?id=14261&action=edit test case With top of tree and the attached test case, if I run "llc -mcpu=knl bugpoint-reduced-simplified.ll", I get: Assertion failed: (VT.getSizeInBits() == Operand.getValueType().getSizeInBits() && "Cannot BITCAST between types of different sizes!"), function getNode, file SelectionDAG.cpp, line 2989. [....] Stack dump: 0. Program arguments: llc -mcpu=knl bugpoint-reduced-simplified.ll 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@raytrace_tile___uniuniuniuniuniuniuniuniun_3C_Cunf_5B_4_5D__3E_un_3C_Cunf_5B_4_5D__3E_un_3C_unf_3E_un_3C_uni_3E_un_3C_s_5B__c_unLinearBVHNode_5D__3E_un_3C_s_5B__c_unTriangle_5D__3E_' [2] 40640 illegal hardware instruction llc -mcpu=knl bugpoint-reduced-simplified.ll -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 18:10:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 01:10:39 +0000 Subject: [LLVMbugs] [Bug 23332] clang: error: unable to execute command: Segmentation fault: 11 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23332 Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Duncan --- Fixed in r235955 (clang test in r235956). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 18:29:58 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 01:29:58 +0000 Subject: [LLVMbugs] [Bug 23057] fuzz clang In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23057 Bug 23057 depends on bug 21846, which changed state. Bug 21846 Summary: [fuzz] Assertion `!isAnnotation() && "getIdentifierInfo() on an annotation token!"' failed. https://llvm.org/bugs/show_bug.cgi?id=21846 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 27 18:29:57 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 01:29:57 +0000 Subject: [LLVMbugs] [Bug 21846] [fuzz] Assertion `!isAnnotation() && "getIdentifierInfo() on an annotation token!"' failed. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21846 Davide Italiano changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |davide at freebsd.org Resolution|--- |FIXED --- Comment #1 from Davide Italiano --- Fixed in clang head. % ./clang -fno-crash-diagnostics -std=c++11 -xc++ -c -emit-llvm lex_crash.cpp lex_crash.cpp:2:15: error: declaration of anonymous struct must be a definition struct A::X < struct T ^ lex_crash.cpp:3:1: error: expected a type ^ lex_crash.cpp:2:11: error: explicit specialization of non-template struct 'X' struct A::X < struct T ^ lex_crash.cpp:2:11: error: no struct named 'X' in 'A' struct A::X < struct T ~~~^ lex_crash.cpp:3:1: error: expected member name or ';' after declaration specifiers ^ lex_crash.cpp:3:1: error: expected '}' lex_crash.cpp:1:32: note: to match this '{' template struct A { ^ lex_crash.cpp:2:23: error: expected ';' after struct struct A::X < struct T ^ ; 7 errors generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 02:41:24 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 09:41:24 +0000 Subject: [LLVMbugs] [Bug 23364] New: Untangle libunwind from libc++abi and compiler-rt Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23364 Bug ID: 23364 Summary: Untangle libunwind from libc++abi and compiler-rt Product: libc++abi Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedbugs at nondot.org Reporter: renato.golin at linaro.org CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified Now that we moved libunwind to its own repository, and have made it compile and run on buildbots around, we need to make sure we get all dependencies correct: 1. No hard-coded dependencies on any other component. Most relevant are compiler-rt and libc++abi. 2. No cyclic dependency between all three low-level libraries, with both compiler-rt and libc++abi using libunwind and not each other. 3. Build systems / CMake files need to be aware of the existence, so libunwind can be used inside LLVM (projects/libunwind) and be used directly by compiler-rt/libc+abi in case CMake options allow for this. 4. Different systems will have different defaults. For example, it's perfectly valid for GNU systems to rely on libgcc / libgcc_s by default and BSD systems to rely on compiler-rt / libunwind. There should be CMake settings for either to change their behaviour. 5. All tests must pass in the targets they were passing before, namely x86_64/ARM on linux/darwin. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 02:58:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 09:58:34 +0000 Subject: [LLVMbugs] [Bug 23365] New: clang should not throw away #ident directives Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23365 Bug ID: 23365 Summary: clang should not throw away #ident directives Product: clang Version: 3.5 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: fuzxxl at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified clang seems to throw away #ident directives without actually adding an identification to the object file. #ident directives are useful for adding version or copyright information to binaries and their usage is widespread through the *BSD and Solaris code bases. It would be great if clang could support #ident directives. The implementation boils down to turning a directive in C or C++ source code of the form #ident "something" into assembly of the form .ident "something" on ELF targets at least, although the gas manual suggests that this directive does something to a similar effect on other platforms as well. The general mechanism to emit such assembly directives seems to exist already as clang is able to emit a compiler identification string as an ident assembly directive. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 04:04:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 11:04:56 +0000 Subject: [LLVMbugs] [Bug 23366] New: Incredibly slow compilation of inline-assembly-heavy C++ code Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23366 Bug ID: 23366 Summary: Incredibly slow compilation of inline-assembly-heavy C++ code Product: clang Version: 3.6 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: johan.overbye at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14263 --> https://llvm.org/bugs/attachment.cgi?id=14263&action=edit OS X Activity Monitor sample of the clang process In our project we have a single C++ file that contains very large amounts of inline assembly code. It used to take no noticeable time to compile this (< 1 second), but after upgrading to LLVM 3.6 (Apple LLVM 6.1 in Xcode), it's taking tens of minutes. I'm guessing roughly 30 minutes on this MacBook: 2.2 GHz Intel Core i7 8 GB 1333 MHz DDR3 I'm not at liberty to share the code, however after some testing, it looks like it might be down to just the quantity of inline assembly code. On profiling the clang process, the function clang::GCCAsmStmt::AnalyzeAsmString() seems to be doing all the work. Call stack from OS X Activity Monitor is attached. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 05:31:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 12:31:10 +0000 Subject: [LLVMbugs] [Bug 13269] incorrect debug location info in ConstantSDNodes In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=13269 Sergey Dmitrouk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Sergey Dmitrouk --- ConstantSDNodes gained debug locations in r235977, so it will be available since LLVM 3.7 release. Note however that because of constant materialization optimization in FastISel and related to it resetting of debug locations when using FastISel debug locations might still be not accurate in some cases (this might be resolved separately and is not directly related to this PR as FastISel doesn't use SDNodes). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 07:38:12 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 14:38:12 +0000 Subject: [LLVMbugs] [Bug 22072] Regression/crash for noexcept In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22072 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aaron at aaronballman.com Resolution|--- |FIXED --- Comment #1 from Aaron Ballman --- Fixed with r235931 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 11:06:39 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 18:06:39 +0000 Subject: [LLVMbugs] [Bug 22047] ObjC: Method unavailability attribute doesn't work with overloaded methods In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22047 Jonathan Roelofs changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jonathan at codesourcery.com Resolution|--- |FIXED --- Comment #2 from Jonathan Roelofs --- Fixed in r236006. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 12:12:30 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 19:12:30 +0000 Subject: [LLVMbugs] [Bug 23367] New: Attach subprograms to functions via a !dbg metadata attachment Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23367 Bug ID: 23367 Summary: Attach subprograms to functions via a !dbg metadata attachment Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedbugs at nondot.org Reporter: dexonsmith at apple.com CC: aprantl at apple.com, dblaikie at gmail.com, echristo at gmail.com, friss at apple.com, llvmbugs at cs.uiuc.edu Depends on: 23340 Classification: Unclassified Bug 23340 implemented function metadata attachments. We should use a !dbg attachment to directly map functions to subprograms, rather than building it up implicitly from the compile unit subprograms array and the subprogram `function:` field. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 15:15:34 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 22:15:34 +0000 Subject: [LLVMbugs] [Bug 23368] New: __chkstk call in function prologue is too far away Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23368 Bug ID: 23368 Summary: __chkstk call in function prologue is too far away Product: new-bugs Version: 3.6 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: nick at indigorenderer.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14267 --> https://llvm.org/bugs/attachment.cgi?id=14267&action=edit IR On Windows x64, while JITing some code, there is a problem if more than 4K is allocated on the stack. In this case X86FrameLowering::getStackProbeFunction() is called, and a call to __chkstk is emitted. However, the memory address of __chkstk is very high in the memory space, e.g. 0x000007f8bc432590. As a result the assertion assert(RealOffset <= INT32_MAX && RealOffset >= INT32_MIN); fails in RuntimeDyldELF.cpp, line 271. I have attached some IR and also assembly. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 15:45:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 22:45:08 +0000 Subject: [LLVMbugs] [Bug 23368] __chkstk call in function prologue is too far away In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23368 Nicholas Chapman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 15:58:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 28 Apr 2015 22:58:32 +0000 Subject: [LLVMbugs] [Bug 23369] New: r235837 broke 8-bit vector multiplies on older x86 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23369 Bug ID: 23369 Summary: r235837 broke 8-bit vector multiplies on older x86 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: andrew.b.adams at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified vectorized 8-bit multiplies no longer produce correct results on k8. To repro: scratch.ll: define void @test(<16 x i8>* %a, <16 x i8>* %b, <16 x i8>* %c) { %1 = load <16 x i8>, <16 x i8>* %a %2 = load <16 x i8>, <16 x i8>* %b %3 = mul <16 x i8> %1, %2 store <16 x i8> %3, <16 x i8>* %c ret void } test.c: #include #include void test(uint8_t *a, uint8_t *b, uint8_t *c); int main(int argc, char **argv) { uint8_t a[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16}; uint8_t b[] = {2, 4, 1, 3, 2, 4, 1, 2, 2, 3, 1, 4, 1, 2, 3, 4}; uint8_t correct[16]; for (int i = 0; i < 16; i++) { correct[i] = a[i] * b[i]; } uint8_t actual[16]; test(a, b, actual); for (int i = 0; i < 16; i++) { printf("%d %d\n", correct[i], actual[i]); } return 0; } Compile scratch.ll two different ways: llc -O3 scratch.ll -mcpu=penryn -filetype=obj -o scratch_penryn.o llc -O3 scratch.ll -mcpu=k8 -filetype=obj -o scratch_k8.o Make two binaries: clang test.c scratch_penryn.o -o test_penryn clang test.c scratch_k8.o -o test_k8 Run them: test_penryn: 2 2 8 8 3 3 12 12 10 10 24 24 7 7 16 16 18 18 30 30 11 11 48 48 13 13 28 28 45 45 64 64 The columns match, this is correct. test_k8: 2 1 8 4 3 9 12 16 10 25 24 36 7 49 16 64 18 18 30 30 11 11 48 48 13 13 28 28 45 45 64 64 The multiply only happened for the second half of the lanes. For the first half of the lanes it just passes through the input. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 17:24:41 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 29 Apr 2015 00:24:41 +0000 Subject: [LLVMbugs] [Bug 20625] static constexpr member function of a local struct in a function template is instantiated too late In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=20625 Michael Park changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 28 18:20:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 29 Apr 2015 01:20:08 +0000 Subject: [LLVMbugs] [Bug 23370] New: [meta] Using Clang/LLVM as the FreeBSD/mips system compiler Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23370 Bug ID: 23370 Summary: [meta] Using Clang/LLVM as the FreeBSD/mips system compiler Product: new-bugs Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: emaste at freebsd.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified FreeBSD supports 32- and 64-bit x86, arm, mips, and powerpc, as well as sparc64. We intend to use Clang as the system compiler across supported architectures, and are either using it now or are close for architectures other than mips and sparc64. This bug will depend on those issues that prevent us from enabling Clang as the FreeBSD/mips system compiler. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 29 04:05:07 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 29 Apr 2015 11:05:07 +0000 Subject: [LLVMbugs] [Bug 23372] New: COFF Global Variable failing Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23372 Bug ID: 23372 Summary: COFF Global Variable failing Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: OrcJIT Assignee: unassignedbugs at nondot.org Reporter: mbsteixeira at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I have the following problem: Assertion failed: (Sec->Characteristics & COFF::IMAGE_SCN_CNT_UNINITIALIZED_DATA ) == 0 && "BSS sections don't have contents!", file C:\llvm_3.5\lib\Object\COFFO bjectFile.cpp, line 996 It happens because the instruction below : ; ModuleID = 'totvs' %errorStatus_TOTVS_ASM = type { i32, i32, i8*, i32 (i8*)* } %VariantData_TOTVS_ASM = type { i32, %genData_TOTVS_ASM } %genData_TOTVS_ASM = type <{ double }> %error2_TOTVS_ASM = type { i32, i32 (i8*)*, i32 } @0 = private unnamed_addr constant [10 x i8] c"\0AMSG : %s\00" @errorStru_TOTVS_ASM = global %errorStatus_TOTVS_ASM zeroinitializer <== HERE When I ask to compile the module and this module has a global variable, it fails calling Check(SI->getContents(SectionData)); on RuntimeDyld.cpp, line 193. I am using MSVC 2013 on MS Windows 7 Professional 64 bits . -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 29 05:28:46 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 29 Apr 2015 12:28:46 +0000 Subject: [LLVMbugs] [Bug 23373] New: Miscompile of defaulted union copy ctor Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23373 Bug ID: 23373 Summary: Miscompile of defaulted union copy ctor Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: dario.domizioli at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Contrived example: // --------------------------------------------------------------------------- int testflag = 0; int main() { union U { int data; // Some data member. U(U&) = default; // Note the non-const &. It is allowed by the // standard. A non-deleted, defaulted copy ctor // should copy the data representation of the // union. U(int u) { data = u; } // Constructor from int. } obj1(2), obj2(obj1); // Obj2 must be initialized after obj1, so it // should contain 2. if(obj2.data != 2) { // This should be false (i.e. obj2.data == 2)! testflag++; // This should never be executed, but it is! } return testflag; } // --------------------------------------------------------------------------- Compile and link with just: clang -std=c++11 I am using the x86_64-unknown-linux triple. Even when compiled at -O0, testflag is incremented and this code returns with an exit code of 1. I believe the implementation of the explicitly-defaulted, implicitly-defined, non-const-& version of the copy ctor for union U is miscompiled. I've looked at my copy of the C++11 standard (INCITS+ISO+IEC+14882-2012) and I think the code is OK. The copy ctor is allowed to have a non-const reference and it's still a copy ctor (Clause 12.8 paragraph 2). An explicitly defaulted copy ctor is implicitly defined in this case (Clause 12.8 paragraph 13). An implicitly defined copy ctor for a union copies the object representation of the union (Clause 12.8 paragraph 16) so it should copy the data. The initialization of "obj2" must happen after "obj1" because of Clause 8, paragraph 3 (and footnote 97 for clarification). I have also noticed that the miscompile does not seem to happen when the defaulted copy ctor is the "const&" variant. U(U const&) = default; // This would work fine. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 29 10:07:15 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 29 Apr 2015 17:07:15 +0000 Subject: [LLVMbugs] [Bug 23080] Remove DIDescriptor and its subclasses In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23080 Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Duncan --- And this one is finished, as of r236120, r236121 (clang), and r236127 (polly). Here are the rest of the commits, in case this is useful to someone. r234175 = b508daa9c2f69d38fd939765530ec0b03373175f r234177 = fe42afc0e5044373279d3bbf36b82b87ce5b3819 r234181 = e75a8c3855273ffcc72461a3057e50bf0baee31f r234182 = c6370a13cfb21947126e388bf468d063013a26c5 r234183 = 8eb45116ef6ba34a579b4c55f906b7f3371dc606 r234186 = 3a69ccdae1676014a80b505b3a53ff4ea749e5d2 r234188 = 05652b6afa44be14fe33e9a20f0e508f2bfd292e r234192 = 46b9332e0eafc0012c2da3780771908463daca69 (polly) r234198 = 0e89353f21ba90fc1e735397d845d6f18d420f89 r234200 = 520ab696d0bc2096fbb62422364fae6e2807ca32 r234201 = 1ea24954c6d19e3788434ec3fb0ae5a7d3413517 r234222 = 2925bd0b3c9e0a156404dc02e59fdfda25784dc4 r234225 = 1114e434b00f9559408610488fe2bde596f2cfbd (revert r234222) r234241 = 23e0384808bf16208ba52e590f6e6260c5f0f05b r234245 = adca9604f182d96f3acf6fc58dfc77d23ebd6625 (clang) r234246 = cf0d94f4624603fbd817960fab3547b40ff7562b r234248 = a10307bf9543b8ff09a1469ca36bf500a465a73b r234250 = 2b8aee8cfab4399e94b5530dbadab1a831b564ca r234255 = 1545953510c396585f6bcadf55357d050ae0a113 r234256 = b32dd42dbb0a364559d70729e2fce415c77c66d1 (clang) r234257 = 573ca050d2d41f2e516b188b527dce73a374d7c4 r234258 = 0477045c3240aa75ebf61e66f10585fabee8f5de r234259 = 4a4ba5c687b401aff52d51e25fff04e8b4a244b6 r234262 = 894f455f8af6c861601b475ce1d50a844d997fe8 r234263 = e98edd267cc246fefe697bc22cf61afbb65f9649 r234267 = 329f8219cde304324d9b725494764e037f79cfec r234274 = 5f3bcf7dc4b32328e2f408710b70d7b39a8ab1fc r234275 = 8395c21d775021accaea64bda80b20023354e95e r234282 = 320efb05a1e7516268e711901ca9454bb4d94172 r234285 = fb2e97e4aadf94c6f6eb18fc39a8312d5c286280 r234286 = c6ac80b70108edb2d04b6da306e81724eb3df5cb r234287 = 550b962059a97e7eb3cbc4543ef9ba40644bf486 r234288 = 351071c069d236d5dde13d26fb747eb57ee9c8f3 r234289 = b135631d2e92dbe17738b5c6aadcfcaa2298a98a r234290 = 92d1a5236268c5e1a7878bd0788adf7393658c0d r234291 = b0d698fc614970042b126d603057b39cab7c657f (clang) r234292 = ea6394ec992a1e02feaab7eb7e3e6167b63745d0 r234294 = faa23b7768d087687a0a121f800215439dbc9eea r234295 = c513d37e67d8aa54467d28031286d33f4e06fed3 r234307 = a388c2a9b11b803fe804d4e2bb81d3eb5ba46a8c (clang: thanks to Timur) r234326 = 2e25115e02eda8f47786bca06288917c4437c103 r234327 = f7173ed4a77bec6c36a179d84d45a4d5484a79f1 (clang) r234329 = d9624d4956edcb57ba99d022d512ab3ddc74df53 r234331 = 05d49df6d80c5340f33939723754cee42ba0f059 r234333 = 5351b6d75e711fe2be3a26fb09ecaa4786cad2d3 r234335 = 47a6d12ba71e1aad492cf76feed5b256c9132e58 r234339 = 998dc53a388cdf88f87cd9df41af49946f7ed09d (clang) r234340 = 8d06b526759ed6c9f91a71936678e9f39b321da6 r234665 = 8d8c981a1f20a5454a4abeffa64942aa0e94d0c5 r234671 = 5fc3fbd3ca71c91607047cf456b63fcca02274fb r234672 = cb36df33ba05ec791a9e67cff25a21691e228b62 r234674 = 2c64a1129f14d6322631e1c6d610b92c4c4871d0 r234691 = 4e1b79bbd8944bd7875ec720a895664f46b9ed9c r234693 = 7ba137f94b3ca2f7a63cd30b785d6d73f794b7f1 r234695 = 9b30c7bd3839553e104553b014dcf0812c405b4a r234696 = dc54701c1f092eb688feee78d50a0bfad557636c (clang) r234697 = 429f5391adac7f453211b9f2a82d1055feee1d5e r234698 = 3ec16b419f8101ea195b7cc05ee152b9156becea r234699 = e2e641234fd4749ffa548bd18c9697b8eb066eef r234717 = ea8c1595246e81ba4273e6975c740d99705581d2 (revert r234698) r234776 = 88116fe71ab0953859fd3f32027149b5ee6d3a16 r234778 = 8ca57e685e7452487232c6e12c2e9a76ee3f4638 r234782 = eed6a11f81db8a86b3630a5e90fb072d99368f8d r234783 = 461b82ddb6d358465adf163bf05be846301789de r234792 = afb02d5d0d3cf2d7cd59a90410594901620d00f2 r234796 = 7153e0d49b735df94eabd501a3ff984654dcf22c r234799 = fafe7a41a567ad53d95c85e5e4891638a16206a2 r234802 = 26117d38cc1ac201effa73bfb962b6b90cae9d6b r234812 = 7ca9328e168cbfa41b0c42eee594c856943b8ff9 r234816 = 8ae5482d490af742ff34eb897d2d1752814bcb9a r234818 = dc4806ef72a27a9b10d44f53505749d8554e8159 r234819 = 3c42b7f3b7ae0258985e75806b55b27dc53c64e4 r234824 = 31bbd1ac1e62a25a751bc43c04d3dd6def02de2e r234825 = 5f1ef8aec6932a6fc6125021ebf3ace693c58eed r234829 = d48d32bba960d249d8f1784d5649f7b18d357244 r234832 = 15552c46a0f3307e5e363dcce33638aa489fe928 r234835 = d59e30dfb7cf7ecfa16557cd36da645df2d600d7 r234836 = b0b5cb29ab785eebab423ef93d5dd133c78dbe7a r234837 = 3e31f5eeb105539a137447f6b7c3914d304db008 r234838 = 79666c21ab6d29d9c5b69d3d7690a043c9d84c9a r234840 = 355ec009e5a1d7c3defa4e0740f45a292b7bdcbf r234842 = 32cb99437ef2921bcad7e62de0c3438d594997e6 r234843 = 41ed49389bc67e1855aeb6a026acb4992424a245 r234848 = 7f288cef47abe4b5fce83cb6c625603920effedb (clang) r234850 = 125e3d3959eebc6f4c56fe3863ece3f953c14d4e r234852 = 35adce33f1f45caf7f77dc2cc75ff893e9826a43 r234890 = 30e4b17e25b3a13efcabf102f16d8c7df8b15b60 (thanks Aaron Ballmon) r234904 = 66192e4b082f024d2141af3266bf35ffb72537bc r235054 = dfa1d05b32111fae649c9ec281806ed7a02ef9a2 (clang) r235055 = ed0e117ff38559aba99eb7a02187e3bf07e55488 r235058 = c64fc4415be9203cbe6173082fb8819704c63c70 (clang) r235059 = 7c020713160581410cd0431146c26cbc20f5e6cf r235063 = dbdd3a1a5d98e0250e81fe04375b38485d4d05ca (clang) r235064 = 7f76d2954e35dc23e499f50e7631d2ad6422eced r235066 = 32cb4405ec773e6a2743cd85df81362f93526f22 (clang) r235067 = 9c1aa1c021755e9cea1ddb23398e6c3d8e70f03c r235068 = b4a4ab9bdd5e0cbb32588aee51a2c67f9a18373f (clang) r235069 = b07e129e63b0d67e009c8733cf1e8b71500df644 r235071 = ce6a39f31f1b17089b1a3d12390733da1616fed1 r235111 = afc67405f8d3a755650a1cb4bb62ea76e21ed5fb r235112 = 3878f8557aea090769bb80eb3af73f03bbe506d5 (clang) r235115 = d6629b3db8a731259c8f6de12c6df79bf079d2a4 r235240 = 5d801364e2f2b193d1ab2f2aec4a7a33620e53c6 r235244 = 603fc8c265bac8a03e0c9d9fa4625c96b9478c67 r235245 = eff7a82be59a3edc81bb33bedb15f32eafa8f926 (clang) r235246 = 91dca02f4bfc5d978908e5845969902e203b84cd (clang) r235248 = 20b39c653c3db539a728cd67faf7b6026619e4e2 r235323 = 59abfa10b712132cd0c40403dc540b21e8334b22 r235326 = e106cb10347264a510b4f70190468e68dc14baed (clang) r235327 = b54df5252a94075d5d070818b7da0dbc9a71d379 r235330 = 9e883ba88418cb945c471df3f23770763f0cc6e3 (clang) r235331 = 91ad62302f557261cd45b719d6d08a695f6167a7 r235343 = 4103ea79fe723cc7969db7d260981da53ffb0a40 (polly) r235345 = 878f959d7f228e2f1d1f26858d00e5b6a504b0b8 r235349 = 80608c5d42fe8998eddad5ad2bf16fe2a8515fb1 r235350 = f5b4bb6556b6b055002bc91c127c1cc9f0c96181 (clang) r235351 = 92b3bf95a1846e16bb85929544747b1c074b2fab r235353 = 6219380952f0cedef590175f858b683bbf8db971 r235355 = 91e509234ee370ec58a1cb3fa7e6b1ad5a74c891 (clang) r235356 = d3c29ac587e8d4a1590a0b3c2efa5f1ce35e5c90 r235400 = 43eab6bce02309f470e486667e45d21f09884f51 r235403 = 8fc937c2fbeacef98069d574a9665f2ebc46320b (clang) r235404 = 7f892716df57263dabb4063a563975b0a296c737 r235405 = fb32d5211670afc689e12f46840cc769bc478d67 r235407 = 6238cb16f33c7e7cff5009feec3b7f6f4e51d495 r235412 = 431bf466edadebed39c04a9db63bcda013ff2a73 (clang) r235413 = 1cacd28c3b2e5f406d8f678ab8fa1a6d03c3713e r236120 = e56023a059e5fafa97f0df32c65cf31cfc33ba17 r236121 = 062dd42436d2a4cd9cb3f2391f3fd5f27e84c367 (clang) r236127 = 19a8458d5f855ae9a4585166b3a0ff2991ce3cd8 (polly) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 29 10:18:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 29 Apr 2015 17:18:56 +0000 Subject: [LLVMbugs] [Bug 23190] MSPropertyDeclRefExpr crashes with noexcept In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23190 Aaron Ballman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Aaron Ballman --- Fixed in r235931 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 29 11:11:54 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 29 Apr 2015 18:11:54 +0000 Subject: [LLVMbugs] [Bug 21609] [AsmPrinter] DwarfFile: Assertion `(LS->getParent() || CurNum != ArgNum) && "Duplicate argument for top level (non-inlined) function"' failed. In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21609 Duncan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Duncan --- (In reply to comment #8) > (In reply to comment #7) > > Created attachment 14270 [details] > > Patch as per David's proposal. > > > > Around 175 testcases across clang/llvm will need to be updated because of > > this change in schema. > > Hmm - was this addressed by r235955/r 235956 ? Yes, I think I caught this in r235955. Sandeep, feel free to reopen if you're seeing something different. Forward duping to bug 23332. *** This bug has been marked as a duplicate of bug 23332 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 29 12:27:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 29 Apr 2015 19:27:13 +0000 Subject: [LLVMbugs] [Bug 23373] Miscompile of defaulted union copy ctor In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23373 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |FIXED --- Comment #2 from Richard Smith --- Thanks, fixed in r236142. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 29 13:53:26 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 29 Apr 2015 20:53:26 +0000 Subject: [LLVMbugs] [Bug 23375] New: Regression(r236060): Building .S files in android asan mode is broken Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23375 Bug ID: 23375 Summary: Regression(r236060): Building .S files in android asan mode is broken Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: nicolasweber at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Repro: $ curl 'https://boringssl.googlesource.com/boringssl/+/master/crypto/chacha/chacha_vec_arm.S?format=TEXT' | base64 --decode > tmp.S $ path/to/clang -march=armv7-a -mtune=generic-armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -no-integrated-as -B/path/to/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin -marm -fsanitize=address -fsanitize=leak --sysroot=path/to/third_party/android_tools/ndk//platforms/android-14/arch-arm -target arm-linux-androideabi -mllvm -asan-globals=0 -c tmp.S -o tmp.o $ path/to/clang -shared -fPIC -B/path/to/third_party/binutils/Linux_x64/Release/bin -fuse-ld=gold -fsanitize=address -fsanitize=leak --sysroot=path/to/third_party/android_tools/ndk//platforms/android-14/arch-arm -nostdlib -target arm-linux-androideabi tmp.o Used to work. Now: error: /usr/local/google/home/thakis/src/llvm-build/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan-arm-android.so uses VFP register arguments, output does not (libclang_rt.asan-arm-android.so was built with the same clang as the output files, but possibly with different fp flags.) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 29 18:32:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 01:32:01 +0000 Subject: [LLVMbugs] [Bug 23376] New: AVX512: We don't always need EVEX for VEX-encodable instructions. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23376 Bug ID: 23376 Summary: AVX512: We don't always need EVEX for VEX-encodable instructions. Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: ahmed.bougacha at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This: define float @t(float %a, float %b) { %res = fadd float %a, %b ret float %res } Generates the EVEX-prefixed: 62f17e0858c1 vaddss %xmm1, %xmm0, %xmm0 instead of using VEX: c5fa58c1 vaddss %xmm1, %xmm0, %xmm0 AFAIK, there is no transition penalty between AVX512 and AVX, so I believe the only reason to use EVEX in this case is to access more registers (xmm0-31). That's not always useful, so we should recognize that, and relax EVEX->VEX when possible. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 29 18:57:37 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 01:57:37 +0000 Subject: [LLVMbugs] [Bug 23377] New: Hexagon: test/CodeGen/Generic/MachineBranchProb.ll crashes Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23377 Bug ID: 23377 Summary: Hexagon: test/CodeGen/Generic/MachineBranchProb.ll crashes Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: hans at chromium.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified It started failing after I added a test as part of r236192, but it turns out that test crashes regardless of my change or not. It also has nothing to do with branch weights: $ cat | bin/llc -o /dev/null -march=hexagon -mcpu=hexagonv5 declare void @g(i32) define void @left_leaning_weight_balanced_tree(i32 %x) { entry: switch i32 %x, label %return [ i32 0, label %bb0 i32 10, label %bb1 i32 20, label %bb2 i32 30, label %bb3 i32 40, label %bb4 i32 50, label %bb5 ] bb0: tail call void @g(i32 0) br label %return bb1: tail call void @g(i32 1) br label %return bb2: tail call void @g(i32 2) br label %return bb3: tail call void @g(i32 3) br label %return bb4: tail call void @g(i32 4) br label %return bb5: tail call void @g(i32 5) br label %return return: ret void } llc: ../include/llvm/CodeGen/MachineOperand.h:423: llvm::MachineBasicBlock *llvm::MachineOperand::getMBB() const: Assertion `isMBB() && "Wrong MachineOperand accessor"' failed. #0 0x1ea3a6e llvm::sys::PrintStackTrace(llvm::raw_ostream&) /work/llvm/build.debug/../lib/Support/Unix/Signals.inc:430:15 #1 0x1ea49e9 PrintStackTraceSignalHandler(void*) /work/llvm/build.debug/../lib/Support/Unix/Signals.inc:489:1 #2 0x1ea4eee SignalHandler(int) /work/llvm/build.debug/../lib/Support/Unix/Signals.inc:205:60 #3 0x7f7d6f3b4340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x7f7d6e5d5cc9 gsignal /build/buildd/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f7d6e5d90d8 abort /build/buildd/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f7d6e5ceb86 __assert_fail_base /build/buildd/eglibc-2.19/assert/assert.c:92:0 #7 0x7f7d6e5cec32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #8 0x77d6ba llvm::MachineOperand::getMBB() const /work/llvm/build.debug/../include/llvm/CodeGen/MachineOperand.h:424:5 #9 0xbd4289 llvm::HexagonInstrInfo::AnalyzeBranch(llvm::MachineBasicBlock&, llvm::MachineBasicBlock*&, llvm::MachineBasicBlock*&, llvm::SmallVectorImpl&, bool) const /work/llvm/build.debug/../lib/Target/Hexagon/HexagonInstrInfo.cpp:274:13 #10 0x1565b52 (anonymous namespace)::IfConverter::RemoveExtraEdges((anonymous namespace)::IfConverter::BBInfo&) /work/llvm/build.debug/../lib/CodeGen/IfConversion.cpp:971:8 #11 0x1563007 (anonymous namespace)::IfConverter::IfConvertSimple((anonymous namespace)::IfConverter::BBInfo&, (anonymous namespace)::IfConverter::IfcvtKind) /work/llvm/build.debug/../lib/CodeGen/IfConversion.cpp:1102:7 #12 0x1561e7b (anonymous namespace)::IfConverter::runOnMachineFunction(llvm::MachineFunction&) /work/llvm/build.debug/../lib/CodeGen/IfConversion.cpp:348:18 #13 0x160640e llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /work/llvm/build.debug/../lib/CodeGen/MachineFunctionPass.cpp:40:10 #14 0x19ea65d llvm::FPPassManager::runOnFunction(llvm::Function&) /work/llvm/build.debug/../lib/IR/LegacyPassManager.cpp:1537:23 #15 0x19ea968 llvm::FPPassManager::runOnModule(llvm::Module&) /work/llvm/build.debug/../lib/IR/LegacyPassManager.cpp:1557:16 #16 0x19eb029 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /work/llvm/build.debug/../lib/IR/LegacyPassManager.cpp:1615:23 #17 0x19eac1e llvm::legacy::PassManagerImpl::run(llvm::Module&) /work/llvm/build.debug/../lib/IR/LegacyPassManager.cpp:1722:16 #18 0x19eb4d1 llvm::legacy::PassManager::run(llvm::Module&) /work/llvm/build.debug/../lib/IR/LegacyPassManager.cpp:1755:10 #19 0x75aa41 compileModule(char**, llvm::LLVMContext&) /work/llvm/build.debug/../tools/llc/llc.cpp:378:3 #20 0x7598b6 main /work/llvm/build.debug/../tools/llc/llc.cpp:201:22 #21 0x7f7d6e5c0ec5 __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:321:0 #22 0x7595d4 _start (/usr/local/google/work/llvm/build.debug/bin/llc+0x7595d4) Stack dump: 0. Program arguments: bin/llc -o /dev/null -march=hexagon -mcpu=hexagonv5 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'If Converter' on function '@left_leaning_weight_balanced_tree' Aborted -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 00:13:19 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 07:13:19 +0000 Subject: [LLVMbugs] [Bug 23378] New: Lacking documentation on -fapple-kext Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23378 Bug ID: 23378 Summary: Lacking documentation on -fapple-kext Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: dannyniu at hotmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The -fapple-kext option specifies that clang generate kext codes for C++ files instead of regular user-space codes. But this option is undocumented here and elsewhere. I'm among those who believe that an overly-complicated language such as C++ should never be used to program a system kernel or a compiler, Much of the esoteric features of C++ has complicated the implementations of the language. Although I'm fine with Clang being written in C++ since it's already capable of self-hosting, I'd have a serious argument with someone if he uses it in system kernel, especially when ABI is poorly documented. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 00:56:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 07:56:10 +0000 Subject: [LLVMbugs] [Bug 23379] New: error code for broken_promise is incorrect & inconsistent with thrown future_error exception Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23379 Bug ID: 23379 Summary: error code for broken_promise is incorrect & inconsistent with thrown future_error exception Product: libc++ Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: vlovich at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified Broken promises on futures have an error code of 0 which results in the weird result that std::future_errc::broken_promise isn't comparable to any exception thrown, contrary to the standard specification & all the examples I've found online. Steps: 1. // test.cpp #include #include int main() { std::future f; { std::promise p; f = p.get_future(); } try { f.get(); std::cerr << "Shouldn't get here?\n"; } catch(const std::future_error& e) { bool is_broken_promise = e.code() == std::make_error_condition(std::future_errc::broken_promise); std::cout << e.code().message() << "\n"; std::cout << e.code().value() << "\n"; std::cout << is_broken_promise << "\n"; } } 2. clang++ -std=c++11 -stdlib=libc++ test.cpp && ./a.out 3. clang++ -std=c++14 -stdlib=libc++ test.cpp && ./a.out Actual for both 2 & 3: The associated promise has been destructed prior to the associated state becoming ready. 0 0 Expected for #2: The associated promise has been destructed prior to the associated state becoming ready. 0 1 or The associated promise has been destructed prior to the associated state becoming ready. 0 1 Expected for #3: The associated promise has been destructed prior to the associated state becoming ready. 4 1 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 01:25:45 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 08:25:45 +0000 Subject: [LLVMbugs] [Bug 23369] r235837 broke 8-bit vector multiplies on older x86 In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23369 Simon Pilgrim changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- Fixed in http://reviews.llvm.org/rL236209 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 02:09:08 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 09:09:08 +0000 Subject: [LLVMbugs] [Bug 21420] [Meta] Android+Clang platform support In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21420 Bug 21420 depends on bug 13007, which changed state. Bug 13007 Summary: ARM CodeGen fails with large stack alignment https://llvm.org/bugs/show_bug.cgi?id=13007 What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 02:09:05 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 09:09:05 +0000 Subject: [LLVMbugs] [Bug 13007] ARM CodeGen fails with large stack alignment In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=13007 Kristof Beyls changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Kristof Beyls --- This got fixed by http://llvm.org/viewvc/llvm-project?rev=225446&view=rev, back in January. A fix for AArch64 (which didn't support stack realignment at all before) got committed as http://llvm.org/viewvc/llvm-project?rev=234471&view=rev. A new test that checks basic correct functionality of frame lowering, including overaligned objects on the stack got committed as http://llvm.org/viewvc/llvm-project?view=revision&revision=236085. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 02:10:13 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 09:10:13 +0000 Subject: [LLVMbugs] [Bug 23380] New: Loop vectorizer crash Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23380 Bug ID: 23380 Summary: Loop vectorizer crash Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: chfast at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This code crashes clang 3.7: void test(unsigned* out) { #pragma clang loop vectorize(enable) for (unsigned i = 0; i != 256; ++i) { for (unsigned w = 0; w != 16; ++w) ++out[w]; } } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 04:29:04 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 11:29:04 +0000 Subject: [LLVMbugs] [Bug 23381] New: "error: default initialization of an object of const type 'const Z' requires a user-provided default constructor" even when no constructor needed. Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23381 Bug ID: 23381 Summary: "error: default initialization of an object of const type 'const Z' requires a user-provided default constructor" even when no constructor needed. Product: compiler-rt Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: daniel.black at openquery.com.au CC: llvmbugs at cs.uiuc.edu Classification: Unclassified "error: default initialization of an object of const type 'const Z' requires a user-provided default constructor" even when no constructor needed. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#253 $ cat > /tmp/x.cc struct Z { // no data members operator int() const { return 0; } }; void f() { const Z z1; // ill-formed: no initializer const Z z2 = { }; // well-formed } $ clang++ -c /tmp/x.cc /tmp/x.cc:7:17: error: default initialization of an object of const type 'const Z' requires a user-provided default constructor const Z z1; // ill-formed: no initializer ^ 1 error generated. g++ compiles without error clang++ --version clang version 3.4.2 (tags/RELEASE_34/dot2-final) Target: x86_64-redhat-linux-gnu Thread model: posix g++ (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 10:16:09 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 17:16:09 +0000 Subject: [LLVMbugs] [Bug 21073] MS ABI: Derived class has fewer vftable entries than base In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=21073 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED Assignee|timurrrr at google.com |david.majnemer at gmail.com --- Comment #5 from David Majnemer --- Fixed in r236239. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 10:16:10 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 17:16:10 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 21073, which changed state. Bug 21073 Summary: MS ABI: Derived class has fewer vftable entries than base https://llvm.org/bugs/show_bug.cgi?id=21073 What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 13:10:56 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 20:10:56 +0000 Subject: [LLVMbugs] [Bug 23383] New: Error during template instantiation in exception specification for defaulted functions Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23383 Bug ID: 23383 Summary: Error during template instantiation in exception specification for defaulted functions Product: clang Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: mattia.basaglia at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified When defining exception specification in explicitly defaulted functions, it appears that templates aren't expanded correctly and clang gives the error "exception specification is not available until end of class definition". If the same template has been already expanded the error doesn't occur. The error occurs on clang 3.6 but not on 3.5. Follows an example (note that only the first class causes the error): struct something { static const bool value = true; }; template struct something_template { static const bool value = true; }; struct A_error { // This fails to compile A_error() noexcept(something_template::value) = default; }; // All of the following compile fine struct A1 { A1() noexcept(1+1) = default; }; struct A2 { A2() noexcept(something::value) = default; }; struct A3 { void foo() noexcept(something_template::value) {} }; struct A4 { A4() noexcept(something_template::value) {} }; // Note: A5 is identical to A_error but it compiles fine struct A5 { A5() noexcept(something_template::value) = default; }; -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 13:37:14 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 20:37:14 +0000 Subject: [LLVMbugs] [Bug 15735] list-initialization of array new-expression requires declared default constructor In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=15735 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |DUPLICATE --- Comment #4 from Richard Smith --- *** This bug has been marked as a duplicate of bug 22924 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 13:51:22 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 20:51:22 +0000 Subject: [LLVMbugs] [Bug 22354] generic lambda capture fails with undefined reference to custom copy ctor In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=22354 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |FIXED --- Comment #4 from Richard Smith --- Fixed by r235921, regtest added in r236254. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 13:53:36 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 20:53:36 +0000 Subject: [LLVMbugs] [Bug 19691] class MacroDirective::DefInfo default constructor fails to initialize IsPublic In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=19691 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |FIXED --- Comment #2 from Richard Smith --- Fixed in r236256. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 14:13:01 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 21:13:01 +0000 Subject: [LLVMbugs] [Bug 11449] instcombine can introduce wrapping into a nuw/nsw operation In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=11449 Matthias Braun changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |matze at braunis.de Resolution|--- |FIXED --- Comment #1 from Matthias Braun --- This is fixed in llvm trunk: define i32 @_Z1gi(i32 %c) #0 { entry: %add.i = add i32 -2147483648, %c %and.i = and i32 %add.i, 2147483647 ret i32 %and.i } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 14:48:32 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 21:48:32 +0000 Subject: [LLVMbugs] [Bug 23103] Crash in Register Scavenger In-Reply-To: References: Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23103 Andrea Di Biagio changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrea Di Biagio --- This bug has been fixed at revision 236258. http://llvm.org/viewvc/llvm-project?view=revision&revision=236258 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 30 16:38:50 2015 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 30 Apr 2015 23:38:50 +0000 Subject: [LLVMbugs] [Bug 23384] New: LSR needs to be improved for x86 Message-ID: https://llvm.org/bugs/show_bug.cgi?id=23384 Bug ID: 23384 Summary: LSR needs to be improved for x86 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedbugs at nondot.org Reporter: wmi at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 14272 --> https://llvm.org/bugs/attachment.cgi?id=14272&action=edit testcase 1.cc For the testcase attached, llvm now generates 3 AddRec but 1 AddRec is enough by using complex addressing modes. Every AddRec will be translated to an add insn at the end of loop, so the number of AddRec is important for loop performance. And it is more important than NumRegs especially when register pressure is not very high. ~/workarea/llvm-r234391/build/bin/clang++ -std=c++11 -O2 -fno-omit-frame-pointer -S 1.cc -o 1.s The kernel loop: .LBB1_10: # %for.body6.i movss -4(%rcx), %xmm2 # xmm2 = mem[0],zero,zero,zero movss (%rcx), %xmm1 # xmm1 = mem[0],zero,zero,zero mulss -4(%rdi), %xmm2 addss %xmm0, %xmm2 mulss (%rdi), %xmm1 addss %xmm2, %xmm1 addq $8, %rdi addq $8, %rcx addl $-2, %esi movaps %xmm1, %xmm0 jne .LBB1_10 A better version is: .LBB1_8: # %for.body6.i movss (%rdi,%rcx,4), %xmm0 # xmm0 = mem[0],zero,zero,zero mulss (%rsi,%rcx,4), %xmm0 addss %xmm1, %xmm0 movss 4(%rdi,%rcx,4), %xmm1 # xmm1 = mem[0],zero,zero,zero mulss 4(%rsi,%rcx,4), %xmm1 addss %xmm0, %xmm1 addq $2, %rcx cmpl %ecx, %eax movaps %xmm1, %xmm0 jne .LBB1_8 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: