search for: vg_leak

...be inclined to agree (or at least voice the same concern) as Renato here - as a project we don't really have very good bug hygiene, so adding more bug filing doesn't seem to me like it'd give us much value. I haven’t done a full audit, but we have 257 XFAILs in LLVM. * 44 of those are vg_leak failures on TableGen tests which should be UNSUPPORTED because we allow TableGen to leak for performance the same way we allow clang to leak. * 15 of them are vg_leak in the OCaml bindings. Someone familiar with OCaml should chime in on it, but I suspect those too should be UNSUPPORTED * 125 of the...

...vm/trunk/test/TableGen/intrinsic-long-name.td =================================================================== --- llvm/trunk/test/TableGen/intrinsic-long-name.td +++ llvm/trunk/test/TableGen/intrinsic-long-name.td @@ -0,0 +1,32 @@ +// RUN: llvm-tblgen -gen-intrinsic %s | FileCheck %s +// XFAIL: vg_leak + +class IntrinsicProperty; + +class ValueType<int size, int value> { + string Namespace = "MVT"; + int Size = size; + int Value = value; +} + +class LLVMType<ValueType vt> { + ValueType VT = vt; +} + +class Intrinsic<string name, list<LLVMType> param_types = []&g...

...=================================================================== >> --- llvm/trunk/test/TableGen/intrinsic-long-name.td >> +++ llvm/trunk/test/TableGen/intrinsic-long-name.td >> @@ -0,0 +1,32 @@ >> +// RUN: llvm-tblgen -gen-intrinsic %s | FileCheck %s >> +// XFAIL: vg_leak >> + >> +class IntrinsicProperty; >> + >> +class ValueType<int size, int value> { >> + string Namespace = "MVT"; >> + int Size = size; >> + int Value = value; >> +} >> + >> +class LLVMType<ValueType vt> { >>...

...? If you can, send the whole short program and the exact command line you used to build it, along with the output of `llvm-config --build-mode`. (We need to reproduce your problem locally in order to fix it.) Note that if the leaks appear on http://google1.osuosl.org:8011/builders/llvm-x86_64-linux-vg_leak/builds/5/steps/test-llvm/logs/stdio we already know about them and are working on fixes. On Tue, Mar 23, 2010 at 12:42 PM, Gabi <bugspynet at gmail.com> wrote: > Hi Jeffrey, > Listed below the Full valgrind report (using latest revision r99309) > The program creates many thousands o...

On Jan 31, 2013, at 4:37 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi all, > > We'd like to promote the AArch64 backend to being built by default. I > know it's very soon after the initial upload, but we think the backend > is in a good position and should be stable. > > We'd very much like to get it tested in more diverse environments >

> I think this is the right thing to do. Once you've resolved the Mac and Windows issues, go for it. Thanks Doub. Just to let people know what happened. I enabled in r174322 around lunchtime. Here's a report of the noticed failures with status (important/outstanding ones at the top). Feel free to do anything from telling me about more problems to reverting the patch when llvm.org comes

On 28 September 2016 at 10:08, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I cannot think of any situation where a universally failing test > should be in-tree unless it is a bug that someone is expecting to fix. It seems moderately common to mark something XFAIL temporarily to get the bots green while then going ahead to fix the issue. Your proposal would add

> On Sep 16, 2015, at 9:45 AM, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 16, 2015 at 7:47 AM, Teresa Johnson <tejohnson at google.com> wrote: >> On Tue, Sep 15, 2015 at 3:31 PM, Duncan P. N. Exon Smith via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>>> On 2015-Sep-02, at 19:31, Peter

Hi Jeffrey, Listed below the Full valgrind report (using latest revision r99309) The program creates many thousands of instructions and values as you can see from the report below ==20504== Memcheck, a memory error detector ==20504== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==20504== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==20504==