Make the my_compiler.h header, like my_attribute.h, part of
the distribution. This is required due to the dependency of
the former on the latter (which can undefine __attribute__).
not tested by ABI check
plugin_audit.h and plugin_ftparser.h are now subject
for ABI check. plugin.h is now tested implicitly.
Also fixed broken ABI check cmake rules.
Reverted the ulong->uint diff
Re-applied the first diff.
The original commit message follows:
enum plugin system variables are ulong internally, not int.
On systems where long is not the same as an int it causes
problems.
Fixed by correct typecasting. Removed the test from the
experimental list.
The enum system variables were handled inconsistently
as ints, unsigned int and unsigned long on various places.
This caused problems on platforms on which
sizeof(int) != sizeof(long).
Fixed by homogenizing the type of the enum variables
to unsigned int, since it's size compatible with the C enum
type.
Removed the test from the experimental list.
Remove wrappers around inline -- static inline is used without
wrappers throughout the source code. We rely on the compiler or
linker to eliminate unused static functions.
Fix warnings flagged by the new warning option -Wunused-but-set-variable
that was added to GCC 4.6 and that is enabled by -Wunused and -Wall. The
option causes a warning whenever a local variable is assigned to but is
later unused. It also warns about meaningless pointer dereferences.
Bug#52261: 64 bit atomic operations do not work on Solaris i386
gcc in debug compilation
One of the various problems was that the source operand to
CMPXCHG8b was marked as a input/output operand, causing GCC
to use the EBX register as the destination register for the
CMPXCHG8b instruction. This could lead to crashes as the EBX
register is also implicitly used by the instruction, causing
the value to be potentially garbaged and a protection fault
once the value is used to access a position in memory.
Another problem was the lack of proper clobbers for the atomic
operations and, also, a discrepancy between the implementations
for the Compare and Set operation. The specific problems are
described and fixed by Kristian Nielsen patches:
Patch: 1
Fix bugs in my_atomic_cas*(val,cmp,new) that *cmp is accessed
after CAS succeds.
In the gcc builtin implementation, problem was that *cmp was
read again after atomic CAS to check if old *val == *cmp;
this fails if CAS is successful and another thread modifies
*cmp in-between.
In the x86-gcc implementation, problem was that *cmp was set
also in the case of successful CAS; this means there is a
window where it can clobber a value written by another thread
after successful CAS.
Patch 2:
Add a GCC asm "memory" clobber to primitives that imply a
memory barrier.
This signifies to GCC that any potentially aliased memory
must be flushed before the operation, and re-read after the
operation, so that read or modification in other threads of
such memory values will work as intended.
In effect, it makes these primitives work as memory barriers
for the compiler as well as the CPU. This is better and more
correct than adding "volatile" to variables.
strict aliasing violations.
Post-merge fix: include my_compiler.h before my_attribute.h
as the latter will undef __attribute__ if the compiler is not
GCC. Based on the compiler version, in my_compiler.h we know
for sure whether the aligned attribute is supported. Furthermore,
undefining attribute might cause bugs if some system header
uses it.
strict aliasing violations.
Another rather noisy violation of strict aliasing rules
is the spatial code which makes use of stack-based memory
(of type Geometry_buffer) to provide placement for Geometry
objects. Although a placement new is allowed to dynamically
change the type of a object, the object returned by the
new placement was being ignored and the original stack-based
object was being casted to the new type, thus violating strict
aliasing rules.
The solution is to reorganize the code so that the object
returned by the new placement is used instead of casting the
original object. Also, to ensure that the stack-based object
is properly aligned with respect to the objects it provides
placement for, a set of compiler-dependent macros and types
are introduced so that the alignment of objects can be inquired
and specified.