Bug 51654

Summary: C++ preprocessor bug with -maltivec and typedefs involving 'vector'
Product: gcc Reporter: Mathias Gaunard <mathias>
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Severity: normal CC: segher
Priority: P3    
Version: 4.6.0   
Target Milestone: ---   
Host: Target: powerpc*-*-*
Build: Known to work:
Known to fail: Last reconfirmed: 2011-12-22 00:00:00

Description Mathias Gaunard 2011-12-22 15:11:04 UTC
The following C++ code

template<class T>
struct test
    typedef T::vector vector;

when preprocessed using the following command
g++ -maltivec -E test.cpp

generates the following output:

template<class T>
struct test
    typedef T::vector;

Expected output should be the file unchanged.

In particular, this prevents from using significant parts of the Boost C++ libraries with AltiVec enabled.

I'm not sure which is the best place to affect this bug (c++, preprocessor, target), feel free to move it.
Affecting to target because it seems similar to bug #39558.
Comment 1 Mathias Gaunard 2011-12-22 15:16:18 UTC
Excuse the typo, the above code should have been

template<class T>
struct test
    typedef typename T::vector vector;

to be valid C++ code.

The " vector" bit is incorrectly removed in both cases though.
Comment 2 Jonathan Wakely 2011-12-22 15:36:34 UTC
you haven't said what version you're using

Comment 3 Mathias Gaunard 2011-12-22 15:54:20 UTC
The workarounds
#undef vector
compiling with -Dvector=vector
seem to work.

But shouldn't this not be necessary when altivec.h is not included?
Comment 4 Andrew Pinski 2011-12-22 18:43:37 UTC
Can you provide the output of "gcc -v"?
Comment 5 Mathias Gaunard 2011-12-22 18:48:36 UTC
gaunard@emeria:~$ g++-4.6 -v
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6-20101220-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --enable-secureplt --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu
Thread model: posix
gcc version 4.6.0 20101220 (experimental) [trunk revision 168097] (Ubuntu/Linaro 4.6-20101220-1)
Comment 6 Mathias Winkel 2013-06-20 14:36:17 UTC
Unfortunately, the way the altivec extensions are defined still poses some issues when using the latest GNU C Preprocessor. The configure flags for my GCC are given below.
We are using the cpp to preprocess some of our Fortran code that makes heavy use of variadic parameter macros etc.
In one of our source files, there is a Fortran comment "! Separation vector". Here, the cpp recognizes 'vector' as a predefined macro (apparently with missing parameters, compare http://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built_002din-Functions.html) and inserts a number of empty lines that prevent to Fortran code from being compileable. 

A reduced test example is:

XXX@juqueen1:~/gcc-test/pepc $ cat testbla
! separation vector
// separation vector

! separation vector int a
// separation vector int a

XXX@juqueen1:~/gcc-test/pepc $ cpp -P -C testbla 
! separation
// separation vector
! separation vector int a
// separation vector int a

Interestingly, nothing happens for 'vector int a', i.e. with trailing arguments or in C++ comments.
One solution is to explicitly undefine 'vector':

XXX@juqueen1:~/gcc-test/pepc $ cpp -P -C -Uvector testbla 
! separation vector
// separation vector
! separation vector int a
// separation vector int a

However, it would be more desireable of the code was just left unchanged of the 'vector ...' pattern is not matched or if it is found behind the exclamation mark that introduces Fortran comments.

GCC configure options:

XXX@juqueen1:~/gcc-test $ cpp -v       
Using built-in specs.
Target: powerpc64-bgq-linux
Configured with: ../gcc_source/configure --disable-bootstrap --prefix=/bgsys/local/gcc/4.9 --program-suffix= --program-prefix= --enable-lto --disable-checking --enable-shared --enable-threads=posix --target=powerpc64-bgq-linux --host=powerpc64-linux-gnu --build=powerpc64-linux-gnu --enable-secureplt --disable-libmudflap --disable-libspp --enable-languages=c,c++,fortran,lto --disable-multilib --with-long-double-128 --with-headers=/bgsys/drivers/ppcfloor//gnu-linux/powerpc64-bgq-linux//sys-include --with-libs=/bgsys/drivers/ppcfloor//gnu-linux/powerpc64-bgq-linux//lib --with-bin=/bgsys/drivers/ppcfloor//gnu-linux/powerpc64-bgq-linux//bin --with-sbin=/bgsys/drivers/ppcfloor//gnu-linux/powerpc64-bgq-linux//sbin : (reconfigured) ../gcc_source/configure --disable-bootstrap --prefix=/bgsys/local/gcc/4.9 --program-suffix= --program-prefix= --enable-lto --disable-checking --enable-shared --enable-threads=posix --target=powerpc64-bgq-linux --host=powerpc64-linux-gnu --build=powerpc64-linux-gnu --enable-secureplt --disable-libmudflap --disable-libspp --enable-languages=c,c++,fortran,lto --disable-multilib --with-long-double-128 --with-headers=/bgsys/drivers/ppcfloor//gnu-linux/powerpc64-bgq-linux//sys-include --with-libs=/bgsys/drivers/ppcfloor//gnu-linux/powerpc64-bgq-linux//lib --with-bin=/bgsys/drivers/ppcfloor//gnu-linux/powerpc64-bgq-linux//bin --with-sbin=/bgsys/drivers/ppcfloor//gnu-linux/powerpc64-bgq-linux//sbin
Thread model: posix
gcc version 4.9.0 20130620 (experimental) (GCC)
Comment 7 Segher Boessenkool 2019-06-04 19:25:56 UTC
Is this still an issue?
Comment 8 Mathias Gaunard 2019-06-05 05:41:18 UTC
Works with 8.3, was apparently fixed at some point.