[Mesa-stable] [Mesa-dev] [PATCH] clover: work around altivec build failure with GNU C++ and -std=c++

[Chí-Thanh Christopher Nguyễn]

Francisco Jerez schrieb:
> Chí-Thanh Christopher Nguyễn <chithanh at gentoo.org> writes:
> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68504 Bugzilla:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58241 CC:
>> mesa-stable at lists.freedesktop.org --- configure.ac
>> | 11 +++++++++++ src/gallium/state_trackers/clover/Makefile.am |  2
>> +- 2 files changed, 12 insertions(+), 1 deletion(-)
>> 
>> diff --git a/configure.ac b/configure.ac index 40e052c..15831fd
>> 100644 --- a/configure.ac +++ b/configure.ac @@ -1390,6 +1390,17 @@ if
>> test "x$enable_opencl" = xyes; then AC_MSG_ERROR([pkg-config cannot
>> use libclc.pc which is required to build clover]) 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 +        CLOVER_CXX_STD="gnu++0x" +    else +
>> CLOVER_CXX_STD="c++0x" +    fi +    AC_SUBST([CLOVER_CXX_STD]) + 
>> GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS clover" 
>> GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS opencl" 
>> enable_gallium_loader=yes diff --git
>> a/src/gallium/state_trackers/clover/Makefile.am
>> b/src/gallium/state_trackers/clover/Makefile.am index b4c197a..e339c1f
>> 100644 --- a/src/gallium/state_trackers/clover/Makefile.am +++
>> b/src/gallium/state_trackers/clover/Makefile.am @@ -30,7 +30,7 @@
>> libclllvm_la_SOURCES = \ llvm/invocation.cpp
>> 
>> libclover_la_CXXFLAGS = \ -	-std=c++0x +	-std=$(CLOVER_CXX_STD)
>> 
>> libclover_la_LIBADD = \ libcltgsi.la libclllvm.la
> 
> How about disabling AltiVec code generation by adding "-mno-altivec" to 
> CXXFLAGS?  AFAICT what's going on is that the "-maltivec" option (which 
> is implied by your "-mcpu=7450") enables a number of language
> extensions as a side effect that collide with the C++ standard, which
> is exacerbated by GCC's seemingly broken implementation.

Then what is the purpose of the altivec code in cl_platform.h?

> I wonder if they could have any undesirable side effects on components 
> other than clover: not including "altivec.h" doesn't seem to guarantee 
> that the problematic preprocessor definitions ("bool" and "vector") 
> aren't going to be present.
> 
> Switching the dialect we're compiling with to GNU C++ isn't especially 
> reassuring, clover doesn't need GNU's C++ extensions and we don't want 
> to start using any of them by accident -- we don't use the AltiVec 
> extensions either so disabling the latter seems like the most
> reasonable solution to me.

Unintentional use of GNU C++ extensions could be mitigated by adding
-Wpedantic (although the gcc manpage admits that this check is not complete).

I have no strong opinion either way.


Best regards,
Chí-Thanh Christopher Nguyễn