Menu

#475 1.3.3 fails to build on non-VSX ppc64 CPUs

1.3.x
open
nobody
ppc64 (1)
5
2022-04-21
2019-12-04
Erhard F.
No

Tried to build flac 1..3.3 on my ppc64 boxes. It succeeds on the Talos 2 but fails on the PowerMac G5.

Seems it pulls in VSX instructions without checking if the CPU is capable. VSX is >=POWER7 only. You get the same effect on POWER9 if you use -mcpu=970.

I did a standard build from git-1.3.3:
./autogen.sh && ./configure && make

[...]
make[4]: Entering directory '/root/build/flac/src/libFLAC'
CC lpc_intrin_vsx.lo
lpc_intrin_vsx.c: In function 'FLAC__lpc_compute_autocorrelation_intrin_power8_vsx_lag_16':
lpc_intrin_vsx.c:94:7: warning: implicit declaration of function 'vec_vsx_ld'; did you mean 'vec_vslh'? [-Wimplicit-function-declaration]
94 | d0 = vec_vsx_ld(0, base);
| ^~~~~~~~~~
| vec_vslh
lpc_intrin_vsx.c:94:7: warning: nested extern declaration of 'vec_vsx_ld' [-Wnested-externs]
lpc_intrin_vsx.c:94:7: error: incompatible types when assigning to type '__vector float' {aka '__vector(4) float'} from type 'int'
lpc_intrin_vsx.c:95:7: error: incompatible types when assigning to type '__vector float' {aka '__vector(4) float'} from type 'int'
95 | d1 = vec_vsx_ld(16, base);
| ^~~~~~~~~~
lpc_intrin_vsx.c:96:7: error: incompatible types when assigning to type '__vector float' {aka '__vector(4) float'} from type 'int'
96 | d2 = vec_vsx_ld(32, base);
| ^~~~~~~~~~
lpc_intrin_vsx.c:97:7: error: incompatible types when assigning to type '__vector float' {aka '__vector(4) float'} from type 'int'
97 | d3 = vec_vsx_ld(48, base);
[...]

Kernel: 5.3.13-gentoo-PowerMacG5 ppc64 bits: 64 Console: tty 1 Distro: Gentoo Base System release 2.6
Machine: Type: PowerPC Device System: PowerMac11 2 details: PowerMac11 2 rev: 1.1 (pvr 0044 0101) serial: R6V
CPU: Dual Core: PPC970MP altivec supported type: MCP speed: 2300 MHz min/max: 1150/2300 MHz
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] R580+ [Radeon X1950 XTX] driver: N/A
Display: server: X.org 1.20.5 driver: none tty: 211x53
Message: Advanced graphics data unavailable in console for root.
Network: Device-1: Broadcom and subsidiaries NetXtreme BCM5780 Gigabit Ethernet driver: tg3
Device-2: Broadcom and subsidiaries NetXtreme BCM5780 Gigabit Ethernet driver: tg3
Drives: Local Storage: total: 596.17 GiB used: 12.65 GiB (2.1%)
Info: Processes: 129 Uptime: 1h 31m Memory: 15.45 GiB used: 2.18 GiB (14.1%) Init: systemd Shell: bash inxi: 3.0.36

1 Attachments

Discussion

  • Erhard F.

    Erhard F. - 2019-12-04

    config.h

     
  • Martijn van Beurden

    FLAC version 1.3.4 has been released with some fixes for PPC. Can you try whether this is fixed now?

     
  • Erhard F.

    Erhard F. - 2022-03-07

    Just tested 1.3.4 on my Talos II (POWER9). There it get the same problem. See attached files.

    1.3.4 builds however if I use./configure --disable-vsx && make or if I do a standard build explicitely for capable CPUs, e.g. ./configure && CFLAGS="-O2 -mcpu=power9" make.

    On my PowerMac G4 (ppc32) 1.3.4 builds and runs fine wieh ./configure && make.

    And I can check out 1.3.4 on my G5 (the machine I originally reported the bug on) next weekend.

     

    Last edit: Erhard F. 2022-03-07
  • Martijn van Beurden

    It seems for some reason the compiler provides attribute((target("cpu=power9"))) but not the vsx functions in altivec.h when -mcpu=power9 isn't defined. This is much unlike GCC on x86, so I'm not sure how to proceed. I could check for the precence of vec_vsx_ld in altivec.h, but that would mean power9 functions aren't compiled in on your power9 machine when -mcpu=power9 isn't specified.

     
  • Erhard F.

    Erhard F. - 2022-03-12

    Meanwhile I checked 1.3.4 on the G5 I originally reported the bug. Result is the same.

    BTW power9 is not necessary for VSX, it only needs power7 (https://en.wikipedia.org/wiki/AltiVec#VSX_(Vector_Scalar_Extension)).

     
  • Erhard F.

    Erhard F. - 2022-04-19

    Thanks for pointing out! But the patches didn't work out yet.

    I'll test & answer directly on https://github.com/xiph/flac/issues/199 from now on. Reporting on 2 bugtrackers seems a bit of an overkill. ;)

     
  • Martijn van Beurden

    Ah, it wasn't clear to me both accounts pointed to the same user :)

     

Log in to post a comment.