Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic

[Konstantinos Margaritis]

On Fri, 24 Oct 2014 12:13:16 -0300
Felipe Sateler <fsateler at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20141024/46d63400/attachment.sig>