| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|\ |
|
| | |
|
|/
|
|
|
|
|
| |
Includes files generated by each of:
* autogen.sh
* configure
* make
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |\
| | |
| | | |
Release objects allocated by InitializeDefaultRepeatedFields()
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
|/ |
|
| |
|
|\
| |
| | |
Fix "warning C4018: '<' : signed/unsigned mismatch"
|
| | |
|
|\ \
| | |
| | | |
Fix a bug that causes DynamicMessage.setField() to not work for repeated enum fields.
|
| | | |
|
| | |
| | |
| | |
| | | |
enum fields.
|
| | | |
|
|\ \ \
| | | |
| | | | |
Fix descriptor validation logic for packed enum fields.
|
| |/ / |
|
|\ \ \
| |/ /
|/| | |
Explicitly specify pyext/cpp_message.py in py_modules list
|
| | | |
|
|\ \ \
| | | |
| | | | |
Replace links to code.google.com/protobuf with developers.google.com/protocol-buffers
|
|/ / /
| | |
| | |
| | | |
developers.google.com/protocol-buffers
|
|\ \ \
| |_|/
|/| | |
Add support for solaris atomicops
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| |/ /
|/| | |
Add check for sched_yield in librt
|
|/ /
| |
| |
| |
| | |
In Solaris, sched_yield lives in librt, rather than libc. This patch adds a
check which will link in librt if necessary.
|
|\ \
| | |
| | | |
generic atomicops: promote Acquire_Store() and Release_Load() to use SEQ_CST fence
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
fence
__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.)
|
|\ \ \
| |/ /
|/| |
| | |
| | | |
edmonds/branches/undef_GOOGLE_PROTOBUF_PLATFORM_ERROR
platform_macros.h: #undef GOOGLE_PROTOBUF_PLATFORM_ERROR once it's no longer needed
|
| | |
| | |
| | |
| | | |
needed
|
|\| |
| | |
| | | |
Fix atomicops build failure on non-Clang
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| | |
| | | |
Expose generic atomicops on Clang
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The generic atomicops implementation is only exposed if GCC >= 4.7 is
available, but Clang, where the underlying __atomic built-ins are also
available, typically only claims to be GCC 4.2. This causes build
failures when compiling protobuf or the output of protoc's C++ code
generator on an architecture that needs the generic atomicops
implementation with Clang.
Clang has a "c_atomic" extension which can be tested for which almost
does what we want:
C11 atomic operations
Use __has_feature(c_atomic) or __has_extension(c_atomic) to
determine if support for atomic types using _Atomic is enabled.
Clang also provides a set of builtins which can be used to implement
the <stdatomic.h> operations on _Atomic types.
I'm not sure if this guarantees that the GNU atomic builtins (the ones
with the __atomic prefix) are also available, but in practice this
should guarantee that Clang is new enough.
With this change in place, Clang generates several diagnostics when
compiling the generic atomicops implementation. These appear to be bugs
in the generic atomicops implementation and are not Clang-specific.
|
|\| |
| | |
| | | |
Remove GOOGLE_PROTOBUF_ARCH_PPC
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The macro GOOGLE_PROTOBUF_ARCH_PPC is not used anywhere in the protobuf
source; there is no Power-specific atomics implementation, etc.
Funnily enough, the macro __ppc__ is not actually defined on 32-bit
Power on GCC/Linux, according to the following webpage:
http://nadeausoftware.com/articles/2012/02/c_c_tip_how_detect_processor_type_using_compiler_predefined_macros#POWER
and verified on a 32-bit Debian sid 'powerpc' chroot:
(sid_powerpc-dchroot)edmonds@partch:~$ gcc -dM -E - < /dev/null | grep -c __ppc__
0
(sid_powerpc-dchroot)edmonds@partch:~$ gcc -dM -E - < /dev/null | grep -c __LP64__
0
|
|\ \
| | |
| | | |
Bump version for maven-bundle-plugin
|
|/ / |
|
|\ \
| | |
| | | |
remove a const qualifier in a method's return type
|
|/ / |
|