search for: concrt

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc (C:\lld-x86_64_win7\lld-x86_64-win7\llvm.src\tools\lld\lib\ReaderWriter\ELF\Hexagon\HexagonLinkingContext.cpp) [C:\lld-x86_64_win7\lld-x86_64-win7\llvm.obj\tools\lld\lib\ReaderWriter\ELF\Hexago...

On Sun, Oct 6, 2013 at 8:21 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > C:\Program Files (x86)\Microsoft Visual Studio > 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler used, > but unwind semantics are not enabled. Specify /EHsc > (C:\lld-x86_64_win7\lld-x86_**64-win7\llvm.src\tools\lld\** > lib\ReaderWriter\ELF\Hexagon\**HexagonLinkingContext.cpp) > [C:\lld-x86_64_win7\lld-x86_**64-win7\llvm.obj\tools\lld\*...

...would get called before the Windows handler. Furthermore, we seem to assume inside the handler that it's impossible to reach the handler unless there was an actual crash scenario. Is this necessarily true? It's worth pointing out that std::[recursive_]mutex on MSVC are implemented using ConcRT (Microsoft Concurrency Runtime), which is all sorts of crazy (even has its own user mode scheduler [1]), so I think the user of a vectored exception handler is not safe with ConcRT. Any other windows experts have any thoughts into what might be going on here? [1] - http://blogs.msdn.com/b/nativec...

I spent a week to optimize LLD performance and just wanted to share things what I found. Also if there's anyone who have a good idea on how to make it faster, I'd like to hear. My focus is mainly on Windows, but my optimizations are generally platform neutral. I aim both single-thread and multi-thread performance. r231434 <http://reviews.llvm.org/rL231454> is a change that has the