[Bug preprocessor/63662] New: __has_include defined but not implemented

[Bug preprocessor/63662] New: __has_include defined but not implemented

[andre.mccurdy at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662

            Bug ID: 63662
           Summary: __has_include defined but not implemented
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andre.mccurdy at linaro dot org

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

[Bug preprocessor/63662] __has_include defined but not implemented

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
4.9 does not have __has_include, only 5.  Linaro must have backported the patch
for it.

[Bug preprocessor/63662] __has_include defined but not implemented

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I bet you need -std=c++1y .  And also this feature is not fully there for GCC
4.9.

[Bug preprocessor/63662] __has_include is not implemented but it is defined, so "#ifdef __has_include" guards are ineffective in blocking usage of __has_include

[andre.mccurdy at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662

andre.mccurdy at linaro dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|__has_include defined but   |__has_include is not
                   |not implemented             |implemented but it is
                   |                            |defined, so "#ifdef
                   |                            |__has_include" guards are
                   |                            |ineffective in blocking
                   |                            |usage of __has_include

--- Comment #3 from andre.mccurdy at linaro dot org ---
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.

[Bug preprocessor/63662] __has_include is not implemented but it is defined, so "#ifdef __has_include" guards are ineffective in blocking usage of __has_include

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
> gcc-4.9 -c tst.c
>

works for me.  Also works on trunk for me.

[Bug preprocessor/63662] __has_include is not implemented but it is defined, so "#ifdef __has_include" guards are ineffective in blocking usage of __has_include

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[Bug preprocessor/63662] __has_include is not implemented but it is defined, so "#ifdef __has_include" guards are ineffective in blocking usage of __has_include

[andre.mccurdy at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662

--- Comment #6 from andre.mccurdy at linaro dot org ---
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.