clang 4.0.0 using gcc 7.1.1 build error with -std=c++1z

[TrueBers]

Not sure whether it's a clang's upstream bug or the lib's one, but anyway it doesn't build.

Sysinfo

System: ArchLinux CURRENT

$ clang++ -v

clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/7.1.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/7.1.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

$ gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 7.1.1 20170528 (GCC) 

Test code

// test.cpp
#include <tao/pegtl.hpp>

int main() {
  return 0;
}

Compilers results

-std=	g++	clang++
c++11	✅	✅
c++14	✅	✅
c++1z	✅	❌
c++17	✅	(N/A)

Output

clang++ -std=c++1z test.cpp:

In file included from test.cpp:1:
In file included from PEGTL/include/tao/pegtl.hpp:10:
In file included from PEGTL/include/tao/pegtl/ascii.hpp:8:
In file included from PEGTL/include/tao/pegtl/eol.hpp:28:
In file included from PEGTL/include/tao/pegtl/internal/eol.hpp:11:
In file included from PEGTL/include/tao/pegtl/internal/../analysis/generic.hpp:9:
In file included from PEGTL/include/tao/pegtl/internal/../analysis/grammar_info.hpp:7:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/map:60:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/bits/stl_tree.h:72:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/bits/node_handle.h:39:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/optional:1032:27: error: use of class template 'optional' requires template arguments
  template <typename _Tp> optional(_Tp) -> optional<_Tp>;
                          ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/optional:451:11: note: template is declared here
    class optional
          ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/optional:1032:40: error: expected ';' at end of declaration
  template <typename _Tp> optional(_Tp) -> optional<_Tp>;
                                       ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/optional:1032:41: error: cannot use arrow operator on a type
  template <typename _Tp> optional(_Tp) -> optional<_Tp>;
                                        ^
3 errors generated.

[ColinH]

Just to be sure, does it compile with #include <map> instead of including the PEGTL?

[TrueBers]

Hell, you are right. Got the same error.

Found this as well. It seems there is a problem with <optional> header at upstream, but since 21st of May nobody has assigned to this bug.

So dumb am I haven't checked it initially.

[ColinH]

No problem, just glad that we found it quickly. Or at least we found that it isn't an issue in the PEGTL. Assuming your agreement I'll close this issue for now...

[d-frey]

FWIW, I just added GCC 7 automated testing to our .travis.yml. So at least stock GCC 7 is covered, as is Clang 4.0 with an older libstdc++. This will, of course, not solve the problem you encountered, but I'm afraid there is not much we can do about it anyways.