[x264-devel] [bug] asm operand has impossible constraints (x86)
Loren Merritt
lorenm at u.washington.edu
Wed Aug 12 04:20:05 CEST 2015
On Mon, 10 Aug 2015, Johannes Dewender wrote:
> when compiling the 32 bit package of libx264 (on a 64 bit machine) I
> get (current git master):
>
> yasm -I. -I. -DARCH_X86_64=0 -I./common/x86/ -f elf32 -Worphan-labels
> -DSTACK_ALIGNMENT=32 -DPIC -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o
> common/x86/pixel-32.o common/x86/pixel-32.asm
Btw, this isn't the command that produced the error. You're probably
using multithreaded make, which means that compilation messages aren't
necessarily displayed in order.
> In file included from ./common/common.h:1014:0,
> from encoder/me.c:28:
> encoder/me.c: In function 'x264_me_search_ref':
> ./common/x86/util.h:130:5: error: 'asm' operand has impossible constrain
> ts
> asm(
> ^
> ./common/x86/util.h:193:5: error: 'asm' operand has impossible constrain
> ts
> asm(
> ^
> <builtin>: recipe for target 'encoder/me.o' failed
>
> The problem appears in building the Arch Linux 32 bit package
> "lib32-libx264":
> https://aur.archlinux.org/packages/lib32-libx264/
>
> Built on a 64 bit machine with:
> ./configure --prefix=/usr --libdir=/usr/lib32 --host=i686-linux-gnu \
> --enable-shared \
> --enable-pic
> make
>
> The 64 bit build runs fine on the same machine, but that isn't using
> files out of common/x86/, I guess.
The 64bit build does use the same code, it's just that it has more
registers available, so the same constraint is easier to solve.
> Arch Linux always ships the newest (stable) versions of all software
> so the problem is probably related to a new version of important build
> tools.
> However, I couldn't pinpoint the exact update generating the problem.
>
> The complete build log is in
> https://gist.github.com/JonnyJD/6aa13527e8b98055a1d0
>
> This is the list of packages and versions updated (breaking the build):
> https://gist.github.com/JonnyJD/22b65e6101d0e971ee4d
> (It worked before the Arch Linux update)
>
> I can't tell if that is a bug in the build tools or in x264 and I
> don't have pratical experience in assembler.
It's a gcc bug.
More precisely: Allocating registers to inline-asm blocks is an NP Hard
optimization problem. N is sufficiently small that "NP Hard" doesn't imply
"intractable", but it still requires a certain amount of intelligence on
the compiler's part. That's true of ordinary C code too. The difference is
that in C code, a suboptimal compilation is just a bit slower than it
could have been, whereas in inline-asm it can result in the compiler
incorrectly throwing an "impossible constraints" error.
I have verified that the constraints are not in fact impossible. But if
you want to make it easier on the compiler, you could disable pic.
--Loren Merritt
More information about the x264-devel
mailing list