Bug#594093: NEON pass failure on ffmpeg
siretart at tauware.de
Wed Aug 25 20:52:30 UTC 2010
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
On Wed, Aug 25, 2010 at 21:49:54 (CEST), Loïc Minier wrote:
> tags 594093 + patch confirmed
> 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?
Reinhard Tartler, KeyID 945348A4
More information about the pkg-multimedia-maintainers