[x264-devel] [bug] asm operand has impossible constraints (x86)

[Johannes Dewender]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/08/15 04:20, Loren Merritt wrote:
> 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.

Yes, that was only a quick idea to also give that line.
Disabling multithreaded make and removing additional
optimization/debug CFLAGS on my system this is the problematic line:

gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -m32 -Wall -I.
- -I. -march=i686 -mfpmath=sse -msse -std=gnu99
- -mpreferred-stack-boundary=5     -fomit-frame-pointer
- -fno-tree-vectorize  -c -o encoder/me.o encoder/me.c


>> 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.

Removing "--enable-pic" doesn't seem to help.

Arch Linux updated to gcc 5.2.0 recently, which is probably triggering
the problem.
https://gcc.gnu.org/gcc-5/changes.html
Lists "register allocation improvements".

However, the exact problem seems to be complex.
I tried the same build for the same distribution with the same
versions (including gcc 5.2.0) and FLAGS on a different machine and it
works.
Possibly a variation in the features of the system/CPU leads to
different code to be compiled and that triggers the problem or not.
I can't even get a minimum working example just using util.h (where
the error is given in) and 1-2 header files.
Probably because of all that inlining and such.

I currently have a "minimum" working example with 24 files and 404
Kilobyte and something that only seems to happen for certain CPUs.
The "broken" CPU is Intel Core i5 750 and working an i7 4600U.
I don't even know what the major difference is between these in this
regard. Well, the i5-750 is quite old and i7-4600U is quite new, but
they are both x86_64 CPUs that shouldn't make a difference when
compiling a generic x86 target.
Nothing really that makes a good bug report for gcc.
I can try to trim a tiny bit more of the working example and a
regression test. Although that probably takes ages for things as big
as gcc. (although less than for wine, which I managed before)

- --
JonnyJD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlXR44cACgkQaDBIOMxoZgeshwCaAimTMCBOpPKcbmFPB3+Etxfi
TxkAnRmhTcD3GmvIHRxR1dW8NTHDWOru
=S1Uh
-----END PGP SIGNATURE-----