Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
Source: supercollider
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
Dear Maintainer,
The package fails to build from source on ppc64el because the usage of altivec
is not implemented for the architecture.
So, the workaround was to disable it for ppc64el.
While at it, Konstantinos also went ahead and fixed it for ppc32. He tested it
and it builds.
So there are 2 patches attached:
- ppc64el.debdiff which contains the disabling of altivec/vsx usage for ppc64el
- altivec-powerpc.debdiff which contains Konstantinos' modifications.
Thanks.
Fernando
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)
Kernel: Linux 3.16-trunk-powerpc64le (SMP w/32 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
diff -Nru supercollider-3.6.6~repack-2/debian/changelog supercollider-3.6.6~repack-2/debian/changelog
--- supercollider-3.6.6~repack-2/debian/changelog 2014-10-04 16:33:25.0 +
+++ supercollider-3.6.6~repack-2/debian/changelog 2014-10-24 12:23:30.0 +
@@ -1,3 +1,9 @@
+supercollider (1:3.6.6~repack-2-1ppc64el1) UNRELEASED; urgency=medium
+
+ * debian/rules: disabled altivec/vsx for ppc64el since the package does not support the usage for now
+
+ -- Fernando Seiti Furusato ferse...@br.ibm.com Fri, 24 Oct 2014 12:22:54 +
+
supercollider (1:3.6.6~repack-2-1) unstable; urgency=low
[ Dan Stowell ]
diff -Nru supercollider-3.6.6~repack-2/debian/rules supercollider-3.6.6~repack-2/debian/rules
--- supercollider-3.6.6~repack-2/debian/rules 2014-10-04 16:33:25.0 +
+++ supercollider-3.6.6~repack-2/debian/rules 2014-10-24 12:22:48.0 +
@@ -32,6 +32,11 @@
endif
endif
+ifeq ($(DEB_HOST_ARCH_CPU),ppc64el)
+ CFLAGS=-mno-altivec -mno-vsx
+ CXXFLAGS=-mno-altivec -mno-vsx
+endif
+
DEB_CMAKE_EXTRA_FLAGS = \
-DDSO_VISIBILITY=on \
-DSC_EL_BYTECOMPILE=off \
diff -Nru supercollider-3.6.6~repack-2/debian/changelog supercollider-3.6.6~repack-2/debian/changelog
--- supercollider-3.6.6~repack-2/debian/changelog 2014-10-04 16:33:25.0 +
+++ supercollider-3.6.6~repack-2/debian/changelog 2014-10-24 13:25:11.0 +
@@ -1,3 +1,10 @@
+supercollider (1:3.6.6~repack-2-1ppc64el1) UNRELEASED; urgency=medium
+
+ * debian/patches/altivec-powerpc.patch by Konstantinos Margaritis to enable altivec usage on powerpc.
+ * debian/rules: enable supernova and altivec for powerpc
+
+ -- Fernando Seiti Furusato ferse...@br.ibm.com Fri, 24 Oct 2014 13:19:58 +
+
supercollider (1:3.6.6~repack-2-1) unstable; urgency=low
[ Dan Stowell ]
diff -Nru supercollider-3.6.6~repack-2/debian/patches/altivec-powerpc.patch supercollider-3.6.6~repack-2/debian/patches/altivec-powerpc.patch
--- supercollider-3.6.6~repack-2/debian/patches/altivec-powerpc.patch 1970-01-01 00:00:00.0 +
+++ supercollider-3.6.6~repack-2/debian/patches/altivec-powerpc.patch 2014-10-24 13:21:51.0 +
@@ -0,0 +1,160 @@
+Description: This patch, by Konstantinos Margaritis, enables altivec usage on powerpc.
+Author: Konstantinos Margaritis mar...@freevec.org
+
+--- supercollider-3.6.6~repack-2.orig/external_libraries/nova-simd/vec_altivec.hpp
supercollider-3.6.6~repack-2/external_libraries/nova-simd/vec_altivec.hpp
+@@ -22,6 +22,8 @@
+
+ #include altivec.h
+ #undef bool
++#undef pixel
++#undef vector
+
+ #include detail/vec_math.hpp
+ #include vec_int_altivec.hpp
+@@ -39,13 +41,13 @@ namespace nova
+
+ template
+ struct vecfloat:
+-vec_basefloat, vector float, 4
++vec_basefloat, __vector float, 4
+ {
+-typedef vector float internal_vector_type;
++typedef __vector float internal_vector_type;
+ typedef float float_type;
+
+ private:
+-typedef vec_basefloat, vector float, 4 base;
++typedef vec_basefloat, __vector float, 4 base;
+
+ static internal_vector_type set_vector(float f0, float f1, float f2, float f3)
+ {
+@@ -231,7 +233,7 @@ private:
+ // adapted from http://developer.apple.com/hardwaredrivers/ve/algorithms.html
+
+ // Get the reciprocal estimate
+-vector float estimate = vec_re(arg);
++__vector float estimate = vec_re(arg);
+
+ // One round of Newton-Raphson refinement
+ return vec_madd(vec_nmsub(estimate, arg, gen_one()), estimate, estimate);
+@@ -284,7 +286,7 @@ public:
+
+ friend vec fast_reciprocal(const vec arg)
+ {
+-vector float estimate = vec_re(arg);
++__vector float estimate = vec_re(arg.data_);
+ return estimate;
+ }
+
+@@ -316,8 +318,8 @@ public:
+ vec operator op(vec const rhs) const \
+ { \
+ const internal_vector_type one = gen_one(); \
+-vector unsigned int mask = (vector unsigned int)opcode(data_, rhs.data_); \
+-return (internal_vector_type)vec_and(mask, (vector unsigned int)one); \
++__vector unsigned int mask =
Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
Hi Fernando, On Fri, Oct 24, 2014 at 10:41 AM, Fernando Seiti Furusato ferse...@br.ibm.com wrote: Source: supercollider Severity: normal Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el Dear Maintainer, The package fails to build from source on ppc64el because the usage of altivec is not implemented for the architecture. So, the workaround was to disable it for ppc64el. What does usage of altivec is not implemented? In supecollider, or in the compiler? In any case, perhaps the solution is to disable supernova in ppc64el as well instead of adding custom flags. While at it, Konstantinos also went ahead and fixed it for ppc32. He tested it and it builds. I'm very ignorant on altivec (or simd in general), but I try to understand the patch anyway. This patch seems to consist mostly of s/vector/__vector/. Why is that? I presume the upstream code works on apple platforms, is that an important difference? The second part is adding -mabi=altivec and -maltivec, which is unfortunately not possible, because that would contaminate the rest of the binaries with altivec code. AFAIK, debian still supports non-altivec machines. (supernova requires altivec, but for other machines we have scsynth). Perhaps a more correct patch would alter the logic in external_libraries/nova-simd/CMakeLists.txt to allow passing the required flags just to nova-simd. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
On Fri, Oct 24, 2014 at 11:19 AM, Felipe Sateler fsate...@debian.org wrote: Hi Fernando, On Fri, Oct 24, 2014 at 10:41 AM, Fernando Seiti Furusato ferse...@br.ibm.com wrote: Source: supercollider Severity: normal Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el Dear Maintainer, The package fails to build from source on ppc64el because the usage of altivec is not implemented for the architecture. So, the workaround was to disable it for ppc64el. What does usage of altivec is not implemented? In supecollider, or in the compiler? In any case, perhaps the solution is to disable supernova in ppc64el as well instead of adding custom flags. While at it, Konstantinos also went ahead and fixed it for ppc32. He tested it and it builds. I'm very ignorant on altivec (or simd in general), but I try to understand the patch anyway. This patch seems to consist mostly of s/vector/__vector/. Why is that? I presume the upstream code works on apple platforms, is that an important difference? The second part is adding -mabi=altivec and -maltivec, which is unfortunately not possible, because that would contaminate the rest of the binaries with altivec code. AFAIK, debian still supports non-altivec machines. (supernova requires altivec, but for other machines we have scsynth). Perhaps a more correct patch would alter the logic in external_libraries/nova-simd/CMakeLists.txt to allow passing the required flags just to nova-simd. Ehm, nova-simd is a header-only lib so that would not work :p. The correct path to add the logic would be to server/supernova/CMakeLists.txt -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
Hi Felipe. Thank you for your very quick response. What does usage of altivec is not implemented? In supecollider, or in the compiler? In supercollider. In any case, perhaps the solution is to disable supernova in ppc64el as well instead of adding custom flags. Simply disabling it for ppc64el did not do the work (completely), but you can test it if you want =) I think Konstantinos would be able to give you more accurate answers to your questions regarding altivec and simd in general. He knows a lot of that stuff. He is cc'ed (markos). Thanks!
Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
On Fri, 24 Oct 2014 12:39:18 -0200 ferse...@br.ibm.com wrote: In any case, perhaps the solution is to disable supernova in ppc64el as well instead of adding custom flags. Simply disabling it for ppc64el did not do the work (completely), but you can test it if you want =) The problem is that in ppc64el the default compile flags include -mvsx -which also implies altivec support, so just disabling supernova doesn't work, the compiler will still try to build the altivec stuff. Doing a simple : $ gcc -dM -E - /dev/null|grep ALTIVEC #define __ALTIVEC__ 1 #define __APPLE_ALTIVEC__ 1 on a ppc64le system will show why explicitly disabling it is needed. Evenmore so, even if it worked, much of the code assumes 32-bit pointers (eg. a table lookup in server/plugins/OscUGens.cpp:1541, so the code would break on ppc64le as it's 64-bit and little-endian. A lot of stuff would have to be fixed for that. So, unless/until it's fixed and tested for ppc64le, there isn't much one can do apart from disabling altivec completely. I think Konstantinos would be able to give you more accurate answers to your questions regarding altivec and simd in general. He knows a lot of that stuff. He is cc'ed (markos). Thanks, I just like the stuff :) Regards Konstantinos pgpDLhphuNmyR.pgp Description: PGP signature
Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
Hi Konstantinos, On Fri, Oct 24, 2014 at 12:03 PM, Konstantinos Margaritis mar...@freevec.org wrote: On Fri, 24 Oct 2014 12:39:18 -0200 ferse...@br.ibm.com wrote: In any case, perhaps the solution is to disable supernova in ppc64el as well instead of adding custom flags. Simply disabling it for ppc64el did not do the work (completely), but you can test it if you want =) The problem is that in ppc64el the default compile flags include -mvsx -which also implies altivec support, so just disabling supernova doesn't work, the compiler will still try to build the altivec stuff. Doing a simple : $ gcc -dM -E - /dev/null|grep ALTIVEC #define __ALTIVEC__ 1 #define __APPLE_ALTIVEC__ 1 on a ppc64le system will show why explicitly disabling it is needed. Evenmore so, even if it worked, much of the code assumes 32-bit pointers (eg. a table lookup in server/plugins/OscUGens.cpp:1541, so the code would break on ppc64le as it's 64-bit and little-endian. A lot of stuff would have to be fixed for that. So, unless/until it's fixed and tested for ppc64le, there isn't much one can do apart from disabling altivec completely. OK, that sounds a good enough reason :). I think Konstantinos would be able to give you more accurate answers to your questions regarding altivec and simd in general. He knows a lot of that stuff. He is cc'ed (markos). Thanks, I just like the stuff :) I had a few questions regarding the patch for enabling altivec on ppc32, I'll repeat them here: I'm very ignorant on altivec (or simd in general), but I try to understand the patch anyway. This patch seems to consist mostly of s/vector/__vector/. Why is that? I presume the upstream code works on apple platforms, is that an important difference? The second part is adding -mabi=altivec and -maltivec, which is unfortunately not possible, because that would contaminate the rest of the binaries with altivec code. AFAIK, debian still supports non-altivec machines. (supernova requires altivec, but for other machines we have scsynth). Perhaps a more correct patch would alter the logic in server/supernova/CMakeLists.txt to allow passing the required flags just to supernova I'm somewhat wary of adding this patch this close to the freeze... -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
On Fri, 24 Oct 2014 12:13:16 -0300 Felipe Sateler fsate...@debian.org wrote: I had a few questions regarding the patch for enabling altivec on ppc32, I'll repeat them here: I'm very ignorant on altivec (or simd in general), but I try to understand the patch anyway. This patch seems to consist mostly of s/vector/__vector/. Why is that? I presume the upstream code works on apple platforms, is that an important difference? The second part is adding -mabi=altivec and -maltivec, which is unfortunately not possible, because that would contaminate the rest of the binaries with altivec code. AFAIK, debian still supports non-altivec machines. (supernova requires altivec, but for other machines we have scsynth). Ok, the problem is that recently gcc enables also __APPLE_ALTIVEC__ as well, which defines the vector keyword. However, that proves just how bad of a choice this keyword was, as it collides with both STL and Boost -if you leave it out you'll eventually have a failed compile at: /usr/include/boost/mpl/vector.hpp:36:73: fatal error: boost/mpl/__attribute__((altivec(vector__)))/__attribute__((altivec (vector__)))20.hpp: No such file or directory # include BOOST_PP_STRINGIZE(boost/mpl/vector/AUX778076_VECTOR_HEADER) (see how vector is replaced with _attribute__((altivec(vector__))) That has been a problem ever since, and the only solution is to #undef vector and usually typedef new types, that map to eg. __vector float, etc. Perhaps a more correct patch would alter the logic in server/supernova/CMakeLists.txt to allow passing the required flags just to supernova That alone won't do for the reasons above. I'm somewhat wary of adding this patch this close to the freeze... Sure, that could come after the freeze, I guess the most important one would be to just disable altivec for now for ppc64le only, both powerpc/ppc64 have altivec by default so that won't break the existing packages. And you're right, that powerpc is supposed to support non-altivec systems as well. I was thinking that maybe it would be a good idea to build a separate -altivec package if there is interest -and not too much trouble :) Regards Konstantinos pgpobV83IUAOy.pgp Description: PGP signature
Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
On Fri, Oct 24, 2014 at 12:27 PM, Konstantinos Margaritis mar...@freevec.org wrote: On Fri, 24 Oct 2014 12:13:16 -0300 Felipe Sateler fsate...@debian.org wrote: I had a few questions regarding the patch for enabling altivec on ppc32, I'll repeat them here: I'm very ignorant on altivec (or simd in general), but I try to understand the patch anyway. This patch seems to consist mostly of s/vector/__vector/. Why is that? I presume the upstream code works on apple platforms, is that an important difference? The second part is adding -mabi=altivec and -maltivec, which is unfortunately not possible, because that would contaminate the rest of the binaries with altivec code. AFAIK, debian still supports non-altivec machines. (supernova requires altivec, but for other machines we have scsynth). Ok, the problem is that recently gcc enables also __APPLE_ALTIVEC__ as well, which defines the vector keyword. However, that proves just how bad of a choice this keyword was, as it collides with both STL and Boost -if you leave it out you'll eventually have a failed compile at: /usr/include/boost/mpl/vector.hpp:36:73: fatal error: boost/mpl/__attribute__((altivec(vector__)))/__attribute__((altivec (vector__)))20.hpp: No such file or directory # include BOOST_PP_STRINGIZE(boost/mpl/vector/AUX778076_VECTOR_HEADER) (see how vector is replaced with _attribute__((altivec(vector__))) Ah, OK, makes sense. Indeed, that is a bad word choice. But I find it weird that cpp would try to replace vector inside an include statement. Perhaps this is one reason it works in apple platforms but not for us. That has been a problem ever since, and the only solution is to #undef vector and usually typedef new types, that map to eg. __vector float, etc. Perhaps a more correct patch would alter the logic in server/supernova/CMakeLists.txt to allow passing the required flags just to supernova That alone won't do for the reasons above. Hmm, it seems I was unclear. With this comment I was referring to adding -maltivec and -mabi=altivec wholesale to supercollider (in d/rules), not the vector attribute replacing code. I'm somewhat wary of adding this patch this close to the freeze... Sure, that could come after the freeze, I guess the most important one would be to just disable altivec for now for ppc64le only, both powerpc/ppc64 have altivec by default so that won't break the existing packages. OK, will try to upload this later today (no promises though). FWIW, I wouldn't mind an NMU for this change, although I'd try changing the explicit setting with DEB_*FLAGS_APPEND, so that we still have the optimization and hardening flags (I believe cdbs recently fixed this usage). And you're right, that powerpc is supposed to support non-altivec systems as well. I was thinking that maybe it would be a good idea to build a separate -altivec package if there is interest -and not too much trouble :) That would be an option, but it would require some work and I don't have any ppc hardware ;). Possibly it could make sense to optimize the server and unit generators only. Hmm, if a solution can be found using ld paths (like libav), maybe this can also be used to enable sse in the i386 version... I'd have to investigate further. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
Hi all - Felipe has covered most of the reviewing already. Just noting here that I have proposed to send the nova-simd part of this patch upstream: https://github.com/timblechmann/nova-simd/pull/2, plus: 2014-10-24 16:55 GMT+01:00 Felipe Sateler fsate...@debian.org: On Fri, Oct 24, 2014 at 12:27 PM, Konstantinos Margaritis Perhaps a more correct patch would alter the logic in server/supernova/CMakeLists.txt to allow passing the required flags just to supernova That alone won't do for the reasons above. Hmm, it seems I was unclear. With this comment I was referring to adding -maltivec and -mabi=altivec wholesale to supercollider (in d/rules), not the vector attribute replacing code. I am thinking the same as Felipe here. Best Dan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
