Issue seen with Linaro GCC 4.9-2014.10, but believed to also be present in upstream gcc 4.9.x $ i586-rdk-linux-gcc -v Using built-in specs. COLLECT_GCC=i586-rdk-linux-gcc COLLECT_LTO_WRAPPER=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/libexec/i586-rdk-linux/gcc/i586-rdk-linux/4.9.2/lto-wrapper Target: i586-rdk-linux Configured with: /home/andre/rdk/rdk-master/build-qemux86/tmp/work-shared/gcc-linaro-4.9-r2014.10/gcc-linaro-4.9-2014.10/configure --build=x86_64-linux --host=x86_64-linux --target=i586-rdk-linux --prefix=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr --exec_prefix=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr --bindir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/bin/i586-rdk-linux --sbindir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/bin/i586-rdk-linux --libexecdir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/libexec/i586-rdk-linux --datadir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/share --sysconfdir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/etc --sharedstatedir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/com --localstatedir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/var --libdir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/lib/i586-rdk-linux --includedir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/include --oldincludedir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/include --infodir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/share/info --mandir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=i586-rdk-linux- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-gxx-include-dir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/qemux86/usr/include/c++/4.9.2 --with-sysroot=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/qemux86 --with-build-sysroot=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/qemux86 --enable-targets=all --enable-poison-system-directories --with-mpfr=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr --with-system-zlib --disable-nls --enable-__cxa_atexit Thread model: posix gcc version 4.9.2 20141013 (prerelease) (Linaro GCC 4.9-2014.10) Issue originally seen when building Qt 5.4 alpha1, which includes references to __has_include such as: https://qt.gitorious.org/qt/qtbase/source/8e512fbe0b0f99d80d0cf60cd6187a9a9a5a3eb9:src/corelib/global/qlogging.cpp#L77 Minimal testcase: $ cat tst.c #ifdef __has_include # if __has_include(<stdio.h>) # include <stdio.h> # endif #endif $ i586-rdk-linux-gcc -c tst.c tst.c:2:7: error: missing binary operator before token "(" # if __has_include(<stdio.h>) ^ Related gcc-4_9-branch check-in ( SVN r215998 ): https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=215998
4.9 does not have __has_include, only 5. Linaro must have backported the patch for it.
I bet you need -std=c++1y . And also this feature is not fully there for GCC 4.9.
Thanks. I have updated the original summary since it was unclear: The bug is not that the __has_include feature can't be used in 4.9.x. The bug is that __has_include is defined in gcc-4_9-branch, which causes "#ifdef __has_include" be ineffective as a guard to prevent attempts to use the __has_include feature.
> gcc-4.9 -c tst.c > works for me. Also works on trunk for me.
Are you sure you've built your compiler properly. I've indeed reproduced this in my 4.9 tree, but only because I've only done make in the gcc subdir after updating to latest 4.9 branch and not in libcpp first. So, it sounds like you have the same case, compiler that predefines __has_include, but libcpp that doesn't handle it.
The issue seems to be specific to Linaro 4.9-2014.10. There's now a Linaro 4.9-2014.10-1 release which merges the missing updates to libcpp.