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

[Johannes Dewender]

On 18/08/15 19:00, Johannes Dewender wrote:
> After checking and testing several things in my build environment
> (like starting a git bisect for gcc) I found the actual problem:
> -fstack-check was recently added in my build environment wrappers.
> This has nothing to do with gcc or kernel updates. Details below.
> 
> Effectively the failing (and minimized) line is:
> 
> gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -m32
> -fstack-check -Wall -I.
> -I. -march=i686 -mfpmath=sse -msse -std=gnu99
> -mpreferred-stack-boundary=5     -fPIC -fomit-frame-pointer
> -fno-tree-vectorize -c -o encoder/me.o encoder/me.c
> 
> On 12/08/15 04:20, Loren Merritt wrote:
>> On Mon, 10 Aug 2015, Johannes Dewender wrote:
>>> 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 
>>> constraints asm( ^ ./common/x86/util.h:193:5: error: 'asm' 
>>> operand has impossible constraints asm( ^ <builtin>: recipe for 
>>> target 'encoder/me.o' failed
>>>
>>> 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" helps in general.

Reported as a problem of gcc with -fstack-check at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265

--
JonnyJD