similar to: GCC prerequisites for building LLVM head?

I just checked with '-E' and I am picking up '<string>' from: /usr/lib/gcc/i686-pc/cygwin/4.9.3/include/c++/string all other C++ headers are coming from the same place. The 'std::to_string' functions are not present in '<string>', but they are located in '<bits/basic_string.h>' - which is included. Perhaps it is a broken Cygwin

I've no idea, but without it, the 'std::to_string' definitions are not enabled! -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org] Sent: 06 July 2016 19:35 To: Martin.ORiordan at movidius.com Cc: LLVM Developers <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] GCC prerequisites for building LLVM head? On 6 July 2016 at 19:02, Martin J.

Sorry for the delay, I had to experiment and build everything to be sure. I am actually getting the same problem with GCC v4.9.3 on CentOS, but for both Cygwin and Linux adding '-D_GLIBCXX_USE_C99' to the '-DCMAKE_CXX_FLAGS:STRING=' flag during configuration cured the problem. MartinO -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org] Sent: 06

Rafael, Filipe, I am looking at the fixes you apply to sanitizer tests and they worry me. (e.g. https://reviews.llvm.org/D31498) The fixes are mostly mechanical and thus every single change looks safe, but given the amount of changes there is large risk to cripple some of the tests in a way that they will stop detecting failures. When I write a test for new functionality, I always verify that

I'll need more details then. Maybe you can share the binary & its .sancov file? Or if you have a way to reproduce it? On Tue, Mar 7, 2017 at 1:23 PM Kostya Serebryany <kcc at google.com> wrote: > On Tue, Mar 7, 2017 at 12:50 PM, Mike Aizatsky <aizatsky at google.com> > wrote: > > Justin, > > I haven't seen this before. I suspect it is because of

This is a pretty nice warning. Should we enable it for LLVM's build when the host compiler supports it? Benjamin Kramer via llvm-commits <llvm-commits at lists.llvm.org> writes: > Author: d0k > Date: Mon Feb 22 07:11:58 2016 > New Revision: 261524 > > URL: http://llvm.org/viewvc/llvm-project?rev=261524&view=rev > Log: > Fix some abuse of auto flagged by

Given the following C++ code: ``` // test.cpp struct Foo { int public_foo(); int outside_foo(); [[gnu::always_inline]] int inline_foo() { int x = outside_foo(); if (x % 17) { x += 1; } return x; } [[gnu::noinline]] int inline_bar1() { int x = inline_foo(); if (x % 23) { x += 2; } return x; } [[gnu::noinline]] int inline_bar2() {

Justin, I haven't seen this before. I suspect it is because of line-tables-only. Can you try it with full debug info? On Tue, Mar 7, 2017 at 12:36 PM Kostya Serebryany <kcc at google.com> wrote: > +aizatsky > > On Tue, Mar 7, 2017 at 12:34 PM, Justin Bogner <mail at justinbogner.com> > wrote: > > I'm working on a fuzzer using libFuzzer and I wanted to take

I'm working on a fuzzer using libFuzzer and I wanted to take a look at how my coverage was doing, as per the instructions here: http://llvm.org/docs/LibFuzzer.html#how-good-is-my-fuzzer First of all, I suspect the instructions there are out of date, but passing -dump_coverage=1 to the binary rather than setting ASAN_OPTIONS generated a .sancov file for me. However, when I inspect this

Hi Fangrui, Many thanks for providing such detailed feedback! Please find my comments inlined below. - Ammar On Sun, Jun 28, 2020 at 5:59 AM Fangrui Song <maskray at google.com> wrote: > On 2020-06-26, Ammar Ben Khadra via llvm-dev wrote: > >## TL;DR > > > >We introduce bcov, an open-source binary-level coverage analysis tool [1]. > >The details are discussed

> On Aug 24, 2017, at 2:55 PM, Kostya Serebryany <kcc at google.com> wrote: > > Interesting. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Aug 24, 2017 at 3:20

On Thu, Aug 24, 2017 at 6:30 PM, Justin Bogner <mail at justinbogner.com> wrote: > Peter Collingbourne <peter at pcc.me.uk> writes: > > On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> > wrote: > > > >> > >> > >> On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > >> wrote:

## TL;DR We introduce bcov, an open-source binary-level coverage analysis tool [1]. The details are discussed in our paper [2], which is accepted to ESEC/FSE'20. bcov statically instruments x86-64 ELF binaries without compiler support. It features several techniques that allow it to achieve high performance, transparency, and flexibility. For example, running "make

Kostya Serebryany <kcc at google.com> writes: > Justin, > Calling appendToUsed has horrible complexity and if we call it in > every function clang consumes tons of memory (6Gb when compiling one > of the clang's source files). This killed my machine today :) > > The solution is to call appendToUsed once per module, instead of once > per function. Oh right,

Hi, I'm playing around with LLVM and stumbled upon this issue while while performing "make install". The build itself was successful. I'm using the latest git version. #make install -- Installing: /home/alesko/llvm-install/bin/llvm-mc -- Installing: /home/alesko/llvm-install/bin/sancov -- Installing: /home/alesko/llvm-install/bin/opt -- Installing:

> On Dec 9, 2015, at 1:56 PM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Not sure, but my guess is that the ocaml documents targets aren’t being included in the ALL target, which is resulting in them not being built before the install action. I think you're right. Running "make ocaml_doc" then rerunning "make install" completed the

I'm fairly sure the problem is that we still support building with gcc 4.8.x, and that version of gcc did not have std::to_string. It is not just an NDK issue. -Hal On 05/17/2017 06:05 AM, Pavel Labath via llvm-dev wrote: > Hi Diana, > > I am responsible for that bot, and probably a great number of those fixups. > > The root of the problem is that android NDK comes with a