similar to: [LLVMdev] recognizing DTORs and vptr updates in LLVM.

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 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 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

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

>> Using instruction level metadata for this would be appropriate. However, I >> also don't understand why a race on this is truly benign. > > It isn't, really; calling it "benign" is deceptive. It's just that > storing a pointer which is equal to the existing pointer stored at a > given address almost always makes the optimizer/codegen generate code

On Mar 20, 2012, at 12:51 AM, Duncan Sands wrote: >>> Using instruction level metadata for this would be appropriate. However, I >>> also don't understand why a race on this is truly benign. >> >> It isn't, really; calling it "benign" is deceptive. It's just that >> storing a pointer which is equal to the existing pointer stored at a

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 >> special-casing any store where the value stored is a pointer to a >> global... but it could be argued either way, I

On Tue, Mar 20, 2012 at 1:50 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 20, 2012, at 12:51 AM, Duncan Sands wrote: > > >>> Using instruction level metadata for this would be appropriate. > However, I > >>> also don't understand why a race on this is truly benign. > >> > >> It isn't, really; calling it

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 > >>

Chris, is this how the tbaa for vtable loads/stores should look like? Metadata: !0 = metadata !{metadata !"vtable pointer", metadata !1} !1 = metadata !{metadata !"omnipotent char", metadata !2} !2 = metadata !{metadata !"Simple C/C++ TBAA", null} ... Load: %0 = bitcast %struct.A* %a to void (%struct.A*)*** %vtable = load void (%struct.A*)*** %0, align 8, !tbaa

On Mar 21, 2012, at 11:53 AM, Kostya Serebryany wrote: > > The gcc Ada front-end does this too, in quite a range of situations. For > > example multiple threads racily initialize a pointer variable, but they all > > initialize to the same value. The various valgrind based race detection > > tools all complain about this, which makes them much less useful than they >

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 > special-casing any store where the value stored is a pointer to a > global... but it could be argued either way, I guess. > I users expect this to "just work", why not extend the language and make it just work? We could, as

Hi, I've tagged LLVM 9.0.1-rc2. Testers can begin testing and uploading binaries. If all goes well, this will be the last -rc. -Tom

Bill, For some reason the llvm-symbolizer tests fail on ppc: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/182/steps/ninja%20check%201/logs/stdio because it can't be started: /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by

Hi, I've just tagged the 9.0.1-final release. Testers can begin uploading binaries. -Tom

Hi, I've just tagged LLVM 9.0.1-rc3. Testers can begin testing and uploading binaries. This will be the last release candidate unless there is a major problem. I'm planning to tag the final release on Dec 19. -Tom

On Dec 10, 2011, at 5:20 PM, David Blaikie wrote: >>> Thanks Chris, committed as r145578. I don't suppose you'll mind some >>> similar commits as I encounter them? >> >> Yep, please feel free. > > While you said this - given that I've now gone & fixed /every/ > violation of -Wweak-vtables across LLVM & Clang (apart from some llvm >

On Thu, Dec 1, 2011 at 9:11 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 1, 2011, at 12:08 AM, David Blaikie wrote: > >> On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: >>> On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >>>> For a bit of an experiment I've been trying to compile LLVM & Clang

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 invariants associated with the same pointer SSA value simultaneously, there's no need to also identify the invariant with a metadata string as well. When we need a new "identifier" for the pointed-to value, we

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