[FFmpeg-trac] #10405(undetermined:new): mathops.h: Assembler messages errors, type mismatch for shr

FFmpeg trac at avcodec.org
Fri Jul 14 17:52:18 EEST 2023


#10405: mathops.h: Assembler messages errors, type mismatch for shr
-------------------------------------+-------------------------------------
             Reporter:  shevy        |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by 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;
 }
 }}}
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10405#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list