Bug#594093: NEON pass failure on ffmpeg

[Reinhard Tartler]

clone 594093 -1
reassign -1 src:ffmpeg
found -1 4:0.6-1
severity -1 important
retitle -1 FTBFS/armel: neon flavor requires 'ubfx' instruction
reassign 594093 mplayer
fixed 594093 2:1.0~rc4~try1.dsfg1-1
thanks

On Wed, Aug 25, 2010 at 21:49:54 (CEST), Loïc Minier wrote:

> tags 594093 + patch confirmed
> stop
>
> On Wed, Aug 25, 2010, Riku Voipio wrote:
>> Neither is it a toolchain bug nor do we have any NEON capable buildds.
>
>  It's ok, we don't need NEON capable buildds; this builds an alternate
>  set of ffmpeg libs for NEON (available via hwcaps).
>
>> And, btw ubfx is not even a NEON instruction. It is a ARMv7 instruction.
>
>  It actually seems to have been added in armv6t2+ (even in ARM mode).
>
>> The error is caused by debians toolchain default flags. you need to pass
>> -march=armv7-a for the debian-neon pass to get armv7 instructions accepted.
>
>  Now the NEON flavor implies armv7-a, so that's what we should turn on.
>
>
>  Riku, Reinhard, I only checked the gcc tests in the attached debdiff,
>  but didn't do a full build under Debian; would you mind trying it out?

I wouldn't mind, but I'd say, just commit it to our git branch, and I'll
try to build it on a porter machine in a sid chroot. I don't have any
other armel hardware available.

Please note that bug 594093 was a bug in mplayer. This particular issue
is actually another bug, so I'm cloning the bug with this message. So
your patch now needs some minor adjustment to debian/changelog.

>  Now one thing which this patch does NOT do is turn on armv7-a for the
>  NEON flavour if the toolchain defaults to armv6t2, so we might be
>  missing some small optimizations, but I didn't check how to test for
>  armv7-a versus armv6t2.  If ffmpeg relies on the some armv7-a-only
>  assembly, then we will quickly find out  :-)

Hm, why can't we unconditionally turn on armv7-a for the neon flavor?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4