search for: memory_order

...e 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) + __theAmount); ^ .../usr/bin/../include/c++/v1/atomic:548:5: note: candidate found by name lookup is 'std::__1::memory_order::memory_order_relaxed' memory_order_relaxed, memory_order_consume, memory_order_acquire, ^ ../src/projec...

...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) + __theAmount); >> ^ >> .../usr/bin/../include/c++/v1/atomic:548:5: note: candidate found by name >> lookup is 'std::__1::memory_order::memory_order_relaxed' >> memory_order_relaxed, memory_order_c...

Hi, what's the current status of the memory-ordered operations described in https://docs.google.com/Doc?docid=0AYWBeVVqyP7dZGRiNG1oeHpfMjJkejVnOThkZA&hl=en.&pli=1 i.e. the ones for "load acquire", "store release" etc. for C++0x atomics, not the older ones for the __sync intrinsics? The specification looks good - is it just waiting to be implemented? Al --

...me examples to test this xray part in llvm ? > in xray runtime, > bool atomic_compare_exchange_strong(volatile atomic_sint32_t *a, > s32 *cmp, > s32 xchg, > memory_order mo) > is missed for MSVC , I take atomic_uint32_t implementation > > > This is in compiler-rt/lib/sanitizer_common/... right? yes, sanitizer_atomic_msvc.h didn't provide this override. according to msdn of interlockedcompareexchange, implementation for atomic_uint32_t should also...

...romotion, are not always valid. Of course, the problem with this approach is that it is often the case that compiler/hardware cannot reorder accesses to gain optimal performance and in light of this C++0x allows values of type atomic to be accessed through a relaxed consistency model, e.g. x.load(memory_order_relaxed); x.store(something, memory_order_relaxed); In this case the compiler is free to order load/stores to x, in different threads, any why it feels fit. The full set of relaxed options are defined by the enumeration: typedef enum memory_order { memory_order_relaxed, memory_order_acqu...

...ngs in that situation that it disallows for the multi-threaded case. In particular, global objects of type "volatile sig_atomic_t" can be read and written between signal handlers in a thread and that thread's main control flow without locking. C++0x also defines an atomic_signal_fence(memory_order) that only synchronizes with signal handlers, in addition to the atomic_thread_fence(memory_order) that synchronizes to other threads. See [atomics.fences] > I'm not familiar with what synchronization occurs as > part of the interrupt process, but I'd verify it before making too >...

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

...ay args. with this, generated code seems have sled and xray parts. in xray runtime, bool atomic_compare_exchange_strong(volatile atomic_sint32_t *a, s32 *cmp, s32 xchg, memory_order mo) is missed for MSVC , I take atomic_uint32_t implementation msvc 14.1 treats BufferQueue::Buffer::Buffer as constructor instead of data member, Buf.Buffer=>Buf.Data FunctionRecord pack , __attribute__((packed)) => #pragma pack(push,1), msvc also requires bitfields to be same type to pa...

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

...n that it disallows for the multi-threaded case. In > particular, global objects of type "volatile sig_atomic_t" can be read > and written between signal handlers in a thread and that thread's main > control flow without locking. C++0x also defines an > atomic_signal_fence(memory_order) that only synchronizes with signal > handlers, in addition to the atomic_thread_fence(memory_order) that > synchronizes to other threads. See [atomics.fences] Very interesting, and thanks for the clarifications. I'm not particularly familiar with either those parts of C or C++0x, althou...

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

I'm learning the xray library and try if it can be built on windows, in xray_fdr_logging_impl.h line 152 , comment written as // Using pthread_once(...) to initialize the thread-local data structures but at line 175, 183, code written as thread_local pthread_key_t key; // Ensure that we only actually ever do the pthread initialization once. thread_local bool UNUSED Unused = [] {