If t->bottom is close to MIN_INT (probably invalid value), subtracting
top can lead to underflow which causes crashes. Attached patch will
fix the issue.
This fixes bug 67484.
(cherry picked from commit 5e14da97f1)
There is a couple of bugs in bugzilla where bugs in the X server
triggered asserts in the pixman region code. It is probably better to
let the X server survive this. (In fact, I thought I had disabled them
for 0.16.0, but apparently not).
The patch below uses these rules:
- In _stable_ pixman releases, assertions and selfchecks are turned
off. Assertions, so that the X server doesn't die. Selfchecks,
for performance reasons.
- In _unstable_ pixman releases, both assertions and selfcheck are
turned on. These releases are what get added to development
distributions such as rawhide, so we want as much self-checking
as possible.
- In _random git checkouts_, assertions are enabled, so that bugs
are caught, but selfchecks are disabled so that you can use them
for performance work without having to fiddle with turning
selfchecks off.
When masking out the x bits, blitter-test would make the incorrect
assumption that the they were always in the topmost position. This is
not correct for formats of type PIXMAN_TYPE_BGRA.
These generally extracted the 2 bits of alpha, then shifted them 62
bits and replicated across 16 bits. Then they were shifted another 48
bits, making the resulting alpha channel 0.
For consistency we will probably want to allow component alpha to be
set on all masks at some point, but not in the stable branch, and this
commit only enabled it for solid images anyway.
This reverts commit 29e22cf38e.
CFLAGS are always appended to the end of gcc options when compiling
sources in autotools based projects. Configure tests should do the
same. Otherwise build fails on PPC when using CFLAGS="-O2 -mno-altivec"
for example. Similar problem affects ARM.
This can help to fix build problems with '-mthumb' gcc option in CFLAGS.
ARMv6 optimized code can't be compiled for thumb (because of its inline
assembly) and gets automatically disabled in configure. Reference
to it from NEON optimized code resulted in linking problems.
Every ARMv6 optimized fast path function also has a better NEON
counterpart, so there is no need to fallback to ARMv6. Shorter
delegate chain should additionally result in a bit better performance.
Autoconf's AC_PROG_CC sets the default CFLAGS to -O2 -g for
gcc and -g for every other compiler. This patch defaults
CFLAGS to the equivalent -O -g when we're using Sun Studio's cc
if the user or site admin hasn't already set CFLAGS.
Calling a static function wrapper around _mm_set_epi32() when not
using optimisation causes Sun Studio 12's cc to emit a spurious
floating point load which confuses the assembler. Using a macro wrapper
rather than a function steps around the problem.
Some versions of gcc (cs2009q1, 4.4.1) incorrectly reject
shift operand having value >= 8, claiming that it is out of
range. So inline assembly is used as a workaround.
This is one example of a compiler warning that was lost amit the build
noise.
The error here is that in a list of required conditions we used ';'
instead of '&&' with the result of continuing to use the fast-path
even if we had a wide mask.
Another error is that it was testing src, not mask as it should.
Inline assembly for handling <8 pixels width did not pass blitters-test.
Fortunately gcc has no problems compiling alternative implementation
which is using RVCT style intrinsics, so it can be used instead.
