Bug 587210 – media-libs/mesa-11.2.2[opencl] on PPC64 - In file included from .../work/mesa-11.2.2/src/gallium/state_trackers/clover/api/context.cpp:23: error: ‘__vector(4) __bool int’ is not a valid type for a template non-type parameter

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Jeroen Roovers (RETIRED) 2016-06-27 06:10:53 UTC]

Created attachment 438936 [details]
media-libs:mesa-11.2.2:20160626-184813.log.xz

[ebuild     U ~] media-libs/mesa-11.2.2::gentoo [11.0.6::gentoo] USE="classic dri3 egl gallium gbm llvm nptl opencl* udev -bindist -d3d9 -debug -gles1 -gles2 (-openmax) -osmesa -pax_kernel -pic (-selinux) (-vaapi) (-vdpau) -wayland -xa (-xvmc)" VIDEO_CARDS="radeon (-freedreno) (-i915) (-i965) (-ilo) (-intel) -nouveau -r100 -r200 -r300 -r600 (-radeonsi) (-vc4) (-vmware)" 0 KiB

In file included from /usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/map:60:0,
                 from /var/tmp/portage/media-libs/mesa-11.2.2/work/mesa-11.2.2/src/gallium/state_trackers/clover/core/property.hpp:26,
                 from /var/tmp/portage/media-libs/mesa-11.2.2/work/mesa-11.2.2/src/gallium/state_trackers/clover/api/util.hpp:30,
                 from /var/tmp/portage/media-libs/mesa-11.2.2/work/mesa-11.2.2/src/gallium/state_trackers/clover/api/context.cpp:23:
/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/bits/stl_tree.h: In constructor ‘std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Rb_tr
ee(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>&&, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Node_allocator&&)’:
/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/bits/stl_tree.h:1332:76: error: ‘__vector(4) __bool int’ is not a valid type for a template non-type parameter
       using __eq = integral_constant<bool, _Alloc_traits::_S_always_equal()>;
                                                                            ^


Mon Jun 27 08:10:19 CEST 2016
emerge --info media-libs/mesa
Portage 2.2.28 (python 3.4.3-final-0, default/linux/powerpc/ppc64/13.0/64bit-userland, gcc-5.4.0, glibc-2.22-r4, 4.4.6-gentoo ppc64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.4.6-gentoo-ppc64-PPC970FX,_altivec_supported-with-gentoo-2.2
KiB Mem:     8096876 total,   3013928 free
KiB Swap:    1048572 total,   1011108 free
Timestamp of repository gentoo: Mon, 27 Jun 2016 03:00:01 +0000
sh bash 4.3_p42-r1
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
distcc 3.2rc1 powerpc64-unknown-linux-gnu [enabled]
ccache version 3.2.4 [disabled]
app-shells/bash:          4.3_p42-r1::gentoo
dev-java/java-config:     2.2.0-r3::gentoo
dev-lang/perl:            5.20.2::gentoo
dev-lang/python:          2.7.10-r1::gentoo, 3.3.5-r3::gentoo, 3.4.3-r1::gentoo, 3.5.0-r1::gentoo
dev-util/ccache:          3.2.4::gentoo
dev-util/cmake:           3.3.1-r1::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.19.1::gentoo
sys-apps/sandbox:         2.10-r1::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.12.6::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.24-r3::gentoo, 2.25.1-r1::gentoo
sys-devel/gcc:            4.7.4::gentoo, 4.8.4::gentoo, 4.8.5::gentoo, 4.9.3::gentoo, 5.4.0::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers)
sys-libs/glibc:           2.22-r4::gentoo
Repositories:

gentoo
    location: /aches/gentoo/portage
    sync-type: rsync
    sync-uri: rsync://rsync.nl.gentoo.org/gentoo-portage
    priority: 0

JeR
    location: /aches/gentoo/local
    masters: gentoo
    priority: 10000

ACCEPT_KEYWORDS="ppc64"
ACCEPT_LICENSE="*"
CBUILD="powerpc64-unknown-linux-gnu"
CFLAGS="-O2 -ggdb -mcpu=G5 -mtune=G5 -Wall"
CHOST="powerpc64-unknown-linux-gnu"
CONFIG_PROTECT="/etc /etc/stunnel/stunnel.conf /usr/lib/ccache/bin /usr/lib/distcc/bin /usr/share/config /usr/share/gnupg/qualified.txt /var/bind"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/apache2-php5.6/ext-active/ /etc/php/apache2-php7.0/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cgi-php5.6/ext-active/ /etc/php/cgi-php7.0/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/php/cli-php5.6/ext-active/ /etc/php/cli-php7.0/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -ggdb -mcpu=G5 -mtune=G5 -Wall"
DISTDIR="/aches/gentoo/distfiles"
EMERGE_DEFAULT_OPTS="--autounmask=n --keep-going"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs buildpkg cgroup compressdebug config-protect-if-modified distcc distlocks ebuild-locks fixlafiles merge-sync metadata-transfer multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms sign splitdebug strict test test-fail-continue unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS=" http://mirror.netcologne.de/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://gentoo.tiscali.nl/ http://mirror.leaseweb.com/gentoo/ "
LANG="en_GB.utf8"
LC_ALL="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/aches/gentoo/packages/martijn"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X acl alsa altivec apache2 avahi berkdb botan bzip2 cairo cli consolekit cracklib crypt cups cxx dri drm evdev fontforge fortran fusionsound gadu gdbm gstreamer http2 ibm iconv idn introspection ipv6 jpeg jpeg2k kerberos lcms lensfun lua modules mpi multilib multislot multitarget natspec ncurses nethack nls nptl offensive ofono-headset opengl openmp pam pcre png ppc64 qt3support qt4 r600-llvm-compiler raw readline rubberband rubytests scanner sdl session ssl tcl tcmalloc tcpd theora threads tiff tk truetype unicode vpx webp xattr zlib" ABI_PPC="64" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CURL_SSL="gnutls" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" L10N="en_GB en nl" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_GB en nl" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="modesetting radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

=================================================================
                        Package Settings
=================================================================

media-libs/mesa-11.0.6::gentoo was built with the following:
USE="classic dri3 egl gallium gbm llvm nptl udev -bindist -d3d9 -debug -gles1 -gles2 -opencl (-openmax) -osmesa -pax_kernel -pic (-selinux) (-vaapi) (-vdpau) -wayland -xa (-xvmc)" VIDEO_CARDS="radeon -freedreno -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -r600 -radeonsi -vmware"

[Comment 1 Chí-Thanh Christopher Nguyễn 2016-06-27 08:29:46 UTC]

This is a long-standing issue with AltiVec. fdo and gcc folks blame each other. See the referenced bug reports.

Workaround: -mno-altivec or -std=g++11

[Comment 2 Jeroen Roovers (RETIRED) 2016-06-27 08:33:51 UTC]

(In reply to Chí-Thanh Christopher Nguyễn from comment #1)
> This is a long-standing issue with AltiVec. fdo and gcc folks blame each
> other. See the referenced bug reports.
> 
> Workaround: -mno-altivec or -std=g++11

I guess the latter would be preferable. In high performance code, losing the SIMD would be worse than elevating standards compliance? Can we somehow work this into the mesa ebuilds?

[Comment 3 Chí-Thanh Christopher Nguyễn 2016-06-27 08:40:29 UTC]

According to upstream, they don't want to use -std=g++xy because they fear gcc extensions creeping into the code unnoticed.
Plus they say the code in question does not use any altivec extensions.

However, -mno-altivec implies -mabi=no-altivec. I could not find an answer to the question whether mixing -mabi=altivec and -mabi=no-altivec code is possible or leads to problems.

https://lists.freedesktop.org/archives/mesa-dev/2013-August/043916.html

[Comment 4 Jeroen Roovers (RETIRED) 2016-06-27 09:41:47 UTC]

(In reply to Chí-Thanh Christopher Nguyễn from comment #3)
> According to upstream, they don't want to use -std=g++xy because they fear
> gcc extensions creeping into the code unnoticed.

Yes, but is that our concern as well?

> Plus they say the code in question does not use any altivec extensions.

But the compiler is optimising for it? Note that I don't actually set that in make.conf and that it doesn't show up in the build log either.

[Comment 5 Chí-Thanh Christopher Nguyễn 2016-06-27 10:10:39 UTC]

(In reply to Jeroen Roovers from comment #4)
> Yes, but is that our concern as well?

If we want to get our patch into an upstreamable state, then yes.

> > Plus they say the code in question does not use any altivec extensions.
> 
> But the compiler is optimising for it?

You mean autovectorization? I am not sure to which extent this happens in the clover state tracker.

> Note that I don't actually set that
> in make.conf and that it doesn't show up in the build log either.

-maltivec is implied by -mcpu=G5 in your case.

[Comment 6 Jeroen Roovers (RETIRED) 2016-06-30 08:02:47 UTC]

(In reply to Chí-Thanh Christopher Nguyễn from comment #5)
> (In reply to Jeroen Roovers from comment #4)
> > Yes, but is that our concern as well?
> 
> If we want to get our patch into an upstreamable state, then yes.

I took what you said about "-std=g++11" to mean that this will fix the issue so that we don't need a patch but a small addition to the ebuild.

Also, I understand that upstream is aware of the problem but does not want to fix it, blaming a third party, so how they would accept any patch for a problem they don't perceive as their problem to fix I don't know.

[Comment 7 Matt Turner 2016-07-02 03:02:22 UTC]

Just use.mask opencl on PPC/PPC64? It seems unlikely to be of much use, and avoids quite a boneheaded mistake in altivec.h.

If someone cares to investigate further, take a look at

https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html#PowerPC-AltiVec_002fVSX-Built-in-Functions

and include/CL/cl_platform.h in Mesa. One might try removing the inclusion of altivec.h since the file states

   #include <altivec.h>   /* may be omitted depending on compiler. AltiVec spec provides no way to detect whether the header is required. */

[Comment 8 Jeroen Roovers (RETIRED) 2016-07-02 08:39:51 UTC]

(In reply to Matt Turner from comment #7)
> Just use.mask opencl on PPC/PPC64? It seems unlikely to be of much use, and
> avoids quite a boneheaded mistake in altivec.h.

It's already use.masked for PPC64. I'm trying to get rid of that as it actually can be quite useful on PPC64. I'm not sure if PPC(32) is affected since I don't have a G4 type system.

> If someone cares to investigate further, take a look at

Will do.

[Comment 9 Jeroen Roovers (RETIRED) 2016-07-03 09:12:41 UTC]

Adding

    if use ppc64; then
       append-cflags -mno-altivec
       append-cxxflags -mno-altivec
    fi

works with my "-mcpu=G5 -mtune=G5".

I have no idea if this bug affects 32-bit PowerPC.

[Comment 10 Chí-Thanh Christopher Nguyễn 2016-07-03 23:07:22 UTC]

(In reply to Jeroen Roovers from comment #6)
> Also, I understand that upstream is aware of the problem but does not want
> to fix it, blaming a third party, so how they would accept any patch for a
> problem they don't perceive as their problem to fix I don't know.

They will accept a patch that disables altivec for the clover state tracker.
They will not accept a patch that switches the compiler to GNU mode.
I am willing to make such a patch. However I am unsure about potential issues mixing -mabi=altivec and -mabi=no-altivec code. If there are none, we can just add -mno-altivec. If there are, a configure check may be necessary.

(In reply to Jeroen Roovers from comment #9)
>        append-cflags -mno-altivec

This will disable altivec for the whole of mesa, not just for clover. I think this may be undesirable.

> I have no idea if this bug affects 32-bit PowerPC.

It does. I sent my original report to upstream because I hit it on my PowerBook G4.

[Comment 11 Chí-Thanh Christopher Nguyễn 2016-07-11 17:56:24 UTC]

Created attachment 440374 [details, diff]
mesa-12.0.1-clover-altivec.patch

Attached patch fixes the clover build for me on ppc, and should be in line with upstream requirements. Please test on ppc64.

[Comment 12 Jeroen Roovers (RETIRED) 2016-07-13 05:05:04 UTC]

Comment on attachment 440374 [details, diff]
mesa-12.0.1-clover-altivec.patch

Yes, that works (with 11.2.2 as well).

[Comment 13 Agostino Sarubbo 2016-11-16 21:46:11 UTC]

(In reply to Jeroen Roovers from comment #9)
> I have no idea if this bug affects 32-bit PowerPC.

it is not affected. It works here.

[Comment 14 Jeroen Roovers (RETIRED) 2017-01-07 10:06:14 UTC]

Comment on attachment 440374 [details, diff]
mesa-12.0.1-clover-altivec.patch

>diff -ur a/configure.ac b/configure.ac
>--- a/configure.ac	2016-07-07 17:12:34.000000000 +0200
>+++ b/configure.ac	2016-07-11 02:18:16.820020167 +0200
>@@ -1938,6 +1938,19 @@
>         AC_SUBST([LIBCLC_LIBEXECDIR])
>     fi
> 
>+dnl
>+dnl Workaround for altivec failure with GNU C++ and -std=c++0x, PR58241
>+dnl
>+    if test "x${ac_cv_cxx_compiler_gnu}" = xyes ; then
>+        case $target_cpu in
>+            powerpc|powerpc64 )

Just powerpc64 thank you.

Also, when? :)

[Comment 15 Matt Turner 2017-01-26 23:12:53 UTC]

*** Bug 549096 has been marked as a duplicate of this bug. ***

[Comment 16 Matt Turner 2017-03-02 05:59:09 UTC]

Any powerpc platform that enables altivec is affected. Both ppc32 and ppc64 can have altivec.

The patch in comment #14 that adds -mno-altivec to CXXFLAGS does not fix the problem, because the user's CXXFLAGS (which likely contain -maltivec) appear *after* -mno-altivec, thus negating it.

I have sent a new patch, which I believe satisfies upstream's requirements. I have tested it, and it works in my powerpc chroot.

https://lists.freedesktop.org/archives/mesa-dev/2017-March/146322.html

[Comment 17 Matt Turner 2017-03-03 00:10:00 UTC]

Fixed upstream by

commit 7d1195c1e4d071fe796bf5f210c468ea1cc86225
Author: Matt Turner <[e-mail]>
Date:   Thu Mar 2 04:43:21 2017 +0000

    clover: Work around build failure with AltiVec.

and I have patched 13.0.5 and 17.0.0:

commit 2104b7bb6990014b7e1c83dfa22f44d9af8d58ad
Author: Matt Turner <[e-mail]>
Date:   Thu Mar 2 15:57:09 2017 -0800

    media-libs/mesa: Apply patch to fix Clover build with AltiVec.