Re: [Pixman] anongit.freedesktop.org
On 7/13/20 8:25 AM, John Emmas wrote:
On 13/07/2020 15:57, Alan Coopersmith wrote:
Which URL did you try? g...@gitlab.freedesktop.org:cairo/cairo.git or
https://gitlab.freedesktop.org/cairo/cairo.git ?
I tried the one you gave me:- https://gitlab.freedesktop.org/cairo/cairo - but
I've just added ".git" on the end and it's working now!
Sorry - I tried to be clear that the URL I gave was something to go to in your
web browser and it in turn would list the actual URL's to use when you clicked
on the "clone" button there.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] anongit.freedesktop.org
On 7/13/20 5:54 AM, John Emmas wrote:
This might be a temporary issue but I can't seem to do a git pull any more from
either pixman or cairo. In both cases, TortoiseGit seems to fail at the
following stage:-
Connecting to anongit.freedesktop.org
Is this just something temporary or have the repos moved somewhere else?
Thanks,
You should be able to use the URL's shown under the "clone" button on
https://gitlab.freedesktop.org/pixman/pixman
https://gitlab.freedesktop.org/cairo/cairo
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] 'AV_386_SSSE3' undeclared when building pixman0.34.1 with Solaris10-u2
On 04/ 4/16 06:51 PM, Yike Zhang wrote:
Hi Alan,
Thanks so much for your promptly response. Based on your valuable input, I find
the following RN
http://www.c0t0d0s0.org/archives/4974-Whats-new-in-Solaris-10-1008-also-known-as-Update-6.html
and
x86: Kernel Support for Intel SSSE3, SSE4.1, SSE4.2, and AMD SSE4A
Am I finding the correct path?
It is a little bit embarrassing to say that the build system we kept for
Solaris is still based on 10-u2, company-wide unfortunately. So to adding a
fresh new 10-u6 build env might bring much effort.
So may I know if any other simpler solution if we have to stick to 10-u2 (CC
flag?)
I've not tried it, but I can't see any reason why "cc -DAV_386_SSSE3=0x40"
wouldn't work for that particular bit of code. If you need to actually call
other functions added in that support, you'd probably need something more
though.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] 'AV_386_SSSE3' undeclared when building pixman0.34.1 with Solaris10-u2
On 04/ 4/16 05:56 PM, Yike Zhang wrote: Hello there, May I know if anyone hit the similar issue and guide me how to work around it? Double check and found that AV_386_SSSE3 is not defined in the solaris10-u2 header file, According to our bug tracker, it was added in Solaris 10 Update 6 (Solaris 10 8/08). Can you not update to an OS that's only 8 years old instead of sticking to the 10 year old release? -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ Pixman mailing list Pixman@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pixman
[Pixman] CVE-2014-9766 assigned for integer overflow in pixman < 0.32.6
See attached emails for discussion from the oss-security mailing list. The quoted patch was applied to the master branch of the pixman git repo as: https://cgit.freedesktop.org/pixman/commit/?id=857e40f3d2bc2cfb714913e0cd7e6184cf69aca3 and to the pixman-0.32 branch as: https://cgit.freedesktop.org/pixman/commit/?id=50d7b5fa8ea2ae119f35c20ab0dd0413d5103cbb It is included in pixman 0.32.6 and later releases. -- -Alan Coopersmith- alan.coopersm...@oracle.com X.Org Security Response Team - xorg-secur...@lists.x.org --- Begin Message --- Hi, There is an (old) integer overflow in create_bits in the pixman library. Patch and details are available here: https://web.archive.org/web/20141227044037/http://lists.freedesktop.org/archives/pixman/2014-April/003244.html Please, assign a CVE to this issue. Regards, Gustavo. --- End Message --- --- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > There is an (old) integer overflow in create_bits in the pixman library. > https://web.archive.org/web/20141227044037/http://lists.freedesktop.org/archives/pixman/2014-April/003244.html > https://bugzilla.redhat.com/show_bug.cgi?id=972647 Use CVE-2014-9766. 003244.html has this linked discussion, which is not part of the definition of the CVE-2014-9766 ID: https://bugs.freedesktop.org/show_bug.cgi?id=69014 https://lists.freedesktop.org/archives/pixman/2013-September/002915.html https://bugs.freedesktop.org/attachment.cgi?id=85448 - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWzdF9AAoJEL54rhJi8gl5BlIQALu4bdEqoZE/fTlEJSOXQj2s 4ZWZYb120yISoKjK3kHfGfDtJMi/JeEkXkMTkQjulreq/wYHBHnBeGBxJBw1laae 7JtS8ULmmR8+WBd/X1ZTmfZ4VhwYcJn0utXaN7su0QK6a3YfG7DasL1Paywf1z6E eDMXRJgDE2ml3sHTyodAFvfHbYcpMK7EQao7HJA7o49Vr0NcNJVmW+pYqu0Hq0N+ j+WilQ4eYiw1I6GgXxiQQlOKFKdnKmflOJXEJp8qMr8iokP9OX5ewN7d/007uZNA 3gCzt7tpsBACzjx/01exaUdKOFDxHB+l1vglHiC2aFlLN46U637DiJpL0OMN+soF AYV0vRGIfxKZOSpSk4398gbX10kv2ew9uOG9UbzkRqneZmdXWqZXPMJ2eH/H2doV hdNpt7B+6mgKQpYZZI3OrMilj5ZXfGNc4R2RSt0ViTfabn6D5gYynTrE+Jh37mgZ phfBvReUZIP108iAgdxOOi2pLRuUYU4ayeDmQkhNQPaokoAyxkOdy7eorJC8yRD5 HJ/sL6zKuLJkfaBrsr5zbOe3DD2VqtFQ/mGp0kgAjcKpgdvFyR5IG3n0JiBS+p8c Q/CC7tb/gFLJYR9fReUmeJJ4xIY6dzUaXRaxocWuSts8sOgwwyUEiIdDdEK3vxu2 Gew7VEXZN1T9nBktQhgY =IpY0 -END PGP SIGNATURE- --- End Message --- ___ Pixman mailing list Pixman@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [PATCH] Resolve implementation-defined behaviour for division rounded to -infinity
On 08/26/15 06:21 AM, Ben Avison wrote: No, but I'd have thought it was bad practice to assume C99 behaviour when compiling C89. Perhaps the AC_PROG_CC_C99 macro should be added to the pixman/configure.ac to avoid that then. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [PATCH 00/10] Cleanups to CPU detection
On 06/29/12 01:44 PM, Søren Sandmann Pedersen wrote: I was looking at making use of some of the newer x86 SIMD instruction sets and realized that (a) we don't ever call cpuid on x86-64, we just assume that MMX and SSE2 are present, I thought the amd64 ABI guaranteed MMX SSE2 would always be present - is that not the case? -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [PATCH 00/10] Cleanups to CPU detection
On 06/29/12 02:36 PM, sandm...@cs.au.dk wrote: Alan Coopersmith alan.coopersm...@oracle.com writes: On 06/29/12 01:44 PM, Søren Sandmann Pedersen wrote: I was looking at making use of some of the newer x86 SIMD instruction sets and realized that (a) we don't ever call cpuid on x86-64, we just assume that MMX and SSE2 are present, I thought the amd64 ABI guaranteed MMX SSE2 would always be present - is that not the case? The problem is not so much that assumption, but the fact that for newer instruction sets such as SSSE3 and AVX, we do need to call cpuid even on x86-64. So the main point is just preparing the code for that. But in fact, I'm pretty sure I saw in some Knight's Corner (which is x86-64) manual, linked from here: http://software.intel.com/en-us/forums/showthread.php?t=105443 that it doesn't support SSE and MMX, only the new 512 bit vector instructions. I can't find it now though, so maybe I was hallucinating. They do say that that chip is not binary compatible with other x86 chips, and in the instruction manual chapter 4.8, they say that the state of mm0 through mm7 and xmm0 through xmm7 is NA. Ah, okay. It should't hurt, and if it may be useful going forward, then go for it. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [PATCH 08/10] Cleanups and simplifications in x86 CPU feature detection
On 06/29/12 01:44 PM, Søren Sandmann Pedersen wrote:
typedef enum
{
-NO_FEATURES = 0,
-MMX = 0x1,
-MMX_EXTENSIONS = 0x2,
-SSE = 0x6,
-SSE2 = 0x8,
-CMOV = 0x10
+X86_MMX = (1 0),
+X86_MMX_EXTENSIONS = (1 1),
+X86_SSE = (1 2) | X86_MMX_EXTENSIONS,
+X86_SSE2 = (1 3),
+X86_CMOV = (1 4)
} cpu_features_t;
+#ifdef HAVE_GETISAX
-static unsigned int
+#include sys/auxv.h
+
+static cpu_features_t
detect_cpu_features (void)
{
-unsigned int features = 0;
-unsigned int result = 0;
-
-#ifdef HAVE_GETISAX
+cpu_features_t features;
+
if (getisax (result, 1))
{
if (result AV_386_CMOV)
@@ -69,15 +64,47 @@ detect_cpu_features (void)
if (result AV_386_SSE2)
features |= SSE2;
}
+
Don't you need to update the feature flags set in the getisax code to match
the renaming you did to cpu_features_t ?
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [PATCH 1/8] Add doubly linked lists
On 05/30/12 04:41 PM, Søren Sandmann wrote: +# define OFFSET_OF(type, member) \ +((unsigned long)type *)0)-member)) +#endif Why not use the offsetof(type, member) macro that C89 guarantees to be provided by #include stddef.h instead of coding up your own? Presumably GCC's __builtin_offsetof is designed to mimic the standard C offsetof. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
[Pixman] [PATCH] Just use xmmintrin.h when building with Solaris Studio compilers
Since the Solaris Studio compilers don't have a mode where MMX instructions are available and SSE instructions are not, we can just use the xmmintrin.h header directly. Fixes build failure due to Studio not supporting the __gnu_inline__ or __artificial__ attributes. Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- pixman/pixman-mmx.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/pixman/pixman-mmx.c b/pixman/pixman-mmx.c index bd44f63..fe31b08 100644 --- a/pixman/pixman-mmx.c +++ b/pixman/pixman-mmx.c @@ -57,6 +57,9 @@ _mm_empty (void) #endif #ifdef USE_X86_MMX +# ifdef __SUNPRO_C +# include xmmintrin.h +# else /* We have to compile with -msse to use xmmintrin.h, but that causes SSE * instructions to be generated that we don't want. Just duplicate the * functions we want to use. */ @@ -82,6 +85,7 @@ _mm_shuffle_pi16 (__m64 __A, int8_t const __N) return ret; } +# endif #endif #define _MM_SHUFFLE(fp3,fp2,fp1,fp0) \ -- 1.7.3.2 ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
[Pixman] [PATCH] Make mmx code compatible with Solaris Studio 12.3 compilers
Rearranged some of the existing gcc Intel compiler checks to allow
easier sharing of common cases among the compilers.
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
pixman/pixman-mmx.c | 57 ++-
1 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/pixman/pixman-mmx.c b/pixman/pixman-mmx.c
index 5da1f66..937ce8f 100644
--- a/pixman/pixman-mmx.c
+++ b/pixman/pixman-mmx.c
@@ -77,17 +77,38 @@ _mm_empty (void)
/* --- MMX primitives - */
-#ifdef __GNUC__
+/* If __m64 is defined as a struct or union, then define M64_MEMBER to be
+ * the name of the member used to access the data.
+ * If __m64 requires using mm_cvt* intrinsics functions to convert between
+ * uint64_t and __m64 values, then define USE_CVT_INTRINSICS.
+ * If __m64 and uint64_t values can just be cast to each other directly,
+ * then define USE_M64_CASTS.
+ */
+#ifdef _MSC_VER
+# define M64_MEMBER m64_u64
+#elif defined(__ICC)
+# define USE_CVT_INTRINSICS
+#elif defined(__GNUC__)
+# define USE_M64_CASTS
+#elif defined(__SUNPRO_C)
+# if (__SUNPRO_C = 0x5120) !defined(__NOVECTORSIZE__)
+/* Solaris Studio 12.3 (Sun C 5.12) introduces __attribute__(__vector_size__)
+ * support, and defaults to using it to define __m64, unless __NOVECTORSIZE__
+ * is defined. If it is used, then the mm_cvt* intrinsics must be used.
+ */
+# define USE_CVT_INTRINSICS
+# else
+/* For Studio 12.2 or older, or when __attribute__(__vector_size__) is
+ * disabled, __m64 is defined as a struct containing unsigned long long l_.
+ */
+# define M64_MEMBER l_
+# endif
+#endif
+
+#if defined(USE_M64_CASTS) || defined(USE_CVT_INTRINSICS)
typedef uint64_t mmxdatafield;
#else
typedef __m64 mmxdatafield;
-/* If __m64 is defined as a struct or union, define M64_MEMBER to be the
- name of the member used to access the data */
-# ifdef _MSC_VER
-# define M64_MEMBER m64_u64
-# elif defined(__SUNPRO_C)
-# define M64_MEMBER l_
-# endif
#endif
typedef struct
@@ -113,7 +134,7 @@ typedef struct
# define MMXDATA_INIT(field, val) { val ## UI64 }
#elif defined(M64_MEMBER) /* __m64 is a struct, not an integral type */
# define MMXDATA_INIT(field, val) field = { val ## ULL }
-#else /* __m64 is an integral type */
+#else /* mmxdatafield is an integral type */
# define MMXDATA_INIT(field, val) field = val ## ULL
#endif
@@ -136,12 +157,10 @@ static const mmx_data_t c =
MMXDATA_INIT (.mmx_, 0x),
};
-#ifdef __GNUC__
-#ifdef __ICC
-#define MC(x) to_m64 (c.mmx_ ## x)
-#else
-#define MC(x) ((__m64)c.mmx_ ## x)
-#endif
+#ifdef USE_CVT_INTRINSICS
+#define MC(x) to_m64 (c.mmx_ ## x)
+#elif defined(USE_M64_CASTS)
+#define MC(x) ((__m64)c.mmx_ ## x)
#else
#define MC(x) c.mmx_ ## x
#endif
@@ -149,14 +168,14 @@ static const mmx_data_t c =
static force_inline __m64
to_m64 (uint64_t x)
{
-#ifdef __ICC
+#ifdef USE_CVT_INTRINSICS
return _mm_cvtsi64_m64 (x);
#elif defined M64_MEMBER/* __m64 is a struct, not an integral type */
__m64 res;
res.M64_MEMBER = x;
return res;
-#else /* __m64 is an integral type */
+#else /* USE_M64_CASTS */
return (__m64)x;
#endif
}
@@ -164,12 +183,12 @@ to_m64 (uint64_t x)
static force_inline uint64_t
to_uint64 (__m64 x)
{
-#ifdef __ICC
+#ifdef USE_CVT_INTRINSICS
return _mm_cvtm64_si64 (x);
#elif defined M64_MEMBER/* __m64 is a struct, not an integral type */
uint64_t res = x.M64_MEMBER;
return res;
-#else /* __m64 is an integral type */
+#else /* USE_M64_CASTS */
return (uint64_t)x;
#endif
}
--
1.7.3.2
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
