Opened 5 months ago

Last modified 6 weeks ago

#7861 new defect

altivec compilation broken on specific setups starting with gcc 8.3

Reported by: q66 Owned by:
Priority: normal Component: swscale
Version: git-master Keywords: ppc altivec
Cc: dan@danny.cz Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Change History (11)

comment:1 Changed 5 months ago by q66

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.

comment:2 Changed 5 months ago by q66

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.

comment:3 Changed 5 months ago by q66

  • Summary changed from altivec compilation broken starting with gcc 8.3 to altivec compilation broken on specific setups starting with gcc 8.3

comment:4 Changed 5 months ago by cehoyos

  • Keywords ppc added; ppc64 power removed

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

comment:5 Changed 6 weeks ago by leigh123linux

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

comment:6 Changed 6 weeks ago by q66

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)

comment:7 Changed 6 weeks ago by q66

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

comment:8 Changed 6 weeks ago by sharkcz

  • Cc dan@danny.cz added

comment:9 Changed 6 weeks ago by cehoyos

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'

comment:10 Changed 6 weeks ago by q66

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.

comment:11 Changed 6 weeks ago by q66

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

Note: See TracTickets for help on using tickets.