- 21 Oct, 2014 3 commits
- 16 Oct, 2014 1 commit
-
-
John Beard authored
Includes files generated by each of: * autogen.sh * configure * make
-
- 11 Oct, 2014 1 commit
-
-
William Orr authored
-
- 09 Oct, 2014 9 commits
- 08 Oct, 2014 2 commits
-
-
Antoni Buszta authored
-
Feng Xiao authored
-
- 06 Oct, 2014 1 commit
-
-
Feng Xiao authored
Fix "warning C4018: '<' : signed/unsigned mismatch"
-
- 03 Oct, 2014 4 commits
- 02 Oct, 2014 3 commits
- 01 Oct, 2014 2 commits
- 23 Sep, 2014 3 commits
-
-
xfxyjwf authored
Add support for solaris atomicops
-
Dinis Rosário authored
-
William Orr authored
-
- 22 Sep, 2014 2 commits
-
-
William Orr authored
-
xfxyjwf authored
Add check for sched_yield in librt
-
- 20 Sep, 2014 2 commits
-
-
William Orr authored
This patch adds support for atomic operations on Solaris, on any platform. It makes use of the atomic functions made available in Solaris' atomic.h header.
-
William Orr authored
In Solaris, sched_yield lives in librt, rather than libc. This patch adds a check which will link in librt if necessary.
-
- 19 Sep, 2014 5 commits
-
-
xfxyjwf authored
generic atomicops: promote Acquire_Store() and Release_Load() to use SEQ_CST fence
-
Robert Edmonds authored
__atomic_store_n() cannot take a memory model argument of __ATOMIC_ACQUIRE, and __atomic_load_n() cannot take a memory model argument of __ATOMIC_RELEASE, per the GCC documentation: https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fatomic-Builtins.html On Clang this generates a -Watomic-memory-ordering warning. Promote the fences in Acquire_Store() and Release_Load() to the stronger __ATOMIC_SEQ_CST memory model, which ought to be safe. Note that there are no actual uses of Acquire_Store() or Release_Load() in protobuf, though. This follows the TSAN atomicops implementation, which also uses SEQ_CST fences for these functions. (Fixes #25.)
-
xfxyjwf authored
platform_macros.h: #undef GOOGLE_PROTOBUF_PLATFORM_ERROR once it's no longer needed
-
Robert Edmonds authored
-
xfxyjwf authored
Fix atomicops build failure on non-Clang
-
- 18 Sep, 2014 2 commits
-
-
Robert Edmonds authored
We cannot use Clang's __has_extension macro unless we really are compiling on Clang, which means we cannot use this expression: #if (defined(__clang__) && __has_extension(c_atomic))) // ... #endif On GCC, this generates the following errors: In file included from ./google/protobuf/stubs/atomicops.h:59:0, from google/protobuf/stubs/atomicops_internals_x86_gcc.cc:36: ./google/protobuf/stubs/platform_macros.h:67:41: error: missing binary operator before token "(" (defined(__clang__) && __has_extension(c_atomic))) ^ In file included from google/protobuf/stubs/atomicops_internals_x86_gcc.cc:36:0: ./google/protobuf/stubs/atomicops.h:196:40: error: missing binary operator before token "(" (defined(__clang__) && __has_extension(c_atomic)) ^ Instead, we have to protect the __has_extension expression by only executing it when __clang__ is defined: #if defined(__clang__) # if __has_extension(c_atomic) // ... # endif #endif
-
xfxyjwf authored
Expose generic atomicops on Clang
-