search for: __sync

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 -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose th...

...least not on x86). A mutex-based programs works fine (but is > substantially slower than gcc) but my wait-free alternative fails with: > > $ llvm-g++ -O3 -lpthread waitfree.c -o waitfree > /tmp/cc6t7jaO.o: In function `inc_count(void*)': > (.text+0x2ee): undefined reference to `__sync_add_and_fetch_4' > collect2: ld returned 1 exit status This probably means that you're target triple starts with i386, where __sync instructions aren't supported, possibly reconfiguring llvm-g++ explicitly with i686 (if that's what you have) will fix your problem. This should...

...work as I had hoped (at least not on x86). A mutex-based programs works fine (but is substantially slower than gcc) but my wait-free alternative fails with: $ llvm-g++ -O3 -lpthread waitfree.c -o waitfree /tmp/cc6t7jaO.o: In function `inc_count(void*)': (.text+0x2ee): undefined reference to `__sync_add_and_fetch_4' collect2: ld returned 1 exit status The source is: #include <pthread.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> #define NUM_THREADS 9 #define TCOUNT (1 << 23) #define COUNT_LIMIT (1 << 25) volatile int count = 0; pthre...

...dex 752e0b8..3eac4b9 100644 --- a/arch/mips/include/asm/barrier.h +++ b/arch/mips/include/asm/barrier.h @@ -10,9 +10,6 @@ #include <asm/addrspace.h> -#define read_barrier_depends() do { } while(0) -#define smp_read_barrier_depends() do { } while(0) - #ifdef CONFIG_CPU_HAS_SYNC #define __sync() \ __asm__ __volatile__( \ @@ -87,8 +84,6 @@ #define wmb() fast_wmb() #define rmb() fast_rmb() -#define dma_wmb() fast_wmb() -#define dma_rmb() fast_rmb() #if defined(CONFIG_WEAK_ORDERING) && defined(CONFIG_SMP) # ifdef CONFIG_CPU_CAVIUM_OCTEON @@ -112,9 +107,6 @@ #define...

...dex 752e0b8..3eac4b9 100644 --- a/arch/mips/include/asm/barrier.h +++ b/arch/mips/include/asm/barrier.h @@ -10,9 +10,6 @@ #include <asm/addrspace.h> -#define read_barrier_depends() do { } while(0) -#define smp_read_barrier_depends() do { } while(0) - #ifdef CONFIG_CPU_HAS_SYNC #define __sync() \ __asm__ __volatile__( \ @@ -87,8 +84,6 @@ #define wmb() fast_wmb() #define rmb() fast_rmb() -#define dma_wmb() fast_wmb() -#define dma_rmb() fast_rmb() #if defined(CONFIG_WEAK_ORDERING) && defined(CONFIG_SMP) # ifdef CONFIG_CPU_CAVIUM_OCTEON @@ -112,9 +107,6 @@ #define...

...sue. > Great. Let's make the bikeshed blue then? Yes, let's make it blue, but please promise to check into Peter's register API so we can remove the case offsetof. I checked that it works on RHEL5, which is 4.1 and probably the oldest compiler we care about (any other 4.1 lacks the __sync builtins; upstream added them in 4.2). Paolo

On Wed, May 29, 2013 at 09:16:39AM -0500, Anthony Liguori wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > On Wed, May 29, 2013 at 07:52:37AM -0500, Anthony Liguori wrote: > >> 1) C makes no guarantees about structure layout beyond the first > >> member. Yes, if it's naturally aligned or has a packed attribute, > >>

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the