similar to: [LibFuzzer] Recent performance regression due to r270942

Reproduced, should be easy to fix. Will do it. And thanks for noticing, on my machine this fails very fast and the test passes because it sees everything it wants to see. --kcc On Fri, May 27, 2016 at 6:18 PM, Dan Liew <dan at su-root.co.uk> wrote: > Hi, > > This started as an off hand comment in [1] but this appears to be a > real issue so I'm moving the discussion to the

Done. r271095 On Fri, May 27, 2016 at 7:55 PM, Kostya Serebryany <kcc at google.com> wrote: > Reproduced, should be easy to fix. Will do it. > And thanks for noticing, on my machine this fails very fast and the test > passes because it sees everything it wants to see. > > --kcc > > On Fri, May 27, 2016 at 6:18 PM, Dan Liew <dan at su-root.co.uk> wrote: >

On 27 May 2016 at 21:26, Kostya Serebryany <kcc at google.com> wrote: > Done. r271095 Thanks that fixed the issue for me. But now ``fuzzer.test`` is failing for me. Specifically ``` not LLVMFuzzer-NullDerefTest -close_fd_mask=3 2>&1 | FileCheck %s --check-prefix=NullDerefTest ``` However it looks like this is to be expected because this test is relying on the symbol

I decided to try out the fuzzer library and clang-fuzzer, but it doesn't seem to build for me. From the cmake files, I was pretty sure all I need to do is set -DLLVM_USE_SANITIZE_COVERAGE=ON, but with this I get a number of link errors for "lib/Fuzzer/test/LLVMFuzzer-CounterTest", for example: lib/libLLVMFuzzer.a(FuzzerLoop.cpp.o): In function `SetDeathCallback':

Here is a small btrfs vs. ext4 benchmark with kernel 2.6.37-rc1. compilebench with options -i 10 -r 30 on 2.6.37-rc1 btrfs ========================================================================== intial create total runs 10 avg 73.11 MB/s (user 0.34s sys 1.96s) create total runs 5 avg 49.53 MB/s (user 0.41s sys 1.62s) patch total runs 4 avg 22.13 MB/s (user 0.09s sys 1.79s) compile total runs

Hello LLVM/Clang developers, We recently switched to use the same clang version on all our platforms. This included switching from apple-clang from xcode to a pre-built binary we downloaded from llvm.org. We noticed that this actually came with a pretty big performance regression in compile times. If we do the simplest test program like this: #include <string> #include <iostream>

I don’t think Apple disable assertion on the release build. I remember having clang and llvm crash because of assertion failure regularly at some point in the past. Nowadays, it is far more unusual to get a clang crash, so I can’t tell, but I doubt they change the configuration. > Le 20 nov. 2018 à 16:32, Jack Howarth via cfe-dev <cfe-dev at lists.llvm.org> a écrit : > > The

I have recently compiled and installed openssh-2.1.1p1 on a linux box. The login reporting does not seem to work properly. When logging into the box via ssh (protocol 1) utmp shows the user logged in and the tty properly, but the field for the login date/time and the field for originating host contain all NULLs. Is anyone else seeing this same behavior, or have I just done something really

> On 7 May 2018, at 11:01, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, May 7, 2018 at 5:52 AM, Brian Cain <brian.cain at gmail.com <mailto:brian.cain at gmail.com>> wrote: >> The simplest way to run a clang test case that I know of is to clone both >> llvm and clang repos, run all the tests, then run an individual test. >>

> On 27 Jun 2017, at 13:25, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > Despite the statement in the HowToCrossCompileLLVM guide "If you’re > using Clang as the cross-compiler, there is a problem in the LLVM ARM > back-end that is producing absolute relocations on > position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you

Oh, so it looks like I hit a bit of a wall there :-) I’ll take a look thanks. That bug talks about R_ARM_THM_CALL which I assume are thumb related. Will your implementation fix also R_ARM_CALL errors? > On 28 Jun 2017, at 17:15, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > The LLD ARM port doesn't currently support range extension thunks,

I've successfully used Peter's patches to get past those relocation errors. On 6/28/17, 9:36 AM, "llvm-dev on behalf of Peter Smith via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Yes it should cover the following relocations: R_ARM_CALL (ARM BL/BLX) R_ARM_JUMP24 (ARM B) R_ARM_THM_CALL (Thumb BL/BLX)

Hello! I'm facing ReInvites as caller from UAS despite configured session-timers=refuse (which can be seen in the SIP trace) always after 900s. (The behavior is the same if session-timers is set to accept). This just happens with one provider (German Telekom to callee at kabelbw). - The incoming ReInvite is answered immediately by asterisk (Status 100 / Status 200 - 0.02s). Media stream

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

At a guess that looks like your llvm and lld checkouts are not quite in synch. It will be worth updating llvm and lld to top of trunk. I've rebased the consolidated patch https://reviews.llvm.org/D34634 this morning, it might be worth trying that if you are seeing problems. Peter On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote: > Hi, I tried

On Mon, May 7, 2018 at 4:03 PM, Amara Emerson <aemerson at apple.com> wrote: > On 7 May 2018, at 11:01, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > On Mon, May 7, 2018 at 5:52 AM, Brian Cain <brian.cain at gmail.com> wrote: > > The simplest way to run a clang test case that I know of is to clone both > llvm and clang repos, run all the

On Sep 20, 11:50 am, wbrana@gmail.com wrote: > On Sun, Sep 20, 2009 at 3:47 AM, Daniel J Blueman > > <daniel.blueman@gmail.com> wrote: > > On Sep 19, 7:20 pm, wbr...@gmail.com wrote: > > >> RAID details: > >> > >> md8 : active raid10 sda7[0] sdd7[3] sdc7[2] sdb7[1] > >> 62925824 blocks 256K chunks 2 far-copies [4/4] [UUUU] >

On Mon, May 7, 2018 at 5:52 AM, Brian Cain <brian.cain at gmail.com> wrote: > The simplest way to run a clang test case that I know of is to clone both > llvm and clang repos, run all the tests, then run an individual test. > > IIRC like so: > > git clone llvm ...... > cd llvm/tools > git clone clang ..... > cd ../../ > mkdir build > cd build > cmake

Óscar Fuentes <ofv at wanadoo.es> writes: >> Chris is absolutely on-target as to why the current build is slow. It's >> slow because recursive make hides the parallelism. It hides the >> parallelism because it hides the dependencies. There is no way to get >> around that problem with a recursive make build system. > > You keep repeating that and I say

On 06/08/2011 01:17 AM, MORIYAMA Tomohiro wrote: > Hi, all > > I tried Polly installation on Ubuntu. > > On its building, it returned no errors. > But when I run "make polly-test", it returns 11 unexpected failures as > follows. > ----------------------------------- > ******************** > Testing Time: 19.77s > ******************** > Failing Tests