On Fri, Jul 14, 2023 at 10:47 AM James Almer <jamr...@gmail.com> wrote: > > On 7/14/2023 1:49 PM, James Zern wrote: > > On Fri, Jul 14, 2023 at 5:37 AM James Almer <jamr...@gmail.com> wrote: > >> > >> On 7/14/2023 7:12 AM, Nicolas George wrote: > >>> James Almer (12023-07-13): > >>>> Curious that they pull git snapshots of this package for Debian testing. > >>>> For > >>>> others they seem to stick to tagged releases. > >>> > >>> I do not understand what you mean. *I* pulled my work tree to the head > >>> to fix a bug in the OpenGL device, it was the first time since Testing > >>> was unfrozen, and I noticed it fails to build. > >> > >> I mean that for pretty much every other package, Debian Unstable/Testing > >> sticks to tagged releases. But for this one they pull git snapshots > >> every other day. > >> If they did what the do for every other package, they'd have waited > >> until binutils 2.41 was tagged. > >> > >>> > >>>> This definitely sounds like a regression in binutils, so other than > >>>> reporting it upstream, i don't see much more we can do. > >>> > >>> It could also be a case where we have been using a slightly invalid and > >>> unsupported construct. My knowledge of assembly stopped at the 386, so I > >>> cannot tell which one it is, but I think the likeliness are balanced. > >>> Somebody more skilled will look at it, hopefully. > >> > >> I'm not an expert, but i learned a bit of inline asm when i was porting > >> some of it to nasm syntax. > >> > >> > static inline uint32_t NEG_USR32(uint32_t a, int8_t s){ > >> > __asm__ ("shrl %1, %0\n\t" > >> > >> Nothing to say here, it's just shr. > >> > >> > : "+r" (a) > >> > >> r means the first operand, %0, needs to be a register. The + means it's > >> both input and output, meaning the value at the time of entering this > >> block is not to be ignored/discarded, and the value at the time of > >> leaving the block needs to be in a. > >> > >> > : "ic" ((uint8_t)(-s)) > >> > >> i means this operand can be an immediate value, and c means it can also > >> be the rcx/ecx/cx/cl register. > >> > >> According to https://www.felixcloutier.com/x86/sal:sar:shl:shr this is > >> indeed correct. > >> > > > > I think it wants I/J to constrain the size of the immediate. > > https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html > > Are these arguments something added recently to GCC? Assuming this is > the case, it would mean we're passing this function out of range values. > But even then, binutil's as suddenly rejecting them when until now it > seemingly just clipped or truncated them is a considerable breakage.
I/J have been around for a while: https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC180 I guess binutils got pickier after 2.40. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".