internal error: assertion failed

[Jose_M_2]

I just installed the Intel c++ compiler in linux and tried to compile our application. It starts the compilation ok, successfully compiling several of the source files until it reaches a point where it throws this weird error:

/usr/include/c++/6.2.1/bits/stl_uninitialized.h(573): internal error: assertion failed at: "shared/cfe/edgcpfe/types.c", line 2409

        return __uninitialized_default_n_1<__is_trivial(_ValueType)
                                                        ^

compilation aborted for /home/jose/src/simulator/shwfs_init.cpp (code 4)

I have no idea what this means. The error does not seem to relate to our code at all. Btw, the code works fine with gcc.

$ icpc -v
icpc version 17.0.0 (gcc version 6.2.1 compatibility)

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.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 6.2.1 20160830 (GCC)

[Judith_W_Intel]

This means you've triggered an assertion in the compiler itself (i.e. a compiler bug).

In order to fix it and perhaps provide you with more information such as a workaround we need to be able to reproduce it.

Please provide us with a preprocessed file (attach it to a note). You can create one by adding the -P or the -E options to your command line.

thanks!

Judy

[Jose_M_2]

Find attached the output using icpc -E.

This is the actual command I used to generate the output:

/opt/intel/composerxe/linux/bin/intel64/icpc   -DARMA_DONT_USE_WRAPPER -DARMA_NO_DEBUG -DARMA_USE_HDF5 -DPYTHONLIBS_FOUND -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -I/home/jose/src/simulator/build -I/home/jose/src/simulator -I/usr/local/include/kaos -isystem /usr/include/qt -isystem /usr/include/qt/QtWidgets -isystem /usr/include/qt/QtGui -isystem /usr/include/qt/QtCore -isystem /usr/lib/qt/mkspecs/linux-g++ -isystem /usr/include/qt/QtNetwork -I/usr/include/python3.5m  -mtune=corei7 -Wall -std=c++11 -O2 -g -std=c++11   -fPIC  -c /home/jose/src/simulator/shwfs_init.cpp -E > out_icpc-E.txt

[Jose_M_2]

I was able to narrow down the problem to a simple demo case. I can reproduce the bug with this code:

#include <atomic>
#include <vector>

void main()
{
    std::vector<std::atomic_int> var(2);
}

I compile it with: icpc -o demo -c demo.cpp

And get this error:

/usr/include/c++/6.2.1/bits/stl_uninitialized.h(573): internal error: assertion failed at: "shared/cfe/edgcpfe/types.c", line 2409

        return __uninitialized_default_n_1<__is_trivial(_ValueType)
                                                        ^

compilation aborted for demo.cpp (code 4)

I attach the output of icpc -E from this code.

[SergeyKostrov]

For consistency, here is a block of template C++ codes where Intel C++ compiler fails: [ stl_uninitialized.h ] ... // __uninitialized_default_n // Fills [first, first + n) with n default constructed value_type(s). template inline _ForwardIterator __uninitialized_default_n(_ForwardIterator __first, _Size __n) { typedef typename iterator_traits<_ForwardIterator>::value_type _ValueType; // trivial types can have deleted assignment const bool __assignable = is_copy_assignable<_ValueType>::value; return __uninitialized_default_n_1< __is_trivial( _ValueType ) && __assignable >::__uninit_default_n(__first, __n); } ... Do you see how that C++ code looks like where Intel C++ compiler fails?

[SergeyKostrov]

C++ template codes from the previous Post #5 are from MinGW C++ compiler version 6.1.0 I've recently upgraded to.

[Judith_W_Intel]

Thanks for the reproducer. I have submitted DPD200414459 in our internal bugs database to fix the defect.

The problem is shown in this small example which uses the __is_trivial type trait:

struct base {};

struct derived : base
{
  using base::operator=;
};

void foo()
{
  __is_trivial(derived);
}

Our compiler is asserting inside the routine that is iterating over all the routines inside the class for which the __is_trivial type trait is called and it thinks that the only possible symbol is a member function symbol. In the case of the atomic struct there is a symbol which is an inherited member function symbol (what our compiler calls a projection symbol).

Anyhow, the good news is I think the fix is very simple (just modify the assertion). The bad news is I can't think of an easy workaround except possibly to add this #define before including the <vector> and <atomic> headers:

#define __is_trivial(type)  __has_trivial_constructor(type) && __has_trivial_copy(type)

Sorry for the trouble and I hope this helps...

Judy

[SergeyKostrov]

>>...Anyhow, the good news is I think the fix is very simple ( just modify the assertion ).... Judith, What do you mean? I think you need to specify it more clearly or to provide instructions for Jose. A message in the 1st post: ... ...internal error: assertion failed at: "shared/cfe/edgcpfe/types.c", line 2409 ... shows that this is a result of an accert inside of Intel C++ compiler C codes and this is Not an accert in user's source codes. Even if Jose declares its own macro, like C_ASSERT, or so, its scope is still user's source codes, Not Intel's C++ compiler.

[Jose_M_2]

I just did some testing and the suggested workaround seems to work. The code compiles and runs happily.

Any idea when a fix will be released?

Thanks.

[Judith_W_Intel]

Sergey,

Yes I realize the assertion is in the compiler. I work on the front end of the compiler so I was explaining what was triggering it and that the compiler fix is going to be fairly simple. I also provided a workaround so that his code would not trigger the compiler bug.

Jose,

It should be fixed in the next 17.0 update (17.0 update 1). I'm not sure when that will actually hit the streets but the code freeze is the end of September. Happy to hear you have an acceptable workaround until then...

Judy

[Bernard]

For me it looks like ICC failed to recodnized  typename :  iterator_traits<_ForwardIterator>::value_type which declared as typedef _ValueType.

[Jose_M_2]

For the record I'd like to confirm that this bug seems to be fixed in newest update (17.0.1).

The bug does not occur with version:

$ icpc -v
icpc version 17.0.1 (gcc version 6.2.1 compatibility)