similar to: [LLVMdev] atomic (memory ordered) operations

Hi Sanitizer Runtime Developers, We recently ran into a problem building clang because some of the definitions in sanitizer_common conflicted with system definitions and later another system header was trying to use the system definition: .../usr/include/libkern/OSAtomicDeprecated.h:756:17: error: reference to 'memory_order_relaxed' is ambiguous __theAmount, memory_order_relaxed) +

> On Jul 1, 2016, at 12:10 PM, Dmitry Vyukov <dvyukov at google.com> wrote: > > On Fri, Jul 1, 2016 at 8:53 PM, Anna Zaks <ganna at apple.com> wrote: >> Hi Sanitizer Runtime Developers, >> >> We recently ran into a problem building clang because some of the >> definitions in sanitizer_common conflicted with system definitions and later >>

Hi Ben, Vacation is always a good thing. Hope you had a good one. In my mind, having a more general memory consistency model is going to be very useful in LLVM in the future. It is still a little unclear to me what we should support. I haven't looked at what C++ is considering for their model. Are they going to support different relaxations models like relaxing write to read or

Quoting Tim Northover <t.p.northover at gmail.com>: > On 24 April 2015 at 13:53, Tyler Denniston <tyler at csail.mit.edu> wrote: >> I'm wondering how I can create an atomic load and add instruction for >> floating point values. If I use IRBuilder::CreateAtomicRMW() I get the >> error message: "atomicrmw operand must have integer type". > >

Hi Mon Wang, As I understand it the C++0x memory model will, by default, be similar to Java's in that it will assume sequential consistency, using acquire/release atomics (similar to Java's volatile), for all programs that do not contain data races. Unlike Java in the case when a program contains a data race, the program behavior is undefined. Adopting this model allows many sequential

> } while (__c11_atomic_compare_exchange_weak( > addr, &oldval, newval, memory_order_seq_cst, memory_order_relaxed)); Actually, I think this condition is inverted. Should be "while (!_c11...". Sorry about that. Tim.

Ptr member of ManagedStaticBase is now atomic. In ManagedStaticBase::RegisterManagedStatic we have such code: void *Tmp = Creator(); Ptr.store(Tmp, std::memory_order_release); DeleterFn = Deleter; // Add to list of managed statics. Next = StaticList; StaticList = this; StaticList is not atomic and not guarded by any fence. The same applies to the members

Though it won't actually help to guard this: while (StaticList) - a fence here is needed... On Mon, Dec 26, 2016 at 9:20 AM, Viacheslav Nikolaev < viacheslav.nikolaev at gmail.com> wrote: > Ptr member of ManagedStaticBase is now atomic. > In ManagedStaticBase::RegisterManagedStatic we have such code: > > void *Tmp = Creator(); > > Ptr.store(Tmp,

On Wed, Nov 22, 2017 at 10:37 AM, Dean Michael Berris <dean.berris at gmail.com> wrote: > > On 22 Nov 2017, at 02:32, comic fans <comicfans44 at gmail.com> wrote: > > with some dirty hack , I've made xray runtime 'built' on windows , > > > \o/ with more test, I've found that trampoline didn't got built for windows :/ currently cmake didn't

Hi, TL;DR: should we add a new memory ordering to fences? ``fence seq_cst`` is currently use to represent two things: - GCC-style builtin ``__sync_synchronize()`` [0][1]. - C11/C++11's sequentially-consistent thread fence ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. As far as I understand: - The former orders all memory and emits an actual fence instruction. - The

On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: > Hi, thanks everyone for all the comments. I think maybe I wasn't clear that > I *only* care about atomicity w.r.t. a signal handler interruption in the > same thread, *not* across threads. Therefore, many of the problems of > cross-CPU atomicity are not relevant. The signal handler gets invoked via

Jon Harrop wrote: > Having implemented a GC for HLVM, I am now turning my attention to > implementing a GC that supports parallelism. To do this, I would like to use > atomic instructions as well as mutexes. What is the status of LLVM's atomic > instrinsics (e.g. CAS)? Is anyone using them in real projects? > > I realised that an obvious test would be to compile some

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

On Mon, Jan 4, 2010 at 8:43 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: >> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that >> I *only* care about atomicity w.r.t. a signal handler interruption in the >> same thread, *not* across threads. Therefore,

2013/7/31 JF Bastien <jfb at google.com>: > Hi, > > TL;DR: should we add a new memory ordering to fences? > > > ``fence seq_cst`` is currently use to represent two things: > - GCC-style builtin ``__sync_synchronize()`` [0][1]. > - C11/C++11's sequentially-consistent thread fence > ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. > > As far

On Tue, Jun 7, 2016 at 4:02 PM, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > (+CC LLVM dev - I'd dropped it in my original reply unintentionally and > just noticed.) > > On 06/07/2016 01:35 PM, Philip Reames wrote: > >> (This was written in a rush. There may be mistakes; if so I'll try to >> correct later.) >> >> At the

with some dirty hack , I've made xray runtime 'built' on windows , but unfortunately I haven't enough knowledge about linker and the runtime, and finally built executable didn't run. I'd like to share my changes here , hopes somebody help me to make it run on windows. in AsmPrinter, copy/paster xray for coff target InstMap =

On Fri, Apr 18, 2014 at 11:13 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > Hi, > > This is long thread, so I will combine several comments into single email. > > > >> - 8-bit per-thread counters, dumping into central counters on overflow. > >The overflow will happen very quickly with 8bit counter. > > Yes, but it reduces contention by 256x (a thread

Hi All , We are looking at the C sample i.e extern int i,j; int test() { while(1) { i++; j=20; } return 0; } command used :(clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) ) clang -S test.c -O2 the generated asm for x86 .L2: jmp .L2 we understand that,the infinite loop is not deterministic ,compiler is free to treat as that as UB and do aggressive

On Jan 4, 2010, at 4:35 AM, Chandler Carruth wrote: > Responding to the original email... > > On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: >> In working on an LLVM backend for SBCL (a lisp compiler), there are >> certain sequences of code that must be atomic with regards to async >> signals. > > Can you define exactly what