| Summary: | 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 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
| Component: | Current packages | Assignee: | Matt Turner <mattst88> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ppc64, x11 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | PPC64 | ||
| OS: | Linux | ||
| See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=68504 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58241 https://bugs.gentoo.org/show_bug.cgi?id=673622 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 585588, 600104, 611056 | ||
| Attachments: |
media-libs:mesa-11.2.2:20160626-184813.log.xz
mesa-12.0.1-clover-altivec.patch |
||
|
Description
Jeroen Roovers (RETIRED)
2016-06-27 06:10:53 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 (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? 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 (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. (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. (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. 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. */ (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. 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.
(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. 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 on attachment 440374 [details, diff]
mesa-12.0.1-clover-altivec.patch
Yes, that works (with 11.2.2 as well).
(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 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? :) *** Bug 549096 has been marked as a duplicate of this bug. *** 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 Fixed upstream by commit 7d1195c1e4d071fe796bf5f210c468ea1cc86225 Author: Matt Turner <mattst88@gmail.com> 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 <mattst88@gentoo.org> Date: Thu Mar 2 15:57:09 2017 -0800 media-libs/mesa: Apply patch to fix Clover build with AltiVec. |