Since the last time these makefiles were last updated some new source
files have been added and one renamed. In addition, a "clean" rule
needed to be added to the pixman makefile. And the "clean" rule in the
main cairo makefile wasn't working properly for me.
The warning happens all the place when the code converts from ullong to __m64.
The way the conversion is done is a C idiom: 1) get a pointer to the value, 2)
convert it to the suitable pointer type for the target, 3) dereference it.
That is "*(__m64*)(&m)" in this case. This is necessarily (as opposed to just
casting to target type) because the two types may not be "compatible" from the
compiler's point of view. Example of types that are not compatbile is structs
vs anything.
The "dereferencing type-punned pointer will break strict-aliasing rules" from
gcc exactly means: "some code may be assuming that pointers with different
types do not compare equal (or otherwise share the same target object). If
you case a pointer to a different type and dereference it, it may happen
here." However, in our usecase, it's clear that the compiler cannot make any
false assumptions. So we just go ahead and hide it by using a middle cast to
"void *". Since the compiler does not many any aliasing assumptions about
generic pointers, it will not warn either. (Though the problems if any, will
still occure. So this is not an ideal solution to this problem and should be
used very carefully, to no hide useful warnings for when things go loose on
some weird architecture.)
Another solution would have been to use gcc's "may_alias" function attribute,
but trying to define a may_alias version of __m64 hit a bug in gcc. That is,
try replacing "__m64" with "m64" and define:
typedef __m64 m64 __attribute__((may_alias));
and see it fail to compile. This seems to be because of the special vector
type that __m64 has.
The implementation of _FbOnes in iccolor.c would not work on 64-bit
longs correctly. Fortunately, it's only used on integers, so make it
explicit in the declaration.
Use an inline function for the gcc builtin implementation to make sure
that it's never used with arguments of incorrect size.
There is no __INT_MIN__ in gcc 4.1.1, but it's not an issue now because
the argument is 32-bit.
Signed-off-by: Pavel Roskin <proski@gnu.org>
The patch implements a few more operations with special cases MMX
code. On my laptop, applying the patch to cairo speeds up the
benchmark (rendering page 14 of a PDF file[*]) from 20.9 seconds
to 14.9 seconds, which is an improvement of 28.6%.
[*] http://people.redhat.com/jakub/prelink.pdf
This also benefits the recently added unaligned_clip perf case:
image-rgb unaligned_clip-100 0.11 -> 0.06: 1.65x speedup
▋
image-rgba unaligned_clip-100 0.11 -> 0.06: 1.64x speedup
▋
We update the test suite reference images where needed, (pdiff
avoided a few, but most still needed updating). We take advantage
of the need for new reference images to shrink some of the giant
tests to speed them up a bit.
This optimization provides a 2x improvement in linear gradient
generation performance (numbers from an x86 laptop):
image-rgb paint_linear_rgba_source-512 26.13 -> 11.13: 2.35x speedup
█▍
image-rgb paint_linear_rgba_source-256 6.47 -> 2.76: 2.34x speedup
█▍
image-rgba paint_linear_rgb_over-256 6.51 -> 2.86: 2.28x speedup
█▎
image-rgb paint_linear_rgba_over-512 28.62 -> 13.70: 2.09x speedup
█▏
image-rgba fill_linear_rgb_over-256 3.24 -> 1.94: 1.66x speedup
▋
image-rgb stroke_linear_rgba_over-256 5.68 -> 4.10: 1.39x speedup
▍
This was thanks to a report from crucible (run #2113) since it tested
with older versions of gcc (3.3.6) than most of the cairo developers
use, (so we had been getting the _FbOnes macro not the function).
There was a bad mix of LIBCMT (the static runtime lib) and MSVCRT (the dynamic
one) before, because LIBCMT is the default. This specifies /MD everywhere.
This patch adds a bunch of makefiles for building cairo with Visual C++.
gnu make is still required, and make must be run from a command prompt
that has the Visual C++ paths set up, as well as has the cygwin environment
in the path. Run 'make -f Makefile.win32'.
In order for SLIM's PLT indirection avoidance to work, everything in
the library that makes internal function calls needs to see the
relevant slim_hidden_proto() macro in addition to the function's
prototype. However, external headers used by clients of the shared
library should not use the SLIM macros at all.
Pixman is a rather odd case -- it's mostly independent from cairo, so
it has it's own public interface, but it's built as a part of cairo
instead of its own shared library. This means that cairo would need to
see all of pixman's slim_hidden_proto() macros in order to function
and it doesn't currently, which results in a link failure on AMD64
systems and on i386 systems (I think, I haven't actually verified
this) it produces a shared object that isn't actally sharable.
I have no idea why exactly the link failure only showed up as a result
of commit e06246b9b1. I think it has
something to do with the pixman functions no longer having PLT entries
at all, but the exact interaction isn't clear to me.
However, all of these pixman functions aren't part of the cairo ABI
(which is why they were marked pixman_private in the first place),
which means that the SLIMification of pixman is largely pointless --
they aren't externally visible, so they don't need PLT entries at
all. Furthermore, while pixman may eventually be shared among cairo
and X, I'm told that this sharing will be source-level only, which
means it won't ever be an actual shared library and thus won't ever
need SLIM at all.
So, I just removed all use of SLIM in pixman (leaving behind
slim_internal.h for the future edification of anyone who cares).This
fixes the AMD64 link failure and passes the check-plt & check-def
parts of make check.
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
This doesn't actually fix the AMD64 link failure, but it does make the
foo/EXT_foo/INT_foo symbol names generated by the slim_hidden_proto()
and slim_hidden_def() macros consistent in the face of the meddling of
pixman-remap.h.
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
This approach to fixing the bug is valid since there is code in pixman
for rendering to BGR images, (which is why cairo 1.0 worked with BGR X
servers for example). But, since we don't want to advertise additional
image formats we implement this through a new cairo_internal_format_t.
This is rather fragile since we don't want to leak any internal formats
nor do we ever want an internal format to be used somewhere a real
format is expected, (and trigger a CAIRO_FORMAT_VALID assertion failure).
More comments than code are added here to help compensate for the
fragility and to give some guidance in fixing this mess in a better way
in the future.
We were doing something more complicated originally, and that was because
pixman.h was an installed public header file at one time. But that hasn't
been the case for quite a long time.
This patch was produced by running git-stripspace on all *.[ch] files
within cairo. Note that this script would have also created all the changes
from the previous commits to remove trailing whitespace.
This patch was produced with the following (GNU) sed script:
sed -i -r -e 's/[ \t]+$//'
run on all *.[ch] files within cairo.
Note that the above script would have also created all the changes
from the previous commits to remove trailing whitespace.
This patch was produced with the following (GNU) sed script:
sed -i -r -e '/^[ \t]*\/?\*/ s/[ \t]+$//'
run on all *.[ch] files within cairo, (though I manually excluded
src/cairo-atsui-font.c which has a code line that appears as a comment
to this script).
