Created attachment 30696 [details] testcase Originally reported as https://bugs.freedesktop.org/show_bug.cgi?id=68504 Compiling attached testcase with g++ -maltivec -std=c++11 fails with the following error: fdo_68504.cpp: In function ‘__vector(4) __bool int returnbool()’: fdo_68504.cpp:11:21: error: cannot convert ‘bool’ to ‘__vector(4) __bool int’ in return Building with -std=gnu++11 does not fail. It appears that bool is redefined by altivec.h to __attribute__((altivec(bool__))) unsigned in c++11 mode.
Created attachment 30697 [details] preprocessed source with -std=c++11
Created attachment 30698 [details] preprocessed source with -std=gnu++11
You need to use -std=g++11 or undefine bool after the include of altivec.h as context sensitive keywords is not part of the C++11 standard. Also it does not make sense to do extern "C" around altivec.h at all since it uses C++ code.
The testcase was based on http://cgit.freedesktop.org/mesa/mesa/plain/src/gallium/state_trackers/clover/core/base.hpp?id=f0cb66b69904b0a3e4083aa8874af63cf1c14321 That header file still fails to compile with -std=c++11 after adding #undef bool, but now with a different error. base.hpp:206:26: error: expected type-specifier base.hpp:206:26: error: expected ‘>’ I will maybe file a separate bug.
(In reply to Andrew Pinski from comment #3) > You need to use -std=g++11 or undefine bool after the include of altivec.h > as context sensitive keywords is not part of the C++11 standard. > Isn't the bool keyword part of the C++ standard? I fail to see how this bug is invalid, the inclusion of a system header is redefining the meaning of a language keyword in a way that breaks standard C++ code, and the definition of "vector" collides with the C++ standard library. Forcing the user to undef those in order to get their expected behaviour according to the C++ standard seems like a questionable and dangerous practice to me... If OTOH this file was never supposed to be included from non-GNU C++ code, the include line should probably be removed from Khronos' cl_platform.h. Thank you.
(In reply to Francisco Jerez from comment #5) > (In reply to Andrew Pinski from comment #3) > > You need to use -std=g++11 or undefine bool after the include of altivec.h > > as context sensitive keywords is not part of the C++11 standard. > > > > Isn't the bool keyword part of the C++ standard? I fail to see how this bug > is invalid, the inclusion of a system header is redefining the meaning of a > language keyword in a way that breaks standard C++ code, and the definition > of "vector" collides with the C++ standard library. Yes bool is a keyword fully in the C++ standard. A system header which is defined by the AltiVec (VMX) PIM to maybe define bool in the header. > Forcing the user to undef those in order to get their expected behaviour > according to the C++ standard seems like a questionable and dangerous > practice to me... Since altivec.h is outside of the standard C++ land, it could do what ever it feels like. And If you read the PIM you will understand why this is implemented this way.
(In reply to Andrew Pinski from comment #6) > (In reply to Francisco Jerez from comment #5) > > (In reply to Andrew Pinski from comment #3) > > > You need to use -std=g++11 or undefine bool after the include of altivec.h > > > as context sensitive keywords is not part of the C++11 standard. > > > > > > > Isn't the bool keyword part of the C++ standard? I fail to see how this bug > > is invalid, the inclusion of a system header is redefining the meaning of a > > language keyword in a way that breaks standard C++ code, and the definition > > of "vector" collides with the C++ standard library. > > Yes bool is a keyword fully in the C++ standard. A system header which is > defined by the AltiVec (VMX) PIM to maybe define bool in the header. > Apparently the AltiVec PIM gives two possibilities to the implementation: | 2.2.1 The Keyword and Predefine Method | | In this method, __vector, __pixel, and bool are added as | keywords while vector and pixel are predefined macros. bool is | already a keyword in C++. To allow its use in C as a keyword, | it is treated the same as it is in C++. This means that the C | language is extended to allow bool alone as a set of type | specifiers. Typically, this type will map to int. [...] | | 2.2.2 The Context Sensitive Keyword Method | | In this method, __vector and __pixel are added as keywords | without regard to context while the new uses of vector, pixel, | and bool are keywords only in the context of a type. [...] I understand that what is described in section 2.2.2 might not be possible to achieve in standard C++ mode, so GCC's implementation would be expected to stick to section 2.2.1, which also involves treating bool as a keyword as it is in standard C++. This makes me think that the intention of the authors was to preserve the usual semantics of bool in C++ programs except where it's used in conjunction with the __vector type specifier, so code like "bool a = (b == 0);" (which is being rejected in Chí-Thanh's set-up) would still be valid in presence of the AltiVec extensions. Am I missing something?