similar to: [cfe-dev] RFC: Replacing the default CRT allocator on Windows

Asan and the Debug CRT take different approaches, but the problems they cover largely overlap. Both help with detection of errors like buffer overrun, double free, use after free, etc. Asan generally gives you more immediate feedback on those, but you pay a higher price in performance. Debug CRT lets you do some trade off between the performance hit and how soon it detects problems. Asan

Hello, I was wondering how folks were feeling about replacing the default Windows CRT allocator in Clang, LLD and other LLVM tools possibly. The CRT heap allocator on Windows doesn't scale well on large core count machines. Any multi-threaded workload in LLVM that allocates often is impacted by this. As a result, link times with ThinLTO are extremely slow on Windows. We're observing

I hadn't heard this before. If I use clang with -fsanitize=address to build my program, and then run my program, what difference does it make for the execution of my program whether the compiler itself was instrumented or not? Do you mean that ASAN runtime itself should be instrumented, since your program loads that at runtime? On Tue, Jul 7, 2020 at 2:04 PM Mitch Phillips <mitchp at

Thanks for the suggestion James, it reduces the commit by about ~900 MB (14,9 GB -> 14 GB). Unfortunately it does not solve the performance problem. The heap is global to the application and thread-safe, so every malloc/free locks it, which evidently doesn’t scale. We could manually create thread-local heaps, but I didn’t want to go there. Ultimately allocated blocks need to share ownership

Hey list, TL;DR - LLVM 10 is around 7-8% slower than LLVM 9 when compiling the same inputs. So here at Unity our Burst HPC# compiler uses LLVM to provide our users with some very optimal codegen. LLVM is used in two ways: 1. In the Unity editor we JIT compile user code. 2. We also have an AOT mode for when our users are building a full game. Particularly for 1., compile time really matters for

This patch splits LLVM_USE_CRT into new CMake variables LLVM_USE_CRT_DEBUG, LLVM_USE_CRT_RELEASE, etc (one for each build type). It also automatically detects which CRT was already chosen by CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to those values. (Before, it was using add_llvm_definitions(), which worked...somehow, but CMAKE_CXX_FLAGS_RELEASE and friends were still

nobled <nobled at dreamwidth.org> writes: > This patch splits LLVM_USE_CRT into new CMake variables > LLVM_USE_CRT_DEBUG, LLVM_USE_CRT_RELEASE, etc (one for each build > type). It also automatically detects which CRT was already chosen by > CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to > those values. > > (Before, it was using

Rotated text for axis labels should be possible with one of par(srt=90) axis(1,at,labels) par(srt=0) or axis(1,at,labels,srt=90) (or similar with crt instead of srt) None of these works in pre0.65 or in 0.64.2 _ platform sparc-sun-solaris2.7 arch sparc os solaris2.7 system sparc,

https://bugs.freedesktop.org/show_bug.cgi?id=69083 Priority: medium Bug ID: 69083 Assignee: nouveau at lists.freedesktop.org Summary: using DVI to VGA adapter for CRT and specifying supported "PreferredMode" >EDID preferred mode, screen output is compressed into small fraction of top scan

Óscar Fuentes <ofv at wanadoo.es> wrote: > I'm a bit wary about this patch. So much complexity for so petty > feature... Maybe the right thing is to determine the scenarios where > people set LLVM_USE_CRT. Maybe all we need is to define another build > type that inherits from Release which uses the debug version of the CRT. > > Anyways, the patch have some issues:

Hello, I'm currently failing to install Linux to an older PC. It has a Nvidia Quadro 4 graphics adapter built in and is connected to a 21" CRT monitor. Shortly after the kernel started to boot, my screen says "Frequency out of range". Is there any way to fix this? Thanks in advance Yours Manuel

Óscar Fuentes <ofv at wanadoo.es> wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.compilers.llvm.devel as well. > > nobled <nobled at dreamwidth.org> writes: > > [snip] > > Please move the new code to a new file named > cmake/modules/WindowsCRTControl.cmake and include it from the top level > CMakeLists

nobled <nobled at dreamwidth.org> writes: [snip] Please move the new code to a new file named cmake/modules/WindowsCRTControl.cmake and include it from the top level CMakeLists when LLVM_ON_WIN32.

After installing 2005&2008 C++ , msxml 6, xmlparser I am getting an error box when running the App "Microsoft Visual C++ Runtime Library" "R6034 An Application has made an attempt to load the C runtime library incorrectly" from term I get [/code]ncts at ncts:~/.wine/drive_c/Program Files/NEC/SV8100 AU PCPro$ wine AppMgr.exe fixme:actctx:parse_depend_manifests Could not

On Thu, Jun 18, 2020 at 3:37 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > We’re talking about verbose output right? Verbose isn’t the default. > I'm fairly certain the issue in this thread is just the verbosity of -dump-input=fail. Yes, -vv makes it even more verbose by annotating input lines with good matches, etc., but that's not part of the "new

Bringing this up on llvm-dev for more general attention. The problem here is two fold: (1) Reuse of enumeration values is just a major no-go. (2) I'm not sure why the existing vector types had to be killed completely. But something clearly has to be done here. This majorly affects e.g. Mesa. Joerg ----- Forwarded message from Joerg Sonnenberger via llvm-commits <llvm-commits at

Sorry if I wasn't clear about my use case. In my daily dev work, I do many local "ninja check"s, or "llvm-lit" on a subdirectory as a quick(er) smoke test if I am making changes in that area (e.g. "llvm-lit ../llvm/test/CodeGen"). Nothing wrong here, as indeed nothing changed here. But in case of a test failure, I want to run just that test: bin/llvm-lit

Hi Chris, On Thu, Jun 18, 2020 at 1:37 PM Chris Tetreault via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The thing I use normally only shows the first N lines by default (I don’t > know off hand what N is). Honestly, I don’t feel very strongly about the > specific order, but it’s not useful when somebody proposes something on the > list, and nobody voices any dissent

Regarding the numerical value of the LLVMTypeKind enum, my understanding is that LLVM-C does not promise to maintain ABI compatability between versions. If I am mistaken, I can fix this issue. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of James Y Knight via llvm-dev Sent: Wednesday, May 13, 2020 7:33 AM To: Joerg Sonnenberger <joerg at bec.de>; llvm-dev <llvm-dev

Folks, I'm at a loss trying to add Compiler-RT to an LLVM build, even after checking out the instructions at http://compiler-rt.llvm.org, so I'd appreciate your help. I've tried adding the CMake options LLVM_ENABLE_PROJECTS, LLVM_BUILD_EXTERNAL_COMPILER_RT, LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, CLANG_DEFAULT_RTLIB. All to no avail. FWIW, I'm building for the targets