[FFmpeg-devel] Build failure un Debian Testing

[James Zern]

On Fri, Jul 14, 2023 at 5:37 AM James Almer <jamrial at 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

>  >     );
>  >     return a;
>  > }
>
> This is most likely a bug in the assembler. The "Error: operand type
> mismatch for 'shr'" error message makes me think it may be trying to use
> a register other than CL for the second operand.
>
> That said, i don't know if this asm block is needed at all, seeing how
> the generic C implementation is
>
> define NEG_USR32(a,s) (((uint32_t)(a))>>(32-(s)))
>
> Which the compiler can surely convert into whatever is most optimized
> for the target. The BMI2 instruction set added shrx, which accepts any
> register as second operand, for example.