Intel compiler and 'using' for importing constructors

Simone_L_ · ‎02-12-2017

#include <vector>
struct A : public std::vector<double>
{ using std::vector<double>::vector; };

compiles fine with g++ and clang, but the Intel compiler [icpc (ICC) 17.0.0 20160720] gives me (with flag -std=c++11)

error: function template "A::A(_ForwardIterator, _ForwardIterator, const std::__1::allocator &)" already inherited from "std::__1::vector>"

at the using directive. Any ideas why this is happening and/or how to solve it?
Should I just start suspecting an icpc bug or just blame my poor coding skills?
I'd appreciate any help, thanks!

Judith_W_Intel · ‎02-13-2017

Hi Simone,

They're called "inherited" not "imported" constructors.

I can't reproduce the error you are seeing. Can you do the following:

(1) uname -a

(2) gcc -v

(3) icc -v

and cut and paste the results here?

This is what I see - it's possible that there was a bug that has been fixed.

sptel15-162> icc -v
icc version 17.0.2 Beta (gcc version 6.3.0 compatibility)
sptel15-163> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/6.3.0/rhel60/efi2/bin/../libexec/gcc/x86_64-linux-gnu/6.3.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-6.3.0/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --enable-bootstrap --enable-__cxa_atexit --enable-threads=posix --prefix=/home/cmplr/bata/ref/gcc/6.3.0/rhel60/efi2 --with-gmp=/home/cmplr/bata/comp/ia32e/gmp-5.1.3 --with-mpfr=/home/cmplr/bata/comp/ia32e/mpfr-3.1.2 --with-mpc=/home/cmplr/bata/comp/ia32e/mpc-1.0.2 --enable-languages=c,c++,objc,fortran
Thread model: posix
gcc version 6.3.0 (GCC)
sptel15-164> cat t.cpp

#include <vector>

struct A : public std::vector<double>
{ using std::vector<double>::vector; };
sptel15-165> icpc -std=c++11 -c t.cpp
sptel15-166>

thanks

Judy

SergeyKostrov · ‎02-13-2017

>>Any ideas why this is happening and/or how to solve it? >>Should I just start suspecting an icpc bug or just blame my poor coding skills? I also couldn't reproduce the problem with two versions of Intel C++ compiler ( 16.x and 17.x ). More technical details in two next posts.

SergeyKostrov · ‎02-13-2017

[ Verifications with Intel C++ compiler 16.0.3 ] [guest@... WorkTest]$ uname -a Linux ... 3.10.0-327.13.1.el7.xppsl_1.4.0.3211.x86_64 #1 SMP Fri Jul 8 11:44:24 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [guest@... WorkTest]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) [guest@... WorkTest]$ icpc -v icpc version 16.0.3 (gcc version 4.8.5 compatibility) [guest@... WorkTest]$ icc -v icc version 16.0.3 (gcc version 4.8.5 compatibility) [guest@... WorkTest]$ icpc -std=c++11 test01.c C++ Language Standard version: 201103L Intel C++ compiler Build Date: 20160415 [ Summary ] Compiled without any problems.

SergeyKostrov · ‎02-13-2017

[ Verifications with Intel C++ compiler 17.0.1 ] ubuntu@ubuntu-vm:~$ uname -a Linux ubuntu-vm 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux ubuntu@ubuntu-vm:~$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.1-14ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) ubuntu@ubuntu-vm:~$ icpc -v icpc version 17.0.1 (gcc version 5.0.0 compatibility) ubuntu@ubuntu-vm:~$ icc -v icc version 17.0.1 (gcc version 5.0.0 compatibility) ubuntu@ubuntu-vm:~/WorkTest$ icpc -std=c++11 test01.c C++ Language Standard version: 201103L Intel C++ compiler Build Date: 20161005 [ Summary ] Compiled without any problems.

SergeyKostrov · ‎02-13-2017

>>...Should I just start suspecting an icpc bug As you can see something else on your side is wrong. >>This is what I see - it's possible that there was a bug that has been fixed. >> >>sptel15-162> icc -v >>icc version 17.0.2 Beta (gcc version 6.3.0 compatibility) So, successful verifications are done for 3 versions of Intel C++ compiler: 16.0.3 17.0.1 17.0.2 Beta

SergeyKostrov · ‎02-13-2017

Here is a verification with a 4-year-old Intel C++ compiler version 13.x: C:\WorkEnv\XeonPhiWork\WorkTest>icl.exe Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.0.149 Build 20130118 Copyright (C) 1985-2013 Intel Corporation. All rights reserved. C:\WorkEnv\XeonPhiWork\WorkTest>icl.exe /Qstd=c++11 -c test01.cpp Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.0.149 Build 20130118 Copyright (C) 1985-2013 Intel Corporation. All rights reserved. test01.cpp test01.cpp(26): warning #1140: a using-declaration may not name a constructor or destructor using std::vector< double >::vector; ^ C++ Language Standard version: 199711L Intel C++ compiler Build Date: 20130118

SergeyKostrov · ‎02-13-2017

Here is last thing: >>... >>error: function template "A::A(_ForwardIterator, _ForwardIterator, const std::__1::allocator &)" already inherited from "std::__1::vector>" >>... Intel C++ compiler always reports an error number in case of a compilation problem and the error output above doesn't have it.

Simone_L_ · ‎02-13-2017

Thank you all for your replies.

(1) uname -a
Darwin dhcp-192-033-100-233 15.6.0 Darwin Kernel Version 15.6.0: Mon Jan 9 23:07:29 PST 2017; root:xnu-3248.60.11.2.1~1/RELEASE_X86_64 x86_64

(2) gcc -v
Target: x86_64-apple-darwin15.6.0
Configured with: ../configure --build=x86_64-apple-darwin15.6.0 --prefix=/usr/local/Cellar/gcc/6.3.0_1 --libdir=/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-6 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --with-build-config=bootstrap-debug --disable-werror --with-pkgversion='Homebrew GCC 6.3.0_1' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-plugin --disable-nls --enable-multilib
Thread model: posix
gcc version 6.3.0 (Homebrew GCC 6.3.0_1)

(3) icc -v
icc version 17.0.0 (gcc version 4.9.0 compatibility)

(4) clang -v
Apple LLVM version 7.3.0 (clang-703.0.29)
Target: x86_64-apple-darwin15.6.0
Thread model: posix

As you can see, I omitted I'm on OS X - couldn't see why this would be relevant at first, but now I'm starting to suspect it.

Thanks again for looking into this!

Simone_L_ · ‎02-13-2017

Just to be complete:

$ g++-6 -std=c++11 -c try.cpp -o try.o
$ clang -std=c++11 -c try.cpp -o try.o
$ icc -std=c++11 -c try.cpp -o try.o

try.cpp(3): error: function template "A::A(_ForwardIterator, _ForwardIterator, const std::__1::allocator<double> &)" already inherited from "std::__1::vector<double, std::__1::allocator<double>>"
{ using std::vector<double>::vector; };
^

compilation aborted for try.cpp (code 2)

SergeyKostrov · ‎02-13-2017

Could you upload try.cpp file? As you can see a set of verifications was completed for Intel C++ compiler installed on: - Linux Ubuntu - OK - Linux Red Hat - OK - Windows 7 - OK - OS X - Failed to compile >>As you can see, I omitted I'm on OS X - couldn't see why this would be relevant at first, but now I'm starting to suspect it. It is possible that a version of Intel C++ compiler for OS X has some issue and it needs to be verified.

Simone_L_ · ‎02-13-2017

Dear Sergey,

I literally copy-pasted the three lines of code above, and that's it.
[I had actually deleted the old minimal working example =)]

If you still insist, I can upload it.

By the way, I also have access to a cluster running Linux (CentOS) with different icc versions:
icc -std=c++11 -c try.cpp
*compiles* with icc 15.0.3 and 16.0.1
while with 14.0.1 or 14.0.5 I get:
try.cpp(3): error #1140: a using-declaration may not name a constructor or destructor

Best,
S.

SergeyKostrov · ‎02-13-2017

>>...I literally copy-pasted the three lines of code above, and that's it. I simply wanted to verify that nothing else is in the try.cpp file. Thanks.

Judith_W_Intel · ‎02-15-2017

I was able to reproduce the problem on MacOS (their version of the <vector> class is needed to see the error).

Below is a reduced example. The problem seems to be that the compiler doesn't recognize that these two overloads are distinct because they only differ in the value of the default argument (which is used for SFINAE). Clang and Windows accept the code below, but both GNU and Interl give a spurious error. I have entered this defect in our bug tracking database as DPD200417938. Thanks for reporting it.

Judy

// clang and MSVC++ 2015 accept this, icpc and icl do not
template <bool, class _Tp = void>
struct enable_if {
typedef int type;
};

template <class _Tp>
struct enable_if<true, _Tp> {typedef char type;};

struct C
{
template <class T> C(T, typename enable_if<!T::value>::type* = 0);
template <class T> C(T, typename enable_if<T::value>::type* = 0);
};

struct A : public C
{
using C::C;
};

Simone_L_ · ‎02-15-2017

Thanks for your insight Judy.
I appreciate your help.
Can the bug database be seen by users to check progress status?

Judith_W_Intel · ‎02-15-2017

No sorry this is an internal bugs database. If you would like to enter a ticket via Intel Premier support and tell them about the number then you could monitor the status that way.

Judy

SergeyKostrov · ‎02-15-2017

>>...By the way, I also have access to a cluster running Linux (CentOS) with different icc versions... Simply to let you know that all compilations of your test on Linux Ubuntu and RHEL done with Intel Parallel Studio XE 2017 Cluster Edition Update 1 for Linux.

Spacetracker · ‎02-03-2022

It is 2022 and I am getting this error still:

MacOS 11.6.3 Big Sur

$ icpc --version

icpc (ICC) 2021.5.0 20211109

error: function template "vtkFoamPtrList<T>::vtkFoamPtrList(_ForwardIterator, _ForwardIterator, const std::__1::allocator<vtkFoamEntryValue *> &) [with T=vtkFoamEntryValue]" already inherited from "std::__1::vector<vtkFoamEntryValue *, std::__1::allocator<vtkFoamEntryValue *>>"

using std::vector<T*>::vector;

^

As this is the most recent compiler, what is the fix or code change to get past this error? This code builds with the default Clang compiler.

Thanks