From nobody Mon Jul 12 16:53:43 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 E01598D0C27 for ; Mon, 12 Jul 2021 16:53:42 +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 4GNqbV5fTsz4m29 for ; Mon, 12 Jul 2021 16:53:42 +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 AB2E4129B5 for ; Mon, 12 Jul 2021 16:53:42 +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 16CGrgLK078606 for ; Mon, 12 Jul 2021 16:53:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 16CGrgmT078605 for multimedia@FreeBSD.org; Mon, 12 Jul 2021 16:53:42 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: Mon, 12 Jul 2021 16:53:43 +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: emaste@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 #9 from Ed Maste --- (In reply to Mikhail Teterin from comment #7) > I'm confused... Is not the number of registers the same on the same proce= ssor > -- whether it is running in 32- or 64-bit mode? Even if they are > named/accessed differently? amd64 has r8 through r15 in addition to the 64-bit versions of the common registers (rax, rbx etc.) > Frankly, if optimization results in errors, then it is not an optimizatio= n... > I don't blame anyone here for the failure, just debating terminology :-) Perhaps a non-functional optimization, but indeed it doesn't really matter. > If the otherwise valid code cannot be compiled (and/or linked), than it i= s a > compiler (and/or linker) bug, is not it? Would it make sense to bring thi= s up > with LLVM-project directly? Perhaps, although I suspect there will not be a lot of interest in investigating i386-specific optimization issues. > I would've thought, with multimedia every CPU-instruction counts... Even = if > the hardware is fast enough for regular realtime playback, when performing > format-conversions, CPU is almost always the bottleneck even on the faste= st > computers. Indeed, no disagreement that optimization is desirable on multimedia ports.= My point is just that there is likely to be little developer effort available (upstream or in FreeBSD) to work on these issues on i386. > Perhaps, the option should carry a warning -- and be disabled by default = on > i386 -- but disabling it altogether seems too drastic. I believe it is disabled by default on all archs right now? The option should be a warning, error, or not available on i386; I don't ha= ve strong feelings on which it is. --=20 You are receiving this mail because: You are the assignee for the bug.=