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

[James Zern <jzern-at-google.com@ffmpeg.org>]

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