mathops.h: Assembler messages errors, type mismatch for shr

[shevy]

MAN doc/libswscale.3
POD doc/libswresample.pod
MAN doc/libswresample.3
POD doc/libavcodec.pod
MAN doc/libavcodec.3
POD doc/libavformat.pod
MAN doc/libavformat.3
POD doc/libavdevice.pod
MAN doc/libavdevice.3
POD doc/libavfilter.pod
MAN doc/libavfilter.3
INSTALL doc/ffmpeg.1
INSTALL doc/ffplay.1
INSTALL doc/ffprobe.1
INSTALL doc/ffmpeg-all.1
INSTALL doc/ffplay-all.1
INSTALL doc/ffprobe-all.1
INSTALL doc/ffmpeg-utils.1
INSTALL doc/ffmpeg-scaler.1
INSTALL doc/ffmpeg-resampler.1
INSTALL doc/ffmpeg-codecs.1
INSTALL doc/ffmpeg-bitstream-filters.1
INSTALL doc/ffmpeg-formats.1
INSTALL doc/ffmpeg-protocols.1
INSTALL doc/ffmpeg-devices.1
INSTALL doc/ffmpeg-filters.1
INSTALL doc/libavutil.3
INSTALL doc/libswscale.3
INSTALL doc/libswresample.3
INSTALL doc/libavcodec.3
INSTALL doc/libavformat.3
INSTALL doc/libavdevice.3
INSTALL doc/libavfilter.3
INSTALL doc/ffmpeg.1
INSTALL doc/ffplay.1
INSTALL doc/ffprobe.1
INSTALL doc/ffmpeg-all.1
INSTALL doc/ffplay-all.1
INSTALL doc/ffprobe-all.1
INSTALL doc/ffmpeg-utils.1
INSTALL doc/ffmpeg-scaler.1
INSTALL doc/ffmpeg-resampler.1
INSTALL doc/ffmpeg-codecs.1
INSTALL doc/ffmpeg-bitstream-filters.1
INSTALL doc/ffmpeg-formats.1
INSTALL doc/ffmpeg-protocols.1
INSTALL doc/ffmpeg-devices.1
INSTALL doc/ffmpeg-filters.1
INSTALL doc/libavutil.3
INSTALL doc/libswscale.3
INSTALL doc/libswresample.3
INSTALL doc/libavcodec.3
INSTALL doc/libavformat.3
INSTALL doc/libavdevice.3
INSTALL doc/libavfilter.3
CC libavformat/adtsenc.o
./libavcodec/x86/mathops.h: Assembler messages:
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
make: * [ffbuild/common.mak:81: libavformat/adtsenc.o] Error 1

This is for ffmpeg 6.0. I was able to compile it previously, so it may be my environment is wrong. Either way it is odd that this fails - can someone look at the file and check whether this works fine with recent gcc + binutils?

My system is:

Operating system: GNU/Linux
Operating system bit type: x86_64 (64 bit)
CPU Model: AMD Ryzen 5 5500, 32 cores
RAM: 64095 MB RAM
Screen Resolution: 2560x1080
CFLAGS in use: -O2 -fPIC -fno-strict-overflow -Wno-error
gcc: gcc version: 14.0.0 20230526 (experimental)
g++: g++ version: 14.0.0 20230526 (experimental)
glibc: 2.37
linux: 6.1.29
binutils: 2.40.50.20230531
cmake: 3.26.4

[shevy]

Note that I tried it with a recent ffmpeg git checkout too and the same assembler error happens too. If anyone is able to find out why that happens, perhaps the configure script could issue some warning or so. Most other software I compile (I try to compile everything from source) works fine and compiles well; only ffmpeg is hiccuping recently.

[Balling]

effadce6c756247ea8bae32dc13bb3e6f464f0eb

[RoverAz]

Related:
​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
​https://sourceware.org/bugzilla/show_bug.cgi?id=30578

It's a change in binutils that has worked its way through.

[RoverAz]

Are binutils and ffmpeg playing chicken to see who relents first?

This is the original commit that has now made its way into debian testing and other rr distros:

​https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34d1cc9200ae24dc7572aaf77d80276c0490e9b

For shifts (but not ordinary rotates) and other cases where an immediate
describes e.g. a bit count or position, allowing negative operands is at
best confusing. An extreme example would be the two rotate-through-carry
insns, where a negative value would _not_ mean rotating the
corresponding number of bits in the other direction. To refuse such,
give meaning to the combination of Imm8 and Imm8S in templates (so far
these weren't used together anywhere). The issue was with
smallest_imm_type() blindly setting .imm8 for signed numbers determined
to fit in a byte.

VPROT{B,W,D,Q} is a little special: The rotate count there is a signed
quantity, so Imm8 is replaced by Imm8S. Adjust affected testcases
accordingly as well.

Another small adjustment to the testsuite is necessary: AAM and AAD were
never sensible to use with 0xffffff90 operands. This should have been an
error.

I have no idea what the assembly below in mathops.h does or what it's for, but it doesn't look like too big a problem to solve... can these not be changed to do the same thing and compile with the newly fastidious binutils?

// avoid +32 for shift optimization (gcc should do that ...)
#define NEG_SSR32 NEG_SSR32
static inline  int32_t NEG_SSR32( int32_t a, int8_t s){
    __asm__ ("sarl %1, %0\n\t"
         : "+r" (a)
         : "ic" ((uint8_t)(-s))
    );
    return a;
}
    
#define NEG_USR32 NEG_USR32
static inline uint32_t NEG_USR32(uint32_t a, int8_t s){
    __asm__ ("shrl %1, %0\n\t"
         : "+r" (a)
         : "ic" ((uint8_t)(-s))
    );  
    return a;
}

[RoverAz]

Fixed in latest git. Muchas gracias assembros.

[Alberto Salvia Novella]

Which commit does fix it?

[Balling]

Replying to Alberto Salvia Novella:

Which commit does fix it?

effadce6c756247ea8bae32dc13bb3e6f464f0eb