Date: Mon, 12 Jul 2021 16:21:11 +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-qd6QofRNNd@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 #7 from Mikhail Teterin <mi@FreeBSD.org> --- > Yes, it's likely that the low number of registers I'm confused... Is not the number of registers the same on the same process= or -- whether it is running in 32- or 64-bit mode? Even if they are named/acce= ssed differently? > combined with more aggressive whole program optimization (in particular > inlining) will lead to this type of error. Frankly, if optimization results in errors, then it is not an optimization.= .. I don't blame anyone here for the failure, just debating terminology :-) If the otherwise valid code cannot be compiled (and/or linked), than it is a compiler (and/or linker) bug, is not it? Would it make sense to bring this = up with LLVM-project directly? > Yes, the benefit of fixing LTO for i386 is not worth the effort > it will require. 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 fastest computers. Perhaps, the option should carry a warning -- and be disabled by default on i386 -- but disabling it altogether seems too drastic. --=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-qd6QofRNNd>