From nobody Tue Jul 13 18:52:53 2021 X-Original-To: multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7D18C12438F7 for ; Tue, 13 Jul 2021 18:52:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GPVBY2xwlz4mwv for ; Tue, 13 Jul 2021 18:52:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4D1AD277E9 for ; Tue, 13 Jul 2021 18:52:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 16DIqrHZ011966 for ; Tue, 13 Jul 2021 18:52:53 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 16DIqrQ9011965 for multimedia@FreeBSD.org; Tue, 13 Jul 2021 18:52:53 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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] Date: Tue, 13 Jul 2021 18:52:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? maintainer-feedback? maintainer-feedback? maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257124 --- Comment #13 from Dimitry Andric --- (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.=