Date: Tue, 13 Jul 2021 18:52:53 +0000 From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 257124] multimedia/ffmpeg: Fails to link: ld: error: inline assembly requires more registers than available at line [on i386 with LTO option] Message-ID: <bug-257124-12827-PC60gQmsYm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-257124-12827@https.bugs.freebsd.org/bugzilla/> References: <bug-257124-12827@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257124 --- Comment #13 from Dimitry Andric <dim@FreeBSD.org> --- (In reply to Mikhail Teterin from comment #12) > Why would a problem with inline assembly be manifested only in case of LT= O? LTO will enable global optimizations, such as inlining functions from diffe= rent translation units. If functions get inlined, the number of available regist= er slots can change, since there are now also other variables in the blocks of code being compiled. This can lead to a shortage of registers. In case of p= lain C or C++ code, the compiler knows how to rearrange some variables so they g= o to the stack instead, but for inline assembly there is no such choice, since t= he author specifies (or at least, can specify) precisely the registers to use.= In some situations this can leave the compiler with no registers 'left' to put other variables in, and typically it will error out then. This is indeed a cop-out strategy, and happens often with inline assembly. In the past, FFmpeg had many more cases of this, and also could make gcc ke= el over unless you used very specific optimization flags. Which is probably why FFmpeg started rewriting most of their assembly functions in nasm. > If it is not, then the bug is with ffmpeg -- something FreeBSD port-maint= ainers may be able to patch and/or raise with the upstream authors. The problem here is pinpointing the particular function that is causing the error. This is at the moment not possible, since the LTO stage doesn't seem= to keep enough information around to tell you which source file is involved. A= lso, since the line numbers it mentions are very large, I guess it is reporting something about an intermediate form (.ll or .bc file). So to be able to fi= nd the culprit(s), you'd have to somehow get to that intermediate form. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257124-12827-PC60gQmsYm>