<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 1, 2015 at 6:26 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Tue, Sep 1, 2015 at 4:43 AM, İsmail Dönmez<br>
<<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
> Hi,<br>
><br>
> On Tue, Sep 1, 2015 at 1:17 AM, Richard Smith via cfe-commits<br>
> <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
>> Author: rsmith<br>
>> Date: Mon Aug 31 17:17:11 2015<br>
>> New Revision: 246497<br>
>><br>
>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=246497&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=246497&view=rev</a><br>
>> Log:<br>
>> [modules] Rework serialized DeclContext lookup table management. Instead of<br>
>> walking the loaded ModuleFiles looking for lookup tables for the context, store<br>
>> them all in one place, and merge them together if we find we have too many<br>
>> (currently, more than 4). If we do merge, include the merged form in our<br>
>> serialized lookup table, so that downstream readers never need to look at our<br>
>> imports' tables.<br>
>><br>
>> This gives a huge performance improvement to builds with very large numbers of<br>
>> modules (in some cases, more than a 2x speedup was observed).<br>
>><br>
>> Added:<br>
>>     cfe/trunk/lib/Serialization/MultiOnDiskHashTable.h<br>
><br>
> This doesn't seem to compile with VS2015:<br>
><br>
> FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe   /nologo /TP<br>
> /DWIN32 /D_WINDOWS   -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291<br>
> -wd4345 -wd4351 -wd4355 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503<br>
> -wd4624 -wd4722 -wd4800 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610<br>
> -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389<br>
> -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4324 -w14062 -we4238 /W4<br>
> /Zc:inline /Zc:sizedDealloc- /MT /O2 /Ob2<br>
> -Itools\clang\lib\Serialization -I..\tools\clang\lib\Serialization<br>
> -I..\tools\clang\include -Itools\clang\include -Iinclude -I..\include<br>
>   -UNDEBUG  /EHs-c- /GR- /showIncludes -DCLANG_ENABLE_ARCMT<br>
> -DCLANG_ENABLE_OBJC_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER<br>
> -DGTEST_HAS_RTTI=0 -D_CRT_NONSTDC_NO_DEPRECATE<br>
> -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE<br>
> -D_CRT_SECURE_NO_WARNINGS -D_GNU_SOURCE -D_HAS_EXCEPTIONS=0<br>
> -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS<br>
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS<br>
> /Fotools\clang\lib\Serialization\CMakeFiles\clangSerialization.dir\ASTReader.cpp.obj<br>
> /Fdtools\clang\lib\Serialization\CMakeFiles\clangSerialization.dir\<br>
> /FS -c ..\tools\clang\lib\Serialization\ASTReader.cpp<br>
> c:\cygwin64\home\ismail\src\llvm\tools\clang\lib\serialization\MultiOnDiskHashTable.h(117):<br>
> error C2065: 'Files': undeclared identifier<br>
> c:\cygwin64\home\ismail\src\llvm\tools\clang\lib\serialization\MultiOnDiskHashTable.h(111):<br>
> note: while compiling class template member function 'void<br>
> clang::serialization::MultiOnDiskHashTable<clang::serialization::reader::ASTDeclContextNameLookupTrait>::removeOverriddenTables(void)'<br>
> c:\cygwin64\home\ismail\src\llvm\tools\clang\lib\serialization\MultiOnDiskHashTable.h(243):<br>
> note: see reference to function template instantiation 'void<br>
> clang::serialization::MultiOnDiskHashTable<clang::serialization::reader::ASTDeclContextNameLookupTrait>::removeOverriddenTables(void)'<br>
> being compiled<br>
> c:\cygwin64\home\ismail\src\llvm\tools\clang\lib\serialization\ASTReaderInternals.h(114):<br>
> note: see reference to class template instantiation<br>
> 'clang::serialization::MultiOnDiskHashTable<clang::serialization::reader::ASTDeclContextNameLookupTrait>'<br>
> being compiled<br>
> c:\cygwin64\home\ismail\src\llvm\tools\clang\lib\serialization\MultiOnDiskHashTable.h(117):<br>
> error C2228: left of '.count' must have class/struct/union<br>
> c:\cygwin64\home\ismail\src\llvm\tools\clang\lib\serialization\MultiOnDiskHashTable.h(117):<br>
> note: type is 'unknown-type'<br>
> ninja: build stopped: subcommand failed.<br>
<br>
</div></div>I have reverted r246497 (which required also reverting r246524 and<br>
r246521 to avoid merge conflicts) to get back to green. Commit was<br>
r246546.<br>
<br>
I'm not certain why MSVC is falling over on this code, but I suspect<br>
compiler bug. If anyone has a reduced testcase (which I may spend some<br>
time on if I have a moment), I would be happy to report it to<br>
Microsoft.</blockquote><div><br></div><div>It's two compiler bugs.</div><div><br></div><div>In MSVC 2013, providing a move constructor apparently doesn't suppress the implicit generation of copy operations in some cases. In particular, given:</div><div><br></div><div><div>  struct X { X(); X(X&&); X &operator=(X&&); ~X(); };</div><div>  struct Y { X x; };</div></div><div><br></div><div>... Y is copyable (and in my case, copying it led to a use-after-free, because X had the equivalent of a pointer member).</div><div><br></div><div>In MSVC 2015, it appears that implicit lambda capture doesn't work reliably inside a member function of a class template. The testcase looks something like:</div><div><br></div><div>template<typename T> struct S {</div><div>  typedef T type;</div><div>  type f() {</div><div>    type n;</div><div>    [&] { ++n; }();</div><div>    return n;</div><div>  }</div><div>};</div><div>int k = S<int>().f();</div><div><br></div><div>... though I don't know if that's enough to reproduce the rejects-valid.</div><div><br></div><div>Anyway, these are hopefully both worked around in r246582.</div></div></div></div>