Bug 58241 - [PPC/Altivec] altivec.h inclusion in -std=c++98..11 causes bool to be redefined
Summary: [PPC/Altivec] altivec.h inclusion in -std=c++98..11 causes bool to be redefined
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.7.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-25 21:20 UTC by Chí-Thanh Christopher Nguyễn
Modified: 2017-04-01 15:09 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
testcase (145 bytes, text/x-c++)
2013-08-25 21:20 UTC, Chí-Thanh Christopher Nguyễn
Details
preprocessed source with -std=c++11 (6.01 KB, text/x-c++)
2013-08-25 21:21 UTC, Chí-Thanh Christopher Nguyễn
Details
preprocessed source with -std=gnu++11 (6.00 KB, text/x-c++)
2013-08-25 21:22 UTC, Chí-Thanh Christopher Nguyễn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chí-Thanh Christopher Nguyễn 2013-08-25 21:20:37 UTC
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.
Comment 1 Chí-Thanh Christopher Nguyễn 2013-08-25 21:21:36 UTC
Created attachment 30697 [details]
preprocessed source with -std=c++11
Comment 2 Chí-Thanh Christopher Nguyễn 2013-08-25 21:22:14 UTC
Created attachment 30698 [details]
preprocessed source with -std=gnu++11
Comment 3 Andrew Pinski 2013-08-25 21:33:22 UTC
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.
Comment 4 Chí-Thanh Christopher Nguyễn 2013-08-25 21:46:29 UTC
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.
Comment 5 Francisco Jerez 2013-08-25 22:36:20 UTC
(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.
Comment 6 Andrew Pinski 2013-08-25 22:44:16 UTC
(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.
Comment 7 Francisco Jerez 2013-08-26 01:45:26 UTC
(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?