[FFmpeg-devel] Build failure un Debian Testing

[James Almer]

On 7/14/2023 1:49 PM, James Zern wrote:
> 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

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.