search for: ccc_override_options

I have been working for extending test coverage for years. Nowadays, I have several cross-testing (target != host). See http://bb.pgr.jp/console Each of them (test-*-linux) is doing; - Assume a preceding builder passes with warming ccache. - All compilation units will hit ccache whenever the tree is built before lit. - Almost all compilation units will hit ccache except for Host.cpp when

...tioned that it can be really useful to see coverage reporting interactively, as you're working on a patch. Here's a hacky way to do this: * Build your code as you normally would (say, "ninja opt") * Change the files you're interested in * cd to your build directory and export CCC_OVERRIDE_OPTIONS="+-fcoverage-mapping +-fprofile-instr-generate=/tmp/opt_%m.profraw" * Rebuild ("ninja opt" again). This will enable coverage instrumentation, but only for the files you've affected with your changes. * Run a one-liner to generate a coverage report (http://clang.llvm.org/docs...

Hello all! I find that using lldb to debug LLVM libraries can be super frustrating, because a lot of LLVM classes, like the constructor for StringRef, are marked LLVM_ATTRIBUTE_ALWAYS_INLINE. So when I attempt to have lldb evaluate an expression that implicitly instantiates a StringRef, I get 'error: Couldn't lookup symbols: __ZN4llvm9StringRefC1EPKc'. As an example, most recently

...ould result in very few cache hits. On Thu, Sep 6, 2018 at 11:34 AM, Matthias Braun via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I can definitely relate to third party Makefiles being a huge pain to > manipulate. And env vars can be an okay tool to help debugging (see also > CCC_OVERRIDE_OPTIONS in clang for example). I also don't want to dispute > that they may be the right solution in some cases. > That said in my opinion we should not make it look like using environment > variables is a good or encouraged thing because there are downsides: > > - The bug reproducetion...

...to see coverage reporting interactively, as you're working on a patch. Here's a hacky way to do this: >> >> * Build your code as you normally would (say, "ninja opt") >> * Change the files you're interested in >> * cd to your build directory and export CCC_OVERRIDE_OPTIONS="+-fcoverage-mapping +-fprofile-instr-generate=/tmp/opt_%m.profraw" >> * Rebuild ("ninja opt" again). This will enable coverage instrumentation, but only for the files you've affected with your changes. >> * Run a one-liner to generate a coverage report (http://c...

Yes, but in your example getenv is called every time enableFooBar needs to be initialized. What if your code is itself wrapped inside another loop you can't see (for example, the PassManager invoking passes)? Maybe I'm being overly pedantic. We use a lot of environment variables in our compiler because it's really super annoying and takes a lot of developer time to have to update

I'm trying to compile some large programs with clang on Windows (with a view to compiling to bit code and then running some whole program optimisations on the bit code). Take for example the Python 2.7 interpreter: As is typically the case, the usual build procedure involves running msbuild which invokes the Microsoft compiler. The most obvious procedure would then be to substitute

In order to minimize edit/compile/debug turn time, is there a way to compile llvm tools so that the majority of the files are compiled as if for release (eg, no debug symbols), and only the handful of files that I have touched are compiled for debugging? This will reduce the load on the file system, linker and gdb tremendously. At present, AFAICT, it's all or nothing. -------------- next part