"error: template with C linkage" within nested include

Bug #1710838 reported by Torsten Robitzki on 2017-08-15
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU ARM Embedded Toolchain
Undecided
Unassigned

Bug Description

I have a situation, where a cpp-file includes a header and that header includes <utility>. This results in arm-none-eabi-g++ complaining about a „template with C linkage“ when it sees the first template declaration in stl_relops.h, which is included by <utility>. When I directly include <utility> from the cpp-file, this error is not reported. The „template with C linkage“ is even reported, when the included header contains nothing (but include guards).

For me, the problem is easily reproducible by the short attached output of the preprocessor:

$ arm-none-eabi-g++ t.cpp -x c++ -std=c++14 -fmax-errors=1
In file included from /usr/local/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/c++/6.3.1/utility:69:0,
                 from /Users/todi/bluetoe/bluetoe/options.hpp:4,
                 from /Users/todi/blueswd_firmware/source/firmware/bootloader.cpp:1:
/usr/local/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/c++/6.3.1/bits/stl_relops.h:85:5: error: template with C linkage
     template <class _Tp>
     ^~~~~~~~

If line 6 and 10 are removed or if the nesting information in both lines are shortened by one, the error is not reported.

I would expect the attached code to compile without error (and to fail at the linking stage).

The compiler spec:

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-arm-none-eabi-6-2017-q1-update/bin/../lib/gcc/arm-none-eabi/6.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: /tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/src/gcc/configure --target=arm-none-eabi --prefix=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native --libexecdir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/lib --infodir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/arm-none-eabi --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --with-gmp=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-mpfr=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-mpc=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-isl=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-libelf=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-lstdc++ -lm' --with-pkgversion='GNU Tools for ARM Embedded Processors 6-2017-q1-update' --with-multilib-list=rmprofile
Thread model: single
gcc version 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512] (GNU Tools for ARM Embedded Processors 6-2017-q1-update)

Running on macOS Sierra 10.12.6

I see the same error when using 4_8-2014q2 or gcc-arm-none-eabi-6-2017-q2-update

And the overall example can be reduced to:

# 1 "t.hpp" 1 3 4

template < class T >
int foo();

Now, I realized that this problem goes away, when I do not use "-isystem" switch to pass the include path for the included header to the compiler (but the normal -I switch).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments