[FFmpeg-devel] Build failure un Debian Testing

[James Almer]

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.

 >     );
 >     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.