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

[Felipe Sateler]

On Fri, Oct 24, 2014 at 12:27 PM, Konstantinos Margaritis
<markos at freevec.org> wrote:
> 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__)))

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