altivec compilation broken on specific setups starting with gcc 8.3

[Daniel Kolesa]

Starting with gcc 8.3, it is not allowed to use typedefs with the altivec vector keyword when this keyword is builtin (e.g. vector uint32_t). It is necessary to either use the base type (like, vector unsigned int) or use the __vector gcc extension (like, __vector uint32_t).

There's a bunch of recently-added code violating this, such as ​https://github.com/FFmpeg/FFmpeg/commit/8dd9df9ecd258cff84cef559f16e682949e78e38#diff-2177d684d44cafdce18adf016216b747

This breaks build on powerpc; see gcc documentation for reference ​https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html

Not sure if other components are affected.

[Daniel Kolesa]

This issue is also hidden by default because of the -std=c11 flag that is used by default, as that disables the builtin vector keyword, and altivec.h then reintroduces it as a macro.

[Daniel Kolesa]

I was also able to confirm that the only affected files are swscale_altivec.c and swscale_vsx.c; replacing the instances of vector (u)int(8|16|32)_t with vec_(u|s)(8|16|32) from libavutil/util_altivec.h fixed the problem.

[Carl Eugen Hoyos]

Please send your patch made with git format-patch to the development mailing list.

[Leigh Scott]

PPC64LE build is broken in ffmpeg-4.2 release

unused-const-variable -Wno-bool-operation -Wno-char-subscripts -O2 -g -pipe -WaIn file included from ./libavutil/ppc/util_altivec.h:55,
BUILDSTDERR: from ./libswscale/swscale_internal.h:34,
BUILDSTDERR: from libswscale/ppc/swscale_vsx.c:28:
BUILDSTDERR: libswscale/ppc/swscale_vsx.c: In function 'yuv2plane1_nbps_vsx':
BUILDSTDERR: libswscale/ppc/swscale_vsx.c:165:53: error: argument 1 must be a 5-bit signed literal
BUILDSTDERR: 165 | const vector uint16_t vswap = (vector uint16_t) vec_splat_u16(big_endian ? 8 : 0);
BUILDSTDERR: |
^{BUILDSTDERR: libswscale/ppc/swscale_vsx.c:166:54: error: argument 1 must be a 5-bit signed literal
BUILDSTDERR: 166 | const vector uint16_t vshift = (vector uint16_t) vec_splat_u16(shift);
BUILDSTDERR: |}
BUILDSTDERR: libswscale/ppc/swscale_vsx.c: In function 'yuv2plane1_16_vsx.isra.0':
BUILDSTDERR: libswscale/ppc/swscale_vsx.c:283:53: error: argument 1 must be a 5-bit signed literal
BUILDSTDERR: 283 | const vector uint16_t vswap = (vector uint16_t) vec_splat_u16(big_endian ? 8 : 0);
BUILDSTDERR: |
^{BUILDSTDERR: make: * [ffbuild/common.mak:59: libswscale/ppc/swscale_vsx.o] Error 1}

[Daniel Kolesa]

Try altering

static void yuv2plane1_nbps_vsx(const int16_t *src, uint16_t *dest, int dstW,

int big_endian, int output_bits)

to

static av_always_inline void yuv2plane1_nbps_vsx(const int16_t *src, uint16_t *dest, int dstW,

const int big_endian, const int output_bits)

[Daniel Kolesa]

(this is an unrelated issue to what I originally reported though; I kinda forgot about this, I can try patching both of them)

[Carl Eugen Hoyos]

Compilation with gcc-8.3.1 for little-endian POWER8 works fine here, please explain how I can reproduce the issue.

$ ffmpeg
ffmpeg version N-94484-gaf3ddd5 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8.3.1 (GCC) 20190304 (Advance-Toolchain-at12.0) [revision 269374]
  configuration: --cpu=power8 --enable-gpl --cc=/opt/at12.0/bin/gcc
  libavutil      56. 33.100 / 56. 33.100
  libavcodec     58. 55.100 / 58. 55.100
  libavformat    58. 30.100 / 58. 30.100
  libavdevice    58.  9.100 / 58.  9.100
  libavfilter     7. 58.100 /  7. 58.100
  libswscale      5.  6.100 /  5.  6.100
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

[Daniel Kolesa]

As I said, the original issue is not reproducible with stock ffmpeg build, as it's hidden by using a strict C11 mode, which disables the builtin "vector" keyword extension. It is reproducible in other projects that build their own ffmpeg (e.g. mplayer). That doesn't mean the issue is not there, it just means using a strict C11 mode ironically enables a very loose behavior of "vector" which is not in line with what is specified by the compiler.

[Daniel Kolesa]

Anyway, I submitted patches for both of the problems reported here to the mailing list the other day, so no worries.

[Daniel Kolesa]

​https://github.com/FFmpeg/FFmpeg/commit/1bdb47b73484dd21ee1bf493d79ac26384eda05e#diff-bc24a20424aea56cdb182b80cc9f46e9
​https://github.com/FFmpeg/FFmpeg/commit/e6625ca41f85ed10b3108d37bd897f0ae063250e#diff-bc24a20424aea56cdb182b80cc9f46e9