search for: racili

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

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

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

> At the dev meeting I heard Doug Gregor say something like, "what kind of dirty animals are you, you just push directly to master!?" Based on that, I think other communities may set up workflows where they push branches to places, and some automation rebases and updates master asynchronously, optionally conditioned on some (light) testing or approval. Someone has already mentioned

Now that we have switched to git and I had to leave behind my wonderfully simple svn workflow I have noticed something curious when committing. My typical workflow once my patch is approved on Phabricator has always been: - Update my source tree to latest - Apply the approved patch - Rebuild - Retest - If all is well, commit Having to update again after rebuilding/retesting was extremely rare