[FFmpeg-devel] Build failure un Debian Testing

[FFmpeg-devel] Build failure un Debian Testing

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 1019 bytes --]

Hi.

We currently have a build failure on Debian Testing (and certainly
Unstable):

        CC      libavformat/adtsenc.o
        src/libavcodec/x86/mathops.h: Assembler messages:
    ×19 src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
        make: *** [src/ffbuild/common.mak:81: libavformat/adtsenc.o] Error 1
        CC      libavformat/av1.o
        src/libavcodec/x86/mathops.h: Assembler messages:
    ×47 src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
        <snip 5000+ similar lines>

It can be worked around by commenting:

#define NEG_SSR32 NEG_SSR32
#define NEG_USR32 NEG_USR32

near the end of libavcodec/x86/mathops.h. According to comments on bug
trackers, it might be related to binutils 2.40.90 (versus 2.40 from
stable).

I do not know how to fix this kind of error, but I can help if a change
needs testing and somebody does not have a Debian Testing with enough
libraries installed.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Build failure un Debian Testing

[James Almer]

On 7/13/2023 7:06 AM, Nicolas George wrote:
> Hi.
> 
> We currently have a build failure on Debian Testing (and certainly
> Unstable):
> 
>          CC      libavformat/adtsenc.o
>          src/libavcodec/x86/mathops.h: Assembler messages:
>      ×19 src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
>          make: *** [src/ffbuild/common.mak:81: libavformat/adtsenc.o] Error 1
>          CC      libavformat/av1.o
>          src/libavcodec/x86/mathops.h: Assembler messages:
>      ×47 src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
>          <snip 5000+ similar lines>
> 
> It can be worked around by commenting:
> 
> #define NEG_SSR32 NEG_SSR32
> #define NEG_USR32 NEG_USR32
> 
> near the end of libavcodec/x86/mathops.h. According to comments on bug
> trackers, it might be related to binutils 2.40.90 (versus 2.40 from
> stable).

Curious that they pull git snapshots of this package for Debian testing. 
For others they seem to stick to tagged releases.

> 
> I do not know how to fix this kind of error, but I can help if a change
> needs testing and somebody does not have a Debian Testing with enough
> libraries installed.

This definitely sounds like a regression in binutils, so other than 
reporting it upstream, i don't see much more we can do.

> 
> Regards,
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Build failure un Debian Testing

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 791 bytes --]

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.

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

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Build failure un Debian Testing

[James Zern]

On Fri, Jul 14, 2023 at 5:37 AM James Almer <jamrial@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [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@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Build failure un Debian Testing

[James Zern]

On Fri, Jul 14, 2023 at 10:47 AM James Almer <jamrial@gmail.com> wrote:
>
> On 7/14/2023 1:49 PM, James Zern wrote:
> > On Fri, Jul 14, 2023 at 5:37 AM James Almer <jamrial@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-request@ffmpeg.org with subject "unsubscribe".