similar to: memory leak in split.screen

64bit Fedora Failing Tests (8): LeakSanitizer-AddressSanitizer :: TestCases/cleanup_in_tsd_destructor.cc LeakSanitizer-AddressSanitizer :: TestCases/disabler.cc LeakSanitizer-AddressSanitizer :: TestCases/disabler_in_tsd_destructor.cc LeakSanitizer-AddressSanitizer :: TestCases/ignore_object.cc LeakSanitizer-Standalone :: TestCases/cleanup_in_tsd_destructor.cc

> Ben reports that he didn't get a tarball even after the rpath fix and > had to disable -o pipefail to get one. Still not sure what caused > this. 'make check' failures can cause this. I had to revert r241599 to get a package. > Appendix: compiler-rt test failures > =================================== > Just to add Mips to this: On big-endian Mips32r2:

On Dec 25, 2013, at 11:55 PM, Kostya Serebryany <kcc at google.com> wrote: > On Thu, Dec 26, 2013 at 11:49 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Dec 26, 2013 at 2:40 AM, Kostya Serebryany <kcc at google.com> wrote: > Like this? > > +extern "C" { > +// Disable LeakSanitizer, see

On Mon, Mar 19, 2012 at 4:30 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 19, 2012, at 2:52 PM, Kostya Serebryany wrote: > > Hello, > > While instrumenting LLVM IR in ThreadSanitizer (race detector), I need > to distinguish between a store to vtable pointer (vptr) and any other > regular store. > This special treatment should be limited to class

I'm looking into how we can improve devirtualization in clang, and there a language in C++ feature I'd like to take advantage of which would let us perform elimination of more vptr loads. In this code: Cls *p = new Cls; p->virtual_method1(); p->method_changing_vptr(); // uses placement new to legally change the vptr p->virtual_method2(); // invalid! Cls *q = p;

2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > On 25 January 2017 at 15:03, Hal Finkel via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi Piotr, >> >> I think makes sense. Modulo bitcasts, the invariant is identified by a >> particular pointer SSA value. Given that you can't sensibly have two >> nonequivalent

On 01/28/2017 10:36 AM, Piotr Padlewski wrote: > > > 2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>>: > > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: >> >> >> 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk >> <mailto:richard at metafoo.co.uk>>: >>

clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c) Native: All ok Cross compiling to MIPS: All ok clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) All ok (aside from non-regression failures in check-all). There were two kinds of check-all failure: * mips64 sanitizers. Not a regression since

On Mon, Mar 19, 2012 at 2:52 PM, Kostya Serebryany <kcc at google.com> wrote: > Hello, > > While instrumenting LLVM IR in ThreadSanitizer (race detector), I need > to distinguish between a store to vtable pointer (vptr) and any other > regular store. > This special treatment should be limited to class DTORs, so I should also > know when a function is a DTOR. >

On Mar 19, 2012, at 2:52 PM, Kostya Serebryany wrote: > Hello, > > While instrumenting LLVM IR in ThreadSanitizer (race detector), I need to distinguish between a store to vtable pointer (vptr) and any other regular store. > This special treatment should be limited to class DTORs, so I should also know when a function is a DTOR. > Rationale: need to distinguish benign and

On Fri, Mar 31, 2017 at 10:23 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Piotr, > > On March 31, 2017 at 9:07:42 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: > > Hi all, > > I have a question about dereferenceable metadata on load instruction. I > > have a patch (https://reviews.llvm.org/D31539) for LICM that hoists >

2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov>: > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: > > > > 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > >> On 25 January 2017 at 15:03, Hal Finkel via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> Hi Piotr, >>> >>> I think

On Mon, Feb 29, 2016 at 2:20 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c) > Native: All ok > Cross compiling to MIPS: All ok > > clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) > All ok

John McCall wrote: > On Dec 8, 2011, at 10:03 PM, Nick Lewycky wrote: >> Noalias returns, nocapture, SCC refinement, linkonce_odr and >> available_externally were added with the goal of making devirtualization >> in LLVM happen, but as orthogonal independent optimizations. I think >> LLVM should continue with this design. If you want to implement a single >>

Hi Nick, Won't this approach run into problems with inlining, unrolling, or just about anything that duplicates code? Suppose I have a bunch of loads of the same load group in the body of the loop, but update the pointer they're dereferencing on the backedge. If that loop gets unrolled, all the loads in the unrolled copies will have the same load group, but it would not be correct to

On Mon, Mar 19, 2012 at 5:24 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Mon, Mar 19, 2012 at 4:52 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Mon, Mar 19, 2012 at 4:46 PM, Eli Friedman <eli.friedman at gmail.com> > > wrote: > >> > >> Given that, I'm not sure I really see the issue with just > >>

2017-04-05 18:30 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > Hi Piotr, > > On Mon, Apr 3, 2017 at 2:01 PM, Piotr Padlewski > <piotr.padlewski at gmail.com> wrote: > >> I don't see any way to model it right now in LLVM, but I see a one > simple > >> solution: > >> add extra information to the metadata nodes indicating that

On Thu, Dec 26, 2013 at 2:40 AM, Kostya Serebryany <kcc at google.com> wrote: > Like this? > > +extern "C" { > +// Disable LeakSanitizer, see http://llvm.org/bugs/show_bug.cgi?id=18325. > We don't often reference bugs in comments. I would give a brief summary in the text of the comment, and mention the bug in the commit log. -------------- next part

Hello, While instrumenting LLVM IR in ThreadSanitizer (race detector), I need to distinguish between a store to vtable pointer (vptr) and any other regular store. This special treatment should be limited to class DTORs, so I should also know when a function is a DTOR. Rationale: need to distinguish benign and harmful races on vptr (

On May 9, 2013, at 6:34 PM, Nick Lewycky <nlewycky at google.com> wrote: > I'm looking into how we can improve devirtualization in clang, and there a language in C++ feature I'd like to take advantage of which would let us perform elimination of more vptr loads. In this code: > > Cls *p = new Cls; > p->virtual_method1(); > p->method_changing_vptr(); //